Kerberos настройка windows server 2019

Описание стенда

Сервер:

ОС: Windows server 2019

доменное имя: server,astradomain.ad

Клиент:

ОС: РЕД ОС Астра Линукс ALT Linux Ubuntu

доменное имя: redos.astradomain.ad smolensk.astradomain.ad orel.astradomain.ad ubuntu.astradomain.ad

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

Установка сервиса Active Directory

Измените имя сервера, если это необходимо. Его можно задать в окне менеджера сервера:

Добавим службу Active Dirrectory и DNS на сервер. Для этого откроем окно добавления ролей в менеджере сервера:

В окне для выбора сервисов установим галочки «Active Directory Domain Services» и «DNS Server»:

Во всех остальных пунктах даем согласие на установку.

После завершения установки сервисов вам надо перейти к настройке домена. Для этого откройте меню уведомлений и выберите пункт «Promote this server to a domain controller»:

На первой вкладке укажите опцию для создания нового домена и укажите его название:

Введите пароль сброса:

На следующей вкладке оставляем все как есть., т.к. наш сервер сам является DNS сервером:

На следующих трёх вкладках также оставляем все как есть:

Перед запуском процесса установки ознакомимся с уведомлениями об ошибках.. И если необходимо, устраняем возникшие проблемы. В нашем случае уведомления не являются критичными:

После установки Active Directory сервер перезагрузится.  Если настройка прошла успешно, то нас попросят войти в аккаунт на этот раз доменного пользователя:

Добавление новых пользователей:

Откроем утилиту управления пользователями и компьютерами домена:

Для удобства можно создать отдельную дирректорию Domain Users, где будем создавать доменных пользователей:

Добавим нового пользователя user:

Аналогичным образом добавьте остальных пользователей, которые должны быть в домене.

Установка центра сертификации Active Directory:

Установите драйверы для работы с Рутокеном на сервер. Их можно получить тут. После этого можно приступить к настройке центра сертификации и выдачи сертификатов для пользователей. Это можно сделать по данной инструкции. Настройку авторизации с помощью сертификатов можно воспроизвести по этой инструкции.

Настройка клиента Linux

Настройка подключения к домену

В первую очередь настроим подключение к домену. Это можно сделать с помощью следующей последовательности команд:

#########################################################
############## Меняем доменное имя клиента ##############
#########################################################
# Меняем имя клиента в нашем домене astradomain.ad на client
sudo hostnamectl set-hostname client.astradomain.ad
 
# После данного этапа потребуется перезагрузка


#########################################################
### Настройка подключения. Изменяем адрес DNS сервера ###
#########################################################
# узнайте название вашего соединения. Они могут отличаться
CON_NAME="Проводное соединение 1"
# название интерфейса, которое использует ваше соединение
INT_NAME="eth0"
# адрес dns сервера
DNS_SERVER_IP=10.0.2.37
# отключаем соединение
sudo nmcli con down "$CON_NAME"
 
# настраиваем сетевую карту соединения - по умолчанию $INT_NAME
sudo nmcli con mod "$CON_NAME" connection.interface-name $INT_NAME
 
# настраиваем DNS - вместо DNS_SERVER_IP указать IP-адрес сервера DNS. При необходимости указываем адрес локального сервера DNS. В нашем случае в качестве DNS сервера выступал сам сервер FreeIPA. Поэтому был указан его IP адрес
sudo nmcli con mod "$CON_NAME" ipv4.dns "$DNS_SERVER_IP 8.8.8.8"
sudo nmcli con mod "$CON_NAME" ipv4.ignore-auto-dns yes
 
# включаем сетевое соединение
sudo nmcli con up "$CON_NAME"

# Проверка подключения
ping server.astradomain.ad

#########################################################
############# Установка необходимых пакетов #############
#########################################################
# для пользователей систем с менеджером пакетов yum
sudo yum install -y realmd PackageKit

# для пользователей систем с менеджером пакетов apt-get
sudo apt-get install -y realmd packagekit

# Узнаем какие пакеты еще необходимы для подключения к домену
realm discover astradomain.ad

# Список необходимых для работы пакетов будет выведен в следующем формате
# required-package: pkg1
# required-package: pkg2
# required-package: pkg3
# ...

# Доустановим отсутствующие пакеты
# для пользователей систем с менеджером пакетов yum
sudo yum install -y pkg1 pkg2 pkg3 ...

# для пользователей систем с менеджером пакетов apt-get
sudo apt-get install -y pkg1 pkg2 pkg3 ...


#########################################################
################# Подключение к домену ##################
#########################################################
# Подключимcя к домену
# Пользователь user должен обладать правами подключения устройств в домен.
sudo realm join astradomain.ad --user=user

# Установим пакет krb5-workstation
# для пользователей систем с менеджером пакетов yum
sudo yum install -y krb5-workstation

# для пользователей систем с менеджером пакетов apt-get
sudo apt-get install -y krb5-user

# для пользователей Alt linux
sudo apt-get install -y krb5-workstation

# Если в домене есть пользователь user, к которому можно подключиться с помощью пароля, то можно осуществить проверку настройки получив тикет для него
kinit user@ASTRADOMAIN.AD

# Проверка получения тикета
klist

# Удаляем тикет
kdestroy

Настройка автоматического создания домашней директории

Когда доменный пользователь аутентифицируется в системе необходимо чтобы для него автоматически создавался домашний каталог.

Это можно сделать в настройках pam. Для этого в файле 

/etc/pam.d/common-session для систем основанных на Debian

/etc/pam.d/system-auth для систем основанных на Red Hat

/etc/pam.d/system-auth-sss-only для пользователей Alt linux

активируем модуль pam_mkhomedir.so, после pam_sss.so. Содержимое файла будет выглядеть следующем образом:

...
session optional pam_sss.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
...

Проверка аутентификации под пользователем в домене без Рутокена

Если в домене есть пользователь user, под которым можно аутентифицироваться без смарт-карты, то можно проверить предыдущую надстройку аутентифицируясь под ним. Для начала можно попробовать аутентифицироваться через командную строку:

Настройка клиента для аутентификации в домене с помощью Рутокена

Упрощенная настройка

Для упрощенной настройки можно воспользоваться утилитой для работы с токенами. Описание упрощенной настройки можно прочитать тут.

Ручная настройка

Установка необходимых пакетов для работу:

# для пользователей систем с менеджером пакетов yum
sudo yum install -y nss-tools opensc krb5-pkinit

# для пользователей систем с менеджером пакетов apt-get
sudo apt-get install -y libnss3-tools opensc krb5-pkinit

Для ручной настройки также потребуется установить библиотеку librtpkcs11ecp. Ее можно получить тут.  Установим данную библиотеку.

