Windows мои документы реестр — Ваш верный помощник с OS Windows

Поделиться через

Kerberos — это протокол аутентификации, который используется для идентификации пользователя или узла. В этом разделе содержатся сведения о проверке подлинности Kerberos в Windows Server и Windows.

Операционные системы Windows Server реализуют протокол проверки подлинности Kerberos версии 5 и расширения для проверки подлинности с помощью открытого ключа, переноса данных авторизации и делегирования. Клиент проверки подлинности Kerberos реализуется в качестве поставщика поддержки безопасности (SSP). Получить к нему доступ можно через интерфейс поставщика поддержки безопасности (SSPI). Начальная проверка подлинности пользователя интегрирована в архитектуру единого входа Winlogon.

Центр распространения ключей Kerberos (KDC) встроен в другие службы безопасности Windows Server, работающие на контроллере домена. Служба KDC использует базу данных доменных служб Active Directory в качестве базы данных учетных записей безопасности. Для стандартной реализации Kerberos в пределах домена или леса необходимы доменные службы Active Directory.

Практическое применение

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

Делегированная аутентификация

Службы, работающие в операционных системах Windows, могут олицетворить клиентский компьютер при доступе к ресурсам от имени клиента. Во многих случаях служба может выполнить свою работу для клиента путем доступа к ресурсам на локальном компьютере. Когда клиентский компьютер проходит проверку подлинности в службе, протоколы NTLM и Kerberos предоставляют сведения авторизации, которые требуются службе для локального олицетворения клиентского компьютера. Однако некоторые распределенные приложения разработаны таким образом, чтобы интерфейсная служба должна использовать удостоверение клиентского компьютера при подключении к серверным службам на других компьютерах. Проверка подлинности Kerberos поддерживает механизм делегирования, позволяющий службе действовать от имени клиента при подключении к другим службам.

Единый вход

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

Совместимость

Реализация протокола Kerberos V5 компанией Microsoft основывается на спецификациях, соответствующих стандартам, рекомендованных Рабочей группой по инженерным задачам Интернета (IETF). Поэтому в операционных системах Windows протокол Kerberos лежит в основе взаимодействия с другими сетями, в которых для проверки подлинности также используется протокол Kerberos. Кроме того, корпорация Майкрософт публикует документацию «Протоколы Windows», содержащую сведения о реализации протокола Kerberos. Документация содержит технические требования, ограничения, зависимости и поведение протокола для Windows для реализации протокола Kerberos корпорации Майкрософт.

Более эффективная проверка подлинности на серверах

Перед применением Kerberos можно использовать проверку подлинности NTLM, которая требует подключения сервера приложений к контроллеру домена для проверки подлинности каждого клиентского компьютера или службы. При использовании протокола Kerberos возобновляемые билеты сеанса заменяют пропускную проверку подлинности. Серверу не требуется обращаться к контроллеру домена, если ему не нужно проверять сертификат атрибута привилегий (PAC). Вместо этого сервер может проверить подлинность клиентского компьютера путем проверки учетных данных, предоставленных клиентом. Клиентские компьютеры могут получить учетные данные для определенного сервера однократно и затем использовать их в течение всего сеанса после входа в сеть.

Взаимная проверка подлинности

С помощью протокола Kerberos сторона на любом конце сетевого подключения может проверить, что сторона на противоположном конце является субъектом, за которого себя выдает. NTLM не позволяет клиентам проверять удостоверение сервера или одному серверу проверять удостоверение другого. Проверка подлинности NTLM предназначена для сетевой среды, в которой серверы считаются подлинными. В протоколе Kerberos такого допущения нет.

Связанный контент

Обзор проверки подлинности Windows

Источник

После добавления учетной записи компьютера или пользователя в группу безопасности Active Directory, новые полномочия доступа к ресурсам или новые GPO применяются не сразу. Чтобы обновить членство в группах и применить назначенные права/политики, нужно перезагрузить компьютер или перелогиниться в систему (для пользователя). Это связано с тем, что членство в группах AD обновляется при создании билета Kerberos, которое происходит при загрузке системы или при аутентификации пользователя во время входа в систему.

Содержание:

Обновить билет Kerberos и группы компьютера без перезагрузки
Klist: сброс тикета Kerberos для пользователя

