Введение


Для настройки функций доменной авторизации и SSO для входа в ЦСУ ПРОМЕТЕЙ необходимо выполнить ряд действий:

Для получения дополнительной информации по процессу аутентификации Kerberos, типам шифрования, конфигурации Kerberos, настройке оповещателей и т.д. см. документ Аутентификация Kerberos.

Настройка веб-сервера


Для настройки AD-аутентификации для apache рекомендуем ознакомиться с подробными материалами в сети Интернет ([1][2]).

Далее приводится подробное описание процесса подготовки и настройки веб-сервера ngnix и всей системы в целом.

В базовой поставке nginx функционал AD-аутентификации отсутствует. Для добавления данного функционала рекомендуется использовать модуль SPNEGO. Таким образом, для начала необходимо собрать nginx с нужным нам модулем. Для этого выполните следующее:

  1. Выполните установку nginx.

    apt-get install nginx -V


  2. Скачайте последнюю версию исходников веб-сервера с официального сайта.

    wget http://nginx.org/download/nginx-1.17.1.tar.gz


  3. Распакуйте папку с исходниками веб-сервера и поместите туда исходники модуля 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


  4.  Выполните команду просмотра текущей версии 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'


  5. Скопируйте приведенный список опций во временный текстовый файл и добавьте новую опцию:

    --add-module=spnego-http-auth-nginx-module


  6. Выполните сборку веб-сервера с нужными параметрами (скопированными из текстового файла):

    ./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 и посмотреть в параметрах наличие модуля.
          

  7. Запустите веб-сервер 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)

Рассмотрим параметры команды подробнее:

На машине с 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

Здесь:

Проверка 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

Перейдите в Свойства браузера -> Безопасность -> Местная интрасеть и нажмите Сайты -> Дополнительно. Добавьте следующие записи в зону:


Добавить сайты в эту зону также можно с помощью групповой политики: Конфигурация компьютера -> Административные шаблоны -> Компоненты 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.

  1. network.negotiate-auth.trusted-uris
  2. network.automatic-ntlm-auth.trusted-uris

Для удобства вы можете отключить обязательный ввод адреса FQDN-сервера в адресной строке Mozilla Firefox, включив параметр network.negotiate-auth.allow-non-fqdn.

Чтобы проверить, что браузер прошел проверку подлинности Kerberos на сервере, воспользуйтесь отладчиком Fiddler или командой klist tickets.