Aktualizace delegování TGT mezi příchozími vztahy důvěryhodnosti ve službě Windows Server

Shrnutí

Vztahy důvěryhodnosti doménové struktury poskytují prostředkům v doménové struktuře služba Active Directory způsob, jak důvěřovat identitám z jiné doménové struktury. Tento vztah důvěryhodnosti lze nakonfigurovat v obou směrech. Důvěryhodná doménová struktura je zdrojem identity uživatele. Důvěřující doménová struktura obsahuje prostředek, pomocí kterého se uživatelé ověřují. Důvěryhodná doménová struktura může ověřovat uživatele v důvěřující doménové struktuře, aniž by došlo k opaku.

Neomezené delegování protokolu Kerberos je mechanismus, ve kterém uživatel odesílá své přihlašovací údaje službě, aby služba mohla přistupovat k prostředkům jménem uživatele. Pokud chcete povolit neomezené delegování protokolu Kerberos, musí být účet služby služba Active Directory označený pro delegování jako důvěryhodný. To způsobí problém, pokud uživatel a služba patří do různých doménových struktur. Doménová struktura služby je zodpovědná za povolení delegování. Delegování zahrnuje přihlašovací údaje uživatelů z doménové struktury uživatele.

Povolení jedné doménové struktury činit rozhodnutí o zabezpečení, která mají vliv na účty jiné doménové struktury, porušuje hranici zabezpečení mezi doménovými strukturami. Útočník, který vlastní důvěřující doménovou strukturu, může požádat o delegování TGT pro identitu z důvěryhodné doménové struktury, což mu umožní přístup k prostředkům v důvěryhodné doménové struktuře. Tento problém neplatí pro omezené delegování protokolu Kerberos (KCD).

Ve službě Windows Server 2012 bylo zavedeno vynucení hranic doménové struktury pro úplné delegování protokolu Kerberos. Tato funkce přidala zásadu důvěryhodné domény, která zakazuje neomezené delegování na základě důvěryhodnosti. Výchozí nastavení této funkce umožňuje neomezené delegování a není to bezpečné.

Aktualizace zajišťující posílení zabezpečení existují pro následující verze systému Windows Server:

• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012

Tato funkce společně se změnami v posílení zabezpečení byla zpětně portována do následujících verzí:

• Windows Server 2008 R2
• Windows Server 2008

Tyto aktualizace zabezpečení přinášejí následující změny:

• Po instalaci aktualizace ze 14. května a novějších aktualizací je ve výchozím nastavení v nové doménové struktuře a nových externích vztazích důvěryhodnosti zakázáno neomezené delegování protokolu Kerberos.
• Po instalaci aktualizace z 9. července 2019 a novějších aktualizací je v doménových strukturách (nových i stávajících) a externích vztazích důvěryhodnosti zakázáno neomezené delegování protokolu Kerberos.
• Správci můžou povolit neomezené delegování protokolu Kerberos pomocí květnové nebo novější verze NETDOM a modulu AD PowerShell.

Tyto aktualizace můžou způsobit konflikty kompatibility u aplikací, které aktuálně vyžadují neomezené delegování v rámci doménové struktury nebo externích vztahů důvěryhodnosti. To platí zejména pro externí vztah důvěryhodnosti, pro který je ve výchozím nastavení povolen příznak karantény (označovaný také jako filtrování SID). Konkrétně požadavky na ověření pro služby, které používají neomezené delegování pomocí uvedených typů důvěryhodnosti, selžou, když požádáte o nové lístky.

Data vydání najdete Aktualizace časové ose.

Alternativní řešení

Chcete-li zajistit zabezpečení dat a účtů ve verzi systému Windows Server, která má funkci Vynucení hranic doménové struktury pro úplné delegování protokolu Kerberos, můžete po instalaci aktualizací z března 2019 prostřednictvím příchozího vztahu důvěryhodnosti zablokovat delegování TGT nastavením příznaku netdom EnableTGTDelegation na Ne následujícím způsobem:

netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No

Delegování TGT je zablokované u nových a stávajících doménových struktur a externích vztahů důvěryhodnosti po instalaci aktualizací z května a července 2019.

Chcete-li znovu povolit delegování mezi vztahy důvěryhodnosti a vrátit se k původní nebezpečné konfiguraci, dokud nebude možné povolit omezené delegování nebo delegování založené na prostředcích, nastavte příznak EnableTGTDelegation na Ano.

Příkazový řádek NETDOM pro povolení delegování TGT je následující:

netdom trust <TrustedDomainName > /domain:<TrustingDomainName > /EnableTgtDelegation:Yes

Syntaxi NETDOM pro povolení delegování TGT si můžete představit takto:

netdom trust <domain that you are administering> /domain:<domain whose trust NETDOM is modifying> /EnableTgtDelegation:Yes

Syntaxe NETDOM k povolení delegování TGT fabrakam.com uživatelů na contoso.com serverech je následující:

netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:Yes

         Poznámky