Если вы не можете немедленно выполнить перезагрузку компьютера или logoff пользователя, можно обновить членство учетной записи в группах AD помощью утилиты
klist.exe
. Эта утилита позволяет сбросить билеты Kerberos.

Примечание. Данная статья применима только для сетевых сервисов, поддерживающих Kerberos аутентификацию. Службы, работающие только с NTLM аутентификацией, по-прежнему требуют выполнения logoff + logon пользователя или перезагрузки Windows.

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

whoami /groups

или GPresult

gpresult /r /scope user

gpresult - The user is a part of the following security groups

Список групп, в которых состоит пользователь указан в разделе “The user is a part of the following security groups”.

Обновить билет Kerberos и группы компьютера без перезагрузки

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

gpresult /r /scope computer

The computer is a part of the following security groups

gpresul: список групп в которых состоит компьютер

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

klist.exe -li 0x3e7

klist-0x3e7 вывести список биетов kerberos компьютера

Примечание. 0x3e7 — специальный идентификатор, указывающий на сессию локального компьютера (Local System).

Теперь добавьте компьютер в новую группу безопасности AD (через оснастку ADUC или с помощью PowerShell команды:
Add-AdGroupMember -Identity corpAntivirusExclusionPC -Members wks-msit012$
)

Чтобы очистить кэш тикетов Kerberos компьютера и обновить членство компьютера в группах AD, выполните команду (для Windows 7 и Windows Server 2008R2)

klist -lh 0 -li 0x3e7 purge

Или для Windows 11/10/8 и Windows Server 2012+

klist –li 0x3e7 purge

Deleting all tickets:
Ticket(s) purged!

Обновите настройки групповых политик командой gpupdate /force , после этого к компьютеру без перезагрузки будут применены все GPO, назначенные группе безопасности AD через Security Filtering.

Вы можете проверить время получения билетов Kerberos компьютера с помощью команды:

klist -li 0x3e7 tgt

Если в вашем домене настроены политики ограничения доступа к LSA(например, политика Debug Program, ограничивающая получение SeDebugPrivilege ), или другие политики безопасности, то в некоторых случаях при запуске команды
klist -li 0:0x3e7 purge
вы получили ошибку вида (Error calling API LsaCallAuthenticationPackage):

Current LogonId is 0:0x5d2ed1
Targeted LogonId is 0:0x3e7
*** You must run this tool while being elevated, and you must have TCB or be a local admin.***
 klist failed with 0xc0000001/-1073741823: {Operation Failed}
The requested operation was unsuccessful.

klist failed Error calling API LsaCallAuthenticationPackage

В этом случае нужно запустить командную строку от имени NT Authority\System и в уже в этой консоли сбросить кэш билетов Kerberos:
psexec -s -i -d cmd.exe
– для запуска cmd.exe от имени System используется утилита psexec.exe.

klist –li 0x3e7 purge
– сброс тикета компьютера

gpupdate /force
– обновление настроек GPO

Такой способ обновления членства в группах компьютера – единственный рабочий вариант обновления настроек GPO на клиентах, который подключаются к вашей сети через VPN, а пользователь входит под кэшированными учетными данными.

Klist: сброс тикета Kerberos для пользователя

Например, вы добавили пользователя в группу безопасности с правами доступа к сетевой папке. Пользователь не сможет отрыть данный сетевой каталог без выполнения logoff+logon.

Если нужно обновить список назначенных групп безопасности для пользователя, нужно сбросить его кэш билетов Kerberos. Откройте в сессии пользователю непривилегированную командную строку (не нужно запускать cmd в режиме Run as administrator). Выполните команду:

klist purge

Current LogonId is 0:0x5d2e96
Deleting all tickets:
Ticket(s) purged!

Чтобы увидеть обновлённый список групп, нужно запустить новое окно командной строки с помощью runas (чтобы новый процесс был создан с новым токеном безопасности). Выведите список групп пользователя:

whoami /groups

На RDS сервере, на котором работает множество пользователей вы можете сбросить Kerberos тикеты сразу для всех сессий пользователей с помощью следующего однострочного PowerShell скрипта:

Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}

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