# Установка пакета для систем основанных на red hat
sudo rpm -i librtpkcs11ecp-2.0.5.1-1.x86_64.rpm
# Установка пакета для Debian систем
sudo dpkg -i librtpkcs11ecp-2.0.5.1-1.x86_64.deb

Добавление корневого сертификата и сертификатов токена в БД

Инициализируем БД:

mkdir /etc/pki/nssdb
sudo certutil -N -d /etc/pki/nssdb --empty-password

Добавление корневого сертификата в БД:

sudo certutil -d /etc/pki/nssdb -A -n 'CA-ROOT-CERT' -t CT,CT,CT -a -i /path/to/ca_cert.pem

Добавление сертификатов с Рутокена:

sudo modutil -dbdir /etc/pki/nssdb -add "Rutoken PKCS11" -libfile librtpkcs11ecp.so

Проверку того, что сертификаты добавились в БД можно осуществить с помощью команды

# перезапустите сервис pcscd на случай, если он выключен
sudo systemctl restart pcscd

# проверяем наличие сертификатов в БД
sudo certutil -L -d /etc/pki/nssdb -h all

Настройка SSSD

Для того, чтобы аутентификация корректно работала на лок скрине. В настройках sssd нужно указать название сервиса, использующегося при аутентификации через лок скрин, чтобы сделать его доверенным. У каждой графической оболочки свое название данного сервиса. Узнать название вашей графической оболочки можно с помощью команды:

echo $XDG_CURRENT_DESKTOP

Вот список соответствий названий графических оболочек и сервиса, используемого лок скрином. Данный список не является полным.

MATE → mate-screensaver
X-Cinnamon → cinnamon-screensaver
fly → <Отсутствует>
KDE → kde
GNOME → xdg-screensaver

Сконфигурируем SSSD. Для этого отредактируем файл /etc/sssd/sssd,conf. Он должен выглядеть примерно следующим образом:

[sssd]
domains = astradomain.ad
config_file_version = 2
services = nss, pam

[domain/astradomain.ad]
ad_domain = astradomain.ad
krb5_realm = ASTRADOMAIN.AD
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
fallback_homedir = /home/%u@%d
access_provider = ad

# Если хотим подключатся к пользователям домена не вводя имя домена
use_fully_qualified_names = False

# Для пользователей Astra Linux также нужно добавить строчку отключения групповых политик
ad_gpo_access_control = permissive

# Для активации входа по смарт-картам
[pam]
pam_cert_auth = True
# Указываем название сервиса, используемого лок скрином. Если сервис отсутствует, то данную строку не используют
pam_p11_allowed_services = +<service_name>

Перезапустим сервис SSSD

sudo systemctl restart sssd

Настройка Kerberos

Скопируем корневой сертификат в директорию /etc/pki/tls/certs/. 

sudo cp /path/to/ca_cert.pem /etc/pki/tls/certs/

Для настройки Kerberos изменим содержимое файла /etc/krb5.conf. Секция [libdefaults] должна содержать следующее:

...
[libdefaults]
...
# Путь до дерриктории с корневым сертификатов с постфиксом .pem
    pkinit_anchors = DIR:/etc/pki/tls/certs/
# Адрес KDC
    pkinit_kdc_hostname = server.astradomain.ad
# Пропускаем проверку EKU сертификата
    pkinit_eku_checking = kpServerAuth
    default_ccache_name = KEYRING:persistent:%{uid}
# Имя домена по умолчанию
    default_realm = ASTRADOMAIN.AD
# Путь д сертификатов и ключей
    pkinit_identities = PKCS11:librtpkcs11ecp.so
# Для совместимости с AD 
    canonicalize = True
...

Проверка настройки с помощью получения тикета для пользователя user, который аутентифицируется по Рутокену

# Получение тикета. Должно быть предложено ввести ПИН-код токена
kinit user

# Проверка получения тикета
klist

# Сброс тикета
kdestroy

Попытка аутентификации по смарт-карте

Попробуйте аутентифицироваться под доменным пользователем user по смарт-карте в системе:

Если аутентификация не прошла успешно, то попробуйте изменить конфигурацию pam модулей, иначе можете пропустить данную часть

Настройка pam модулей

Для аутентификации пользователя в системе с помощью смарт-карты необходимо изменить содержимое pam модулей

Для систем основанных на Debian 

Файл /etc/pam.d/common-auth должен содержать следующие строки:

...
auth [success=2 default=ignore] pam_sss.so forward_pass
auth [success=1 default=ignore] pam_unix.so try_first_pass nullok_secure
...

Для систем основанных на Red Hat

Файл /etc/pam.d/system-auth должен содержать следующие строки:

...
auth        [default=1 ignore=ignore success=ok]         pam_localuser.so
auth        sufficient                                   pam_unix.so nullok try_first_pass
auth        requisite                                    pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient                                   pam_sss.so forward_pass
...

Аутентфикация через гритер

Проверьте аутентификацию через гритер  через лок скрин.

Для пользователей Astra Linux предложение ввода ПИН-кода не отображается. В поле ввода пароля просто введите ПИН-код от Рутокена:

Обновлено 03.08.2017

Добрый день уважаемые читатели, не так давно у меня на работе была задача по настройке групп доступности SQL на Windows кластере, там клиентам сделали красивый веб-инструментарий, все замечательно, теперь клиент ждет следующего развития ситуации, а именно настройка и внедрение механизма Single Sign-On (SSO) или по русски единая точка аутентификация, мы с вами уже с ней знакомились при настройке Vmware vCenter Server. Данный механизм работает на протоколе шифрования kerberos, о котором мы и поговорим. Мы рассмотрим как происходит проверка подлинности kerberos в Active Directory, так как понимание принципов работы, поможет вам в реализации единой точки аутентификации.

Идентификация и доступ в Active Directory

Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:

• Она должна хранить информацию, о всех объектах Active Directory, среди которых: пользователи, группы безопасности, компьютеры, принтеры и другие объекты идентификации. Под объектом идентификации (identity) подразумевается, некое представление сущности, в задачи которой входит выполнение каких-либо действий в корпоративной сети. Простой пример, есть пользователь Вася и он работает с документами в общей папке на сервере. Эти документы имеют защиту на доступ, который определяет список контроля доступа (Access Contro l List, ACL). Доступом у нужным файлам, управляет подсистема безопасности сервера, где лежит папка, и при обращении к ней он производит сравнение объекта идентификации пользователя с теми объектами, которые присутствуют в его списке ACL, и уже на основании этого, он принимает решение предоставить или запретить пользователю доступ. Так как службы, компьютеры, группы и другие объекты выполняют определенные вещи в локальной сети, то у каждого из них есть свой объект идентификации. Данный объект содержит много информации, уникальной для каждого из них, например, имя пользователя, его идентификатор безопасности (Security Identifier, SID), пароль. Так, что хранилище объектов идентификации, является неотъемлемой частью Identity and Access. Все данные в Active Directory, располагаются в каталоге AD, которым управляет контроллер домена.
• Проверка подлинности объекта идентификации. Тут общий принцип такой, когда пользователь обращается к документу, то сервер его ему не покажет, пока тот, не подтвердит подлинность объекта идентификации, который фигурирует в запросе. Чтобы все это сделать, у пользователя есть некая секретная информация, которая известна ему и инфраструктуре IDA, вот эти данные как раз и сравниваются с теми, что есть в хранилище объектов идентификации в момент проверки подлинности.

