Uppdateringar till TGT-delegering mellan inkommande förtroenden i Windows Server

Sammanfattning

Skogsförtroenden är ett sätt för resurser i en služba Active Directory-skog att lita på identiteter från en annan skog. Det här förtroendet kan konfigureras i båda riktningarna. Den betrodda skogen är källan till användaridentiteten. Den betrodda skogen innehåller den resurs som användarna autentiseras för. Den betrodda skogen kan autentisera användare i den betrodda skogen utan att det omvända inträffar.

Obegränsad Kerberos-delegering är en mekanism där en användare skickar sina autentiseringsuppgifter till en tjänst så att tjänsten kan komma åt resurser för användarens räkning. För att kunna aktivera obegränsad Kerberos-delegering måste tjänstens konto i služba Active Directory markeras som betrott för delegering. Det skapar problem om användaren och tjänsten tillhör olika skogar. Tjänstskogen ansvarar för att tillåta delegering. Delegeringen innehåller autentiseringsuppgifter för användare från användarens skog.

Om du tillåter en skog att fatta säkerhetsbeslut som påverkar en annan skogs konton bryter du mot säkerhetsgränsen mellan skogar. En angripare som äger den betrodda skogen kan begära delegering av en TGT för en identitet från den betrodda skogen, vilket ger den åtkomst till resurser i den betrodda skogen. Detta gäller inte för Kerberos-begränsad delegering (KCD).

Windows Server 2012 introducerade tvingande skogsgräns för fullständig delegering för Kerberos. Den här funktionen har lagt till en princip i den betrodda domänen för att inaktivera obegränsad delegering per förtroende. Standardinställningen för den här funktionen tillåter obegränsad delegering och är osäker.

Uppdateringar som ger säkerhetshärdning finns för följande versioner av Windows Server:

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

Den här funktionen, tillsammans med ändringar i säkerhetshärdning, har bakåtanpassats till följande versioner:

• Windows Server 2008 R2
• Windows Server 2008

Dessa säkerhetsuppdateringar gör följande ändringar:

• Obegränsad Kerberos-delegering är inaktiverad som standard för ny skog och nya externa förtroenden när du har installerat uppdateringen från 14 maj och senare uppdateringar.
• Obegränsad Kerberos-delegering inaktiveras för skogar (både nya och befintliga) och externa förtroenden efter att du har installerat uppdateringen från den 9 juli 2019 och senare uppdateringar.
• Administratörer kan aktivera obegränsad Kerberos-delegering med hjälp av maj- eller senare versioner av NETDOM- och AD PowerShell-modulen.

Uppdateringarna kan orsaka kompatibilitetskonflikter för program som för närvarande kräver obegränsad delegering över skog eller externa förtroenden. Detta gäller särskilt externa förtroenden för vilka karantänflaggan (kallas även SID-filtrering) är aktiverad som standard. Mer specifikt misslyckas autentiseringsbegäranden för tjänster som använder obegränsad delegering över de angivna förtroendetyperna när du begär nya biljetter.

Utgivningsdatumen finns i Tidslinje för uppdateringar.

Lösning

För att tillhandahålla data- och kontosäkerhet på en Windows Server version som har funktionen Tvingande för skogsgräns för Kerberos fullständig delegering kan du blockera TGT-delegering efter att du installerat mars 2019-uppdateringarna över ett inkommande förtroende genom att ange netdom-flaggan EnableTGTDelegation till Nej, enligt följande:

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

TGT-delegering blockeras på nya och befintliga skogar och externa förtroenden efter att du har installerat uppdateringarna från maj respektive juli 2019.

Om du vill återaktivera delegering mellan förtroenden och återgå till den ursprungliga osäkra konfigurationen tills begränsad eller resursbaserad delegering kan aktiveras anger du flaggan EnableTGTDelegation till Ja.

NETDOM-kommandoraden för att aktivera TGT-delegering är följande:

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

Tänk på NETDOM-syntaxen för att aktivera TGT-delegering på följande sätt:

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

NETDOM-syntaxen för att aktivera TGT-delegering av fabrakam.com användare på contoso.com servrar är följande:

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

         Obs!