Откройте командную строку;
Завершите процесс File Explorer пользователя:
taskkill /f /im explorer.exe
Запустите новый процесс explorer под вашей учетной записью. Можно использовать переменные окружения
%USERDOMAIN%\%USERNAME%
или указать домен и имя пользователя вручную. Например, winitpro\kbuldogov:
runas /user:winitpro\kbuldogov explorer.exe
Укажите пароль своей учетной записи;

Картинка с сайта: winitpro.ru
После этого оболочка проводника перезапустится с новым токеном и вы сможете получить доступ к сетевой папке с правами новой группы безопасности.

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

Допустим, пользователь был добавлен в группу AD для получения доступа к сетевому каталогу. Попробуйте обратиться к нему по имени или FQDN (!!! это важно) (к примеру, \\msk-fs1.winitpro.loc\distr). Но не по IP адресу.

Для короткого имени ресурса (
NAME
) и полного имени (
FQDN
) используются разные cifs тикеты. Если вы ранее использовали FQDN, то после сброса тикетов на клиенте командой
klist purge
, вы сможете получить доступ по NAME (при первом обращении будет выдан новый тикет с новыми группами). Старый тикет для FQDN при этом все еще находится в процесс explorer и не будет сброшен до его перезапуска (как описано выше).

В этот момент для пользователя выдается новый тикет Kerberos. Вы можете проверить, что TGT тикет был обновлен:

klist tgt

(см. значение
Cached TGT Start Time
)

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

Выполните команду
whoami /groups
чтобы убедиться, что пользователь получил новый TGT с обновленными группами безопасности не завершая сеанс .

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

Источник

Многие сервисы Linux (apache, nginx и др.) могут использовать keytab файлы для Kerberos аутентификации в Active Directory без ввода пароля. В keytab файле хранятся имена принципалов Kerberos и соответствующие им зашифрованные ключи (ключи получаются из паролей Kerberos). В этой статье мы покажем, как создать keytab файл для SPN связанной учетной записи Active Directory с помощью утилит ktpass.

Чаще всего для службы, которая требует использование keytab файла создается отдельная учетная запись пользователя ActiveDirectory (но можно использовать и объект компьютера), затем к ней привязывается имя сервиса (ServicePrincipalName — SPN). SPN используется аутентификацией Kerberos для сопоставления экземпляра сервиса с учетной записью в AD (благодаря этому приложения могут аутентифицироваться в качестве сервиса даже не зная имени пользователя).

Сначала создайте сервисную учетную запись в AD и задайте ей известный пароль. Можно создать учетную запись из графической консоли ADUC или с помощью PowerShell командлета New-ADUser (из модуля PowerShell для Active Directory):

New-ADUser -Name "web" -GivenName "nginx web app" -SamAccountName "web" -UserPrincipalName "[email protected]" -Path "OU=Services,OU=SPB,DC=test,DC=com" –AccountPassword (ConvertTo-SecureString “Bergam0ttapoK” -AsPlainText -force) -Enabled $true

Включите для сервисной учетной записи опции “User cannot change password” и “Password never expires“ через графическую консоль или PowerShell:

Get-ADUser web | Set-ADUser -PasswordNeverExpires:$True -CannotChangePassword:$true

Следующий шаг – привязка имени сервиса (SPN) к учетной записи пользователя. Этот шаг делать отдельно не обязательно, т.к. его автоматически выполняет утилита ktpass при создании keytab файла (я оставлю этот шаг здесь для общего понимания процесса).

Привяжите следующую SPN запись к учетной записи web:

setspn -A HTTP/[email protected] web

Выведите список SPN записей, привязанных к пользователю:

setspn -L web

setspn - вручную привязать SPN запись к пользователю

Чтобы создать keytab файл используется следующая команда:

ktpass -princ HTTP/[email protected] -mapuser web -crypto ALL -ptype KRB5_NT_PRINCIPAL -pass Bergam0ttapoK -target dc01.test.com -out c:\ps\web_host.keytab