• Příznak EnableTGTDelegation by měl být nastaven v důvěryhodné doméně (v tomto případě fabrikam.com) pro každou důvěřující doménu (například contoso.com). Po nastavení příznaku již důvěryhodná doména nepovolí delegování TGT na důvěřující doménu.
• Zabezpečený stav pro EnableTGTDelegation je Ne.
• Jakákoli aplikace nebo služba, která se spoléhá na neomezené delegování mezi doménovými strukturami, selže, když je EnableTGTDelegation ručně nebo programově nastaveno na Ano. Po instalaci aktualizací z května 2019 a července 2019 je výchozí nastavení EnableTGTDelegation u nových a stávajících vztahů důvěryhodnosti na NE . Další informace o tom, jak zjistit tuto chybu, najdete v tématu Vyhledání služeb, které spoléhají na neomezené delegování. Časovou osu změn, které ovlivňují způsob použití tohoto alternativního řešení, najdete Aktualizace časové ose.
• Další informace o platformě NETDOM najdete v dokumentaci kNetdom.exe.
• Pokud musíte u vztahu důvěryhodnosti povolit delegování TGT, doporučujeme toto riziko zmírnit povolením ochrany Credential Guard v programu Windows Defender na klientských počítačích. To zabrání veškerému neomezenému delegování z počítače, na kterém je povolená a spuštěná Ochrana Credential Guard v programu Windows Defender.
• Pokud máte doménovou strukturu nebo externí vztah důvěryhodnosti a oba jsou nakonfigurováni jako v karanténě, delegování TGT nelze povolit, protože tyto dva příznaky mají opačnou sémantiku. Karanténní bit posiluje hranici zabezpečení mezi zúčastněnými doménami. Povolením delegování TGT smažete hranice zabezpečení mezi doménami tím, že důvěřující doméně poskytnete přístup k přihlašovacím údajům uživatelů z důvěryhodné domény. Nemůžete mít obojí.
  Pokud je příznak karantény aktuálně povolen, přidejte do syntaxe příkazového řádku NETDOM příznak quarantine:no.
• Pokud jste změnili EnableTGTDelegation na Ano, odstraňte podle potřeby lístky protokolu Kerberos u původních a zprostředkujících volajících. Příslušným lístkem ke smazání je doporučení TGT klienta v rámci příslušného svěřenského fondu. To může zahrnovat více než jedno zařízení v závislosti na počtu směrování delegování v daném prostředí.

Další informace o tomto postupu najdete v následujícím článku aplikace Windows IT Pro Center:

Ochrana odvozených přihlašovacích údajů domény pomocí ochrany Credential Guard v programu Windows Defender

Aktualizace časové osy

12. března 2019

Vynucení hranic doménové struktury pro úplné delegování protokolu Kerberos bude k dispozici jako aktualizace, která tuto funkci povolí ve všech podporovaných verzích systému Windows Server, které jsou uvedeny v části Platí pro na začátku tohoto článku. Doporučujeme nastavit funkci u příchozích vztahů důvěryhodnosti doménové struktury.

Tato aktualizace přidá funkci vynucení hranic doménové struktury pro úplné delegování protokolu Kerberos do následujících systémů:

• Windows Server 2008 R2
• Windows Server 2008

14. května 2019

Byla vydána aktualizace, která přidává novou bezpečnou výchozí konfiguraci do nové doménové struktury a externích vztahů důvěryhodnosti. Pokud požadujete delegování napříč vztahy důvěryhodnosti, měl by být příznak EnableTGTDelegation před instalací aktualizace z 9. července 2019 nastaven na Ano . Pokud nevyžadujete delegování mezi vztahy důvěryhodnosti, neměli byste nastavovat příznak EnableTGTDelegation . Příznak EnableTGTDelegation bude až do instalace aktualizace z 9. července 2019 ignorován, aby správci měli čas v případě potřeby znovu povolit neomezené delegování protokolu Kerberos.

V rámci této aktualizace bude příznak EnableTGTDelegation ve výchozím nastavení nastaven pro všechny nově vytvořené vztahy důvěryhodnosti na hodnotu Ne . Jedná se o opak předchozího chování. Doporučujeme, aby správci místo toho překonfigurovali dotčené služby tak, aby používaly omezené delegování založené na prostředcích.

Další informace o tom, jak zjistit problémy s kompatibilitou, najdete v tématu Vyhledání služeb využívajících neomezené delegování.

9. července 2019

Byla vydána aktualizace, která vynucuje nové výchozí chování na příchozí straně doménové struktury a externích vztahů důvěryhodnosti. Žádosti o ověření u služeb, které využívají neomezené delegování pomocí uvedených typů důvěryhodnosti, budou ověřeny, ale bez delegování. Služba selže, když se pokusí spustit delegované operace.

Informace o zmírnění rizik najdete v části "alternativní řešení".

Hledání služeb využívajících neomezené delegování

Pokud chcete vyhledat doménové struktury s příchozími vztahy důvěryhodnosti umožňující delegování TGT a všechny objekty zabezpečení, které umožňují neomezené delegování, spusťte následující skripty PowerShellu v souboru skriptu (například 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 
}

Výstup skriptů PowerShellu obsahuje seznam objektů zabezpečení služby služba Active Directory v doménách, které jsou nakonfigurované pro příchozí vztah důvěryhodnosti z provádějící domény, která má nakonfigurované neomezené delegování. Výstup bude vypadat podobně jako v následujícím příkladu.

Zjišťování neomezeného delegování prostřednictvím událostí Windows

Při vystavení lístku protokolu Kerberos zaznamená řadič domény služby služba Active Directory následující události zabezpečení. Události obsahují informace o cílové doméně. Pomocí těchto událostí můžete určit, zda je mezi příchozími vztahy důvěryhodnosti použito neomezené delegování.

Řešení potíží s chybami ověřování

Pokud je zakázané delegování zakázané, můžou mít aplikace problémy s kompatibilitou s těmito změnami, pokud aplikace spoléhají na neomezené delegování. Tyto aplikace by měly být nakonfigurovány pro použití omezeného delegování nebo omezeného delegování, které je založeno na prostředcích. Další informace najdete v tématu Přehled omezeného delegování protokolu Kerberos.

Aplikace, které spoléhají na ověřování pomocí obousměrné cesty mezi vztahy důvěryhodnosti, nejsou podporovány pomocí omezeného delegování. Delegování například selže, pokud se uživatel v doménové struktuře A ověří v aplikaci v doménové struktuře B a aplikace v doménové struktuře B se pokouší delegovat lístek zpět do doménové struktury A.