Чем хороша операционная система Windows, так это тем, что она очень унифицированная, за счет интерфейса SSPI (Security Support Provider Interface). SSPI — это механизм операционной системы Windows в задачи которого идет, предоставление приложениям не зависеть от различных решений протоколов аутентификации, позволяя работать абсолютно с любыми из них, если перефразировать, то любое приложение может использовать любой протокол аутентификации. Еще очень большой плюс интерфейса SSPI, то что он позволяет изолировать сетевой транспорт от протоколов аутентификации, если по простому, то эти протоколы становятся независимыми от протоколов передачи данных по сети,  и приложению вообще до лампочки, какой из них использовать.

Именно за счет провайдеров Security Support Provider (SSP) сделан механизм аутентификации. Операционная система Windows уже имеет встроенные модули, но никто не мешает программистам, взять и написать свой и подключить его к SSPI

Протокол аутентификации kerberos пришел на смену устаревшему и уже с точки зрения не безопасному, протоколу NTLM, он был основным до Windows 2000. Протокол Kerberos всегда используется в построении механизмов Single Sign-On. В его основе лежит такой принцип, что если двум участникам известен некий ключ и у них есть возможность подтвердить это, то они смогут однозначно идентифицировать друг друга.

Пользовательский ключ — когда системный администратор заводит новую учетную запись пользователя, значение его пароля используется при создании ключа, он хранится рядом с самим объектом пользователя AD. И как написано выше, это ключ знают контроллер домена и пользователь, две стороны.

Системный ключ — в момент ввода компьютера в домен Active Directory он так же получает свой уникальный пароль, на его основании и создается ключ, все как у пользователя. Еще отмечу, что данный пароль каждый месяц автоматически меняется, поэтому старые компьютеры, которые долго не были включены, не могут пройти аутентификацию в домене, так как потеряны доверительные отношения.

Ключ службы (service key) — тут все просто, очень часто системные администраторы для запуска службы создают отдельного доменного пользователя, в следствии чего служба получит его ключ, но если она запускается под учетной записью системы (LocalSystem), то получит ключ компьютера.

Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.

• Давайте рассматривать каким образом происходит проверка подлинности Kerberos в домене Active Directory. И так пользователь или же компьютер, пытаются войти в локальную сеть домена, именно протокол Kerberos удостоверяется в подлинности указанных реквизитов, в следствии чего выдает пакет данных, а точнее билет или тикет (Ticket), по правильному он называется TGT (Ticket Granting Ticket).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.

• Теперь когда у пользователя или компьютера есть билет TGT, он может его предоставлять любому сервису или ресурсу. В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). Данный билет будет идентифицировать прошедшего проверку подлинности пользователя на сервере. Пользователь предоставит TGS билет для доступа к серверу, он его примет и подтвердит прохождение проверки подлинности. Вот тут Kerberos и показывает все свои достоинства, ему требуется лишь один сетевой вход и после получения им билета TGT он проходит проверку подлинности для всего домена целиком, что дает ему возможность получать идентификационные билеты на доступ к службам, не вводя ни каких учетных данных, все эти операции осуществляются за счет встроенных клиентов и служб Kerberos в Kerberos.

Сам Ticket-Granting Service состоит из двух вещей, первая это копия сессионного ключа и информация о клиенте. Все эти данные зашифрованы ключом, общим между сервисом к которому идет обращение и KDC. Это означает, что пользователь не сможет посмотреть эти данные, а вот служба или сервер к которому идет обращение да.

За счет высокого уровня безопасности протокола Kerberos, при передаче данных вы не увидите пароли или значения хэш в открытом виде. Еще одним требованием к работе с данным протоколом, выступает системное время, которое не может расходится с временем на контроллере домена более чем 5 минут

Еще очень важным моментом, является тот фактор, что служба KDC, должна точно знать к какому именно сервису идет обращение и каким ключом шифрования производить обработку. Для этого есть такой механизм, как Service Principal Names, по сути это уникальный идентификатор службы, который будет прописан в вашей базе Active Directory. Из требований к нему, он должен быть уникален в рамках леса. Каждая служба, которая будет использовать Kerberos, должна иметь зарегистрированный SPN. Без правильно настроенного идентификатора протокол для этой службы или сервера работать не будет.

Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.

Как производится настройка SPN мною уже была описана в одной из статей.

Детальная проверка kerberos от начала логирования

Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:

• Человек видит поля ввода логина и пароля у себя на компьютере
• Компьютер получив от пользователя первичные данные делает запрос к контроллеру домена, а точнее к службе Key Distribution Center, где передает KDC имя пользователя в открытом виде, имя домена и текущее время на рабочей станции, еще раз напоминаю, что оно не должно отличаться от времени на контроллере домена более ,чем на 5 минут. Значение текущего времени передается в зашифрованном виде, и будет выступать аутентификатором. Напоминаю, что ключ шифрования (пользовательский ключ) формируется из пароля пользователя, как результат хеширования.

• Служба KDC видит обращение с компьютера и начинает поиск пользователя в Active Directory, проверяет его пользовательский ключ и расшифровывает аутентификатор, если по русски она получает время отправления запроса. После чего Key Distribution Center создает два тикета. Первый это  сессионный ключ, он нужен для шифрования данных между клиентом и KDC. Второй тикет, это билет на получение билета (Ticket-Granting Ticket (TGT)), как только он появился у пользователя, тот сможет запрашивать тикеты для сервисов и серверов. Сам TGT билет состоит из таких частей: копия ключа сессии, время окончания жизни билета и имя пользователя. TGT шифруется с использованием мастер ключа самой службы Key Distribution Center, поэтому пользователь не может его расшифровать.
• Как только эти билеты сформированы Key Distribution Center шифрует аутентификатор пользователя (time stamp) и сессионный ключ, с помощью пользовательского ключа и спокойно передает их пользователю.