Successfully mapped HTTP/www.test.com to web.
Password successfully set!
Key created.
Key created.
Key created.
Key created.
Key created.
Output keytab to c:\ps\web_host.keytab:
Keytab version: 0x502
keysize 53 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x1 (DES-CBC-CRC) keylength 8 (0x73f868856e046449)
keysize 53 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x3 (DES-CBC-MD5) keylength 8 (0x73f868856e046449)
keysize 61 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x17 (RC4-HMAC) keylength 16 (0x9365b81e20c6137186d956c06ade2e77)
keysize 77 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x12 (AES256-SHA1) keylength 32 (0x16b6c95e8047e7e70b1dc3cd502353df
5eeab2c24d4097c41165b0ca65b9b31f)
keysize 61 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x11 (AES128-SHA1) keylength 16 (0x72c8b1cde771e59b6f1bc6501d614e32)

Данная команда создала keytab файл (c:\ps\web_host.keytab) для SPN записи сервиса HTTP/[email protected]. При этом SPN запись привязывается к учетной записи web с указанным паролем.

Проверьте, что для SPN записи службы была создана успешно (если вы не создавали ее вручную):

setspn -Q */[email protected]

Видно, что SPN запись найдена (Existing SPN found!). Она привязана к учетной записи web,

В Windows нет встроенных средств для просмотра содержимого keytab файла. Но если, у вас а компьютере установлена версия Java JRE, вы можете воспользоваться утилитой klist.exe, которая входит в комплект java.

cd "c:\Program Files\Java\jre1.8.0_181\bin" klist.exe -K -e -t -k c:\PS\web_host.keytab

Key tab: c:\PS\web_host.keytab, 5 entries found.

klist.exe вывод содержимого keytab файла spn записией в windows

Посмотрим на содержимое key-tab файла. Здесь хранятся имена SPN, ключи, временные метки, алгоритм шифрование и версия ключа (KVNO — key version number).

При создании keytab файла утилита ktpass увеличивает значение атрибута msDS-KeyVersionNumber учетной записи (можно посмотреть в редакторе атрибутов AD) и использует это значение в качестве номера KVNO в keytab таблице.

Картинка с сайта: winitpro.ru

При смене пароля учетной записи значение этого атрибута увеличивается на единицу, при этом все keytab записи с предыдущим номером KVNO становятся невалидными (даже если старый и новый пароли совпадают). Если пароль пользователя в AD изменится, то keytab-файл придется сгенерировать заново.

В одном keytab файле могут хранится ключи нескольких SPN. Дополнительные имена SPN и ключи добавляются в keytab файл с помощью отдельных параметров утилиты ktpass (-in, -setupn, -setpass).

Дальнейшее использование полученного keytab файла зависит от конкретного сервиса, где он применяется. Например, здесь можно посмотреть особенности использования keytab-файла для прозрачной SSO аутентификации пользователей в системе мониторинга Zabbix. Также не забывайте о необходимости обеспечения безопасности keytab файлов (все, кто могут прочитать содержимое keytab смогут воспользоваться любыми ключами из него).

Источник

В прошлой части нашего цикла мы рассмотрели работу протоколов семейства NTLM, отметив ряд их существенных недостатков, которые невозможно решить в рамках протокола. Поэтому вместе с Active Directory на смену им пришел более совершенный протокол Kerberos, который продолжает успешно применяться до сих пор. В данном материале мы рассмотрим общие принципы функционирования данного протокола, что позволит получить начальные знания в этой области самым широким массам читателей.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) в рамках проекта «Афина» в 1983 году и долгое время использовался в качестве образовательного, пока версия 4 не была сделана общедоступной. В настоящий момент принята в качестве стандарта и широко используется следующая версия протокола Kerberos 5.

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

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

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

Перед тем как продолжить, следует прийти к соглашению по поводу используемых в статье терминов. Так под термином клиент будет рассматриваться любой узел сети, обращающийся к любому иному узлу — серверу — с целью доступа к любому из его ресурсов.

Основой инфраструктуры Kerberos является Центр распространения ключей (Key Distribution Center, KDC), который является доверенным центром аутентификации для всех участников сети (принципалов). Область Kerberos (Realm) — пространство имен для которых данный KDC является доверенным, как правило это область ограниченная пространством имен домена DNS, в Active Directory область Kerberos совпадает с доменом AD. Область Kerberos записывается в виде соответствующего ему доменного имени DNS, но в верхнем регистре. Принципалом или учетной записью Kerberos является любой участник отношений безопасности: учетная запись пользователя, компьютер, сетевая служба и т.д.

