В этой статье мы рассмотрим примеры базовой настройки протокола аутентификации 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А в формате вида DOMAIN\gMSA$.
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 можно выделить три типа делегирования:
- Полное делегирование (Unconstrained Delegation);
- Классическое ограниченное делегирование (Constrained Delegation);
- Ограниченное делегирование на основе ресурсов (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
Пошаговая инструкция по настройке на веб-сайте IIS на Windows Server 2012 R2 прозрачной авторизации доменных пользователей в режиме SSO (Single Sign-On) по протоколу Kerberos.
На веб сервере запустите консоль IIS Manager, выберите нужный сайт и откройте раздел Authentication. Как вы видите, по умолчанию разрешена только анонимная аутентификация (Anonymous Authentication). Отключаем ее и включаем Windows Authentication (IIS всегда сначала пытается выполнить анонимную аутентификацию).
Открываем список провайдеров, доступных для Windows аутентификации (Providers). По умолчанию доступны два провайдера: Negotiate и NTLM. Negotiate – это контейнер, который в качестве первого метода проверки подлинности использует Kerberos, если эта аутентификация не удается, используется NTLM. Необходимо, чтобы в списке провайдеров метод Negotiate стоял первым.
Следующий этап – регистрация Service Principal Name (SPN) записей для имени сайта, к которому будут обращаться пользователи. В том случае, если сайт IIS должен быть доступен только по имени сервера, на котором он расположен (http://server-name или http://server-name.contoso.com), создавать дополнительные SPN записи не нужно (SPN записи уже имеются в учетной записи сервера в AD). При использовании адреса сайта, отличного от имени хоста, или при построении веб-фермы с балансировкой, придется привязывать дополнительные записи SPN к учётной записи сервера или пользователя.
Предположим, у нас имеется ферма IIS серверов. В этом случае оптимально создать отдельную учетную запись в AD и привязать SPN записи к ней. Из-под этой же учетной записи будут запускать целевой Application Pool нашего сайта.
Создадим доменную учетную запись iis_service. Убедимся, что SPN записи для этого объекта не назначены (атрибут servicePrincipalName пустой).
Предположим, что сайт должен отвечать по адресам _http://webportal and _http://webportal.contoso.loc. Мы должны прописать эти адреса в SPN атрибут служебной учетной записи
Setspn /s HTTP/webportal contoso\iis_service
Setspn /s HTTP/webportal.contoso.loc contoso\iis_service
Таким образом, мы разрешим этой учетной записи расшифровывать тикеты Kerberos при обращении пользователей к данным адресам и аутентифицировать сессии.
Проверить настройки SPN у учетной записи можно так:
setspn /l iis_service
Совет. Kerberos не будет работать корректно при наличии дублирующих SPN у разных записей домена. С помощью следующей команды, убедитесь, что дубликатов SPN в домене нет:
setspn –x
Следующий этап – настройка в IIS Application Pool для запуска из-под созданной сервисной учетной записи.
Выберите Application Pool сайта (в нашем примере это DefaultAppPool).
Откройте раздел настроек Advanced Settings и перейдите к параметру Identity.
Измените его с ApplicationPoolIdentity на contoso\iis_service.
Затем в консоли IIS Manager перейдите на свой сайт и выберите секцию Configuration Editor.
В выпадающем меню перейдите в раздел system.webServer > security > authentication > windowsAuthentication
Измените useAppPoolCredentials на True.
Тем самым мы разрешим IIS использовать доменную учетку для расшифровки билетов Kerberos от клиентов.
Перезапустим IIS командой:
iisreset
Аналогичную настройку нужно выполнить на всех серверах веб-фермы.
Протестируем работу Kerberos авторизации, открыв в браузере клиента (браузер нужно предварительно настроить для использования Kerberos) адрес _http://webportal.contoso.loc
Примечание. В моем примере, на IE11 сразу авторизоваться не получилось. Пришлось добавить адрес в доверенные и в настройках Trusted Zones Sites выставить значение параметра User Authentication -> Logon на Automatic logon with current user name and password
Убедится, что для авторизации на сайте используется Kerberos можно с помощью инспектирования HTTP трафика утилитой Fiddler.
Запускаем Fiddler, в браузере открываем целевой сайт. В левом окне находим строку обращения к сайте. Справа переходим на вкладку Inspectors. Строка Authorization Header (Negotiate) appears to contain a Kerberos ticket, говорит о том, что для авторизации на IIS сайте использовался протокол Kerberos.
Конечная цель проектов импортозамещения в ИТ — полный отказ от операционной системы Windows. Но, как говорится, гладко было на бумаге, да забыли про овраги. Может так оказаться, что быстро заменить какие-то клиентские корпоративные приложения, написанные под эту операционную систему, не получится. В этом случае вам может пригодиться возможность присоединения Windows-компьютеров к домену ALD Pro.
В этой статье я расскажу, как добиться максимальной функциональности от такого сценария развертывания, и презентую утилиту нашей собственной разработки aldpro-join. С ее помощью можно решить проблему настройки рабочих станций всего за пару кликов. Если это именно то, о чем вы хотели узнать, но не знали, кого спросить, — вы на правильном пути. Поехали!
Материал будет полезен даже в том случае, если в вашей инфраструктуре пока еще используется «ванильная» система FreeIPA.
Присоединение Windows клиентов к домену FreeIPA не находится в фокусе внимания команды разработчиков этой службы каталога, так как проект ставит своей целью не заменить Active Directory для Windows-компьютеров, а создать аналогичное решение для компьютеров под управлением операционной системы Linux. Однако компания Microsoft еще с версии Windows 2000 поддерживает возможность интеграции своих ОС с областями Kerberos, которые совместимы с RFC 2136, а центр распределения ключей FreeIPA работает как раз на базе эталонной реализации MIT KDC. То есть ничто не препятствует тому, чтобы вводить Windows-компьютеры напрямую в домен FreeIPA.
Более того, разработчики FreeIPA реализовали возможность интеграции своего домена с Active Directory на уровне доверительных отношений за счет компонента Samba AD, поэтому контроллеры домена, помимо Kerberos, поддерживают такие протоколы, как NetBIOS, SMB, Netlogon (MS-NRPC) и NTLM. В базе данных DNS есть SRV записи по стандартам Microsoft, а Kerberos-билеты содержат не только аутентификационные данные, но и сертификат PAC, включающий SID’ы пользователя и всех его групп.
Все эти особенности открывают дополнительные возможности по работе Windows-компьютеров в составе домена FreeIPA. Ниже я расскажу, как правильно задействовать эти отличительные черты, чтобы получить доступ к следующим функциям:
-
вход в ОС Windows с помощью учетных записей из домена ALD Pro;
-
прозрачная аутентификация при обращении пользователя к керберизированным ресурсам, например файловым серверам;
-
получение уведомлений об истечении срока действия пароля и возможность сменить пароль штатными функциями ОС Windows;
-
предоставление доменным пользователям прав доступа к локальным ресурсам Windows-компьютера с учетом их участия в доменных группах;
-
синхронизация времени рабочей станции с временем на контроллерах домена;
-
динамическое изменение DNS-записей в домене при изменении IP-адреса на сетевом интерфейсе Windows-компьютера.
1. Настройка Kerberos-аутентификации
Компьютеру для работы в составе домена требуется учетная запись, с помощью которой он будет выполнять авторизованные LDAP-запросы к каталогу и проверять аутентичность пользователей по протоколу Kerberos V5.
Создать эту учетную запись можно на контроллере с помощью команды host-add утилиты ipa, в параметрах которой нужно указать полное доменное имя компьютера и его IP-адрес. Перед выполнением команды нужно произвести Kerberos-аутентификацию привилегированной учетной записью администратора.
Обратите внимание, что служба каталога FreeIPA автоматически приведет доменное имя компьютера к нижнему регистру.
admin@dc-1:~$ kinit admin
admin@dc-1:~$ ipa host-add DESKTOP-7VKREUO.ald.company.lan --ip-address=10.0.1.151
-----------------------------------------------
Добавлен узел "desktop-7vkreuo.ald.company.lan"
-----------------------------------------------
Имя узла: desktop-7vkreuo.ald.company.lan
Имя учётной записи: host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN
Псевдоним учётной записи: host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN
Link to department: ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
Link to head department: ald.company.lan
Пароль: False
Таблица ключей: False
Managed by: desktop-7vkreuo.ald.company.lanЧтобы использовать новую учетную запись, ей нужно назначить пароль. Сделать это можно с помощью утилиты ipa-getkeytab, которая создаст необходимые Kerberos-ключи, запишет их в атрибут krbPrincipalKey учетной записи и сохранит в указанный keytab-файл.
admin@dc-1:~$ sudo ipa-getkeytab -p host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN \
-P -k /tmp/client.keytab << EOF
Windows10ComputerPassword
Windows10ComputerPassword
EOF
Новый пароль учётной записи:
Проверка пароля учётной записи:
Таблица ключей успешно получена и сохранена в: /tmp/client.keytabгде:
-
p — указывает имя Kerberos-принципала, для которого будет сгенерирована связка ключей. Его можно взять из предыдущего шага в текстовом выводе команды host-add.
-
P — указывает, что пароль учетной записи должен быть задан вручную с помощью интерактивного ввода. Если этот параметр не будет задан, то система сгенерирует пароль автоматически, но не отобразит его на экране. Поэтому такой способ подходит только в случае, если мы планируем использовать keytab-файл.
-
k — указывает путь к keytab-файлу, в который нужно сохранить Kerberos-ключи. Параметр является обязательным — невозможно назначить пароль без создания keytab-файла.
-
<< EOF … EOF — позволяет перенаправить следующие две строки в качестве пароля и подтверждения. Не забудьте отключить занесение команды в history, например добавив символ пробела перед командой sudo.
Дополнительно можно воспользоваться следующими параметрами:
-
s — задает fqdn имя контроллера домена, через который следует выполнить установку пароля. По умолчанию используются настройки из /etc/ipa/default.conf.
-
e — задает через запятую способы хеширования паролей. В крайних версиях FreeIPA утилита ipa-getkeytab использует ключи AES256-CTS-HMAC-SHA1-96 и AES128-CTS-HMAC-SHA1-96, совместимые с современными дистрибутивами ОС Microsoft, включая Windows 10. Поэтому задавать параметр не требуется. Полный перечень хешей, поддерживаемых FreeIPA, можно посмотреть командой «ipa-getkeytab —permitted-enctypes». Для Windows это можно узнать в справке к утилите ksetup командой «ksetup.exe /?».
При желании вы можете проверить содержимое keytab-файла с помощью утилиты klist:
admin@dc-1:~$ sudo klist -ket /tmp/client.keytab
Keytab name: FILE:/tmp/client.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
1 19.11.2023 16:05:15 host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96)
1 19.11.2023 16:05:15 host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96)Но сам keytab-файл нам не потребуется, потому что утилите ksetup.exe пароль нужно будет передать открытым текстом. Используя это значение, утилита сгенерирует несколько хешей, не совместимых с Kerberos, таких как NTLM и SHA1, и сохранит пароль «как есть» в менеджере учетных записей безопасности (Security Accounts Manager, SAM). С помощью утилиты Mimikatz можно убедиться, что Windows хранит пароль компьютера в том числе и открытым текстом.
mimikatz # sekurlsa::logonpasswords
...
Authentication Id : 0 ; 2053055 (00000000:001f53bf)
Session : Interactive from 2
User Name : DWM-2
Domain : Window Manager
Logon Server : (null)
Logon Time : 1/11/2024 10:39:38 AM
SID : S-1-5-90-0-2
msv :
[00000003] Primary
* Username : DESKTOP-7VKREUO$
* Domain : ALD
* NTLM : cb4cacacf93394406beb092f12ac797c
* SHA1 : 4fe309666be5630192c09851b20be577a914fee8
tspkg :
wdigest :
* Username : DESKTOP-7VKREUO$
* Domain : ALD
* Password : (null)
kerberos :
* Username : DESKTOP-7VKREUO$
* Domain : ALD.COMPANY.LAN
* Password : Windows10ComputerPassword
ssp : KO
credman :
...Чтобы Windows-компьютер работал в составе домена, в качестве DNS-сервера у него должен быть указан IP-адрес контроллера домена ALD Pro. Дополнительно рекомендуется отключить протокол NetBIOS, иначе вход в систему будет выполняться с большой задержкой. А вот задавать DNS-суффикс необязательно, так как утилита ksetup установит глобальный DNS-суффикс для компьютера и короткие имена будут автоматически дополняться до FQDN-имен.
Продемонстрирую внесение указанных настроек
1. Откройте оснастку «Network Connections» (ncpa.cpl), затем свойства сетевого интерфейса, далее выберите протокол «Internet Protocol Version 4 (TCP/IPv4)» и нажмите кнопку «Properties», см. рисунок 1.
Внесите требуемые значения, см. рисунок 2.
IP address: 10.0.1.151
Subnet mask: 255.255.255.0
Default gateway: 10.0.1.1
Preferred DNS server: 10.0.1.11
Windows-компьютер может совершать ненужные запросы SAM LOGON к контроллеру домена — это сильно замедляет процедуру входа. Чтобы этого не происходило, нажмите кнопку «Advanced» — так вы перейдете к расширенным настройкам. На вкладке «WINS» отключите NetBIOS для сетевого подключения, см. рисунок 3.
Чтобы Windows-компьютер работал в составе домена, ему нужно предоставить логин и пароль от доменной учетной записи, которую мы создали ранее. Логин учетной записи соответствует имени компьютера. Посмотреть текущее значение и изменить его можно с помощью стандартной оснастки sysdm.cpl (System Device Manager), см. рисунок 4.
Пароль учетной записи компьютера можно задать с помощью команды SetComputerPassword утилиты ksetup на Windows-компьютере.
> ksetup.exe /SetComputerPassword Windows10ComputerPasswordгде:
-
/SetComputerPassword — команда утилиты ksetup, с помощью которой можно установить пароль для доменной учетной записи компьютера. Она сохраняет исходный текст пароля и несколько хешей в диспетчере учётных записей безопасности (Security Account Manager, SAM), то есть в защищенной части реестра.
-
Windows10ComputerPassword — пароль, который мы использовали ранее при создании учетной записи компьютера в домене. Напоминаю, что нужно использовать длинные пароли, сгенерированные случайным образом.
Теперь все готово для того, чтобы переключить компьютер на работу в Kerberos-области, совместимой с RFC1510. Для этого нужно выполнить команду SetRealm утилиты ksetup.
> ksetup.exe /SetRealm ALD.COMPANY.LANгде:
-
/SetRealm — команда задает Kerberos-область, создавая ключ в разделе реестра «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains».
-
ALD.COMPANY.LAN — область Kerberos нашего домена ALD Pro.
После изменения имени компьютера, пароля или принадлежности компьютера к домену нужно выполнить перезагрузку компьютера, чтобы указанные изменения вступили в силу.
Текущие настройки можно посмотреть с помощью команды DumpState:
> ksetup.exe /DumpState
default realm = ALD.COMPANY.LAN (external)
ALD.COMPANY.LAN:
(no kdc entries for this realm)
Realm Flags = 0x0No Realm Flags
No user mappings defined.Отмечу еще несколько моментов, которые можно встретить в Интернете. Ниже объясню, почему они не требуются или могут быть даже вредны:
-
Команда SetRealm первоначально называлась SetDomain, и этот алиас продолжает работать до сих пор. Поэтому во многих инструкциях остается такой вариант написания, но команда «установить область» лучше отражает тот факт, что Kerberos-аутентификация Windows-компьютеров возможна не только в домене Active Directory, но и других реализациях, совместимых с RFC1510. Например, в MIT Kerberos.
-
Довольно часто предлагают с помощью команд /addkdc и /addkpasswd задать адреса серверов, через которые можно выполнять аутентификацию и менять пароль. Указанные рекомендации актуальны при интеграции Windows-машины с простой Kerberos-областью, но в домене ALD Pro (FreeIPA) есть все необходимые SRV-записи, и отказываться от функции автоматического обнаружения этих сервисов не имеет смысла.
-
Иногда можно встретить рекомендации по настройке разрешенных типов шифрования Kerberos через локальную групповую политику «Security Options > Network Security: Configure encryption types allowed for Kerberos». Это может потребоваться только для учетных записей хостов, которые находятся под управлением устаревших Windows 2000, Windows Server 2003 и Windows XP. Современные релизы поддерживают необходимые типы шифрования по умолчанию (AES128_HMAC_SHA1 и AES256_HMAC_SHA1).
-
В большинстве инструкций предлагают настроить сопоставление доменных пользователей на локальные учетные записи с помощью команды «ksetup.exe /mapuser * *», что правильно при интеграции Windows с базовой реализацией MIT Kerberos, в которой нет никаких идентификаторов безопасности Windows. При таком способе настройки вход Kerberos-пользователя аналогичен входу локального пользователя. Разница только в том, что первичная проверка аутентичности выполняется через KDC, а все остальные механизмы работают так же, как если бы вход в систему был выполнен локальной учетной записью.
Однако в службе каталога FreeIPA центр распределения ключей MIT KDC интегрирован с Samba AD, поэтому Kerberos-билеты содержат сертификат PAC со всей необходимой авторизационной информацией, включая идентификатор безопасности пользователя и всех его групп. В силу указанного обстоятельства маппинг учетных записей для FreeIPA делать не нужно. При таком способе настройки будет обеспечиваться полноценная работа под доменной учетной записью: при входе пользователя будет сохраняться его доменный SID, у него будет TGT-билет с полным перечнем групп из PAC-сертификата, он сможет выполнять прозрачную Kerberos-аутентификацию при обращении к файловым серверам и другим керберизированным ресурсам в домене.
Для входа в компьютер с помощью доменной учетной записи в качестве имени пользователя нужно вводить полное имя Kerberos-принципала в формате login@REALM.FQDN. Причем логин может быть задан в любом регистре, а реалм — обязательно прописными буквами.
Операционная система Windows позволяет задать домен для входа по умолчанию, для этого нужно изменить в реестре значение DefaultLogonDomain. Из командной строки это можно сделать с помощью командлета Set-ItemProperty:
Set-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System' -Name 'DefaultLogonDomain' -Value 'ALD.COMPANY.LAN'Однако при использовании домена по умолчанию ОС будет дополнять имена пользователей до формата DefaultLogonDomain\login, который будет усечен до NETBIOS\login — например, ALD\admin. Из-за этого перестанут работать такие важные функции, как вход с экрана блокировки, вход последним пользователем и смена пароля через <ctrl> + <alt> + <del>.
Для устранения указанных проблем, после входа необходимо исправить значения LoggedOnUser и LastLoggedOnUser в реестре, что можно сделать PowerShell-скриптом:
> cat FixPreWindowsNames.ps1
function Fix-PreWindowsName ([string]$Domain, [string]$NetBIOS, [string]$Path, [string]$Parameter){
$Path = 'Registry::' + $Path;
$UsernameComponents = (Get-ItemPropertyValue -Path $Path -Name $Parameter) -split '\\';
if ($UsernameComponents.length -eq 2 -AND $UsernameComponents[0].ToUpper() -eq $NetBIOS){
$UPN = $UsernameComponents[1] + '@' + $Domain;
Set-ItemProperty -Path $Path -Name $Parameter -Value $UPN;
}
}
$Domain = (Get-ItemPropertyValue -Path 'Registry::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters' -Name 'Domain').ToUpper();
$NetBIOS = ($Domain -split '\.')[0];
Fix-PreWindowsName $Domain $NetBIOS 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\' 'LastLoggedOnUser';
foreach($SessionData in Get-ChildItem -Path 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\SessionData'){
Fix-PreWindowsName $Domain $NetBIOS $SessionData.Name 'LoggedOnUser';
}Для автоматического выполнения скрипта после входа в систему можно зарегистрировать следующее задание в планировщике. Скрипт небольшой, поэтому его текст можно передать напрямую в параметре EncodedCommand в формате base64, чтобы не хранить файл где-то на диске:
Register-ScheduledTask
-TaskName 'FixPreWindowsNames'
-Description 'Задача исправляет значения LoggedOnUser и LastLoggedOnUser'
-Trigger (New-ScheduledTaskTrigger -AtLogOn)
-Principal (New-ScheduledTaskPrincipal -UserId 'SYSTEM' -LogonType ServiceAccount)
-Settings (New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries)
-Action (New-ScheduledTaskAction -Execute 'cmd' -Argument $('/c start /min powershell -WindowStyle hidden -EncodedCommand ' + [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes((Get-Content FixPreWindowsNames.ps1))) ) )В качестве промежуточного итога добавлю, что для вывода машины из домена FreeIPA достаточно выполнить команду RemoveRealm и ввести компьютер в рабочую группу:
> ksetup.exe /RemoveRealm 'ALD.COMPANY.LAN'
NOTE: /RemoveRealm requires a reboot to take effect on pre-SP1 Win2000 computers
> Add-Computer -WorkGroupName 'WORKGROUP'
WARNING: The changes will take effect after you restart the computer DESKTOP-7VKREUO.2. Балансировка Kerberos аутентификации с использованием сайтов
Функция «локаций» в домене FreeIPA решает ту же задачу, что и «сайты» Active Directory, но несколько иным образом. Если в AD к сайтам привязываются компьютерные сети, и принадлежность компьютера к сайту определяется его текущим IP-адресом, то в FreeIPA привязка выполняется косвенно через DNS-сервер, который обслуживает запросы компьютера.
Например, если запросить SRV-записи «_kerberos._udp.ald.company.lan» у контроллеров из разных локаций, то dc-1 сделает перенаправление на адрес «hq», а dc-4 на адрес «spb» соответственно. В обоих случаях будет выдан полный перечень всех контроллеров домена с приоритизацией по принадлежности серверов к локациям. Проверку доступности серверов клиент SSSD выполняет в порядке заданных приоритетов.
$ nslookup -type=SRV _kerberos._udp.ald.company.lan dc-1.ald.company.lan
Server: dc-1.ald.company.lan
Address: 10.0.1.11#53
_kerberos._udp.ald.company.lan canonical name = _kerberos._udp.hq._locations.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan service = 0 100 88 dc-2.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan service = 0 100 88 dc-3.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan service = 0 100 88 dc-1.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan service = 50 100 88 dc-4.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan service = 50 100 88 dc-5.ald.company.lan.
$ nslookup -type=SRV _kerberos._udp.ald.company.lan dc-4.ald.company.lan
Server: dc-4.ald.company.lan
Address: 10.0.1.14#53
_kerberos._udp.ald.company.lan canonical name = _kerberos._udp.spb._locations.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan service = 50 100 88 dc-1.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan service = 0 100 88 dc-5.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan service = 50 100 88 dc-3.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan service = 0 100 88 dc-4.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan service = 50 100 88 dc-2.ald.company.lan.Windows-клиент тоже учитывает приоритеты SRV-записей, но запрашивает их по адресам вида «_kerberos._udp.dc._msdcs.ald.company.lan» в соответствии со спецификацией Active Directory (Active Directory Technical Specification, MS-ADTS). Такие записи в домене FreeIPA тоже есть, они добавляются автоматически для поддержки интеграции с Active Directory. Таким образом, для использования географической балансировки достаточно в качестве DNS-сервера указать один из контроллеров FreeIPA.
3. Настройка синхронизации времени
Для корректной работы протокола аутентификации Kerberos V5 необходимо, чтобы разница во времени между клиентом и сервером была не более 5 минут. За синхронизацию времени в операционной системе Windows отвечает служба W32Time (Windows Time Service), которая работает по протоколу NTP (Network Time Protocol). Прочитать и изменить параметры службы можно из командной строки с помощью утилиты w32tm. Параметры хранятся в реестре «Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters»:
> w32tm.exe /query /configuration
...
Type: NTP (Local)
NtpServer: time.windows.com,0x9 (Local)
...В домене Active Directory источниками точного времени для рабочих станций выступают контроллеры домена, выбор которых осуществляется с учетом иерархии домена. Имитировать режим DOMHIER не имеет смысла, т. к. в этом случае служба W32Time будет следовать протоколу MS-SNTP и проверять цифровые подписи пакетов, которых нет в Chrony.
Учитывая сказанное, правильно будет использовать режим manual и указать DNS-имена или IP-адреса конкретных контроллеров домена. Например, если у вас в домене только два контроллера, настроить службу W32Time можно с помощью следующей команды:
> w32tm.exe /config /syncfromflags:manual /manualpeerlist:"dc-1.ald.company.lan,0x9 dc-2.ald.company.lan,0x9" /update где:
-
/config — основная команда, используемая для конфигурирования службы W32Time. С ее помощью можно изменить текущие настройки, задать список используемых серверов времени, тип синхронизации и многое другое.
-
/syncfromflags — устанавливает тип источника для синхронизации времени. Допустимы значения:
-
MANUAL — синхронизация времени с серверами из списка, заданного вручную (Type: NTP).
-
DOMHIER — синхронизация времени с контроллерами в соответствии с иерархией домена (Type: NT5DS).
-
ALL — разрешает использовать любой источник, как внешний сервер, так и контроллеры домена в соответствии с установленной иерархией (Type: AllSync).
-
NO — отключает синхронизацию времени (Type: NoSync).
-
-
/manualpeerlist — задает список DNS-имен и/или IP-адресов серверов, которые могут выступать источниками времени для синхронизации.
Адреса разделяются символом пробела, а в конце каждого адреса через запятую может быть задан дополнительный параметр, значение которого складывается из следующих флагов:
-
0x1 (SpecialInterval) — указывает, что между отправкой запросов к этому серверу нужно использовать специальный интервал, заданный параметром SpecialPollInterval, который по умолчанию имеет значение 32768 секунд (9 часов). Если флаг не задан, то используется стандартное значения в 604800 секунд (7 дней).
-
0x2 (UseAsFallbackOnly) — указывает, что данный сервер необходимо использовать в последнюю очередь как резервный.
-
0x4 (SymmetricActive) — указывает, что сервер является одноранговым узлом, с которым возможна симметричная синхронизация времени.
-
0x8 (Client) — означает, что текущий хост должен выступать клиентом по отношению к указанному серверу.
Значение по умолчанию «time.windows.com,0x9» соответствует комбинации первого и последнего флагов SpecialInterval+Client. Если вам нужно будет указать резервный источник времени, то используйте значение 0xB, чтобы к предыдущему значению добавить флаг UseAsFallbackOnly.
-
-
/update — уведомляет службу об изменении параметров для их принудительного применения. Если параметр не использовать, то изменения вступят в силу при следующем перезапуске службы.
Принудительно запустить синхронизацию времени можно с помощью команды resync:
> w32tm.exe /resync
Sending resync command to local computer
The command completed successfully.Посмотреть результаты синхронизации можно с помощью команды status:
> w32tm.exe /query /status /verbose
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0081377s
Root Dispersion: 7.8973731s
ReferenceId: 0x0A00010B (source IP: 10.0.1.11)
Last Successful Sync Time: 1/14/2024 11:32:33 AM
Source: dc-1.ald.company.lan,0x9
Poll Interval: 10 (1024s)
Phase Offset: 0.1344197s
ClockRate: 0.0156250s
State Machine: 1 (Hold)
Time Source Flags: 0 (None)
Server Role: 0 (None)
Last Sync Error: 0 (The command completed successfully.)
Time since Last Good Sync Time: 2.2626619sУчитывая, что со временем топология домена может претерпевать существенные изменения, использовать имена конкретных серверов крайне нежелательно. Лучше будет указать DNS-имя домена:
> w32tm.exe /config /syncfromflags:manual /manualpeerlist:"ald.company.lan,0x9" /update В этом случае A-записи нужно будет добавить вручную, автоматически они в домене не создаются. Сделать это можно на контроллере, используя утилиту командной строки ipa.
# for server in $(ipa-replica-manage list | sed 's/: master//'); do ipa dnsrecord-add ald.company.lan @ --a-rec=$(dig +short $server); doneОднако чтобы учесть географическое распределение инфраструктуры, правильным будет создать запись вида «_ntp._udp.имя_домена» и добавить A-записи в соответствующие локации.
Для упрощения предлагаю воспользоваться уже существующей записью «_kerberos._udp». Создадим необходимые A-записи сначала в головном офисе:
$ ipa dnsrecord-add ald.company.lan _kerberos._udp.hq._locations --a-rec=10.0.1.11
Имя записи: _kerberos._udp.hq._locations
A record: 10.0.1.11
SRV record: 0 100 88 dc-1.ald.company.lan., 0 100 88 dc-2.ald.company.lan., 0 100 88 dc-3.ald.company.lan., 50 100 88 dc-4.ald.company.lan., 50 100 88 dc-5.ald.company.lan.
$ ipa dnsrecord-add ald.company.lan _kerberos._udp.hq._locations --a-rec=10.0.1.12
Имя записи: _kerberos._udp.hq._locations
A record: 10.0.1.11, 10.0.1.12
SRV record: 0 100 88 dc-1.ald.company.lan., 0 100 88 dc-2.ald.company.lan., 0 100 88 dc-3.ald.company.lan., 50 100 88 dc-4.ald.company.lan., 50 100 88 dc-5.ald.company.lan
$ ipa dnsrecord-add ald.company.lan _kerberos._udp.hq._locations --a-rec=10.0.1.13
Имя записи: _kerberos._udp.hq._locations
A record: 10.0.1.11, 10.0.1.12, 10.0.1.13
SRV record: 0 100 88 dc-1.ald.company.lan., 0 100 88 dc-2.ald.company.lan., 0 100 88 dc-3.ald.company.lan., 50 100 88 dc-4.ald.company.lan., 50 100 88 dc-5.ald.company.lanЗатем в офисе Санкт-Петербурга:
$ ipa dnsrecord-add ald.company.lan _kerberos._udp.spb._locations --a-rec=10.0.1.14
Имя записи: _kerberos._udp.spb._locations
A record: 10.0.1.14
SRV record: 50 100 88 dc-1.ald.company.lan., 50 100 88 dc-2.ald.company.lan., 50 100 88 dc-3.ald.company.lan., 0 100 88 dc-4.ald.company.lan., 0 100 88 dc-5.ald.company.lan
$ ipa dnsrecord-add ald.company.lan _kerberos._udp.spb._locations --a-rec=10.0.1.15
Имя записи: _kerberos._udp.spb._locations
A record: 10.0.1.14, 10.0.1.15
SRV record: 50 100 88 dc-1.ald.company.lan., 50 100 88 dc-2.ald.company.lan., 50 100 88 dc-3.ald.company.lan., 0 100 88 dc-4.ald.company.lan., 0 100 88 dc-5.ald.company.lanПроверим работу новых записей:
# nslookup -type=A _kerberos._udp.ald.company.lan dc-1.ald.company.lan
Server: dc-1.ald.company.lan
Address: 10.0.1.11#53
_kerberos._udp.ald.company.lan canonical name = _kerberos._udp.hq._locations.ald.company.lan.
Name: _kerberos._udp.hq._locations.ald.company.lan
Address: 10.0.1.12
Name: _kerberos._udp.hq._locations.ald.company.lan
Address: 10.0.1.11
Name: _kerberos._udp.hq._locations.ald.company.lan
Address: 10.0.1.13Теперь запись «_kerberos._udp.ald.company.lan» можно использовать в настройках службы W32Time на компьютерах Windows. Для синхронизации времени они будут выбирать ближайший к ним контроллер домена.
4. Настройка динамического обновления DNS-записей
Служба каталога FreeIPA и клиентская часть SSSD поддерживают функцию динамического обновления DNS-записей в соответствии с RFC 2136. Чтобы использовать эту функцию, в конфигурационный файл /etc/sssd/sssd.conf достаточно внести несколько строк:
[domain/ald.company.lan]
...
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
...Операционная система Windows тоже поддерживает указанный протокол. Только есть одно маленькое недоразумение, из-за которого ничего не работает: компьютер использует имя принципала в другом формате, поэтому без добавления псевдонима «desktop-7vkreuo$» к учетной записи компьютера хост сможет выполнять только проверку аутентичности пользователей. У него не получится самому пройти аутентификацию в домене, и в журналах будут появляться сообщения об ошибке «CLIENT_NOT_FOUND». Добавить псевдоним можно с помощью команды host-add-principal утилиты ipa:
admin@dc-1:~$ ipa host-add-principal desktop-7vkreuo.ald.company.lan 'desktop-7vkreuo$'
--------------------------------------------------------------------------
Добавлены новые псевдонимы в запись узла "desktop-7vkreuo.ald.company.lan"
--------------------------------------------------------------------------
Имя узла: desktop-7vkreuo.ald.company.lan
Псевдоним учётной записи: host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN, desktop-7vkreuo$@ALD.COMPANY.LANИ останется только расширить политику обновления DNS на сервере:
-
Для прямой зоны:
-
DN: idnsname=ald.company.lan.,cn=dns,dc=ald,dc=company,dc=lan.
-
Атрибут: idnsUpdatePolicy
-
Старое значение: grant ALD.COMPANY.LAN krb5-self * A; grant ALD.COMPANY.LAN krb5-self * AAAA; grant ALD.COMPANY.LAN krb5-self * SSHFP;
-
Новое значение: grant ALD.COMPANY.LAN krb5-self * A AAAA SSHFP; grant ALD.COMPANY.LAN ms-self . A AAAA;
-
-
Для обратной зоны:
-
DN: idnsname=10.0.1.in-addr.arpa.,cn=dns,dc=ald,dc=company,dc=lan.
-
Атрибут: idnsUpdatePolicy
-
Старое значение: grant ALD.COMPANY.LAN krb5-subdomain 1.0.10.in-addr.arpa. PTR;
-
Новое значение: grant ALD.COMPANY.LAN krb5-subdomain 1.0.10.in-addr.arpa. PTR; grant ALD.COMPANY.LAN ms-subdomain 1.0.10.in-addr.arpa. PTR;
-
Внести указанные изменения можно через интерфейс IPA https://dc-1.ald.company.lan/ipa/ui, см. рисунок 5.
В завершение не помешает настроить на рабочей станции политику обновления DNS, так как по умолчанию Windows-клиенты сначала предпринимают попытку неавторизованных запросов, а уже после переключаются на GSS-TSIG. Это приводит к тому, что в журналах сервера скапливается много лишних предупреждений.
Для устранения проблемы нужно разрешить «только безопасные» (only secure) обновления для DNS-клиента на стороне рабочей станции Windows. Это делается с помощью редактора локальной групповой политики (gpedit.msc), см. рисунок 6.
Для проверки настроек вы можете выполнить принудительное обновление DNS-записей на Windows-компьютере командой registerdns утилиты ipconfig:
> ipconfig.exe /registerdnsАвтоматически запросы на обновление DNS-записей отправляются в следующих случаях:
-
Включение компьютера.
-
Изменение IP-адреса в конфигурации сетевого подключения.
-
Продление срока аренды IP-адреса, выданного DHCP-сервером. Такое событие можно вызвать принудительно командой «ipconfig /renew».
На стороне сервера FreeIPA запросы на обновление DNS можно будет найти в журнале daemon.log. Если хосту установить IP-адрес 10.0.1.155, то вы увидите в журнале следующие строки:
# tail -f /var/log/daemon.log | grep -i 'desktop-7vkreuo'
dc-1 named-pkcs11[4920]: client @0x70a05410f640 10.0.1.155#64080/key
desktop-7vkreuo\$\@ALD.COMPANY.LAN: updating zone 'ald.company.lan/IN':
deleting rrset at 'DESKTOP-7VKREUO.ALD.COMPANY.LAN' AAAA
dc-1 named-pkcs11[4920]: client @0x70a05410f640 10.0.1.155#64080/key
desktop-7vkreuo\$\@ALD.COMPANY.LAN: updating zone 'ald.company.lan/IN':
deleting rrset at 'DESKTOP-7VKREUO.ALD.COMPANY.LAN' A
dc-1 named-pkcs11[4920]: client @0x70a05410f640 10.0.1.155#64080/key
desktop-7vkreuo\$\@ALD.COMPANY.LAN: updating zone 'ald.company.lan/IN':
adding an RR at 'DESKTOP-7VKREUO.ALD.COMPANY.LAN' A 10.0.1.155
dc-1 named-pkcs11[4920]: client @0x70a04411a9d0 10.0.1.155#56472/key
desktop-7vkreuo\$\@ALD.COMPANY.LAN: updating zone '1.0.10.in-addr.arpa/IN':
deleting rrset at '155.1.0.10.in-addr.arpa' PTR
dc-1 named-pkcs11[4920]: client @0x70a04411a9d0 10.0.1.155#56472/key
desktop-7vkreuo\$\@ALD.COMPANY.LAN: updating zone '1.0.10.in-addr.arpa/IN':
adding an RR at '155.1.0.10.in-addr.arpa' PTR DESKTOP-7VKREUO.ALD.COMPANY.LAN.На стороне клиента возможные ошибки обновления DNS будут появляться в журнале System, см. рисунок 7.
5. Проверка функциональных возможностей
5.1 Вход в систему
Для входа в систему доменным пользователем «admin» нужно выбрать «Other user» и ввести имя в формате «admin@ALD.COMPANY.LAN», см. рис. 8. Если вы настроили домен по умолчанию, то можно использовать короткое имя «admin» без указания домена.
После входа в операционную систему Windows вы можете проверить состояние из командной строки с помощью утилит whoami и klist.
> whoami.exe
ald\admin
> whoami.exe /groups
GROUP INFORMATION
-----------------
Group Name Type SID
========================================== ================ =============================================
Unknown SID type S-1-5-21-1491017894-2377586105-2170988794-512
Everyone Well-known group S-1-1-0
BUILTIN\Users Alias S-1-5-32-545
NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4
CONSOLE LOGON Well-known group S-1-2-1
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11
NT AUTHORITY\This Organization Well-known group S-1-5-15
LOCAL Well-known group S-1-2-0
Authentication authority asserted identity Well-known group S-1-18-1
Mandatory Label\Medium Mandatory Level Label S-1-16-8192
> klist.exe
Current LogonId is 0:0x396cf
Cached Tickets: (1)
#0> Client: admin @ ALD.COMPANY.LAN
Server: krbtgt/ALD.COMPANY.LAN @ ALD.COMPANY.LAN
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 11/19/2023 6:26:37 (local)
End Time: 11/20/2023 6:26:37 (local)
Renew Time: 11/26/2023 6:26:37 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: dc-1.ald.company.lanЧтобы определить, какой именно контроллер обслуживает Windows-компьютер, можно воспользоваться утилитами systeminfo или nltest:
> systeminfo.exe | find /i "logon server"
Logon Server: \\DC-1
> nltest.exe /dsgetdc:ALD.COMPANY.LAN
DC: \\dc-1.ald.company.lan
Address: \\10.0.1.11
Dom Guid: 808d0975-5d36-47ed-8825-4b4227a348b9
Dom Name: ald.company.lan
Forest Name: ald.company.lan
Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE
The command completed successfullyПервый вход в систему может выполняться около минуты, так как создается профиль пользователя. Второй и последующие входы выполняются значительно быстрее, примерно за 5-10 секунд. При недоступности отдельных контроллеров время входа значительно возрастает.
Совет: не забудьте отключить NetBIOS для сетевого подключения, это значительно ускоряет время входа.
5.2 Автономный вход в систему
Операционная система Windows сохраняет хеш пользовательского пароля, что позволяет ей выполнять автономную аутентификацию пользователей без доступа к контроллерам домена.
Продолжительность автономного входа зависит от настроек сетевого интерфейса: если доступа к сети нет или сетевой интерфейс настроен на работу с публичным DNS-сервером, который отклоняет запросы на разрешение локальных имен, то автономный вход будет выполняться без задержек. Если интерфейс включен, но DNS-сервер недоступен, то компьютер будет отправлять до 15 запросов на поиск SRV-записей Kerberos и LDAP-сервисов — общая задержка может составить больше минуты.
Очевидно, что при автономном входе TGT-билет в системе будет отсутствовать:
> whoami
ald\admin
> whoami /groups
GROUP INFORMATION
-----------------
Group Name Type SID
========================================== ================ =============================================
Unknown SID type S-1-5-21-1491017894-2377586105-2170988794-512
Everyone Well-known group S-1-1-0
BUILTIN\Users Alias S-1-5-32-545
NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4
CONSOLE LOGON Well-known group S-1-2-1
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11
NT AUTHORITY\This Organization Well-known group S-1-5-15
LOCAL Well-known group S-1-2-0
Authentication authority asserted identity Well-known group S-1-18-1
Mandatory Label\Medium Mandatory Level Label S-1-16-8192
> klist
Current LogonId is 0:0x95e78b
Cached Tickets: (0)
> systeminfo | find /i "logon server"
Logon Server: \\DC-1
> nltest /dsgetdc:ALD.COMPANY.LAN
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAINПосле восстановления доступа к локальной сети билеты Kerberos появляются при первом же успешном обращении к керберизированному сервису. Например, при обращении к общим папкам автоматически появятся билеты krbtgt и cifs:
> whoami
ald\admin
> whoami /groups
GROUP INFORMATION
-----------------
Group Name Type SID
========================================== ================ =============================================
Unknown SID type S-1-5-21-1491017894-2377586105-2170988794-512
Everyone Well-known group S-1-1-0
BUILTIN\Users Alias S-1-5-32-545
NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4
CONSOLE LOGON Well-known group S-1-2-1
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11
NT AUTHORITY\This Organization Well-known group S-1-5-15
LOCAL Well-known group S-1-2-0
Authentication authority asserted identity Well-known group S-1-18-1
Mandatory Label\Medium Mandatory Level Label S-1-16-8192
> klist
Current LogonId is 0:0x95e78b
Cached Tickets: (2)
#0> Client: admin @ ALD.COMPANY.LAN
Server: krbtgt/ALD.COMPANY.LAN @ ALD.COMPANY.LAN
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 2/4/2024 11:52:59 (local)
End Time: 2/5/2024 11:52:59 (local)
Renew Time: 2/11/2024 11:52:59 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: dc-1.ald.company.lan
#1> Client: admin @ ALD.COMPANY.LAN
Server: cifs/dc-1.ald.company.lan @ ALD.COMPANY.LAN
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a90000 -> forwardable renewable pre_authent name_canonicalize 0x80000
Start Time: 2/4/2024 11:52:59 (local)
End Time: 2/5/2024 11:52:59 (local)
Renew Time: 2/11/2024 11:52:59 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: dc-1.ald.company.lan
> systeminfo | find /i "logon server"
Logon Server: \\DC-1
> nltest /dsgetdc:ALD.COMPANY.LAN
DC: \\dc-1.ald.company.lan
Address: \\10.0.1.11
Dom Guid: 808d0975-5d36-47ed-8825-4b4227a348b9
Dom Name: ald.company.lan
Forest Name: ald.company.lan
Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE
The command completed successfully5.3 Смена пароля
Функция смены пароля работает штатным образом, если при входе в систему пользователь ввел имя в формате login@REALM.FQDN или это значение было скорректировано автоматически после входа с помощью скриптов, см. рис. 9.
5.4 Прозрачная аутентификация при обращении к сетевой папке
Прозрачная Kerberos-аутентификация при обращении к керберизированным сервисам будет работать, так как у пользователя в системе есть TGT-билет.
Для проверки вы можете создать сетевую папку с именем «testshare» прямо на контроллере домена и предоставить к ней доступ пользователю с именем «admin». Для этого в конец файла /etc/samba/smb.conf допишите следующие строки:
# nano /etc/samba/smb.conf
...
[testshare]
path = /srv/testshare
writable = yes
valid users = admin
write list = adminПосле чего создайте указанную папку и перезапустите службу smbd:
# mkdir /srv/testshare
# systemctl restart smbd.service Откройте сетевую папку в проводнике Windows по адресу «\\dc-1.ald.company.lan\testshare» и проверьте, что у вас есть доступ без ввода пароля и возможность создавать и редактировать файлы, см. рис. 10.
Выполните команду klist в терминале и убедитесь, что там появился дополнительный билет на доступ к службе cifs/dc-1.ald.company.lan:
5.5 Назначение доменным пользователям прав доступа в локальной системе
Как мы убедились ранее, внутри операционной системы пользователь работает под своей доменной учетной записью, но назначать ему какие-то дополнительные права, используя стандартное окно поиска пользователей, не получится — доменных пользователей в нем не будет. Обойти указанную проблему можно путем создания локальных групп, в список участников которых можно включить идентификаторы безопасности из домена.
Текущие идентификаторы пользователей и групп можно посмотреть на контроллере домена FreeIPA с помощью утилиты ipa:
$ ipa user-show admin --all | grep ipantsecurityidentifier
ipantsecurityidentifier: S-1-5-21-1491017894-2377586105-2170988794-500
$ ipa group-show admins --all | grep ipantsecurityidentifier
ipantsecurityidentifier: S-1-5-21-1491017894-2377586105-2170988794-512Создать локальные группы на Windows-компьютере и добавить в них участников по идентификаторам можно из PowerShell с помощью командлетов New-LocalGroup и Add-LocalGroupMember, см. рис. 11:
> New-LocalGroup -Name "ALD-User-Admin" -Description "Domain user"
Name Description
---- -----------
ALD-User-Admin Domain user
> Add-LocalGroupMember -Group "ALD-User-Admin" -Member "S-1-5-21-1491017894-2377586105-2170988794-500"
> New-LocalGroup -Name "ALD-Group-Admins" -Description "Domain group"
Name Description
---- -----------
ALD-Group-Admins Domain group
> Add-LocalGroupMember -Group "ALD-Group-Admins" -Member "S-1-5-21-1491017894-2377586105-2170988794-512"
Целесообразно добавить администраторов домена также в группу локальных администраторов, чтобы у пользователей были все необходимые привилегии для настройки системы без переключения на учетную запись локального администратора:
Add-LocalGroupMember -Group "Administrators" -Member "S-1-5-21-1491017894-2377586105-2170988794-512"Вместо заключения
Приведенный способ значительно расширяет возможности построения гибридной инфраструктуры, но требует много времени для настройки рабочих станций. Это не проблема, если у вас почасовая оплата, но в большинстве случаев создает значительные затруднения. Поэтому команда ALD Pro разработала графическую утилиту aldpro-join, которая позволяет выполнить все настройки в пару кликов, см. рисунок 12.
Приложение написано на языке Python и доступно в публичном репозитории продуктовой команды на GitFlic как в виде исходных кодов, так и в виде скомпилированного с помощью Pyinstaller исполняемого exe-файла.
Чтобы утилита смогла внести необходимые изменения и на локальном компьютере, и в домене, запускать ее нужно от имени локального администратора, а при появлении окна аутентификации требуется предоставить учетные данные привилегированного пользователя домена.
Еще раз акцентирую внимание на том, что утилита работает как для домена ALD Pro, так и для «ванильных» инсталляций FreeIPA. Команда ALD Pro прикладывает значительные усилия для выработки лучших практик использования продуктов технологического стека, и мы будем рады, если наши наработки помогут вам в реализации программы импортозамещения в вашей компании.
Перед началом работ по внедрению метода аутентификации пользователей по протоколу Kerberos, рекомендуем ознакомится с разделом Аутентификация Kerberos Руководства Администратора.
Содержание:
1. Краткое описание алгоритма работы Kerberos
2. Поддержка Kerberos клиентами CommuniGate Pro
3. Общие требования
4. Настройка интеграции с Microsoft Active Directory
5. Загрузка keytab.data на сервер CommuniGate Pro
6. Настройка MS Internet Explorer/MS Edge/Google Chrome
7. Проверка работоспособности
8. Устранение проблем
9. Подготовка информации для предоставления в техническую поддержку
10. Полезные ссылки
Сервер Kerberos и сервер CommuniGate Pro (далее – CGPro) не общаются между собой напрямую. То есть для аутентификации через Kerberos серверу CGPro не нужно связываться с Microsoft Active Directory (далее – Microsoft AD). Ключ для расшифровки билетов загружается на сервер CGPro в виде файла таблицы ключей (далее – keytab файл).
Алгоритм аутентификации через Kerberos:
1. Клиент подключается к серверу CGPro;
2. Сервер CGPro предлагает клиенту аутентифицироваться через Kerberos;
3. Клиент обращается к Microsoft AD за билетом для сервера CGPro;
4. Клиент отправляет серверу CGPro полученный билет;
5. Если сервер CGPro может расшифровать билет, то получает из него имя пользователя;
6. Если пользователь найден, то сервер CGPro предоставляет ему доступ к услугам.
Поддержка Kerberos клиентами CommuniGate Pro
Протокол аутентификации Kerberos поддерживается в веб-версии Samoware, настольном клиенте Samoware Desktop для операционной системы Windows, CommuniGate Pro MAPI-коннектор.
Общие требования
Для возможности аутентификации пользователей домена CGPro по протоколу Kerberos, необходимо выполнение общих требований:
1. В установках домена CGPro должен быть включен Способ Аутентификации GSSAPI (Пользователи → Домены → Имя_домена → Установки домена, секция «Способы Аутентификации»);
Примечание. Также рекомендуется включить Способ Аутентификации SESSIONID. Это понадобится, если будет необходимо входить в веб-интерфейс Samoware через Kerberos по ссылке вида: /login (подробнее в разделе Вход при помощи Аутентификации через Браузер);
2. В установках пользователя CGPro должна быть включена Аутентификация Через Kerberos (Пользователи → Домены → Имя_домена → Объекты → Имя_пользователя → Установки, секция «Аутентификация»);
3. Для использования аутентификации Kerberos при подключении по HTTP, в настройках HTTPU должна быть включена опция «Объявлять ‘Negotiate’-Аутентификацию» (Установки → Услуги → HTTPU, секция «Опции HTTP»);
4. Клиенты для обращения к домену сервера CGPro должны использовать имя хоста (далее FQDN), совпадающее с именем домена. Если будет использоваться FQDN, отличное от имени домена, то необходимо добавить его в Псевдонимы домена;
5. Клиенты должны разрешать используемый FQDN в IP-адрес, назначенный главному или дополнительному домену сервера CGPro.
6. В Microsoft AD должен быть создан сервисный пользователь для сервиса (протокола) CGPro, доступ к которому требуется аутентифицировать по Kerberos;
7. Пароль сервисного пользователя должен удовлетворять парольным политикам;
8. Для сервисного пользователя должен быть назначен SPN (Service Principal Names), ключ шифрования, и выгружен keytab файл:
· SPN, назначаемый сервисному пользователю, должен быть уникальным;
· В экземпляре SPN должен использоваться FQDN, выбранный в пункте 4;
9. На ПК пользователя должен быть выполнен вход в домен Microsoft AD под пользователем, имя для входа которого (sAMAccountName), совпадает с именем пользователя CGPro или его Псевдонимом (имена доменов Microsoft AD и CGPro могут не совпадать).
Настройка интеграции с Microsoft Active Directory
1. В DNS (локальном или публичном) создать А-запись, указывающую на IP-адрес главного или дополнительного домена CGPro (для тестов можно использовать записи в hosts);
2. Добавить полное имя хоста (FQDN) А-записи в псевдонимы домена CGPro;
3. В Microsoft AD создать сервисного пользователя cgatepro;
Примечание. Имя cgatepro дано для примера и используется далее, как имя сервисного пользователя. Вы можете выбрать любое другое имя.
На сервисного пользователя будут зарегистрированы принципалы для сервисов CGPro (HTTP, IMAP и т.п.).
Обратите внимание. Для каждого сервиса (HTTP, IMAP, SMTP) рекомендуется создавать отдельного сервисного пользователя в Microsoft AD, чтобы SPN корректно считывался.
4. На контроллере домена Microsoft AD использовать команду ktpass для создания принципала службы и экспорта ключей.
Для создания keytab файла с привязкой к пользователю (ключ «-mapuser») на контроллере домена нужно открыть cmd или PowerShell с правами администратора и использовать команду ktpass.
Пример команды в cmd:
ktpass -princ service/hostname@REALM -mapuser cgatepro -pass <key> -out C:\keytab.data -crypto All -ptype KRB5_NT_PRINCIPAL
Пример команды в PowerShell:
ktpass /princ service/hostname@REALM /mapuser cgatepro /pass <key> /out C:\keytab.data /crypto All /ptype KRB5_NT_PRINCIPAL /
· service – имя сервиса (протокола) CGPro (IMAP/SMTP/HTTP);
· hostname – FQDN, который был выбран в пункте 4 раздела «Общие требования»;
· REALM — полное имя домена Microsoft AD, через который осуществляется вход, в верхнем регистре;
· <key> — ключ шифрования (придумайте произвольный набор символов, который будет использоваться для шифрования билетов);
· С:\keytab.data — путь к файлу, в который запишется таблица ключей;
· crypto — тип шифрования. В примере дано значение параметра «All». Вы можете указать требуемый тип шифрования из перечисленных: DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC-NT, AES256-SHA1*, AES128-SHA1*.
* AES128-SHA1 и AES256-SHA1 поддерживаются, начиная с версии CGPro 6.3.4.
При включении типа шифрования AES256-SHA1 или AES128-SHA1, необходимо у сервисного пользователя в Microsoft AD в параметрах учетной записи включить «Данная учетная запись поддерживает 256-разрядное шифрование» или 128-разрядное в зависимости от выбранного типа.
Также нужно удостовериться, что у сервисного пользователя Microsoft AD в опциях не включено «Use only Kerberos Des encryption».
Обратите внимание. ktpass не перезаписывает выходной файл (-out), а дополняет. Из-за этого в CGPro не загружается корректный ключ. При пересоздании ключа нужно указывать новое имя файла или предварительно стирать имеющийся.
Загрузка keytab.data на сервер CommuniGate Pro
Нужно загрузить keytab файл на сервер CGPro в веб-интерфейсе администратора: Пользователи → Домены → Имя_домена → Безопасность → Kerberos.
Настройка MS Internet Explorer/MS Edge/Google Chrome
Для настройки нужно:
1. Зайти в свойства браузера: Панель Управления → Свойства браузера → Безопасность → Местная интрасеть → Сайты → Дополнительно;
2. В список сайтов добавить URL входа на сервер CGPro и перезагрузить браузер.
Примечание. В URL для подключения нужно указать FQDN, выбранный в пункте 4 раздела «Общие требования».
Примечание. Для поддержки аутентификации Kerberos в других браузерах их необходимо настраивать отдельно (подробнее см. в документации на нужный тип браузера).
Проверка работоспособности
В браузере для аутентификации по Kerberos можно:
· Использовать URL вида: http(s)://fqdn:port/login/
Например: http://cgatepro.msk:8100/login/
· На странице входа в веб-интерфейс пользователя кнопку «Автоматический вход».
Если все настроено правильно, то вход в веб-интерфейс почты должен быть осуществлен автоматически, минуя запрос логина и пароля.
Пример записи успешной аутентификации Kerberos в журнале сервера CGPro:
14:29:50.336 2 HTTPU-000253([10.2.7.51]:64522) ‘ivanov’ connected(KERBEROS) [10.2.7.51]:64522->[10.2.7.45]:8100
Устранение проблем
Большинство проблем аутентификации Kerberos связано с некорректным созданием/установкой keytab файла (например, были указаны неверные параметры при создании).
Если аутентификация Kerberos не проходит (в браузере запрашивается логин/пароль), то в первую очередь необходимо проверить получил ли ПК пользователя билет для сервиса CGPro и имени хоста, указанного в клиенте для подключения к домену сервера CGPro (FQDN, выбранный в пункте 4 раздела «Общие требования»). Для этого можно использовать команду klist.
Пример:
В примере ПК пользователя получил билет для сервиса HTTP и имени хоста dc-1.ipa.msk, с типом шифрования RC4-HMAC.
Проблема 1. ПК пользователя не получил билет.
Возможные причины:
1. Keytab файл не был сгенерирован для сервиса/имени хоста CGPro;
2. Для подключения к домену CGPro использовалось имя хоста (FQDN), отличное от того, на которое сгенерирован keytab.
Решение: Вернитесь к шагу 4 в разделе «Настройка интеграции с Microsoft Active Directory».
Проблема 2. ПК пользователя получил билет, но аутентификация Kerberos не прошла.
Возможные причины:
1. Keytab файл не был загружен на сервер CGPro;
Пример ошибки в журнале сервера CGPro:
15:15:58.593 1 DOMAIN(example.msk) Kerberos key HTTP/example.msk@EXAMPLE.MSK encType=18 v=13 not found
Решение: Загрузите keytab файл на сервер CGPro (см. раздел «Загрузка keytab.data на сервер CommuniGate Pro»).
2. Тип шифрования в билете на ПК пользователя не совпадает с типом шифрования keytab файла. Тип шифрования keytab можно посмотреть в интерфейсе администратора (см. раздел «Загрузка keytab.data на сервер CommuniGate Pro»);
Пример ошибки в журнале сервера CGPro:
15:15:58.593 1 DOMAIN(example.msk) Kerberos key HTTP/example.msk@EXAMPLE.MSK encType=18 v=13 not found
Решение: Вернитесь к шагу 4 в разделе «Настройка интеграции с Microsoft Active Directory» и создайте keytab файл с типом шифрования, совпадающим с типом шифрования билета.
3. Ключи шифрования в билете и на ПК пользователя не совпадают
Пример ошибки в журнале:
15:18:15.276 4 HTTPU-000226([10.3.9.179]:62117) rsp(1005): 401 Kerberos: failed to verify data integrity
Решение: Вернитесь к шагу 4 в разделе «Настройка интеграции с Microsoft Active Directory», создайте новый keytab файл и загрузите его на сервер CGPro.
Обратите внимание: ПК пользователя кэширует полученные билеты. После пересоздания keytab файла (пункты 2 и 3) нужно очистить кэш билетов, чтобы ПК пользователя запросил новый билет. Можно использовать команду klist purge, либо перезагрузить ПК.
Подготовка информации для предоставления в техническую поддержку
Для решения проблем с аутентификацией Kerberos, необходимо собрать и предоставить в техническую поддержку следующие данные:
1. С ПК пользователя: вывод команды klist ;
2. Из веб-интерфейса администратора CGPro: скриншот страницы с keytab:
Пользователи → Домены → Имя_домена → Безопасность → Kerberos;
3. Для сервиса (протокола) CGPro, к которому происходит подключение, установить уровень журнала «Всё»:
HTTPU: Установки → Услуги → HTTPU → Обработка → Уровень журнала: Всё
IMAP/MAPI: Установки → Доступ → IMAP → Уровень журнала: Всё
SMTP: Установки → Почта → SMTP → Прием → Уровень журнала: Всё;
4. Для модуля ROUTER установить уровень журнала «Всё»:
Установки → Маршрутизатор → Уровень журнала: Всё;
5. Повторить попытку входа;
6. Скопировать журнал сервера CGPro за промежуток -/+2 минуты от времени попытки входа в обычный текстовый файл.
Полезные ссылки
Руководство Администратора раздел Аутентификация Kerberos.
Руководство Администратора раздел Псевдонимы домена.
Руководство Администратора раздел Псевдонимы Пользователя.
Руководство Администратора раздел Вход при помощи Аутентификации через Браузер.
Документация Microsoft раздел ktpass.
17 янв. 2024 г.
Introduction
This article describes the single sign-on (SSO) setup between Joget Workflow and Microsoft Active Directory using Kerberos and SPNEGO.
Kerberos is a network authentication protocol designed by the Massachusetts Institute of Technology (MIT) for SSO in client-server environments, while SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) extends Kerberos SSO to web applications.
This plugin source code is available in a new open source repository at https://github.com/jogetoss/. JogetOSS is a community-led team for open source software related to the Joget no-code/low-code application platform. Projects under JogetOSS are community-driven and community-supported, and you are welcome to contribute to the projects.
Test Environment
-
Joget Server: Joget Workflow v5 Enterprise on Apache Tomcat 8 and Java 8
-
Windows Server: Windows Server 2012 R2 Datacenter (running on VirtualBox within a NAT Network, downloaded from https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2012-r2)
-
Windows Client PC: IE11 on Windows 10 (running on VirtualBox within a NAT Network, downloaded from https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/)
Test Settings
-
Windows Server COMPUTER NAME is WIN-TKDH9LCHUUO
-
WINDOWS DOMAIN is windows.local
-
DOMAIN USER is joget
-
JOGET DOMAIN is joget.windows.local
-
This article assumes familiarity with the basics of Windows Server and Windows 10 system and network administration
-
This setup is tested within a local VirtualBox environment. Actual setup on a different environment should be adapted accordingly.
Kerberos SSO Setup Configuration
1. Setup Windows Server Kerberos Key Distribution Center (KDC):
1.1 Install DNS Server
-
Go to Server Manager > Add roles and features to install the DNS Server.
-
In the Network and Sharing Center, configure the network adapter so that the Preferred DNS server is 127.0.0.1.
-
In the DNS Manager, right click on the server name and Configure a DNS Server to create a forward lookup zone for windows.local.
1.2 Add Joget Domain Name into the Windows Server DNS
-
In the windows.local DNS zone, add an A record for joget to point to the Joget server IP.
-
Test ping to ensure that joget.windows.local resolves to the correct IP.
1.3 Create a Windows Domain User for the Service
-
In Active Directory Users and Computers, create a domain user joget. This is the user account to be mapped to the service name used by the Joget server.
1.4 Register Service Principal Name (SPN)
-
In PowerShell, execute: setspn -s HTTP/{JOGET DOMAIN} {DOMAIN USER} e.g.
setspn -s HTTP/JOGET.WINDOWS.LOCAL joget
In PowerShell, check that the SPN has been registered
should display
Registered ServicePrincipalNames for CN=Joget,CN=Users,DC=windows,DC=local: HTTP/JOGET.WINDOWS.LOCAL
2. Setup Joget Server for Kerberos
2.1 Add Windows Domain to Hosts File
-
Edit /etc/hosts (Linux or macOS) or C:\Windows\System32\drivers\etc\hosts (Windows) and add the server IP e.g.
192.168.56.102 windows.local win-tkdh9lchuuo win-tkdh9lchuuo.windows.local
NOTE: This step is not required if the Joget Server is using the Windows Server as the DNS server.
2.2 Create Kerberos Identification (Keytab) File
Using Windows
-
In PowerShell on the Windows Server, generate a keytab file using the Ktpass tool:
ktpass -out joget.keytab -mapuser joget@WINDOWS.LOCAL -pass Pass@word1 -crypto all -ptype KRB5_NT_PRINCIPAL -princ HTTP/joget.windows.local@WINDOWS.LOCAL
-
Copy the generated joget.keytab file into the Joget server e.g. at C:\Joget-v5-Enterprise\wflow\joget.keytab
-
Java 8 may be required for the Kerberos authentication to work with the ktpass generated keytab. Download and install JDK 8, and edit the tomcat-run.bat startup script to update the JAVA_HOME path accordingly.
Using Linux
-
Install the krb5-user package
sudo apt-get install krb5-user
and configure the realm as WINDOWS.LOCAL and the KDC as WIN-TKDH9LCHUUO.WINDOWS.LOCAL:88
-
In a terminal, run
kinit joget@WINDOWS.LOCAL
IMPORTANT NOTE: The domain must be UPPER CASE
The command should run without error -
Confirm the configuration in /etc/krb5.conf
[libdefaults] default = WINDOWS.LOCAL default_realm = WINDOWS.LOCAL dns_lookup_realm = true dns_lookup_kdc = true [realms] WINDOWS.LOCAL = { kdc = WIN-TKDH9LCHUUO.WINDOWS.LOCAL:88 default_domain = WINDOWS.LOCAL } [domain_realm] .windows.local = WINDOWS.LOCAL windows.local = WINDOWS.LOCALIMPORTANT NOTE: The domain must be UPPER CASE
-
In a terminal, generate a keytab file using:
ktutil ktutil: add_entry -password -p HTTP/JOGET.WINDOWS.LOCAL@WINDOWS.LOCAL -k 1 -e arcfour-hmac-md5 Password for HTTP/JOGET.WINDOWS.LOCAL@WINDOWS.LOCAL: ktutil: wkt /etc/joget.keytab
-
List the SPNs in the keytab using:
ktutil ktutil: rkt /etc/joget.keytab ktutil: list
Using macOS
-
In a terminal, run
kinit joget@WINDOWS.LOCAL
IMPORTANT NOTE: The domain must be UPPER CASE
The command should run without error, or just a warning “Encryption type arcfour-hmac-md5(23) used for authentication is weak and will be deprecated” -
Edit /etc/krb5.conf
[libdefaults] default = WINDOWS.LOCAL default_realm = WINDOWS.LOCAL dns_lookup_realm = true dns_lookup_kdc = true [realms] WINDOWS.LOCAL = { kdc = WIN-TKDH9LCHUUO.WINDOWS.LOCAL:88 default_domain = WINDOWS.LOCAL } [domain_realm] .windows.local = WINDOWS.LOCAL windows.local = WINDOWS.LOCALIMPORTANT NOTE: The domain must be UPPER CASE
-
In a terminal, generate a keytab file using:
ktutil -k joget.keytab add -p HTTP/JOGET.WINDOWS.LOCAL@WINDOWS.LOCAL -e arcfour-hmac-md5 -V 1
-
List the SPNs in the keytab using:
ktutil -k joget.keytab list
-
Keep a copy of the generated joget.keytab file e.g. in /etc/joget.keytab
3. Configure Kerberos Directory Manager Plugin
3.1 Upload Kerberos Directory Manager Plugin
-
Download the Kerberos Directory Manager plugin from the Joget Marketplace and upload it in Settings > Manage Plugins.
3.2 Configure Kerberos Directory Manager Plugin
-
In Settings > Directory Manager, select the Kerberos Directory Manager plugin, and key in the appropriate values in the configuration:
-
Service Principal: HTTP/JOGET.WINDOWS.LOCAL
-
Path to Keytab File: /etc/joget.keytab (Linux) or C:/Joget-v5-Enterprise/wflow/joget.keytab (Windows)
-
Debug Enabled: View debugging messages in the logs
-
3.3 Configure API Domain Whitelist
-
In Settings > General Settings, set the API Domain Whitelist to * to allow SSO requests to the Kerberos Directory Manager.
4.1 Add Client PC to Windows Domain
-
Ensure that the Windows Server is reachable on the network from the Client PC.
-
Set the DNS server to the IP address of the Windows Server.
-
Ping the windows domain name to test.
-
Click on File Explorer, right click on the This PC and choose Properties. Click on Change Settings next to the computer name. Click on Change and set the Domain e.g. windows.local, keying in the domain administrator login when prompted. Restart after joining the domain is successful, and login as a domain user.
4.2 Setup Browser for Windows Authentication
-
In IE, click on Internet Options > Security > Local intranet site > Advanced and add the Joget domain e.g. http://joget.windows.local
4.3 Test the SSO
-
Using the Kerberos Directory Manager plugin approach, access http://joget.windows.local/jw/web/json/plugin/org.joget.plugin.kerberos.KerberosDirectoryManager/service to SSO.
Please note that for the SSO to work properly:
-
the client PC and Joget server must reside on different machines
-
the Windows server and client PC must reside on the same Windows domain
-
Resources
Introduction to Kerberos and SPNEGO
-
http://thekspace.com/home/component/content/article/54-kerberos-and-spnego.html
-
https://developer.ibm.com/answers/questions/246107/what-is-the-difference-between-kerberos-and-spnego.html?lnk=hm
-
http://web.mit.edu/kerberos/www/index.html
Configuring Kerberos on Windows Server
-
https://technet.microsoft.com/en-us/library/hh831553(v=ws.11).aspx
-
https://msftplayground.com/2009/08/configure-kerberos-authentication/
-
https://technet.microsoft.com/en-us/library/cc731241(v=ws.11).aspx
-
https://technet.microsoft.com/en-us/library/hh831553(v=ws.11).aspx
-
https://msftplayground.com/2009/08/configure-kerberos-authentication/
Kerberos with Java and Spring
-
https://venkatsadasivam.com/2009/08/29/single-sign-on-in-java-platform/
-
http://docs.spring.io/spring-security-kerberos/docs/1.0.1.RELEASE/reference/htmlsingle/
-
http://projects.spring.io/spring-security-kerberos/
-
https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html
-
http://docs.oracle.com/javase/jndi/tutorial/ldap/security/gssapi.html
-
http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/lab/part1.html#PART1
-
https://docs.oracle.com/cd/E23943_01/web.1111/e13707/sso.htm#SECMG481
-
https://stackoverflow.com/questions/25289231/using-gssmanager-to-validate-a-kerberos-ticket