Зведення
Лісові трасти дають змогу ресурсам у ліс Active Directory довіряти ідентичностям з іншого лісу. Цю довіру можна налаштувати в обох напрямках. Надійний ліс – це джерело ідентичностей користувачів. Надійний ліс містить ресурс, для якого автентифікуються користувачі. Довірений ліс може автентифікувати користувачів у надійному лісі, не допускаючи зворотної ситуації.
Необмежене делегування Kerberos — це механізм, при якому користувач надсилає свої облікові дані до служби, щоб служба могла отримати доступ до ресурсів від імені користувача. Щоб увімкнути необмежене делегування Kerberos, обліковий запис служби в Active Directory має бути позначено як надійний для делегування. Це створює проблему, якщо користувач і служба належать до різних лісів. За надання дозволу делегування відповідає ліс служби. Делегування включає облікові дані користувачів із лісу користувача.
Якщо дозволити одному лісу приймати рішення щодо безпеки, які впливають на облікові записи іншого лісу, порушується межа безпеки між лісами. Зловмисник, який володіє надійним лісом, може надіслати запит на делегування TGT для посвідчення з довіреного лісу, що надає йому доступ до ресурсів у надійному лісі. Це не стосується обмеженого делегування Kerberos (KCD).
Windows ServerУ Windows Server 2012 запроваджено примусове застосування меж лісу для повного делегування Kerberos. Ця функція додала політику до довіреного домену, яка вимикає необмежене делегування для кожної довіри. Ця функція за промовчанням дає змогу необмежено делегувати повноваження та є небезпечною.
Оновлення, які забезпечують посилення безпеки, існують для таких версій Windows Server:
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
Цю функцію, а також зміни в посиленні безпеки перенесено до наступних версій:
- Windows Server 2008 R2
- Windows Server 2008
Ці оновлення системи безпеки вносять такі зміни:
- Необмежене делегування Kerberos вимкнуто за замовчуванням для нових лісів і нових зовнішніх довірчих зв'язків після інсталяції оновлення від 14 травня та пізніших оновлень.
- Необмежене делегування Kerberos вимкнуто в лісах (як нових, так і існуючих) і зовнішніх довірах після інсталяції оновлення від 9 липня 2019 року та пізніших оновлень.
- Адміністратори можуть увімкнути необмежене делегування Kerberos за допомогою травневих або пізніших версій модуля NETDOM і AD PowerShell.
Оновлення можуть спричинити конфлікти сумісності для програм, які наразі потребують необмеженого делегування в лісі або зовнішніх довірчих зв'язках. Це особливо стосується зовнішньої довіри, для якої позначку карантину (також відома як фільтрування SID) увімкнуто за замовчуванням. Зокрема, запити на автентифікацію для служб, які використовуватимуть необмежене делегування в зазначених типах довірчих зв'язків, завершиться з помилкою під час нових запитів.
Дати випуску дивіться Оновлення часовій шкалі.
Спосіб вирішення
Щоб забезпечити захист даних і облікового запису у версії Windows Server, у якій передбачено функцію повного делегування Kerberos, ви можете заблокувати делегування TGT після інсталяції оновлень за березень 2019 р. для вхідного довіру, встановивши для прапорця netdom значення EnableTGTDelegation значення "Ні", як описано нижче:
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No
Після інсталяції оновлень за травень і липень 2019 р. делегування TGT у нових і наявних лісових і зовнішніх довірчих зв'язках буде заблоковано.
Щоб повторно ввімкнути делегування між довірчими зв'язками та повернутися до вихідної небезпечної конфігурації, доки не буде ввімкнуто делегування з обмеженнями або на основі ресурсів, установіть для прапорця EnableTGTDelegation значення "Yes" ( Так).
Командний рядок NETDOM для делегування TGT виглядає наступним чином:
netdom trust <TrustedDomainName > /domain:<TrustingDomainName > /EnableTgtDelegation:Yes
Концептуально можна уявити синтаксис NETDOM для делегування TGT наступним чином:
netdom trust <domain that you are administering> /domain:<domain whose trust NETDOM is modifying> /EnableTgtDelegation:Yes
Синтаксис функції NETDOM для делегування TGT fabrakam.com користувачів на серверах contoso.com має такий вигляд:
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:Yes
Примітки
- Позначку EnableTGTDelegation потрібно встановити в надійному домені (у цьому випадку fabrikam.com) для кожного надійного домену (наприклад, contoso.com). Після встановлення позначки довірений домен більше не дозволятиме делегувати TGT довіреному домену.
- Безпечний стан для EnableTGTDelegation – No.
- Будь-яка програма або служба, яка використовує необмежене делегування між лісами, завершується помилкою, якщо для параметра EnableTGTDelegation вручну або програмно встановлено значення "Yes" (Так). Після інсталяції оновлень за травень 2019 і липень 2019 р. параметр EnableTGTDelegation за замовчуванням – "НІ" для нових і наявних довірчих зв'язків. Докладні відомості про те, як виявити цю помилку, див. в статті "Пошук служб, які використовують необмежене делегування". Див Оновлення. часову шкалу змін, які впливають на спосіб застосування цього тимчасового вирішення.
- Для отримання додаткової інформації про NETDOM перегляньте документаціюNetdom.exe.
- Якщо потрібно ввімкнути делегування TGT у довіреному зв'язку, рекомендується зменшити цей ризик, увімкнувши Credential Guard для Захисника Windows на клієнтських комп'ютерах. Це запобігає необмеженому делегуванню з комп'ютера, на якому ввімкнуто та запущено Credential Guard для Захисника Windows.
- Якщо використовується ліс або зовнішній довірчий зв'язок, і один із них налаштовано як карантин, делегування TGT неможливо ввімкнути, оскільки ці два прапори мають протилежну семантику. Біт карантину посилює межу безпеки між доменами, що беруть участь. Делегування TGT стирає межі безпеки між доменами, надаючи довіреному домену доступ до облікових даних користувачів із довіреного домену. Не може бути і так, і так.
Додайте позначку quarantine:no до синтаксису командного рядка NETDOM, якщо позначку quarantine увімкнено. - Якщо для параметра EnableTGTDelegation вибрано значення "Так", за потреби видаліть запити Kerberos для вихідних і проміжних абонентів. Релевантним квитком, який потрібно видалити, є реферальний TGT клієнта у відповідному трасті. Для цього може бути задіяно кілька пристроїв, залежно від кількості переходів делегування в певному середовищі.
Докладні відомості про цю процедуру див. у такій статті Windows IT Pro Center:
Захист похідних облікових даних домену за допомогою Засобу Credential Guard для Захисника Windows
Оновлення часової шкали
12 березня 2019 р.
Примусове застосування межі лісу для повного делегування Kerberos буде доступне в міру оновлення для всіх підтримуваних версій Windows Server, перелічених у розділі "Застосовується до" на початку цієї статті. Радимо налаштувати цю функцію на вхідні лісові трасти.
В оновленні буде додано функцію повного делегування меж лісу для Kerberos до таких систем:
- Windows Server 2008 R2
- Windows Server 2008
14 травня 2019 р.
Випущено оновлення, яке додало нову конфігурацію безпеки за замовчуванням для нових лісів і зовнішніх довірчих зв'язків. Якщо вам потрібне делегування для різних довірчих зв'язків, для параметра EnableTGTDelegation потрібно встановити значення "Так ", перш ніж інсталювати оновлення від 9 липня 2019 р. Якщо делегування довірчим трастам не потрібне, не слід встановлювати позначку EnableTGTDelegation . Позначка EnableTGTDelegation ігноруватиметься, доки не буде інстальовано оновлення від 9 липня 2019 р., щоб дати адміністраторам час повторно ввімкнути необмежене делегування Kerberos, коли це потрібно.
У рамках цього оновлення для позначки EnableTGTDelegation за замовчуванням для новостворених трастів буде встановлено значення "Ні ". Це пов'язано з попередньою поведінкою. Радимо адміністраторам натомість змінити настройки служб, на які вплине ця зміна, для застосування обмеженого делегування на основі ресурсів.
Додаткові відомості про виявлення проблем сумісності див. в статті "Пошук служб, які використовують необмежене делегування".
9 липня 2019 р.
Випущено оновлення, яке застосовує нову стандартну поведінку на стороні вхідного лісу та зовнішніх довірчих зв'язків. Запити на автентифікацію для служб, які використовують необмежене делегування в зазначених типах довірчих зв'язків, автентифікуватимуться, але без делегування. У роботі служби станеться збій під час спроби запустити делеговані операції.
Щоб дізнатися, як пом'якшити ризик, перегляньте розділ "Спосіб вирішення".
Пошук служб, які залежать від необмеженого делегування
Щоб перевірити ліси з вхідними довірчими зв'язками, які дозволяють делегувати TGT, і знайти будь-які принципи безпеки, які дозволяють необмежене делегування, виконайте наведені нижче сценарії PowerShell у файлі сценарію (наприклад, Get-RiskyServiceAccountsByTrust.ps1 -Collect):
Примітка.
Ви також можете передати позначку -ScanAll для пошуку в довірчих відносинах, які не дозволяють делегування TGT.
Сценарії PowerShell
[CmdletBinding()]
Param
(
[switch]$Collect,
[switch]$ScanAll
)
if ($Debug) {
$DebugPreference = 'Continue'
}
else {
$DebugPreference = 'SilentlyContinue'
}
function Get-AdTrustsAtRisk
{
[CmdletBinding()]
Param
(
[string]$Direction = "Inbound",
[switch]$ScanAll
)
if ($ScanAll) {
return get-adtrust -filter {Direction -eq $Direction}
}
else {
return get-adtrust -filter {Direction -eq $Direction -and TGTDelegation -eq $false}
}
}
function Get-ServiceAccountsAtRisk
{
[CmdletBinding()]
Param
(
[string]$DN = (Get-ADDomain).DistinguishedName,
[string]$Server = (Get-ADDomain).Name
)
Write-Debug "Searching $DN via $Server"
$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
$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"
)
$riskyAccounts = @()
try {
$accounts = Get-ADObject -LDAPFilter $filter -SearchBase $DN -SearchScope Subtree -Properties $propertylist -Server $Server
}
catch {
Write-Warning "Failed to query $Server. Consider investigating seperately. $($_.Exception.Message)"
}
foreach ($account in $accounts) {
$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
$acct = [PSCustomobject] @{
domain = $Server
sAMAccountName = $account.samaccountname
objectClass = $account.objectclass
isDC = $isDC
isRODC = $isRODC
fullDelegation = $fullDelegation
constrainedDelegation = $constrainedDelegation
resourceDelegation = $resourceDelegation
}
if ($fullDelegation) {
$riskyAccounts += $acct
}
}
return $riskyAccounts
}
function Get-RiskyServiceAccountsByTrust
{
[CmdletBinding()]
Param
(
[switch]$ScanAll
)
$riskyAccounts = @()
$trustTypes = $("Inbound", "Bidirectional")
foreach ($type in $trustTypes) {
$riskyTrusts = Get-AdTrustsAtRisk -Direction $type -ScanAll:$ScanAll
foreach ($trust in $riskyTrusts) {
$domain = $null
try {
$domain = Get-AdDomain $trust.Name -ErrorVariable eatError -ErrorAction Ignore
} catch {
write-debug $_.Exception.Message
}
if($eatError -ne $null) {
Write-Warning "Couldn't find domain: $($trust.Name)"
}
if ($domain -ne $null) {
$accts = Get-ServiceAccountsAtRisk -DN $domain.DistinguishedName -Server $domain.DNSRoot
foreach ($acct in $accts) {
Write-Debug "Risky: $($acct.sAMAccountName) in $($acct.domain)"
}
$risky = [PSCustomobject] @{
Domain = $trust.Name
Accounts = $accts
}
$riskyAccounts += $risky
}
}
}
return $riskyAccounts
}
if ($Collect) {
Get-RiskyServiceAccountsByTrust -ScanAll:$ScanAll | Select-Object -expandProperty Accounts | format-table
}
У вихідних даних сценаріїв PowerShell буде перелічено принципи безпеки Active Directory в доменах, для яких настроєно вхідну довіру з виконуючого домену, у якому настроєно необмежене делегування. Результат виглядатиме приблизно так, як у прикладі нижче.
| домен | sAMAccountName | Клас об'єкта |
|---|---|---|
| partner.fabrikam.com | Небезпечно | користувач |
| partner.fabrikam.com | labsrv$ | комп’ютер |
Виявлення необмеженого делегування за допомогою подій Windows
Під час видачі запиту Kerberos контролер домену служби Active Directory реєструє наведені нижче події безпеки. Події містять відомості про цільовий домен. За цими подіями можна визначити, чи застосовується необмежене делегування до вхідних довірчих зв'язків.
Примітка.
Перевірте, чи є події, які містять значення TargetDomainName, що збігається з надійним ім'ям домену.
| Журнал подій | Джерело події | Ідентифікатор події | Відомості |
|---|---|---|---|
| Безпека | Microsoft-Windows-Security-Auditing | 4768 | Було випущено Kerberos TGT. |
| Безпека | Microsoft-Windows-Security-Auditing | 4769 | Видано квиток на обслуговування Kerberos. |
| Безпека | Microsoft-Windows-Security-Auditing | 4770 | Квиток на обслуговування Kerberos оновлено. |
Виправлення неполадок автентифікації
Якщо необмежене делегування вимкнуто, у програмах можуть виникати проблеми сумісності з цими змінами, якщо програми залежать від необмеженого делегування. Ці програми потрібно настроїти на використання обмеженого делегування або обмеженого делегування на основі ресурсів. Докладні відомості див. в огляді обмеженого делегування Kerberos.
Програми, які використовують автентифікацію через довірчі зв'язки, не підтримуються за допомогою обмеженого делегування. Наприклад, делегування завершується помилкою, якщо користувач у лісі А автентифікується перед програмою в лісі B, а програма в лісі B намагається делегувати квиток назад до лісу A.