Центр распространения ключей содержит долговременные ключи для всех принципалов, в большинстве практических реализаций Kerberos долговременные ключи формируются на основе пароля и являются так называемым «секретом для двоих». С помощью такого секрета каждый из его хранителей может легко удостовериться, что имеет дело со своим напарником. При этом долговременные ключи не при каких обстоятельствах не передаются по сети и располагаются в защищенных хранилищах (KDC), либо сохраняются только на время сеанса.

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

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

Рассмотрим каким образом происходит аутентификация клиента по протоколу Kerberos.

Желая пройти проверку подлинности в сети, клиент передает KDC открытым текстом свое имя, имя домена и метку времени (текущее время клиента), зашифрованное долговременным ключом клиента. Метка времени в данном случае выступает в роли аутентификатора — определенной последовательности данных, при помощи которой узлы могут подтвердить свою подлинность.

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

Убедившись, что метка времени действительна KDC выдает клиенту сеансовый ключ и билет (тикет) на получение билета (ticket granting ticket, TGT), который содержит копию сеансового ключа и сведения о клиенте, TGT шифруется с помощью долговременного ключа KDC и никто кроме него билет расшифровать не может. Сеансовый ключ шифруется с помощью долговременного ключа клиента, а полученная от клиента метка времени возвращается обратно, зашифрованная уже сеансовым ключом. Билет на получение билета является действительным в течении 8 часов или до завершения сеанса пользователя.

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

Чтобы лучше понять этот механизм приведем небольшой пример. Если злоумышленник перехватил посланный KDC запрос, то он может на основе открытых данных послать клиенту поддельный сеансовый ключ и TGT, но не сможет расшифровать метку времени, так как не обладает долговременным ключом. Точно также, он может перехватить отправленные клиенту TGT и сеансовый ключ, но также не сможет расшифровать последний, не имея долговременного ключа. Перехватить долговременный ключ он не может, так как они по сети не передаются.

Успешно пройдя аутентификацию, клиент будет располагать сеансовым ключом, которым впоследствии он будет шифровать все сообщения для KDC и билетом на получение билета (TGT).

Теперь рассмотрим ситуацию, когда клиент хочет обратиться к серверу.

Для этого он снова обращается к KDC и посылает ему билет на получение билета, зашифрованную сеансовым ключом метку времени и имя сервера. Прежде всего KDC расшифровывает предоставленный ему TGT и извлекает оттуда данные о клиенте и его сеансовый ключ, обратите внимание, что сам KDC сеансовые ключи не хранит. Затем сеансовым ключом он расшифровывает данные от клиента и сравнивает метку времени с текущим. Если расхождения нет, то KDC формирует общий сеансовый ключ для клиента и сервера.

Теоретически теперь данный ключ следует передать как клиенту, так и серверу. Но KDC имеет защищенный канал и установленные доверительные отношения только с клиентом, поэтому он поступает по-другому. Экземпляр сеансового ключа для клиента он шифрует сессионным ключом, а копию сеансового ключа для сервера он объединяет с информацией о клиенте в сеансовый билет (session ticket), который шифрует закрытым ключом сервера, после чего также отправляет клиенту, дополнительно зашифровав сессионным ключом.

Таким образом клиент получает сессионный ключ для работы с сервером и сессионный билет. Получить содержимое билета, как и TGT, он не может, так как не располагает нужными долговременными ключами.

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

Он предъявляет ему сеансовый билет и метку времени, зашифрованную сессионным ключом. Сервер расшифровывает билет, извлекает оттуда свой экземпляр ключа и сведения о клиенте, затем расшифровывает метку времени и сравнивает ее с текущим. Если все нормально, то он шифрует полученную метку своим экземпляром сессионного ключа и посылает назад клиенту. Клиент расшифровывает ее своим сеансовым ключом и сравнивает с тем, что было послано серверу. Совпадение данных свидетельствует о том, что сервер тот, за кого себя выдает.

Как можно заметить, сеансовые ключи никогда не передаются по незащищенным каналам и не передаются узлам, с которыми нет доверительных отношений. У KDC нет доверительных отношений с сервером, и он не может передать ему сессионный ключ, так как нет уверенности, что ключ будет передан кому надо. Но у него есть долговременный ключ этого сервера, которым он шифрует билет, это гарантирует, что никто иной не прочитает его содержимое и не получит сессионный ключ.

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

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

