Updates für die TGT-Delegierung für eingehende Vertrauensstellungen in Windows Server

Zusammenfassung

Gesamtstruktur-Vertrauensstellungen bieten Ressourcen in einer Active Directory-Gesamtstruktur die Möglichkeit, Identitäten aus einer anderen Gesamtstruktur zu vertrauen. Diese Vertrauensstellung kann in beide Richtungen konfiguriert werden. Die vertrauenswürdige Gesamtstruktur ist die Quelle der Benutzeridentität. Die vertrauende Gesamtstruktur enthält die Ressource, bei der sich Benutzer authentifizieren. Die vertrauenswürdige Gesamtstruktur kann Benutzer bei der vertrauenden Gesamtstruktur authentifizieren, ohne dass das Gegenteil geschieht.

Die uneingeschränkte Kerberos-Delegierung ist ein Mechanismus, bei dem ein Benutzer seine Anmeldeinformationen an einen Dienst sendet, damit der Dienst im Namen des Benutzers auf Ressourcen zugreifen kann. Um die uneingeschränkte Kerberos-Delegierung zu ermöglichen, muss das Konto des Diensts in Active Directory als vertrauenswürdig für die Delegierung gekennzeichnet werden. Dies führt zu einem Problem, wenn der Benutzer und der Dienst zu unterschiedlichen Gesamtstrukturen gehören. Die Dienstgesamtstruktur ist für das Zulassen der Delegierung verantwortlich. Die Delegierung umfasst die Anmeldeinformationen von Benutzern aus der Gesamtstruktur des Benutzers.

Wenn Sie einer Gesamtstruktur erlauben, Sicherheitsentscheidungen zu treffen, die sich auf die Konten einer anderen Gesamtstruktur auswirken, wird die Sicherheitsgrenze zwischen Gesamtstrukturen verletzt. Ein Angreifer, der Besitzer der vertrauenden Gesamtstruktur ist, kann die Delegierung einer TGT für eine Identität aus der vertrauenswürdigen Gesamtstruktur anfordern und ihr Zugriff auf Ressourcen in der vertrauenswürdigen Gesamtstruktur gewähren. Dies gilt nicht für die eingeschränkte Kerberos-Delegierung (Kerberos Constrained Delegation, KCD).

In Windows Server 2012 wurde die Erzwingung der Gesamtstrukturgrenze für die vollständige Kerberos-Delegierung eingeführt. Dieses Feature hat der vertrauenswürdigen Domäne eine Richtlinie hinzugefügt, um die uneingeschränkte Delegierung pro Vertrauensbasis zu deaktivieren. Die Standardeinstellung für dieses Feature erlaubt uneingeschränkte Delegation und ist unsicher.

Für die folgenden Versionen von Windows Server gibt es Updates, die die Sicherheit verstärken:

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

Dieses Feature wurde zusammen mit Änderungen in der Sicherheitshärtung auf die folgenden Versionen zurückportiert:

• Windows Server 2008 R2
• Windows Server 2008

Diese Sicherheitsupdates bewirken die folgenden Änderungen:

• Die uneingeschränkte Kerberos-Delegierung ist nach der Installation des Updates vom 14. Mai und höher für neue Gesamtstrukturen und neue externe Vertrauensstellungen standardmäßig deaktiviert.
• Die uneingeschränkte Kerberos-Delegierung ist in Gesamtstrukturen (sowohl neuen als auch vorhandenen) und externen Vertrauensstellungen deaktiviert, nachdem Sie das Update vom 9. Juli 2019 und spätere Updates installiert haben.
• Administratoren können die uneingeschränkte Kerberos-Delegierung aktivieren, indem sie die Mai-Versionen oder höhere Versionen des NETDOM- und AD PowerShell-Moduls verwenden.

Die Updates können Kompatibilitätskonflikte für Anwendungen verursachen, die derzeit eine uneingeschränkte Delegierung über die Gesamtstruktur oder externe Vertrauensstellungen erfordern. Dies gilt insbesondere für externe Vertrauensstellungen, für die das Quarantäne-Flag (auch als SID-Filterung bezeichnet) standardmäßig aktiviert ist. Insbesondere schlagen Authentifizierungsanfragen für Dienste, die eine uneingeschränkte Delegierung über die aufgeführten Vertrauenstypen verwenden, fehl, wenn Sie neue Tickets anfordern.

Die Veröffentlichungstermine finden Sie unter Updates Zeitleiste.

Problemumgehung

Um Daten- und Kontosicherheit in einer Windows Server Version zu gewährleisten, die über das Feature "Erzwingung der Gesamtstrukturgrenze für vollständige Kerberos-Delegierung" verfügt, können Sie die TGT-Delegierung blockieren, nachdem Sie die Updates vom März 2019 über eine eingehende Vertrauensstellung installiert haben, indem Sie das Netdom-Flag EnableTGTDelegation wie folgt auf Nein festlegen:

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