• Flaggan EnableTGTDelegation ska anges i den betrodda domänen (fabrikam.com i det här fallet) för varje betrodd domän (till exempel contoso.com). När flaggan har angetts tillåter den betrodda domänen inte längre att TGT:er delegeras till den betrodda domänen.
• Det säkra tillståndet för EnableTGTDelegation är Nej.
• Alla program eller tjänster som förlitar sig på obegränsad delegering mellan skogar misslyckas när EnableTGTDelegation är manuellt eller programmatiskt inställt på Ja. Standardvärdet för EnableTGTDelegation är NEJ på nya och befintliga förtroenden när du har installerat uppdateringarna från maj 2019 och juli 2019. Mer information om hur du upptäcker det här felet finns i Hitta tjänster som förlitar sig på obegränsad delegering. Se tidslinjen för uppdateringar för en tidslinje med ändringar som påverkar hur den här lösningen kan användas.
• Mer information om NETDOM finns i denNetdom.exe dokumentationen.
• Om du måste aktivera TGT-delegering för ett förtroende rekommenderar vi att du minimerar den risken genom att aktivera Windows Defender Credential Guard på klientdatorerna. Detta förhindrar all obegränsad delegering från en dator som har Windows Defender Credential Guard aktiverat och körs.
• Om du har en skog eller ett externt förtroende, och båda är konfigurerade som i karantän, kan TGT-delegering inte aktiveras eftersom de två flaggorna har motsatt semantik. Karantänbiten stärker säkerhetsgränsen mellan de deltagande domänerna. Om du aktiverar TGT-delegering raderas säkerhetsgränserna mellan domäner genom att den betrodda domänen får åtkomst till autentiseringsuppgifterna för användare från den betrodda domänen. Man kan inte få både och.
  Lägg till quarantine:no flaggan i NETDOM-kommandoradssyntaxen om karantänflaggan är aktiverad.
• Om du har ändrat EnableTGTDelegation till Yes tar du bort Kerberos-biljetter på avsändare och mellanliggande uppringare efter behov. Den relevanta biljetten att ta bort är klientens hänvisnings-TGT över det relevanta förtroendet. Det här kan omfatta fler än en enhet, beroende på antalet delegeringshopp i en viss miljö.

Mer information om den här proceduren finns i följande Windows IT Pro Center-artikel:

Skydda härledda domänautentiseringsuppgifter med Windows Defender Credential Guard

Tidslinje för uppdateringar

12 mars 2019

Tillämpning för skogsgräns för fullständig Kerberos-delegering blir tillgänglig som en uppdatering för att aktivera den här funktionen på alla versioner av Windows Server som stöds och som listas i avsnittet Gäller för högst upp i den här artikeln. Vi rekommenderar att du ställer in funktionen på inkommande skogsförtroenden.

Uppdateringen lägger till funktionen Tvingande skogsgräns för Kerberos fullständig delegering i följande system:

• Windows Server 2008 R2
• Windows Server 2008

14 maj 2019

En uppdatering har släppts som lägger till en ny säker standardkonfiguration för ny skog och externa förtroenden. Om du kräver delegering mellan förtroenden ska flaggan EnableTGTDelegation ställas in på Ja innan uppdateringen från den 9 juli 2019 installeras. Om du inte kräver delegering mellan förtroenden bör du inte ange flaggan EnableTGTDelegation . Flaggan EnableTGTDelegation ignoreras tills uppdateringen från 9 juli 2019 installeras för att ge administratörer tid att återaktivera obegränsad Kerberos-delegering när det behövs.

Som en del av den här uppdateringen kommer flaggan EnableTGTDelegation att anges till Nej som standard för alla nyskapade förtroenden. Det här är motsatsen till föregående beteende. Vi rekommenderar att administratörer i stället konfigurerar om berörda tjänster så att de använder resursbaserad begränsad delegering.

Mer information om hur du identifierar kompatibilitetsproblem finns i Hitta tjänster som förlitar sig på obegränsad delegering.

9 juli 2019

En uppdatering har släppts som framtvingar det nya standardbeteendet på inkommande sida av skog och externa förtroenden. Autentiseringsbegäranden för tjänster som använder obegränsad delegering över angivna förtroendetyper autentiseras men utan delegering. Tjänsten misslyckas när den försöker köra delegerade åtgärder.

Information om en lösning finns i avsnittet "Tillfällig lösning".

Hitta tjänster som förlitar sig på obegränsad delegering

Om du vill söka efter skogar som har inkommande förtroenden som tillåter TGT-delegering och hitta säkerhetsobjekt som tillåter obegränsad delegering kör du följande PowerShell-skript i en skriptfil (till exempel 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 
}

Utdata från PowerShell-skripten visar služba Active Directory-säkerhetsobjekt i domäner som har konfigurerats för ett inkommande förtroende från den körande domänen som har obegränsad delegering konfigurerad. Utdata ser ut ungefär så här:

Identifiera obegränsad delegering via Windows-händelser

När ett Kerberos-ärende utfärdas loggar en služba Active Directory-domänkontrollant följande säkerhetshändelser. Händelserna innehåller information om måldomänen. Du kan använda händelserna för att avgöra om obegränsad delegering används mellan inkommande förtroenden.

Felsöka autentiseringsfel

När obegränsad delegering är inaktiverat kan program ha kompatibilitetsproblem med dessa ändringar om programmen förlitar sig på obegränsad delegering. Dessa program ska konfigureras för att använda begränsad delegering eller begränsad delegering som är resursbaserad. Mer information finns i Översikt över Kerberos-begränsad delegering.

Program som förlitar sig på svars-och-retur-autentisering mellan förtroenden stöds inte genom att använda begränsad delegering. En delegering misslyckas till exempel om en användare i Skog A autentiserar till ett program i Skog B och programmet i Skog B försöker delegera en biljett tillbaka till Skog A.