Источник

powershell:active-directory:ps-script-to-get-list-of-all-accounts-with-kerberos-unconstrained-delegation

Powershell скрипт для получения списка всех учётных записей с Kerberos Unconstrained Delegation в домене Active Directory

В рамках аудита безопасности в домене Active Directory бывает полезно получить перечень всех учётных записей разных типов, имеющих включённое делегирование. Особенно в этом контексте интересны учётные записи с полным делегированием Kerberos (Unconstrained Delegation).

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

Перед запуском скрипта необходимо изменить переменную $DN, указав путь в каталоге Active Directory (в формате distinguishedName) к корневому контейнеру, в рамках которого нужно выполнять поиск.

[CmdletBinding()]
Param
(
# start the search at this DN. Default is to search all of the domain.
[string]$DN = "OU=SUB,DC=my,DC=domain,DC=com"
)
 
$SERVER_TRUST_ACCOUNT = 0x2000
$TRUSTED_FOR_DELEGATION = 0x80000
$TRUSTED_TO_AUTH_FOR_DELEGATION= 0x1000000
$PARTIAL_SECRETS_ACCOUNT = 0x4000000
$bitmask = $TRUSTED_FOR_DELEGATION -bor $TRUSTED_TO_AUTH_FOR_DELEGATION -bor $PARTIAL_SECRETS_ACCOUNT
 
# LDAP filter to find all accounts having some form of delegation.
# 1.2.840.113556.1.4.804 is an OR query.
$filter = @"
(&
(servicePrincipalname=*)
(|
(msDS-AllowedToActOnBehalfOfOtherIdentity=*)
(msDS-AllowedToDelegateTo=*)
(UserAccountControl:1.2.840.113556.1.4.804:=$bitmask)
)
(|
(objectcategory=computer)
(objectcategory=person)
(objectcategory=msDS-GroupManagedServiceAccount)
(objectcategory=msDS-ManagedServiceAccount)
)
)
"@ -replace "[\s\n]", ''
 
$propertylist = @(
"servicePrincipalname",
"useraccountcontrol",
"samaccountname",
"msDS-AllowedToDelegateTo",
"msDS-AllowedToActOnBehalfOfOtherIdentity"
)
Get-ADObject -LDAPFilter $filter -SearchBase $DN -SearchScope Subtree -Properties $propertylist -PipelineVariable account | ForEach-Object {
$isDC = ($account.useraccountcontrol -band $SERVER_TRUST_ACCOUNT) -ne 0
$fullDelegation = ($account.useraccountcontrol -band $TRUSTED_FOR_DELEGATION) -ne 0
$constrainedDelegation = ($account.'msDS-AllowedToDelegateTo').count -gt 0
$isRODC = ($account.useraccountcontrol -band $PARTIAL_SECRETS_ACCOUNT) -ne 0
$resourceDelegation = $account.'msDS-AllowedToActOnBehalfOfOtherIdentity' -ne $null
 
$comment = ""
if ((-not $isDC) -and $fullDelegation) {
$comment += "WARNING: full delegation to non-DC is not recommended!; "
}
if ($isRODC) {
$comment += "WARNING: investigation needed if this is not a real RODC; "
}
if ($resourceDelegation) {
# to count it using PS, we need the object type to select the correct function... broken, but there we are.
$comment += "INFO: Account allows delegation FROM other server(s); "
}
if ($constrainedDelegation) {
$comment += "INFO: constrained delegation service count: $(($account.'msDS-AllowedToDelegateTo').count); "
}
 
[PSCustomobject] @{
samaccountname = $account.samaccountname
objectClass = $account.objectclass
uac = ('{0:x}' -f $account.useraccountcontrol)
isDC = $isDC
isRODC = $isRODC
fullDelegation = $fullDelegation
constrainedDelegation = $constrainedDelegation
resourceDelegation = $resourceDelegation
comment = $comment
}
} | Out-Gridview

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

Проверено на следующих конфигурациях:

Версия ОС	Версия PowerShell
Microsoft Windows Server 2016 Standard 10.0.14393 (Build 14393)	PowerShell 5.1.14393.5127

Автор первичной редакции:
Алексей Максимов
Время публикации: 15.12.2022 16:44

Источник