Сводка
Отношения доверия между лесами позволяют ресурсам в лес Active Directory доверять удостоверениям из другого леса. Это доверие можно настроить в обоих направлениях. Доверенный лес является источником удостоверения пользователя. Доверяющий лес содержит ресурс, в котором пользователи проходят проверку подлинности. Доверенный лес может выполнять проверку подлинности пользователей в доверяемом лесу, не разрешая обратное.
Неограниченное делегирование Kerberos — это механизм, в котором пользователь отправляет свои учетные данные службе, чтобы разрешить службе доступ к ресурсам от имени пользователя. Чтобы включить неограниченное делегирование Kerberos, учетная запись службы в Active Directory должна быть помечена как доверенной для делегирования. Это создает проблему, если пользователь и служба принадлежат к разным лесам. Лес служб отвечает за разрешение делегирования. Делегирование включает учетные данные пользователей из леса пользователя.
Разрешение одному лесу принимать решения о безопасности, затрагивающие учетные записи другого леса, нарушает границу безопасности между лесами. Злоумышленник, владеющий лесом доверия, может запросить делегирование TGT для удостоверения из доверенного леса, предоставив ему доступ к ресурсам в доверенном лесу. Это не относится к ограниченному делегированию Kerberos (KCD).
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
Делегирование TGT блокируется в новых и существующих лесах и внешних отношениях доверия после установки обновлений за май и июль 2019 г. соответственно.
Чтобы повторно включить делегирование между отношениями доверия и вернуться к исходной небезопасной конфигурации, пока не будет разрешено ограниченное или ресурсное делегирование, установите для флага EnableTGTDelegation значение Да.
Командная строка 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 — Нет.
- Любое приложение или служба, которые используют неограниченное делегирование между лесами, завершится сбоем, если параметр EnableTGTDelegation вручную или программным способом задается в значение Да. После установки обновлений за май 2019 г. и июль 2019 г. по умолчанию EnableTGTDelegation имеет значение NO для новых и существующих отношений доверия. Дополнительные сведения о том, как обнаружить этот сбой, см. в разделе Поиск служб, использующих неограниченное делегирование. Временная шкала изменений, влияющих на применение этого обходного решения, см. в Обновления временная шкала.
- Дополнительные сведения о NETDOM см. в документации поNetdom.exe.
- Если необходимо включить делегирование TGT для доверия, рекомендуется снизить этот риск, включив Credential Guard в Защитнике Windows на клиентских компьютерах. Это предотвращает все неограниченное делегирование с компьютера, на котором включен и работает Credential Guard в Защитнике Windows.
- Если у вас есть лес или внешнее доверие и оба из них настроены как помещенные в карантин, делегирование TGT невозможно включить, так как два флага имеют противоположную семантику. Бит карантина укрепляет границу безопасности между участвующими доменами. Включение делегирования TGT стирает границы безопасности между доменами, предоставляя домену доверия доступ к учетным данным пользователей из доверенного домена. Вы не можете иметь его в обоих направлениях.
Добавьте флаг quarantine:no в синтаксис командной строки NETDOM, если флаг карантина в настоящее время включен. - Если вы изменили 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 г.
Выпущено обновление, добавив новую безопасную конфигурацию по умолчанию в новый лес и внешние отношения доверия. Если требуется делегирование между отношениями доверия, перед установкой обновления от 9 июля 2019 г. для флага EnableTGTDelegation должно быть установлено значение Да . Если делегирование между отношениями доверия не требуется, не следует устанавливать флаг 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 | Objectclass |
|---|---|---|
| partner.fabrikam.com | Опасно | пользователь |
| partner.fabrikam.com | labsrv$ | компьютер |
Обнаружение неограниченного делегирования через события Windows
При выдаче билета Kerberos контроллер домена Active Directory регистрирует следующие события безопасности. События содержат сведения о целевом домене. События можно использовать, чтобы определить, используется ли неограниченное делегирование во входящих отношениях доверия.
Примечание
Проверьте наличие событий, содержащих значение TargetDomainName , соответствующее доверенному доменному имени.
| Журнал событий | Источник события | Идентификатор события | Подробности |
|---|---|---|---|
| Безопасность | Аудит безопасности Microsoft-Windows | 4768 | Был выдан TGT Kerberos. |
| Безопасность | Аудит безопасности Microsoft-Windows | 4769 | Выдан билет службы Kerberos. |
| Безопасность | Аудит безопасности Microsoft-Windows | 4770 | Продлен билет службы Kerberos. |
Устранение неполадок проверки подлинности
Если неограниченное делегирование отключено, у приложений могут возникнуть проблемы совместимости с этими изменениями, если приложения полагаются на неограниченное делегирование. Эти приложения должны быть настроены на использование ограниченного делегирования или ограниченного делегирования на основе ресурсов. Дополнительные сведения см. в статье Обзор ограниченного делегирования Kerberos.
Приложения, использующие круговую проверку подлинности в отношениях доверия, не поддерживаются с использованием ограниченного делегирования. Например, делегирование завершается ошибкой, если пользователь в лесу A проходит проверку подлинности в приложении в лесу B, а приложение в лесу B пытается делегировать билет обратно в лесУ A.