В прошлой заметке был рассмотрен пример простейшего ограничения доступа к веб-серверу Apache с применением незащищённой Basic-аутентификации и использованием учётных данных из файла. Разумеется такой режим аутентификации нельзя считать безопасным и поэтому в данной заметке мы рассмотрим пример настройки Kerberos-аутентификации и авторизации на веб-сервере Apache c помощью службы SSSD (System Security Services Daemon).
Ранее уже рассматривался пример подобной настройки веб-сервера Apache, однако в том случае для поддержки Kerberos-аутентификации в систему устанавливался пакет krb5-workstation, а для авторизации использовался функционал интеграции oVirt с Active Directory. В этой заметке мы пойдём по несколько иному пути, так как для аутентификации пользователей в домене AD будем использовать модуль Apache mod_auth_gssapi, а для авторизации модуль - mod_authnz_pam, который будет использоваться в связке с SSSD. То есть получать доступ к веб-серверу смогут все те доменные пользователи, что уже имеют доступ на подключение к самому серверу. Такая конфигурация может быть проста в настройке и полезна в тех случаях, когда некоторому кругу администраторов Linux-сервера нужно предоставить возможность прозрачного подключения (Single sign-on) к веб-сайту того или иного сервиса, работающего на этом сервере, как в ранее рассмотренном случае с веб-консолью QUADStor.
Подключаем к веб-серверу модуль mod_authnz_pam
Посмотрим информацию о модуле mod_authnz_pam, который доступен нам в репозиториях CentOS Linux 7.2:
# yum info mod_authnz_pam
...
Available Packages
Name : mod_authnz_pam
Arch : x86_64
Version : 0.9.3
Release : 5.el7_2
Size : 14 k
Repo : updates/7/x86_64
Summary : PAM authorization checker and PAM Basic Authentication provider
URL : http://www.adelton.com/apache/mod_authnz_pam/
License : ASL 2.0
Description : mod_authnz_pam is a PAM authorization module, supplementing
: authentication done by other modules, for example mod_auth_kerb; it
: can also be used as full Basic Authentication provider which runs the
: [login, password] authentication through the PAM stack.
Как видим из описания, этот модуль позволит нам использовать PAM-авторизацию и PAM-аутентификацию (только Basic). В рамках нашей задачи интересна возможность именно PAM авторизации, хотя и пример настройки Basic-аутентификации мы рассмотрим тоже.
Итак, установим в систему модуль:
# yum install mod_authnz_pam
Так как настройка производиться на CentOS 7.2 с включённым SELinux, то нам потребуется разрешить взаимодействие веб-сервера Apache с модулем:
# setsebool -P allow_httpd_mod_auth_pam 1
Откроем на редактирование файл с директивой загрузки модуля:
# nano /etc/httpd/conf.modules.d/55-authnz_pam.conf
и раскомментируем в нём единственную строку, чтобы разрешить автоматическую загрузку нужной библиотеки в процессе запуска веб-сервера:
LoadModule authnz_pam_module modules/mod_authnz_pam.so
Перезапустим службу веб-сервера и убедимся в том, что модуль загружен:
# systemctl restart httpd # httpd -M | grep pam authnz_pam_module (shared)
Создаём службу PAM
Создадим в каталоге /etc/pam.d/ файл описания собственной службы PAM, которая для процедур аутентификации и авторизации будет вызывать библиотеку SSSD (имя файла используем то, которое нам удобно):
# nano /etc/pam.d/httpd-quadstor
Наполним файл содержимым (первая строка определяет вызов библиотеки SSSD для аутентификации, вторая строка – для авторизации):
auth required pam_sss.so account required pam_sss.so
Apache c Basic-аутентификацией и PAM авторизацией
Отредактируем конфигурационный файл веб-сервера Apache (по умолчанию /etc/httpd/conf/httpd.conf) и отредактируем в нём секцию, где описан доступ к нужному нам пути. В нашем примере настраивается ограничение доступа к каталогу с исполняемыми файлами веб-консоли QUADStor Storage Virtualization и соответствующая секция конфигурационного файла веб-сервера примет следующий вид:
<Directory "/var/www/cgi-bin"> AuthType Basic AuthName "QUADStor Private Area" AuthBasicProvider PAM AuthPAMService httpd-quadstor Require valid-user </Directory>
Здесь задана Basic-аутентификация через провайдер PAM с именем ранее созданной нами PAM службы httpd-quadstor. После внесённых изменений перезапустим службу веб-сервера:
# systemctl restart httpd
Теперь попытаемся с клиентского компьютера получить доступ к веб-консоли QUADStor и увидим соответствующий запрос на ввод учётных данных. Здесь введём учётные данные доменного пользователя, который имеет право на вход на наш Linux-сервер согласно настроенных ранее правил в конфигурации SSSD.
В момент отправки введённых учётных данных в логе безопасности на нашем Linux-сервере мы сможем отследить результат попытки аутентификации (в нашем примере он успешный):
# tail -f /var/log/secure ... Oct 24 13:54:52 KOM-AD01-FS03 httpd: pam_sss(httpd-quadstor:auth): authentication success; logname= uid=48 euid=48 tty= ruser= rhost=10.9.1.100 user=petya
Итак, Basic-аутентификация в паре с PAM авторизацией работает, и теперь разрешённые доменные пользователи уже могут использовать привычные им учётные данные для получения доступа к веб-ресурсу. Однако, повторюсь, что с точки зрения информационной безопасности, использовать такой режим аутентификации неправильно, и поэтому мы перейдём к настройке Kerberos-аутентификации.
Apache c Kerberos-аутентификацией и PAM авторизацией
Для работы Kerberos аутентификации в домене AD можно создать отдельную сервисную учётную запись, для которой в дальнейшем зарегистрировать servicePrincipalName (SPN) веб-сервера и сгенерировать keytab-файл, содержащий данную SPN-запись. Повторяться не буду, так как эта процедура пошагово рассмотрена в одной из прошлых заметок (см. пункт "Создание в домене AD сервисной учётной записи" и "Создание keytab-файла для сервисной учётной записи"). Предполагая, что необходимый keytab-файл у нас уже есть, размещаем его в доступном для службы веб-сервера месте и ограничиваем к нему доступ:
# chown apache /etc/httpd/s-FS03-HTTP-Krb.keytab # chmod 400 /etc/httpd/s-FS03-HTTP-Krb.keytab
Устанавливаем модули необходимые веб-серверу для поддержки Kerberos-аутентификации средствами GSSAPI:
# yum install mod_session mod_auth_gssapi
И меняем настроенную ранее на Basic-аутентификацию секцию конфигурационного файла веб-сервера /etc/httpd/conf/httpd.conf следующим образом:
<Directory "/var/www/cgi-bin">
AuthType GSSAPI
AuthName "QUADStor Private Area"
#GssapiBasicAuth On
GssapiCredStore keytab:/etc/httpd/s-FS03-HTTP-Krb.keytab
GssapiUseSessions On
Session On
SessionCookieName quadstor_web_gssapi_session path=/private;httponly;secure;
Require pam-account httpd-quadstor
</Directory>
Как видно здесь уже используется аутентификация GSSAPI c ранее приготовленным keytab-файлом и вызовом ранее созданной PAM службы httpd-quadstor для авторизации пользователей. Обратите внимание на то, что параметр GssapiBasicAuth закомментирован, так как его включение меняет поведение веб-сервера таким образом, что при попытке неудачной прозрачной Kerberos-аутентификации пользователю будет показано окно с запросом на ввод учётных данных. Из некоторых соображений безопасности можно оставить этот параметр в значении по умолчанию, чтобы пользователю не выводилось никаких запросов после неудачной аутентификации.
Опять же, после внесённых изменений перезапустим службу веб-сервера:
# systemctl restart httpd
Теперь попытаемся с клиентского компьютера получить доступ к веб-консоли QUADStor и процедура аутентификации и авторизации должна пройти для пользователя прозрачно без каких либо запросов на ввод учётных данных.
Защита соединений с веб-сервером с помощью SSL-сертификата
В случае если вы решите использовать PAM авторизацию с Basic-аутентификацией, то в целях обеспечения нормального уровня безопасности HTTP-соединений клиентов с веб-сервером, нужно будет включить в конфигурации веб-сервера поддержку SSL. И даже если вы решите использовать Kerberos-аутентификацию, которая имеет свои собственные механизмы защиты, всё равно более правильным будет дополнительное усиление защиты HTTP-соединений с помощью SSL.
Для этого нам потребуется сделать пару несложных вещей – установить модуль веб-сервера для поддержки SSL (mod_ssl) и сгенерировать SSL-сертификат веб-сервера, который в последствии в паре с закрытым ключом от этого сертификата нужно будет привязать к конфигурации веб-сервера.
Устанавливаем модуль веб-сервера:
# yum install mod_ssl
По поводу генерации закрытого ключа и сертификата веб-сервера я повторяться не буду, так как подобная процедура рассматривалась ранее, например в заметке Установка сертификата от Windows Server CA на веб-сервер Apache. Предполагая, что у нас уже есть на руках готовые файлы ключа и сертификата в формате PEM размещаем их на нашем Linux-сервере в каталогах /etc/pki/tls/private/ и /etc/pki/tls/certs/ соответственно.
Чтобы привязать файлы ключа и сертификата к конфигурации веб-сервера, отредактируем конфигурационный файл, который появился в системе после установки модуля mod_ssl
# nano /etc/httpd/conf.d/ssl.conf
В этом файле, как минимум, нам нужно изменить два параметра, указав соответствующие файлы сертификата и его ключа:
... SSLCertificateFile "/etc/pki/tls/certs/FS03-HTTPS.pem" SSLCertificateKeyFile "/etc/pki/tls/private/FS03-HTTPS.key" ...
Дополнительно в основной конфигурационный файл веб-сервера /etc/httpd/conf/httpd.conf можно внести директиву обязательного редиректа всех клиентских соединений на HTTPS, например, добавив секцию описания виртуального хоста:
... <VirtualHost *:80> Redirect permanent "/" "https://kom-ad01-fs03.ad.holding.com/" </VirtualHost> ...
В качестве последнего штриха можно внести дополнительные параметры в секцию описывающую доступ к каталогу веб-сервера, включив обязательное использование SSL, например:
<Directory "/var/www/cgi-bin">
SSLRequireSSL
AuthType GSSAPI
AuthName "QUADStor Private Area"
#GssapiBasicAuth On
GssapiSSLonly On
GssapiCredStore keytab:/etc/httpd/s-FS03-HTTP-Krb.keytab
GssapiUseSessions On
Session On
SessionCookieName quadstor_web_gssapi_session path=/private;httponly;secure;
Require pam-account httpd-quadstor
</Directory>
После всех проделанных изменений перезапустим службу веб-сервера:
# systemctl restart httpd
Теперь наш веб-сайт Apache имеет не только возможность безопасной и удобной аутентификации и авторизации доменных пользователей AD, но и имеет защиту всех HTTP-соединений.
Дополнительные источники информации:
RSS - Записи
Обратная ссылка: Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM | Блог IT-KB /
Настроил оба типа авторизации, работает, спасибо (правда не сразу, неочевидностей хватает). Не работает вход по паролю, в случае с включенной AuthType GSSAPI. Т.е. прозрачная авторизация работает, но если она недоступна, вываливается форма логин/пароль (но не такая, как при включенной PAM, а более простая. Авторизация не проходит, а в логе видно следующее: GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [An unsupported mechanism was requested (Unknown error). При этом GssapiBasicAuth On параметр на поведение не влияет. Не могу нагуглить, как включить этот "механизм".