• Так как у пользователя есть его, пользовательский ключ, он спокойно расшифровывает билеты от Key Distribution Center и проверяет аутентификатор. В итоге он теперь обладает и ключем сессии и TGT ключом, теперь первый этап Kerberos закончен и пользователю больше не нужно в этой сессии заказывать эти билеты.
• Далее клиент хочет получить доступ на сервис, так как у него уже есть ключ на получение других ключей (TGT), для доступа к сервису он предоставляет KDC, свой Ticket-Granting Ticket и штамп времени, которые шифрует сессионным ключом.
• KDC получает этот запрос и билеты, расшифровывает их используя свой ключ. Контроллер домена подтверждает, что запрос поступил именно от нужного пользователя.

• Следующим шагом Key Distribution Center, генерирует два тикета (Service Ticket (TGS)), один для обратившегося клиента, а второй для сервиса, к которому клиент обращается. Каждый из тикетов, будет содержать имя пользователя, кто просит доступ, кто должен получить запрос, штамп времени, рассказывающий, когда создан тикет, и срок его жизни, а так же новый ключ Kcs. Kcs — это ключ для сервиса и клиента, в задачи которого входит обеспечение безопасного взаимодействия между ними. Далее KDC шифрует билет сервиса, используя для этого системный ключ сервера и вкладывает этот билет внутрь билета клиента, у которого так же есть свой Kcs ключ.
• Теперь все это дело шифруется сессионным ключом и передается клиенту.

• Клиент получает билет, расшифровывает его с помощью сессионного ключа и видит свой TGS тикет, и Kcs сервиса, клиент не может прочитать Kcs предназначенный для сервиса

• Теперь клиент формирует штамп времени и шифрует его Kcs ключом, отправляет его вместе с билетом, TGS предназначенным для него.

• Когда сервер с сервисом, получает эту информацию, он сразу видит пакет от KDC предназначенный для него с ключом TGS (Kcs). Он расшифровывает им штамп времени от клиента.
• Так как у обоих участников есть TGS ключ, они могут быть обо уверены, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован Kcs .  В случае необходимости ответа сервера клиенту, сервер воспользуется ключом Kcs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить Kcs.

В этой статье мы рассмотрим примеры базовой настройки протокола аутентификации Kerberos для пула приложений IIS v10 на сервере с ОС Windows Server 2022. При этом мы отдельно поговорим о разных вариантах настройки в зависимости от типа учётной записи, в контексте которой выполняется пул приложений IIS. Кроме того, попробуем рассмотреть задачу подключения к веб-сервису IIS (фронтенд) стороннего файлового ресурса (бэкенд) и делегирования аутентификации пользователей от фронтенда к бэкенду.

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

Этап 1. Базовая настройка Kerberos для IIS

• • Вариант 1. Пул IIS выполняется в контексте учётной записи самого веб-сервера
  • Вариант 2. Пул IIS выполняется в контексте сервисной учётной записи gMSA

Этап 2. Настройка разных типов делегирования аутентификации на примере IIS

• Тип 1. Полное делегирование (Unconstrained Delegation)
• Тип 2. Ограниченное делегирование (Constrained Delegation)
  • Вариант 1. Пул IIS выполняется в контексте учётной записи самого веб-сервера
  • Вариант 2. Пул IIS выполняется в контексте сервисной учётной записи gMSA
• Тип 3. Ограниченное делегирование на основе ресурсов (Resource Based Constrained Delegation)
• Общие выводы по типам делегирования

На первом и втором этапе плана мы рассмотрим конкретные примеры настройки, исходя из двух разных вариантов работы пула приложений IIS:

Вариант 1. Пул IIS выполняется в контексте учётной записи самого веб-сервера:

Вариант 2. Пул IIS выполняется в контексте сервисной учётной записи gMSA:

Этап 1. Базовая настройка Kerberos для IIS

Разные варианты запуска пула приложений IIS требуют разных действий по настройке поддержки Kerberos. Например, пул IIS может выполняться в контексте учётной записи самого веб-сервера (ApplicationPoolIdentity), в контексте учётной записи пользователя или в контексте сервисной учётной записи gMSA.

Вариант 1. Пул IIS выполняется в контексте учётной записи самого веб-сервера

1) Регистрируем в домене уникальную запись SPN вида HTTP/<fqdn> для доменной компьютерной учётной записи веб-сервера. Поиск и регистрацию SPN можно выполнить как с помощью утилиты setspn, так и с помощью PowerShell.

Пример команды для получения всех зарегистрированных SPN-записей для объекта типа компьютер:

Get-ADComputer -Identity "<имя учётной веб-сервера>" -Properties ServicePrincipalNames | Select-Object -ExpandProperty ServicePrincipalNames

В следующем примере регистрируем пару SPN-записей для компьютерной учётной записи веб-сервера:

Set-ADComputer -Identity "WEB03" -ServicePrincipalNames @{Add='HTTP/SRV-Web.holding.com','HTTP/SRV-Web'}

2) Настраиваем в IIS пул приложений (Application Pool), используя в расширенных настройках пула в свойстве «Identity» значение  «ApplicationPoolIdentity«.

3) В свойствах сайта в методах аутентификации выключаем анонимную аутентификацию, и включаем аутентификацию Windows.

В свойствах аутентификации Windows убедимся в том, что провайдер «Negotiate» выставлен как приоритетный (в самом верху списка провайдеров). Если NTLM в чистом виде не нужен, можем его вообще удалить из списка включенных провайдеров.

Провайдер «Negotiate» будет приоритетно работать с протоколом Kerberos с возможностью понижения до протокола NTLM.

4) В редакторе правки конфигурации сайта «Configuration Editor» выбираем секцию system.webServer/security/authentication/windowsAuthentication. Здесь проверим, что опция  «useAppPoolCredentials» выключена (False), а опция «useKernalMode» включена (True).

5) На клиентской машине проверяем отрабатывает ли аутентификация Kerberos.

Перед проверкой, для чистоты эксперимента, на стороне веб-сервера перезапустим службу IIS (команда iisreset), а на клиентской машине закроем веб-браузер и очистим кеш билетов Kerberos в контексте текущего пользователя (команда klist purge).

После этого на клиенте снова откроем браузер и сначала просто пробуем открыть стартовую страницу сайта. Сайт должен открываться без каких-либо запросов аутентификации или ошибок.

В этот момент на клиентской системе с помощью команды klist можно проверить все кэшированные билеты Kerberos и убедиться в том, что в их списке появился билет для веб службы с SPN вида HTTP/srv-web.holding.com.

Дополнительно можем скачать диагностическую страницу, описанную в статье «Microsoft Learn : ASP.NET Authentication test page». Ссылка на архив на странице первоисточника битая, поэтому вот копия.

