В случае использования системы управления LayerPIE в рамках ранее развернутой инфраструктуры домена (AD или SAMBA) необходимо провести дополнительную настройку систем.
Для настройки функций доменной авторизации и SSO для входа в систему централизованного управления необходимо выполнить ряд действий:
Для получения дополнительной информации по процессу аутентификации 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
--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 (Service Principal Name) — уникальный идентификатор экземпляра сервиса. SPN используется аутентификацией Kerberos для сопоставления экземпляра сервиса с учетной записью сервиса (service logon account). Это позволяет клиентским приложением аутентифицироваться в роли сервиса даже не зная имени пользователя.
До того как аутентификация Kerberos сможет использовать SPN для аутентификации сервиса, SPN должен быть привязан к учетной записи, которая будет использоваться для входа. SPN может быть привязан только к одной учетной записи. Если учетная запись, привязанная к SPN, изменяется, то необходимо заново выполнить привязку.
Когда клиент хочет воспользоваться сервисом, он находит экземпляр сервиса и составляет SPN для этого экземпляра, далее использует этот SPN для аутентификации.
Для начала необходимо создать на контроллере домена (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
Для добавления SPN зайдите в web-интерфейс сервера FreeIPA->Identity->Services→Add:
В открывшемся окне необходимо выбрать имя сервиса и имя хоста, к которому будет привязан сервис:
Чтобы добавить SPN с коротким именем хоста (например это необходимо для samba), выполните команду:
ipa service-add cifs/samba --force
Создать keytab-файл можно разными способами.
Рассмотрим некоторые из них.
Необходимо выполнить следующую команду:
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)
Рассмотрим параметры команды подробнее:
Этот способ работает если 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
Для создания 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.
При использовании этого метода 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.
Для генерации 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-файла необходима настроенная 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 или полное доменное имя).
Перейдите в Свойства браузера -> Безопасность -> Местная интрасеть и нажмите Сайты -> Дополнительно. Добавьте следующие записи в зону:
https://*.applite.ru
http://*.applite.ru
Групповые политики
Добавить сайты в эту зону также можно с помощью групповой политики: Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Internet Explorer -> Панель управления Интернетом -> Страница безопасности -> Назначение сайта в зону. Добавьте запись со значением 1 для каждого веб-сайта.
Затем перейдите на вкладку Дополнительно и в разделе Безопасность убедитесь, что установлен флажок «Разрешить встроенную проверку подлинности Windows».
Убедитесь, что веб-сайты, для которых включена аутентификация Kerberos, находятся только в зоне локальной интрасети. Токен Kerberos для веб-сайтов, включенных в зону надежных сайтов (Trusted Zone), не отправляется.
Чтобы функция 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 отключена. Чтобы включить поддержку аутентификации, откройте окно настройки браузера (введите 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.