Актуализации за делегиране на TGT във входящи доверия в Windows Server

Резюме

Доверието на гори осигурява начин на ресурсите в гора на 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). След като флагът бъде зададен, надеждният домейн повече няма да позволява TGTs да бъдат делегирани на доверения домейн.
• Състоянието на защита за EnableTGTDelegation е "Не".
• Всяко приложение или услуга, която разчита на неограничено делегиране в горите, ще бъде неуспешна, когато EnableTGTDelegation ръчно или програмно е зададено на "Да". EnableTGTDelegation по подразбиране е "НЕ " за новите и съществуващите гаранти, след като инсталирате актуализациите от май 2019 г. и юли 2019 г. За повече информация как да откриете тази грешка вижте "Намиране на услуги, които разчитат на неограничено делегиране". Вижте времевата линия на Актуализации за времевата линия на промените, които засягат начина, по който може да се приложи това заобиколно решение.
• За повече информация относно NETDOM вж. документацията наNetdom.exe.
• Ако трябва да разрешите делегирането на TGT на гарант, препоръчително е да намалите този риск, като разрешите Windows Defender Credential Guard на клиентските компютри. Това предотвратява всякакво неограничено делегиране от компютър, който има активиран и работещ Windows Defender Credential Guard.
• Ако имате гора или външно доверие и всеки от тях е конфигуриран като карантина, делегирането на TGT не може да бъде разрешено, защото двата флага имат противоположна семантика. Карантинният бит укрепва границата на защита между участващите домейни. Разрешаването на делегиране на TGT изтрива границите на защита между домейните, като дава на надеждния домейн достъп до идентификационните данни на потребителите от надеждния домейн. Не може да има и двете.
  Добавете флага quarantine:no към синтаксиса на командния ред на NETDOM, ако флагът за карантина е разрешен в момента.
• Ако сте променили EnableTGTDelegation на "Да", изтрийте билетите на Kerberos за първоначални повикващи и средно напреднали повикващи, както е необходимо. Съответният билет за изтриване е препоръката на клиента TGT в съответния тръст. Това може да включва повече от едно устройство в зависимост от броя на преходите за делегиране в дадена среда.

За повече информация относно тази процедура вижте следната статия в Windows IT Pro Center:

Защита на извлечени идентификационни данни за домейн с Windows Defender Credential Guard

Актуализации на времевата линия

12 март, 2019 г.

Прилагането на границата на гората за пълно делегиране на Kerberos ще бъде налично като актуализация, за да разреши тази функция на всички поддържани версии на Windows Server, които са изброени в раздела "Отнася се за" в горната част на тази статия. Препоръчваме ви да настроите функцията за входящи доверия на гори.

Актуализацията ще добави функцията за пълно делегиране на Enforcement for Forest Boundary for 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):

[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 в домейни, които са конфигурирани за входящо доверие от изпълняващия се домейн, който е с конфигурирано неограничено делегиране. Резултатът ще прилича на следващия пример.

Откриване на неограничено делегиране чрез събития на Windows

Когато се издава билет на Kerberos, домейновият контролер на Active Directory регистрира следните събития за защита. Събитията съдържат информация за целевия домейн. Можете да използвате събитията, за да определите дали се използва неограничено делегиране във входящи доверия.

Отстраняване на неизправности при удостоверяване

Когато е забранено неограничено делегиране, приложенията може да имат проблеми със съвместимостта с тези промени, ако приложенията разчитат на неограничено делегиране. Тези приложения трябва да бъдат конфигурирани да използват ограничено делегиране или ограничено делегиране, базирано на ресурси. За повече информация вижте Общ преглед на ограниченото делегиране на Kerberos.

Приложения, които разчитат на двупосочно удостоверяване в доверие, не се поддържат чрез ограничено делегиране. Например делегирането е неуспешно, ако потребител в гора A се удостовери пред приложение в гора B, а приложението в гора B се опитва да делегира билет обратно към гора A.