Распаковываем содержимое архива в корневой каталог сайта в подкаталог /authpage и переходим в клиентском браузере по ссылке srv-web.holding.com/authpage/default.aspx

Как видим, доменный пользователь успешно аутентифицировался на веб-сайте с использованием аутентификации Kerberos.

После проверки на забываем удалить подкаталог /authpage из корневого каталога сайта.

Вариант 2. Пул IIS выполняется в контексте сервисной учётной записи gMSA

1) Создаём в домене сервисную учётную запись gMSA и разрешаем ей вход на веб-сервер. Пример создания учётной записи с помощью PowerShell можно найти в статье Вики.

2) Регистрируем в домене уникальную запись SPN вида HTTP/<fqdn> для доменной учётной записи gMSA. Обратите внимание на то, что если SPN записи веб-службы ранее были заданы в свойствах учётной записи веб-сервера, то эти прежние SPN записи должны быть удалены, прежде чем их добавлять в свойства gMSA. Важно, чтобы соблюдалась уникальность SPN в рамках всего домена.

Проверим SPN-записи для компьютерной учётной записи веб-сервера и для учётной записи gMSA:

Get-ADComputer -Identity "WEB03" -Properties ServicePrincipalNames | Select-Object -ExpandProperty ServicePrincipalNames
Get-ADServiceAccount -Identity "s-S004$" -Properties ServicePrincipalNames | Select-Object -ExpandProperty ServicePrincipalNames

В следующем примере мы удаляем пару SPN из компьютерной учётной записи веб-сервера (если, конечно, это требуется) и добавляем эту же пару записей в учётную запись gMSA, от имени которой в нашем случае работает пул IIS:

Set-ADComputer -Identity "WEB03" -ServicePrincipalNames @{Remove='HTTP/SRV-Web.holding.com','HTTP/SRV-Web'}
Set-ADServiceAccount -Identity "s-S004$" -ServicePrincipalNames @{Add='HTTP/SRV-Web.holding.com','HTTP/SRV-Web'}

3) Настраиваем пул IIS для запуска от имени gMSA. При этом в окне указания учётной записи Identity не указываем пароль, а лишь указываем имя gMSА в формате вида DOMAINgMSA$.

4) В свойствах сайта в методах аутентификации выключаем анонимную аутентификацию, и включаем аутентификацию Windows.

В свойствах аутентификации Windows убедимся в том, что провайдер «Negotiate» выставлен как приоритетный (в самом верху списка провайдеров). Если NTLM в чистом виде не нужен, можем его вообще удалить из списка включенных провайдеров.

5) В редакторе правки конфигурации сайта «Configuration Editor» выбираем секцию system.webServer/security/authentication/windowsAuthentication. Здесь включаем опцию «useAppPoolCredentials» (True), и убеждаемся в том, что включена опция «useKernalMode» (True).

В некоторых статьях можно найти мнение о том, что опцию useKernalMode при работе пула от gMSA нужно выключать. Но есть также информация о том, что опцию useKernalMode при включённой опции useAppPoolCredentials можно не изменять, так как включённая опция useAppPoolCredentials имеет приоритет над опцией useKernalMode.

6) На клиентской машине проверяем отрабатывает ли аутентификация Kerberos.

Перед проверкой на стороне веб-сервера перезапустим службу IIS (команда iisreset), а на клиентской машине закроем веб-браузер и очистим кеш билетов Kerberos текущего пользователя (команда klist purge).

Снова переходим по ссылке srv-web.holding.com/authpage/default.aspx и смотрим, что покажет нам тестовая страница.

Обратим внимание на то, что теперь в поле Windows identity отображается учётная запись gMSA, от имени которой работает пул IIS.

Этап 2. Настройка разных типов делегирования аутентификации на примере IIS

Описанной выше базовой настройки достаточно лишь для того, чтобы реализовать простую прямую аутентификацию Kerberos между клиентом и веб-сервером. Конфигурация усложняется в том случае, если возникает потребность предоставить доступ аутентифицированному клиенту веб-сервера к какому-либо стороннему ресурсу, находящемуся за веб-сервером, например, к базе данных на другом сервере с SQL Server или к файловой шаре на другом файловом сервере. В этом случае для поддержки, так называемого Double Hop, требуется настройка делегирования Kerberos. То есть, на уровне учётных записей домена мы должны разрешить фронтенд службе (веб-серверу) олицетворять пользователей на бэкенд службе (например, файловом сервере).

С точки зрения Kerberos можно выделить три типа делегирования:

1. Полное делегирование (Unconstrained Delegation);
2. Классическое ограниченное делегирование (Constrained Delegation);
3. Ограниченное делегирование на основе ресурсов (Resource Based Constrained Delegation).

Тип 1. Полное делегирование (Unconstrained Delegation)

Для включения этого типа делегирования нужно обладать правами уровня администратора домена или привилегией SeEnableDelegationPrivilege. Включение этого типа делегирования влияет на содержимое атрибута userAccountControl (включается флаг TRUSTED_FOR_DELEGATION).

В графической оболочке в свойствах учётных записей компьютеров на вкладке «Delegation» определяется вариантом «Trust this computer for delegation to any service (Kerberos only)».

В свойствах учётных записей пользователей вкладка «Delegation» отображается только для пользователей, имеющих зарегистрированные SPN-записи в атрибуте servicePrincipalName. Здесь вариант полного делегирования называется по аналогии — «Trust this user for delegation to any service (Kerberos only)».

Для сервисных учётных записей gMSA нет возможности управлять делегированием в графической оболочке, но можно сделать это с помощью PowerShell. Приведу примеры команд, используемых для управления делегированием gMSA.

Проверяем, включено ли полное делегирование:

Get-ADServiceAccount -Identity "s-S004$" -Property TrustedForDelegation

Включаем полное делегирование:

Set-ADServiceAccount -Identity "s-S004$" -TrustedForDelegation $true

Отключаем полное делегирование:

Set-ADServiceAccount -Identity "s-S004$" -TrustedForDelegation $false

Важно понимать то, что «Unconstrained Delegation» это самый «древний» и самый худший, с точки зрения безопасности, вариант делегирования Kerberos. Поэтому следует отказаться от его использования. Об опасности этого варианта написано не мало статей, например, «Semperis : Unconstrained Delegation in Active Directory Leaves Security Gaps».

Тип 2. Ограниченное делегирование (Constrained Delegation)

Для включения этого типа делегирования нужно обладать правами уровня администратора домена или привилегией SeEnableDelegationPrivilege.

