Opdateringer til TGT-delegering på tværs af indgående tillidsforhold i Windows Server

Resumé

Skovtillidsforhold gør det muligt for ressourcer i et Active Directory Forest at have tillid til identiteter fra en anden skov. Dette tillidsforhold kan konfigureres i begge retninger. Den skov, der er tillid til, er kilden til brugeridentitet. Den betroede skov indeholder den ressource, som brugerne godkendes for. Den skov, der er tillid til, kan godkende brugere til den skov, der har tillid til, uden at det omvendte sker.

Ubegrænset Kerberos-delegering er en mekanisme, hvor en bruger sender sine legitimationsoplysninger til en tjeneste for at aktivere tjenesten til at få adgang til ressourcer på vegne af brugeren. For at aktivere ubegrænset Kerberos-delegering skal tjenestens konto i Active Directory være markeret som pålidelig til delegering. Dette skaber et problem, hvis brugeren og tjenesten tilhører forskellige skove. Serviceskoven er ansvarlig for at tillade delegering. Delegeringen omfatter legitimationsoplysninger for brugere fra brugerens område.

At tillade én skov at træffe sikkerhedsbeslutninger, der påvirker en anden skovs konti, overtræder sikkerhedsgrænsen mellem skove. En hacker, der ejer den betroede skov, kan anmode om delegering af en TGT for en identitet fra den betroede skov, hvilket giver denne adgang til ressourcer i den skov, der er tillid til. Dette gælder ikke for Kerberos Constrained delegation (KCD).

Windows Server 2012 introducerede håndhævelse af skovgrænse for fuld Kerberos-delegering. Denne funktion har føjet en politik til det domæne, der er tillid til, for at deaktivere ubegrænset delegering pr. tillid. Standardindstillingen for denne funktion tillader ubegrænset delegering og er usikker.

Der findes Opdateringer, som giver sikkerhedshærdning til følgende versioner af Windows Server:

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

Denne funktion sammen med ændringer i hærdning af sikkerhed blev tilbageført til følgende versioner:

• Windows Server 2008 R2
• Windows Server 2008

Disse sikkerhedsopdateringer foretager følgende ændringer:

• Ubegrænset Kerberos-delegering er som standard deaktiveret for nye skove og nye eksterne tillidsforhold, efter du har installeret opdateringen fra 14. maj og nyere opdateringer.
• Ubegrænset Kerberos-delegering er deaktiveret for skove (både nye og eksisterende) og eksterne tillidsforhold, efter du har installeret opdateringen fra 9. juli 2019 og nyere opdateringer.
• Administratorer kan aktivere ubegrænset Kerberos-delegering ved hjælp af maj eller nyere versioner af NETDOM- og AD PowerShell-modulet.

Opdateringerne kan medføre kompatibilitetskonflikter for programmer, der aktuelt kræver ubegrænset delegering på tværs af skov eller eksterne tillidsforhold. Dette gælder især for eksternt tillidsforhold, hvor karantæneflaget (også kaldet SID-filtrering) er aktiveret som standard. Godkendelsesanmodninger for tjenester, der bruger ubegrænset delegering over de angivne tillidsforholdstyper, mislykkes specifikt, når du anmoder om nye billetter.

Du kan se udgivelsesdatoerne på tidslinjen for Opdateringer.

Løsning

Hvis du vil levere data- og kontosikkerhed på en Windows Server-version, der har funktionen Håndhævelse af skovgrænse for fuld Kerberos-delegering, kan du blokere TGT-delegering, efter du har installeret marts 2019-opdateringerne på tværs af et indgående tillidsforhold ved at indstille netdom-flaget EnableTGTDelegation til Nej på følgende måde:

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

TGT-delegering blokeres for nye og eksisterende skov- og eksterne tillidsforhold, efter du har installeret opdateringerne fra henholdsvis maj og juli 2019.

Hvis du vil genaktivere delegering på tværs af tillidsforhold og vende tilbage til den oprindelige, usikre konfiguration, indtil begrænset eller ressourcebaseret delegering kan aktiveres, skal du angive flaget EnableTGTDelegation til Ja.

NETDOM-kommandolinjen til at aktivere TGT-delegering er som følger:

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

Du kan begrebsmæssigt betragte NETDOM-syntaksen til aktivering af TGT-delegering på følgende måde:

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

NETDOM-syntaksen for at aktivere TGT-delegering af fabrakam.com brugere på contoso.com servere er som følger:

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

         Bemærkninger