Die TGT-Delegierung wird für neue und vorhandene Gesamtstrukturen und externe Vertrauensstellungen blockiert, nachdem Sie die Updates vom Mai bzw. Juli 2019 installiert haben.

Um die Delegierung über Vertrauensstellungen hinweg erneut zu aktivieren und zur ursprünglichen unsicheren Konfiguration zurückzukehren, bis eine eingeschränkte oder ressourcenbasierte Delegierung aktiviert werden kann, legen Sie das Flag EnableTGTDelegation auf Ja fest.

Die NETDOM-Befehlszeile zum Aktivieren der TGT-Delegierung lautet wie folgt:

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

Sie können sich die NETDOM-Syntax zum Aktivieren der TGT-Delegierung konzeptionell wie folgt vorstellen:

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

Die NETDOM-Syntax zum Aktivieren der TGT-Delegierung von fabrakam.com Benutzern auf contoso.com Servern lautet wie folgt:

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

         Hinweise

• Das EnableTGTDelegation-Flag sollte in der vertrauenswürdigen Domäne (in diesem Fall fabrikam.com) für jede vertrauende Domäne (z. B. contoso.com) festgelegt werden. Nachdem das Flag gesetzt wurde, lässt die vertrauenswürdige Domäne nicht mehr zu, dass TGTs an die vertrauende Domäne delegiert werden.
• Der sichere Zustand für EnableTGTDelegation ist Nein.
• Alle Anwendungen oder Dienste, die bzw. der auf uneingeschränkte Delegierung über Gesamtstrukturen hinweg angewiesen sind, schlagen fehl, wenn EnableTGTDelegation manuell oder programmgesteuert auf Ja festgelegt wird . Die EnableTGTDelegation setzt bei neuen und vorhandenen Vertrauensstellungen standardmäßig auf NEIN , nachdem Sie die Updates vom Mai 2019 und Juli 2019 installiert haben. Weitere Informationen zum Erkennen dieses Fehlers finden Sie unter Suchen von Diensten, die auf uneingeschränkter Delegierung basieren. Im Updates Zeitleiste finden Sie eine Zeitleiste von Änderungen, die sich darauf auswirken, wie diese Problemumgehung angewendet werden kann.
• Weitere Informationen zu NETDOM finden Sie in der Netdom.exe-Dokumentation.
• Wenn Sie die TGT-Delegierung für eine Vertrauensstellung aktivieren müssen, wird empfohlen, dieses Risiko zu minimieren, indem Sie Windows Defender Credential Guard auf Clientcomputern aktivieren. Dadurch wird jegliche uneingeschränkte Delegierung von einem Computer verhindert, auf dem Windows Defender Credential Guard aktiviert ist und ausgeführt wird.
• Wenn Sie über eine Gesamtstruktur oder eine externe Vertrauensstellung verfügen und beide als isoliert konfiguriert sind, kann die TGT-Delegierung nicht aktiviert werden, da die beiden Flags eine entgegengesetzte Semantik aufweisen. Das Quarantäne-Bit stärkt die Sicherheitsgrenze zwischen den teilnehmenden Domänen. Durch das Aktivieren der TGT-Delegierung werden die Sicherheitsgrenzen zwischen Domänen gelöscht, indem der vertrauenden Domäne Zugriff auf die Anmeldeinformationen von Benutzern aus der vertrauenswürdigen Domäne gewährt wird. Man kann nicht beides haben.
  Fügen Sie der Befehlszeilensyntax von NETDOM das Flag quarantine:no hinzu, wenn das Quarantäneflag aktuell aktiviert ist.
• Wenn Sie EnableTGTDelegation in Ja geändert haben, löschen Sie Kerberos-Tickets für Ursprungs- und Zwischenanrufer nach Bedarf. Das relevante Ticket, das gelöscht werden muss, ist das Empfehlungs-TGT des Kunden über die jeweilige Vertrauensstellung hinweg. Dies kann je nach Anzahl der Delegierungs-Hops in einer bestimmten Umgebung mehr als ein Gerät umfassen.

Weitere Informationen zu diesem Verfahren finden Sie im folgenden Windows IT Pro Center-Artikel:

Schützen abgeleiteter Domänenanmeldeinformationen mit Windows Defender Credential Guard

Updates Zeitleiste

12. März 2019

Die Erzwingung der Gesamtstrukturgrenze für die vollständige Kerberos-Delegierung wird als Update verfügbar sein, um dieses Feature unter allen unterstützten Versionen von Windows Server zu aktivieren, die im Abschnitt "Gilt für" am Ende dieses Artikels aufgeführt sind. Es wird empfohlen, das Feature für eingehende Gesamtstrukturvertrauensstellungen festzulegen.