Фактически это делегирование настраивается с помощью изменения содержимого атрибута msDS-AllowedToDelegateTo для учётной записи, от имени которой работает фронтенд служба. В этот атрибут вписываются бэкенд службы в формате SPN, в сторону которых фронтенд службе разрешено транслировать учётные данные аутентифицированных пользователей.

Порядок настройки ограниченного делегирования опять же зависит от того, в контексте какой учётной записи выполняется пул приложений IIS.

Вариант 1. Пул IIS выполняется в контексте учётной записи самого веб-сервера

Например, у нас есть сайт IIS, пул которого работает в контексте учётной записи самого веб-сервера (Identity = ApplicationPoolIdentity) и мы подключаем в качестве виртуального каталога этого веб-сайта IIS файловую шару с отдельного файлового сервера, чтобы аутентифицированные пользователи сайта могли скачивать файлы с этой шары через этот виртуальный каталог.

В этом случае нам потребуется в свойствах компьютерной учётной записи веб-сервера выбрать вариант «Trust this computer for delegation to specified services only» > «Use Kerberos only» и в поле описания служб добавить службу cifs от файлового сервера.

При этом обратите внимание на то, что для возможности скачивания файлов с файлового сервера через веб-службу, нам потребуется обеспечить право на чтение в соответствующей файловой шаре как самим конечным пользователям, так и учётной записи веб-сервера. Если этого не сделать, то при попытке перехода по URL-ссылке, ведущей в подкаталоги шары файлового сервера, мы будем получать от веб-сервера ошибку HTTP 500. Как я понял, это связано с тем, что IIS пытается найти и прочитать файл web.config в конечном подкаталоге, и если учётной записи пула приложений IIS не хватает прав на чтение, чтобы выполнить эту операцию, то мы и получаем эту самую 500 ошибку.

После настройки делегирования, если мы заглянем в свойства атрибута msDS-AllowedToDelegateTo у учётной записи веб-сервера, то увидим указанные нами бэкенд службы через вкладку «Delegation».

В принципе этой настройки достаточно, чтобы делегирование заработало и пользователи, успешно прошедшие аутентификацию Kerberos на веб-сайте IIS, могли скачивать файлы шары файлового сервера через виртуальный каталог веб-сайта.

Вариант 2. Пул IIS выполняется в контексте сервисной учётной записи gMSA

Если пул IIS работает в контексте учётной записи gMSA, то нам потребуется настроить делегирование не для учётной записи веб-сервера, а для учётной записи gMSA. Сделать это можно с помощью PowerShell, так как это описано в статье «Microsoft Learn : Configuring Kerberos delegation for group Managed Service Accounts».

Чтобы проверить текущие настройки делегирования для учётной записи gMSA, выполним команду вида:

Get-ADServiceAccount -Identity "s-S004$" -Properties TrustedForDelegation,TrustedToAuthForDelegation,msDS-AllowedToDelegateTo

Чтобы включить ограниченное делегирование с использованием только протокола аутентификации Kerberos выполним команду вида:

Set-ADAccountControl -Identity "s-S004$" -TrustedForDelegation $false -TrustedToAuthForDelegation $false

Это аналогично выбору переключателя «Trust this computer for delegation to specified services only» > «Use Kerberos Only«).

Это как раз то, что нужно сделать нам, исходя из нашего примера с фронтендом на веб-сервере и бэкендом на файловом сервере.

В тех случаях, когда нужно включить ограниченное делегирование с использованием любых протоколов аутентификации, используется команда следующего вида:

Set-ADAccountControl -Identity "s-S004$" -TrustedForDelegation $false -TrustedToAuthForDelegation $true

Это аналогично выбору переключателя «Trust this computer for delegation to specified services only» > «Use Any Authentication Protocol«. Обратите внимание на то, что в этом случае в атрибуте userAccountControl включается флаг TRUSTED_TO_AUTH_FOR_DELEGATION.

Следующим шагом нам нужно заполнить перечень SPN для разрешённых бэкенд служб в атрибуте msDS-AllowedToDelegateTo учётной записи gMSA. В нашем примере это делается следующей командой:

Set-ADServiceAccount -Identity "s-S004$" -Add @{'msDS-AllowedToDelegateTo'='cifs/FSCL02','cifs/FSCL02.holding.com'}

По окончании настройки снова проверяем свойства учётной записи gMSA:

Get-ADServiceAccount -Identity "s-S004$" -Properties TrustedForDelegation,TrustedToAuthForDelegation,msDS-AllowedToDelegateTo

Соответственно, если теперь в графической оболочке заглянем в свойства учётной записи gMSA, то увидим заполненный атрибут msDS-AllowedToDelegateTo (редактировать его при необходимости, можно и здесь, а не через PowerShell).

Обратите внимание на то, что, в рамках нашего примера, для возможности скачивания файлов с файлового сервера через веб-службу, нам потребуется обеспечить право на чтение в соответствующей файловой шаре как самим конечным пользователям, так и учётной записи gMSA, от имени которой выполняется пул IIS на веб-сервере.

Для вступления изменений в силу на веб-сервере перезапустим IIS командой iisreset (или просто перезагрузим веб-сервер).

Теоретически проделанной настройки должно быть достаточно, чтобы делегирование заработало и пользователи, успешно прошедшие аутентификацию Kerberos на веб сайте IIS, могли скачивать файлы шары файлового сервера через виртуальный каталог веб-сайта. Но фактически это не так, так как на практике при ограниченном делегировании доступа к файловой службе (CIFS) мы столкнёмся с проблемой, описанной в статье «KB2602377 : Constrained delegation for CIFS fails with ACCESS_DENIED error».

Эта статья предлагает нам 2 обходных решения.

Первое обходное решение — это не использовать для ограниченного делегирования к службе CIFS сервисную учётную запись, а использовать учётную запись компьютера.  То есть предполагается, что в нашем случае пул IIS (фронтэнд-служба), обращающийся к внешней сетевой шаре (бэкенд-служба) должен работать не в контексте gMSA, а в контексте системы (в IIS в свойствах пула параметр Identity = ApplicationPoolIdentity).

Если же всё-таки по каким-то причинам нам нужно, чтобы пул IIS работал от имени gMSA, то можно воспользоваться вторым обходным решением из вышеупомянутой статьи. Это решение подразумевает то, что помимо выполнения настройки делегирования для gMSA, нам потребуется сделать дополнительную «костыльную» настройку делегирования для компьютерной учётной записи веб-сервера.

После сделанных изменений перезагружаем веб-сервер WEB03.

В конечном итоге, в рассматриваемом нами примере, для того, чтобы заработало делегирование к CIFS для учётной записи gMSA (s-004$), используемой для пула IIS на веб-сервере (WEB03) с подключением к шаре стороннего файлового сервера (FSCL02), потребуется реализовать следующую «костыльную» и абсурдную, на мой взгляд, конфигурацию:

