Введение
Для настройки функций доменной авторизации и SSO для входа в систему централизованного управления необходимо выполнить ряд действий:
- Настроить веб-сервер (ngnix или apache) на поддержку аутентификации HTTP Negotiate.
- Выполнить соответствующие настройки на стороне домена: создать SPN, ServiceUser.
- Сгенерировать keytab-файл.
- Выполнить настройку используемого браузера.
Для получения дополнительной информации по процессу аутентификации Kerberos, типам шифрования, конфигурации Kerberos, настройке оповещателей и т.д. см. документ Аутентификация Kerberos.
Настройка веб-сервера
Для настройки AD-аутентификации для apache рекомендуем ознакомиться с подробными материалами в сети Интернет ([1], [2]).
Далее приводится подробное описание процесса подготовки и настройки веб-сервера ngnix и всей системы в целом.
В базовой поставке nginx функционал AD-аутентификации отсутствует. Для добавления данного функционала рекомендуется использовать модуль SPNEGO. Таким образом, для начала необходимо собрать nginx с нужным нам модулем. Для этого выполните следующее:
Выполните установку nginx.
apt-get install nginx -V
Скачайте последнюю версию исходников веб-сервера с официального сайта.
wget http://nginx.org/download/nginx-1.17.1.tar.gz
Распакуйте папку с исходниками веб-сервера и поместите туда исходники модуля spnego-http-auth-nginx-module следующим образом:
tar xvzf nginx-1.17.1.tar.gz cd nginx-1.17.1 git clone https://github.com/stnoonan/spnego-http-auth-nginx-module
Выполните команду просмотра текущей версии ngnix. На экране появится список опций сборки ngnix из базовой поставки:
# nginx -V nginx version: nginx/1.12.2 built by gcc 4.9.2 (Debian 4.9.2-10+deb8u1) built with OpenSSL 1.1.0g 2 Nov 2017 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-debug --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed'
Скопируйте приведенный список опций во временный текстовый файл и добавьте новую опцию:
--add-module=spnego-http-auth-nginx-module
Выполните сборку веб-сервера с нужными параметрами (скопированными из текстового файла):
./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --with-threads --with-stream --with-stream_ssl_module --add-module=spnego-http-auth-nginx-module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-debug --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed'
Обратите внимание, что утилиты для сборки должны быть установлены в системе, а nginx должен быть остановлен.
make make install
По завершении процедуры мы получим рабочий самосборный nginx с нужным модулем. Проверить это можно также — nginx -V и посмотреть в параметрах наличие модуля.
- Запустите веб-сервер ngnix.
Создание SPN
SPN (Service Principal Name) — уникальный идентификатор экземпляра сервиса. SPN используется аутентификацией Kerberos для сопоставления экземпляра сервиса с учетной записью сервиса (service logon account). Это позволяет клиентским приложением аутентифицироваться в роли сервиса даже не зная имени пользователя.
До того как аутентификация Kerberos сможет использовать SPN для аутентификации сервиса, SPN должен быть привязан к учетной записи, которая будет использоваться для входа. SPN может быть привязан только к одной учетной записи. Если учетная запись, привязанная к SPN, изменяется, то необходимо заново выполнить привязку.
Когда клиент хочет воспользоваться сервисом, он находит экземпляр сервиса и составляет SPN для этого экземпляра, далее использует этот SPN для аутентификации.
DC Windows
Для начала необходимо создать на контроллере домена (DC) пользователя, к которому впоследствии мы привяжем SPN.
Например создадим пользователя squid:
Далее необходимо запретить пользователю смену пароля и не ограничивать срок действия пароля. Последнее важно, так как иначе при истечении срока действия пароля придется не только менять пароль, но и заново генерировать keytab-файлы привязанные к этому пользователю:
В целях безопасности рекомендуется исключить сервисного пользователя из доменных групп.
Создадим SPN для прокси-сервера squid HTTP/sqserver.domg.testg и привяжем его к пользователю squid.
Для этого в командной строке на контроллере домена выполним следующую команду:
C:\>setspn -A HTTP/sqserver.domg.testg squid Регистрация ServicePrincipalNames для CN=squid,CN=Users,DC=domg,DC=testg HTTP/sqserver.domg.testg Обновленный объект
Проверить привязанные SPN у пользователя можно командой:
C:\>setspn -L squid Зарегистрирован ServicePrincipalNames для CN=squid3,CN=Users,DC=domg,DC=testg: HTTP/sqserver.domg.testg
DC FreeIPA
Для добавления SPN зайдите в web-интерфейс сервера FreeIPA->Identity->Services→Add:
В открывшемся окне необходимо выбрать имя сервиса и имя хоста, к которому будет привязан сервис:
Чтобы добавить SPN с коротким именем хоста (например это необходимо для samba), выполните команду:
ipa service-add cifs/samba --force
Генерирование keytab-файла
Создать keytab-файл можно разными способами.
Рассмотрим некоторые из них.
На контроллере домена Windows 2008 R2
Необходимо выполнить следующую команду:
C:\>ktpass -princ HTTP/sqserver.domg.testg@DOMG.TESTG -mapuser squid -pass Pa$$word -ptype KRB5_NT_PRINCIPAL -out C:\squid.keytab Targeting domain controller: dcd.domg.testg Using legacy password setting method Successfully mapped HTTP/sqserver.domg.testg to squid. Key created. Output keytab to C:\squid.keytab: Keytab version: 0x502 keysize 70 HTTP/sqserver.domg.testg@DOMG.TESTG ptype 1 (KRB5_NT_PRINCIPAL) vno 6 etype 0x17 (RC4-HMAC) keylength 16 (0x1a4b1757588cab6298e29e91c06df58d)
Рассмотрим параметры команды подробнее:
- -princ — имя принципала содержащее SPN и Kerberos-область (realm)
- -mapuser — пользователь к которому привязывается SPN
- -pass — пароль пользователя
- -ptype — указывает тип принципала (рекомендуется KRB5_NT_PRINCIPAL)
- -out — путь и имя генерируемого файла
На машине с Debian
С помощью ktutil
Этот способ работает если SPN предварительно были созданы и привязаны.
Установим необходимый пакет:
apt-get install krb5-kadmin
Запустим ktutil и создадим keytab-файл:
ktutil ktutil: addent -password -p HTTP/sqserver.domg.testg@DOMG.TESTG -k 6 -e RC4-HMAC Password for HTTP/sqserver.domg.testg@DOMG.TESTG: ktutil: wkt squid.keytab ktutil: q
С помощью Samba
Для создания keytab-файла с помощью samba, необходима работающая kerberos-аутентификация.
При использовании этого метода нет необходимости генерировать и привязывать SPN на контроллере домена.
Приведите файл настроек /etc/samba/smb.conf к следующему виду:
realm = DOMG.TESTG workgroup = DOMG server string = Samba server on %h (v. %v) security = ads dedicated keytab file = /etc/krb5.keytab kerberos method = dedicated keytab
Введите машину в домен:
net -v ads join DOMG.TESTG -UAdministrator Using short domain name -- DOMG Joined 'DOSERVER' to dns domain 'domg.testg'
Проверить ввод в домен можно командой:
net ads testjoin Join is OK
После этого в домене будет создан аккаунт компьютера к которому можно будет привязать SPN.
Создадим keytab-файл для компьютера:
net ads keytab create -UAdministrator
Добавим в keytab-файл принципала сервиса "HTTP":
net ads keytab add HTTP -U Administrator Processing principals to add...
Далее можно поменять права на keytab и отредактировать его утилитой kutil.
С помощью Samba DC
При использовании этого метода kerberos ни при чём, а все действия выполняются на машине с домен-контроллером.
Создадим пользователя, с которым будем связывать создаваемые SPN:
samba-tool user create <someuser> samba-tool user setexpiry <someuser> --noexpiry
Привяжем к нему SPN (возможно несколько раз для разных сервисов):
samba-tool spn add <service-name>/test.example.com <someuser>
Создадим keytab:
samba-tool domain exportkeytab /tmp/keytab --principal=<service-name>/test.example.com
Данную процедуру необходимо выполнить несколько раз для всех spn, которые требуется поместить в keytab.
Проверка:
klist -ke /tmp/keytab Keytab name: FILE:/etc/http.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 host/test.address.com@INTRANET.COM (des-cbc-crc) 1 host/test.address.com@INTRANET.COM (des-cbc-md5) 1 host/test.address.com@INTRANET.COM (arcfour-hmac) 1 HTTP/test.address.com@INTRANET.COM (des-cbc-crc) 1 HTTP/test.address.com@INTRANET.COM (des-cbc-md5) 1 HTTP/test.address.com@INTRANET.COM (arcfour-hmac)
С помощью FreeIPA Client
Для этого способа необходимо ввести машину в домен FreeIPA.
Для генерации keytab-файла используется команда:
ipa-getkeytab -s dc.ipa.server.ru -p HTTP/httpserver.ipa.server.ru -k /etc/http.keytab
Здесь:
- dc.ipa.server.ru — FreeIPA сервер
- HTTP/httpserver.ipa.server.ru — SPN
- /etc/http.keytab — местоположение создаваемого keytab-файла
Проверка keytab-файла
Для проверки keytab-файла необходима настроенная Kerberos-аутентификация.
Это можно проверить командой:
kinit Administrator@DOMG.TESTG
Она должна запрашивать пароль и получать билет:
klist Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@DOMG.TESTG Valid starting Expires Service principal 14.03.2017 16:45:58 15.03.2017 02:45:58 krbtgt/DOMG.TESTG@DOMG.TESTG renew until 21.03.2017 16:44:36
Попробуем зарегистрироваться с помощью keytab-файла:
kinit -V -k HTTP/sqserver.domg.testg -t /home/test/squid.keytab Using existing cache: persistent:0:krb_ccache_95Lkl2t Using principal: HTTP/sqserver.domg.testg@DOMG.TESTG Using keytab: /home/test/squid.keytab Authenticated to Kerberos v5
Проверить версию ключей на сервере можно, предварительно получив билет, с помощью команды:
kvno HTTP/sqserver.domg.testg HTTP/sqserver.domg.testg@DOMG.TESTG: kvno = 6
Проверить версию kvno и список ключей в keytab-файле можно с помощью команды:
klist -ket /home/test/squid.keytab Keytab name: FILE:/home/test/squid.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 6 01.01.1970 03:00:00 HTTP/sqserver.domg.testg@DOMG.TESTG (arcfour-hmac)
После всех проверок желательно удалить полученные билеты командой:
kdestroy
Подготовка и настройка клиентского браузера
В данном разделе рассматривается процесс настройки аутентификации Kerberos для разных браузеров, чтобы обеспечить прозрачную и безопасную аутентификацию на веб-серверах без необходимости повторного ввода пароля пользователя в корпоративной сети. Большинство современных браузеров (IE, Chrome, Firefox) поддерживают Kerberos, однако для его работы необходимо выполнить несколько дополнительных настроек.
Рассмотрим пример разрешения клиентам Kerberos проходить аутентификацию с использованием браузера на любых веб-серверах домена applite.ru (в данном случае вместо IP-адреса веб-сервера следует всегда использовать имя DNS или полное доменное имя).
Настройка Kerberos-аутентификации в Internet Explorer
Перейдите в Свойства браузера -> Безопасность -> Местная интрасеть и нажмите Сайты -> Дополнительно. Добавьте следующие записи в зону:
https://*.applite.ru
http://*.applite.ru
Групповые политики
Добавить сайты в эту зону также можно с помощью групповой политики: Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Internet Explorer -> Панель управления Интернетом -> Страница безопасности -> Назначение сайта в зону. Добавьте запись со значением 1 для каждого веб-сайта.
Затем перейдите на вкладку Дополнительно и в разделе Безопасность убедитесь, что установлен флажок «Разрешить встроенную проверку подлинности Windows».
Убедитесь, что веб-сайты, для которых включена аутентификация Kerberos, находятся только в зоне локальной интрасети. Токен Kerberos для веб-сайтов, включенных в зону надежных сайтов (Trusted Zone), не отправляется.
Настройка Kerberos-аутентификации в Google Chrome
Чтобы функция SSO работала в Google Chrome, настройте Internet Explorer, используя метод, описанный выше (Chrome использует настройку IE). Кроме того, следует отметить, что все новые версии Chrome автоматически обнаруживают поддержку Kerberos на сайте. Если вы используете одну из более ранних версий Chrome (Chromium), запустите ее со следующими параметрами, чтобы проверка подлинности Kerberos на ваших веб-серверах работала правильно:
--auth-server-whitelist="*.applite.ru" --auth-negotiate-delegate-whitelist="*.applite.ru"
Например:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” --auth-server-whitelist="*.applite.ru" --auth-negotiate-delegate-whitelist="*.applite.ru"
Вы также можете настроить эти параметры с помощью GPO для Chrome (политика AuthServerWhitelist) или параметра реестра AuthNegotiateDelegateWhitelist, расположенного в разделе реестра HKLM\SOFTWARE\Policies\Google\Chrome.
Чтобы изменения вступили в силу, перезапустите браузер и сбросьте билеты Kerberos с помощью команды очистки klist purge
.
Настройка Kerberos-аутентификации в Firefox
По умолчанию поддержка Kerberos в Firefox отключена. Чтобы включить поддержку аутентификации, откройте окно настройки браузера (введите about:config в адресной строке). Затем в следующих параметрах укажите адреса веб-серверов, для которых вы собираетесь использовать аутентификацию Kerberos.
network.negotiate-auth.trusted-uris
network.automatic-ntlm-auth.trusted-uris
Для удобства вы можете отключить обязательный ввод адреса FQDN-сервера в адресной строке Mozilla Firefox, включив параметр network.negotiate-auth.allow-non-fqdn.
Чтобы проверить, что браузер прошел проверку подлинности Kerberos на сервере, воспользуйтесь отладчиком Fiddler или командой klist tickets.