Das Update fügt die Funktion zur Erzwingung der Gesamtstrukturgrenze für vollständige Kerberos-Delegierung für die folgenden Systeme hinzu:

• Windows Server 2008 R2
• Windows Server 2008

14. Mai 2019

Es wurde ein Update veröffentlicht, mit dem eine neue sichere Standardkonfiguration für neue Gesamtstrukturen und externe Vertrauensstellungen hinzugefügt wurde. Wenn Sie die Delegierung über Vertrauensstellungen hinweg benötigen, sollte das Flag EnableTGTDelegation auf Ja festgelegt werden, bevor das Update vom 9. Juli 2019 installiert wird. Wenn Sie keine vertrauensstellungsübergreifende Delegierung benötigen, sollten Sie das EnableTGTDelegation-Flag nicht festlegen. Das EnableTGTDelegation-Flag wird ignoriert, bis das Update vom 9. Juli 2019 installiert wird, um Administratoren Zeit zu geben, die uneingeschränkte Kerberos-Delegierung bei Bedarf wieder zu aktivieren.

Im Rahmen dieses Updates wird das EnableTGTDelegation-Flag für neu erstellte Vertrauensstellungen standardmäßig auf Nein festgelegt. Dies ist das Gegenteil des vorherigen Verhaltens. Es wird empfohlen, dass Administratoren die betroffenen Dienste stattdessen für die Verwendung der ressourcenbasierten eingeschränkten Delegierung neu konfigurieren.

Weitere Informationen zum Erkennen von Kompatibilitätsproblemen finden Sie unter Suchen von Diensten, die auf uneingeschränkte Delegierung angewiesen sind.

9. Juli 2019

Es wurde ein Update veröffentlicht, das das neue Standardverhalten auf der eingehenden Seite der Gesamtstruktur und externer Vertrauensstellungen erzwingt. Authentifizierungsanforderungen für Dienste, die die uneingeschränkte Delegierung über die aufgeführten Vertrauenstypen verwenden, werden authentifiziert, jedoch ohne Delegierung. Der Dienst schlägt fehl, wenn er versucht, delegierte Vorgänge auszuführen.

Informationen zur Risikominderung finden Sie im Abschnitt "Problemumgehung".

Suchen von Diensten, die auf uneingeschränkte Delegation angewiesen sind

Um nach Gesamtstrukturen mit eingehenden Vertrauensstellungen zu suchen, die die TGT-Delegierung zulassen, und um Sicherheitsprinzipale zu finden, die eine uneingeschränkte Delegierung zulassen, führen Sie die folgenden PowerShell-Skripts in einer Skriptdatei aus (z. B. 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 
}

Die Ausgabe der PowerShell-Skripts listet Active Directory-Sicherheitsprinzipale in Domänen auf, die für eine eingehende Vertrauensstellung von der ausführenden Domäne konfiguriert sind, für die eine uneingeschränkte Delegierung konfiguriert ist. Die Ausgabe sieht etwa wie folgt aus:

Erkennen der uneingeschränkten Delegierung durch Windows-Ereignisse

Wenn ein Kerberos-Ticket ausgestellt wird, protokolliert ein Active Directory-Domänencontroller die folgenden Sicherheitsereignisse. Die Ereignisse enthalten Informationen zur Zieldomäne. Sie können die Ereignisse verwenden, um zu bestimmen, ob für eingehende Vertrauensstellungen eine uneingeschränkte Delegation verwendet wird.

Problembehandlung bei Authentifizierungsfehlern

Wenn die uneingeschränkte Delegierung deaktiviert ist, können bei Anwendungen Kompatibilitätsprobleme mit diesen Änderungen auftreten, wenn die Anwendungen auf uneingeschränkte Delegierung angewiesen sind. Diese Anwendungen sollten für die Verwendung der eingeschränkten Delegierung oder der eingeschränkten Delegierung, die ressourcenbasiert ist, konfiguriert werden. Weitere Informationen finden Sie unter Übersicht über die eingeschränkte Kerberos-Delegierung.

Anwendungen, die auf der Roundtripauthentifizierung über Vertrauensstellungen hinweg basieren, werden bei Verwendung der eingeschränkten Delegierung nicht unterstützt. Beispielsweise schlägt eine Delegierung fehl, wenn sich ein Benutzer in Gesamtstruktur A bei einer Anwendung in Gesamtstruktur B authentifiziert und die Anwendung in Gesamtstruktur B versucht, ein Ticket zurück an Gesamtstruktur A zu delegieren.