После этого пользователи веб-сервера действительно смогут скачивать файлы через виртуальный каталог, ссылающийся на шару на файловом сервере.

В случае, если нам потребуется вернуть учётную запись gMSA в исходное состояние и полностью отключить делегирование, то можно использовать команды следующего вида:

Set-ADAccountControl -Identity "s-S004$" -TrustedForDelegation $false -TrustedToAuthForDelegation $false
Set-ADServiceAccount -Identity "s-S004$" -Clear 'msDS-AllowedToDelegateTo'

Тип 3. Ограниченное делегирование на основе ресурсов (Resource Based Constrained Delegation)

Ограниченное делегирование на основе ресурсов Resource Based Constrained Delegation (RBCD) — это технология, доступная начиная с Windows Server 2012.

Если при использовании классического Constrained Delegation нам требуется настройка атрибутов msDS-AllowedToDelegateTo и userAccountControl для учётной записи, от имени которой работает фронтенд-служба (в нашем примере это учётная запись пула IIS и/или самого веб-сервера), то при настройке RBCD используется обратный подход, то есть делегирование настраивается в свойствах учётной запись бэкенд-сервиса (в нашем примере это учётная запись файлового сервера).

Более того, классическое Constrained Delegation для настройки требует привилегии уровня администратора домена, а для настройки RBCD достаточно иметь лишь доступ на изменение учётной записи бэкенд-сервиса (файлового сервера). При этом в ходе настройки делегирования нет необходимости указывать SPN служб, то есть доверительные отношения выстраиваются на уровне учётных записей домена (подразумевается доверие любых служб в рамках отношений между бэкендом и фронтендом). Разумеется, это имеет как свои плюсы, так и свои минусы, но концептуально RBCD позиционируется, как более простой и удобный тип делегирования, чем классическое Constrained Delegation. Например, RBCD позволяет управлять делегированием между разными доменами Active Directory, в то время как классическое делегирование работает лишь в рамках одного домена.

Этот тип делегирования работает с помощью управления атрибутом msDS-AllowedToActOnBehalfOfOtherIdentity и настраивается только через PowerShell с помощью параметра -PrincipalsAllowedToDelegateToAccount в командлетах Set-ADUser, Set-ADComputer, Set-ADServiceAccount.

Рассмотрим типичные команды, используемые для настройки RBCD.

Проверяем текущее состояние настроек RBCD для учётных записей разного типа:

Get-ADComputer -Identity "<имя учётной записи компьютера бэкенд-службы>" -Properties PrincipalsAllowedToDelegateToAccount
Get-ADServiceAccount -Identity "<имя учётной записи gMSA бэкенд-службы>$" -Properties PrincipalsAllowedToDelegateToAccount

Настраиваем делегирование на примере служб, работающих от имени учётных записей gMSA:

Set-ADServiceAccount -Identity "<имя учётной записи gMSA бэкенд-службы>$" -PrincipalsAllowedToDelegateToAccount $(Get-ADServiceAccount -Identity "<имя учётной записи gMSA фронтенд-службы>$")

Если нужно делегировать несколько фронтэнд-служб, то можно воспользоваться конструкцией следующего вида

$BackendSVC = "<имя учётной записи gMSA бэкенд-службы>$"
$FrontendSVC1 = Get-ADServiceAccount -Identity "<имя учётной записи gMSA фронтэнд-службы 1>$"
$FrontendSVC2 = Get-ADServiceAccount -Identity "<имя учётной записи gMSA фронтэнд-службы 2>$"
$Frontends = @($FrontendSVC1,$FrontendSVC2)
Set-ADServiceAccount -Identity $BackendSVC -PrincipalsAllowedToDelegateToAccount $Frontends

Экспериментируя с настройкой RBCD можно обнаружить не совсем очевидную особенность, которую можно отнести к разряду недостатков. Дело в том, что в атрибут msDS-AllowedToActOnBehalfOfOtherIdentity нельзя записать несколько значений разного типа. То есть, либо мы туда пишем учётные записи типа компьютер, либо учётные записи типа gMSA. При попытке указания коллекции из учётных записей разного типа, мы получим от PowerShell ошибку следующего вида:

Set-ADComputer : An AD Property Value Collection may only contain values of the same type. Specified value of type 'Microsoft.ActiveDirectory.Management.ADComputer' does not match the existing type of 'Microsoft.ActiveDirectory.Management.ADServiceAccount'...

Вернёмся к нашему примеру, с вариантом, в котором для учётной записи gMSA (s-S004), от имени которой выполняется пул IIS на веб-сервере (WEB03), требуется разрешить передачу учётных данных пользователей веб-сервера на сторонний файловый сервер (FSCL02). В этом примере команда настройки RBCD будет иметь следующий вид:

Set-ADComputer -Identity "FSCL02"-PrincipalsAllowedToDelegateToAccount $(Get-ADServiceAccount "s-S004$")

И опять же, с теоретической точки зрения, такой настройки должно быть достаточно, чтобы пользователи смогли скачивать файлы с шары файлового сервера через веб-приложение IIS. Однако, на практике это работать не будет, предположительно, всё из-за той же проблемы, которую мы упомянули ранее со ссылкой на статью KB2602377. То есть, в этом случае, чтобы делегирование заработало, опять потребуется сделать дополнительную «костыльную» настройку делегирования для компьютерной учётной записи веб-сервера.

После сделанных изменений перезагружаем веб-сервер WEB03.

В конечном итоге, в рассматриваемом нами примере, для того, чтобы заработало делегирование RBCD, потребовалось реализовать следующую, опять же «костыльную», конфигурацию:

После этого пользователи веб-сервера действительно смогли скачивать файлы через виртуальный каталог, ссылающийся на шару на файловом сервере.

В случае, если нам потребуется вернуть учётную запись бэкенда в исходное состояние и полностью отключить делегирование RDCB, то для очистки атрибута msDS-AllowedToActOnBehalfOfOtherIdentity можно использовать команду следующего вида:

Set-ADComputer -Identity "FSCL02" -PrincipalsAllowedToDelegateToAccount $null

Общие выводы по типам делегирования

Итак, мы рассмотрели три типа делегирования и теперь можно оценить ситуацию в целом.

Однозначно можно сказать, что следует воздерживаться от применения на практике полного делегирования (Unconstrained Delegation), и если где-то требуется настройка делегирования, то всегда правильней использовать ограниченное делегирование (Constrained Delegation). Что-же касается ограниченного делегирования на основе ресурсов (Resource Based Constrained Delegation), то от него у меня двоякие впечатления. С одной стороны RBCD более прост и действительно может оказаться полезен, например, в междоменных отношениях. С другой стороны, потеря контроля над чувствительными операциями делегирования со стороны администраторов домена в пользу администраторов отдельно взятых ресурсов, может привести к неприятным ситуациям с точки зрения информационной безопасности. В качестве наглядного примера можно ознакомится со статьёй «Decoder’s Blog : Donkey’s guide to Resource Based Constrained Delegation Exploitation – from simple user to (almost) DA».