• Flaget EnableTGTDelegation skal angives i det domæne, der er tillid til (fabrikam.com i dette tilfælde) for hvert domæne, der er tillid til (f.eks. contoso.com). Når flaget er angivet, tillader det domæne, du har tillid til, ikke længere, at TGT'er uddelegeres til det domæne, der har tillid til.
• Den sikre tilstand for EnableTGTDelegation er nr.
• Ethvert program eller enhver tjeneste, der er afhængig af ubegrænset delegering på tværs af skove, mislykkes, når EnableTGTDelegation manuelt eller programmeringsmæssigt indstilles til Ja. EnableTGTDelegation er som standard NEJ på nye og eksisterende tillidsforhold, når du har installeret opdateringerne fra maj 2019 og juli 2019. Du kan finde flere oplysninger om, hvordan du registrerer denne fejl, under Søgning efter tjenester, der er afhængige af ubegrænset delegering. Se tidslinjen for Opdateringer for at få en tidslinje med ændringer, der påvirker, hvordan denne løsning kan anvendes.
• Du kan finde flere oplysninger om NETDOM i dokumentationen tilNetdom.exe.
• Hvis du skal aktivere TGT-delegering for et tillidsforhold, anbefales det, at du mindsker denne risiko ved at aktivere Windows Defender Credential Guard på klientcomputere. Dette forhindrer al ubegrænset delegering fra en computer, der har Windows Defender Credential Guard aktiveret og kører.
• Hvis du har en skov eller et eksternt tillidsforhold, og begge er konfigureret som sat i karantæne, kan TGT-delegering ikke aktiveres, fordi de to flag har modsat semantik. Karantænebitten styrker sikkerhedsgrænsen mellem deltagende domæner. Aktivering af TGT-delegering sletter sikkerhedsgrænserne mellem domæner ved at give det domæne, der har tillid til, adgang til legitimationsoplysninger for brugere fra det domæne, der er tillid til. Du kan ikke have begge dele.
  Føj flaget quarantine:no til NETDOM-kommandolinjesyntaksen, hvis karantæneflaget er aktiveret.
• Hvis du har ændret EnableTGTDelegation til Ja, skal du slette Kerberos-billetter på oprindelige og mellemliggende opkald efter behov. Den relevante billet, der skal slettes, er klientens henvisnings-TGT på tværs af den relevante tillidsforhold. Dette kan omfatte mere end én enhed, afhængigt af antallet af delegeringshop i et givent miljø.

Du kan finde flere oplysninger om denne fremgangsmåde i følgende artikel i Windows IT Pro Center:

Beskyt legitimationsoplysninger for afledt domæne med Windows Defender Credential Guard

Opdateringer tidslinje

12. marts 2019

Håndhævelse af skovgrænse for Kerberos' fulde delegering vil være tilgængelig som en opdatering, der aktiverer denne funktion på alle understøttede versioner af Windows Server, der er angivet i afsnittet Gælder for øverst i denne artikel. Vi anbefaler, at du indstiller funktionen på indgående skovtillidsforhold.

Opdateringen føjer funktionen Håndhævelse af skovgrænse for Kerberos fuld delegering til følgende systemer:

• Windows Server 2008 R2
• Windows Server 2008

14. maj 2019

Der blev udgivet en opdatering, som tilføjer en ny sikker standardkonfiguration til ny skov og eksterne tillidsforhold. Hvis du kræver delegering på tværs af tillidsforhold, skal flaget EnableTGTDelegation angives til Ja , før opdateringen fra 9. juli 2019 installeres. Hvis du ikke kræver delegering på tværs af tillidsforhold, bør du ikke angive flaget EnableTGTDelegation . Flaget EnableTGTDelegation ignoreres, indtil opdateringen for 9. juli 2019 er installeret, for at give administratorer tid til at genaktivere ubegrænset Kerberos-delegering, når det er påkrævet.

Som en del af denne opdatering angives flaget EnableTGTDelegation som standard til Nej for alle nyoprettede tillidsforhold. Dette er det modsatte af den forrige funktionsmåde. Vi anbefaler, at administratorer i stedet omkonfigurerer de berørte tjenester til at bruge ressourcebaseret, begrænset delegering.

Du kan finde flere oplysninger om, hvordan du registrerer kompatibilitetsproblemer, i Finde tjenester, der er afhængige af ubegrænset delegering.

9. juli 2019

Der blev udgivet en opdatering, der gennemtvinger den nye standardfunktionsmåde på indgående side af område og eksterne tillidsforhold. Godkendelsesanmodninger for tjenester, der bruger ubegrænset delegering over de angivne tillidsforholdstyper, godkendes, men uden delegering. Tjenesten mislykkes, når den forsøger at køre delegerede handlinger.

Se afsnittet Løsning for at afhjælpe problemet.

At finde tjenester, der er afhængige af ubegrænset delegering

For at søge efter skove, der har indgående tillidsforhold, som tillader TGT-delegering, og for at finde eventuelle sikkerhedskonti, der tillader ubegrænset delegering, skal du køre følgende PowerShell-scripts i en scriptfil (f.eks. 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 
}

Outputtet fra PowerShell-scripts viser Active Directory-sikkerhedsprincipaler i domæner, der er konfigureret til et indgående tillidsforhold fra det eksekverende domæne, hvor ubegrænset delegering er konfigureret. Outputtet vil ligne følgende eksempel.

Registrerer ubegrænset delegering via Windows-hændelser

Når der udstedes en Kerberos-billet, logger en Active Directory-domænecontroller følgende sikkerhedshændelser. Hændelserne indeholder oplysninger om destinationsdomænet. Du kan bruge hændelserne til at bestemme, om ubegrænset delegering bruges på tværs af indgående tillidsforhold.

Fejlfinding af godkendelsesfejl

Når ubegrænset delegering er deaktiveret, kan programmer have kompatibilitetsproblemer med disse ændringer, hvis programmerne er afhængige af ubegrænset delegering. Disse programmer skal konfigureres til at bruge begrænset delegering eller begrænset delegering, der er ressourcebaseret. Du kan finde flere oplysninger i Oversigt over begrænset delegering af Kerberos.

Programmer, der er afhængige af tur-retur-godkendelse på tværs af tillidsforhold, understøttes ikke ved hjælp af begrænset delegering. En delegering mislykkes f.eks., hvis en bruger i skov A godkendes til et program i skov B, og programmet i skov B forsøger at uddelegere en billet tilbage til skov A.