Настройка Kerberos аутентификации с SSO на веб-сервере Apache с помощью SSSD

В прошлой заметке был рассмотрен пример простейшего ограничения доступа к веб-серверу 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-соединений.

 

Дополнительные источники информации:

Всего комментариев: 2 Комментировать

  1. Обратная ссылка: Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM | Блог IT-KB /

  2. Павел /

    Настроил оба типа авторизации, работает, спасибо (правда не сразу, неочевидностей хватает). Не работает вход по паролю, в случае с включенной AuthType GSSAPI. Т.е. прозрачная авторизация работает, но если она недоступна, вываливается форма логин/пароль (но не такая, как при включенной PAM, а более простая. Авторизация не проходит, а в логе видно следующее: GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [An unsupported mechanism was requested (Unknown error). При этом GssapiBasicAuth On параметр на поведение не влияет. Не могу нагуглить, как включить этот "механизм".

Добавить комментарий