Разрешить встроенную проверку подлинности windows chrome

В этой статья, мы рассмотрим, как настроить Kerberos аутентификацию для различных браузеров в домене Windows для прозрачной и безопасной аутентификации на веб-серверах без необходимости повторного ввода пароля в корпоративной сети. В большинстве современных браузерах (IE, Chrome, Firefox) имеется поддержка Kerberos, однако, чтобы она работала, нужно выполнить несколько дополнительных действий.

Чтобы браузер мог авторизоваться на веб-сервере, нужно, чтобы были выполнены следующие условия:

• Поддержка Kerberos должны быть включена на стороне веб-сервера (пример настройки Kerberos авторизации на сайте IIS)
• Наличие у пользователя прав доступа к серверу
• Пользователь должен быть аутентифицирован на своем компьютере в Active Directory с помощью Kerberos (должен иметь TGT — Kerberos Ticket Granting Ticket).

К примеру, мы хотим разрешить клиентам Kerberos авторизацию через браузер на всех веб серверах домена winitpro.ru (нужно использовать именно DNS или FQDN, а не IP адрес веб сервера)

Настройка Kerberos аутентификации в Internet Explorer

Рассмотрим, как включить Kerberos аутентификацию в Internet Explorer 11.

Напомним, что с января 2016 года, единственная официально поддерживаемая версия Internet Explorer – это IE 11.

Откройте Свойства браузера -> Безопасность -> Местная интрасеть (Local intranet), нажмите на кнопку Сайты -> Дополнительно. Добавьте в зону следующие записи:

• https://*.winitpro.ru
• http://*.winitpro.ru

Добавить сайты в эту зону можно с помощью групповой политики: Computer Configuration ->Administrative Templates ->Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Site to Zone Assignment. Для каждого веб-сайта нужно добавить запись со значением 1. Пример смотри в статье об отключении предупреждения системы безопасности для загруженных из интернета файлов

Далее перейдите на вкладку Дополнительно (Advanced) и в разделе Безопасность (Security) убедитесь, что включена опция Разрешить встроенную проверку подлинности Windows (Enable Integrated Windows Authentication).

Важно. Убедитесь, что веб сайты, для которых включена поддержка Kerberos аутентификации приустают только в зоне Местная интрасеть. Для сайтов, включенных в зону Надежные сайты (Trusted sites), токен Kerberos не отправляется на соответствующий веб-сервер.

Включаем Kerberos аутентификацию в Google Chrome

Чтобы SSO работала в Google Chrome, нужно настроить Internet Explorer вышеописанным способом (Chrome использует данные настройки IE). Кроме того, нужно отметить, что все новые версии Chrome автоматически определяют наличие поддержки Kerberos. В том случае, если используется одна из старых версий Chrome (Chromium), для корректной авторизации на веб-серверах с помощью Kerberos, его нужно запустить с параметрами:

--auth-server-whitelist="*.winitpro.ru"
--auth-negotiate-delegate-whitelist="*.winitpro.ru"

Например,

"C:Program Files (x86)GoogleChromeApplicationchrome.exe” --auth-server-whitelist="*.winitpro.ru" --auth-negotiate-delegate-whitelist="*.winitpro.ru"

Либо эти параметры могут быть распространены через групповые политики для Chrome (политика AuthServerWhitelist) или строковый параметр реестра AuthNegotiateDelegateWhitelist (находится в ветке HKLMSOFTWAREPoliciesGoogleChrome).

Для вступления изменений в силу нужно перезагрузить браузер и сбросить тикеты Kerberos командой klist purge (см. статью).

Настройка Kerberos аутентификации в Mozilla 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.

Ответы:

chrome.exe --auth-server-whitelist="*example.com,*foobar.com,*baz"

--auth-server-whitelist="*example.com,*foobar.com,*baz"

Введение

Для настройки функций доменной авторизации и SSO для входа в систему централизованного управления необходимо выполнить ряд действий:

• Настроить веб-сервер (ngnix или apache) на поддержку аутентификации HTTP Negotiate.
• Выполнить соответствующие настройки на стороне домена: создать SPN, ServiceUser.
• Сгенерировать keytab-файл.
• Выполнить настройку используемого браузера.

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

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

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

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

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

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

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 должен быть остановлен.

   По завершении процедуры мы получим рабочий самосборный 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)

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

• -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)

После всех проверок желательно удалить полученные билеты командой:

Подготовка и настройка клиентского браузера

В данном разделе рассматривается процесс настройки аутентификации Kerberos для разных браузеров, чтобы обеспечить прозрачную и безопасную аутентификацию на веб-серверах без необходимости повторного ввода пароля пользователя в корпоративной сети. Большинство современных браузеров (IE, Chrome, Firefox) поддерживают Kerberos, однако для его работы необходимо выполнить несколько дополнительных настроек.

Рассмотрим пример разрешения клиентам Kerberos проходить аутентификацию с использованием браузера на любых веб-серверах домена applite.ru (в данном случае вместо IP-адреса веб-сервера следует всегда использовать имя DNS или полное доменное имя).

Настройка Kerberos-аутентификации в Internet Explorer

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

• https://*.applite.ru
• http://*.applite.ru

Затем перейдите на вкладку Дополнительно и в разделе Безопасность убедитесь, что установлен флажок «Разрешить встроенную проверку подлинности Windows».

Настройка 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)GoogleChromeApplicationchrome.exe” --auth-server-whitelist="*.applite.ru" --auth-negotiate-delegate-whitelist="*.applite.ru"

Вы также можете настроить эти параметры с помощью GPO для Chrome (политика AuthServerWhitelist) или параметра реестра AuthNegotiateDelegateWhitelist, расположенного в разделе реестра HKLMSOFTWAREPoliciesGoogleChrome.

Чтобы изменения вступили в силу, перезапустите браузер и сбросьте билеты Kerberos с помощью команды очистки klist purge.

Настройка Kerberos-аутентификации в Firefox

По умолчанию поддержка Kerberos в Firefox отключена. Чтобы включить поддержку аутентификации, откройте окно настройки браузера (введите about:config в адресной строке). Затем в следующих параметрах укажите адреса веб-серверов, для которых вы собираетесь использовать аутентификацию Kerberos.

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

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