Есть также справедливое мнение, что, в принципе, все три типа делегирования потенциально опасны, и степень рисков может напрямую завесить о правильности выбора типа делегирования и корректности настройки делегирования: «harmj0y : Another Word on Delegation».

Если у вас возникнет желание оценить уровень «развязности» настройки делегирования в текущей доменной инфраструктуре, то получить сводную картину по учётным записям с настроенным делегированием поможет скрипт, позаимствованный из статьи «Microsoft Learn : Get rid of accounts that use Kerberos Unconstrained Delegation».

Что же касается примера с делегированием IIS->FS, которое мы сквозным образом рассматривали в ходе этой статьи, то у меня сложилось впечатление, что, в данном конкретном случае, для запуска пула IIS будет более правильно использовать контекст самой системы веб-сервера(Identity = ApplicationPoolIdentity), нежели контекст учётной записи gMSA. Так как преимущества, которые нам даёт использование gMSA, в данном конкретном случае, из-за костылей KB2602377 «помножаются на ноль», делая конечную конфигурацию более громоздкой и менее безопасной.

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

• Jawahar Ganesh S : Setting up Kerberos Authentication for a Website in IIS
• Microsoft Learn : Troubleshoot Kerberos failures — Internet Information Services
• Database Administrators Stack Exchange : how to stop using sql server login credentials in a linked server?
• Microsoft Learn : Making the second hop in PowerShell Remoting — PowerShell
• hackndo : Kerberos Delegation
• Patrick Keisler : Setup Kerberos Constrained Delegation for Group Managed Service Accounts
• Josh Corrick : Kerberos Constrained Delegation with Group Managed Service Accounts
• Mark Southwell : Resource Based Kerberos Constrained Delegation
• Nichlas Falk : Re-becoming the securest constrained delegation we never weren’t
• Jeff Warren : Resource-Based Constrained Delegation Abuse
• Daniel López Jiménez : You Do (Not) Understand Kerberos Delegation

В этой статья, мы рассмотрим, как настроить 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.

Уровень сложности
Средний

Время на прочтение
4 мин

Количество просмотров 3.1K

Представляю уважаемому сообществу руководство по настройке доменной аутентификации при работе из Java с MSSQL.

Данное руководство создано для администраторов БД, с помощью него можно продемонстрировать возможность использования доменной аутентификации для разработчиков Java и DevOps.

Столкнувшись с одной достаточно большой инфраструктурой, в которой широко используется разработка на Java, я был удивлен, что все подключения осуществляются с SQL аутентификацией, что не только не безопасно, но и не удобно. Последней каплей стало предложение распространить на большое количество SQL серверов встроенную учетную запись и создать механизм аудита и плановой смены паролей. Я же решил посмотреть, можно ли из Java работать со встроенной windows аутентификацией. Мой опыт разработчика в основном был связан с разработкой на C# под windows и, соответственно, Java, особенно под linux, была мне в новинку. Но и это препятствие было преодолено.

Итак сразу вывод: Java c использованием MS JDBC драйвера с MSSQL работать может, настройка проста, если Windows машин находится в домене, то вообще ничего делать не нужно, если Windows не в домене или это Linux машина, то нужно настроить DNS и прописать параметры в одном файле krb5.conf/ini.

Не буду утомлять читателей рассказами о проблемах и поисках решений, а сразу приведу пример рабочего кода, комманды установки необходимых пакетов и комманды запуска с указанием пути до JDBC.

Тестовый стенд

• Домен p4.local, два контроллера, с DNS, Win Server 2019. Никаких специальных настроек Kerberos не производилось;
• SQLCore1 Win Server 2019, машина в домене, standalone SQL Server 2019 (работает под локальной сервисной учетной записью SPN поумолчанию);
• Ws1-test Win10 LTSC, не доменная машина;
• CentOSJava1 7.9.2009 (Core) Java 20;
• CentOSJava2 7.9.2009 (Core) Java 11;
• Доменная учетная запись p4\javaWin c паролем !Qaz123wsx .

Настройка CentOS

• Необходимо прописать доменные dns либо при установке, либо в интерфейсе nmtui
• Yum update
• Yum -y install wget (нужен для скачивания архивов)
• Yum -y install krb5-workstation (позволяет CentOS работать с Kerberos)
• Работаем из-под пользователя root, в домашнем каталоге.

Установка Java 20 и JDBC 12 на CentOSJava1

• wget https://download.oracle.com/java/20/latest/jdk-20_linux-x64_bin.rpm
• yum localinstall jdk-20_linux-x64_bin.rpm
• wget https://go.microsoft.com/fwlink/?linkid=2222954
• tar -xf sqljdbc_12.2.0.0_enu.tar

Установка Java 11 и JDBC 7 на CentOSJava2

• yum -y install java-11-openjdk java-11-openjdk-devel
• wget https://download.microsoft.com/download/6/9/9/699205CA-F1F1-4DE9-9335-18546C5C8CBD/sqljdbc_7.4.1.0_enu.tar.gz
• tar -xf sqljdbc_7.4.1.0_enu.tar.gz

Установка Java на Windows

Для запуска нескомпилированных файлов с кодом (.java) на виндовс необходимо установить пакет JDK https://docs.oracle.com/en/java/javase/20/install/installation-jdk-microsoft-windows-platforms.html

Сам код Java который будет проверять тип подключения к MSSQL выполняя следующий запрос:
select @@servername as srv, system_user as usr, auth_scheme from sys.dm_exec_connections where session_id=@@spid

Запуск для java 20 и 12 JDBC на CentOSJava1

java -cp .:/root/sqljdbc_12.2/enu/mssql-jdbc-12.2.0.jre11.jar KerbautApplication.java

Запуск для java 11 и 7 JDBC CentOSJava2

java -cp .:/root/sqljdbc_7.4/enu/mssql-jdbc-7.4.1.jre11.jar KerbautApplication.java

Запуск из под windows

java.exe -cp «C:\java\sqljdbc_12.2.0.0_enu\sqljdbc_12.2\enu\mssql-jdbc-12.2.0.jre11.jar» KerbautApplication.java

Я сам не являюсь ни разработчиком Java, ни администратором linux, буду признателен за комментарии и замечания по теме.

Надеюсь данная статья будет полезна уважаемому сообществу.