Aktualizacje delegowania TGT między przychodzącymi relacjami zaufania w systemie Windows Server

Podsumowanie

Relacje zaufania lasów umożliwiają zasobom w lesie las usługi Active Directory ufanie tożsamościom z innego lasu. To zaufanie można skonfigurować w obu kierunkach. Zaufany las jest źródłem tożsamości użytkownika. Las ufający zawiera zasób, w którym użytkownicy przeprowadzają uwierzytelnianie. Zaufany las może uwierzytelniać użytkowników w zaufanym lesie, nie zezwalając na odwrotną sytuację.

Nieograniczone delegowanie Kerberos to mechanizm, w którym użytkownik wysyła swoje poświadczenia do usługi, aby umożliwić usłudze dostęp do zasobów w imieniu użytkownika. Aby można było włączyć nieograniczone delegowanie Kerberos, konto usługi w usłudze Active Directory musi być oznaczone jako zaufane do delegowania. Stwarza to problem, jeśli użytkownik i usługa należą do różnych lasów. Las usług jest odpowiedzialny za zezwalanie na delegowanie. Pełnomocnictwo obejmuje poświadczenia użytkowników z lasu danego użytkownika.

Zezwolenie jednemu lasowi na podejmowanie decyzji dotyczących zabezpieczeń, które mają wpływ na konta innego lasu, narusza granicę zabezpieczeń między lasami. Osoba atakująca, która jest właścicielem lasu ufającego, może zażądać delegowania biletu TGT dla tożsamości z zaufanego lasu, co da jej dostęp do zasobów w zaufanym lesie. Nie dotyczy to ograniczonego delegowania Kerberos (KCD).

W systemie Windows Server 2012 wprowadzono wymuszanie granicy lasu dla pełnego delegowania protokołu Kerberos. Ta funkcja dodała zasady do zaufanej domeny w celu wyłączenia nieograniczonego delegowania na podstawie zaufania. Domyślne ustawienie tej funkcji zezwala na nieograniczone delegowanie i jest niebezpieczne.

Aktualizacje umożliwiające wzmacnianie zabezpieczeń są dostępne dla następujących wersji systemu Windows Server:

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

Ta funkcja wraz ze zmianami w utwardzaniu zabezpieczeń została zaimportowana do następujących wersji:

• Windows Server 2008 R2
• Windows Server 2008

Te aktualizacje zabezpieczeń wprowadzają następujące zmiany:

• Nieograniczone delegowanie Kerberos jest domyślnie wyłączone w nowym lesie i nowych zewnętrznych relacjach zaufania po zainstalowaniu aktualizacji z 14 maja i późniejszych aktualizacji.
• Po zainstalowaniu aktualizacji z 9 lipca 2019 r. i późniejszych aktualizacji nieograniczone delegowanie Kerberos jest wyłączone w lasach (nowych i istniejących) oraz zewnętrznych relacjach zaufania.
• Administratorzy mogą włączyć nieograniczone delegowanie Kerberos przy użyciu majowych lub nowszych wersji modułu NETDOM i AD PowerShell.

Aktualizacje mogą powodować konflikty zgodności dla aplikacji, które obecnie wymagają nieograniczonego delegowania między lasami lub zewnętrznymi relacjami zaufania. Dotyczy to szczególnie zaufania zewnętrznego, dla którego flaga kwarantanny (określana także jako filtrowanie identyfikatorów SID) jest domyślnie włączona. W szczególności żądania uwierzytelnienia dla usług, które korzystają z nieograniczonego delegowania za pośrednictwem wymienionych typów zaufań, będą kończyć się niepowodzeniem, gdy zażądasz nowych biletów.

Aby poznać daty wydania, zobacz Oś czasu aktualizacji.

Obejście

Aby zapewnić bezpieczeństwo danych i konta w wersji systemu Windows Server, która ma funkcję wymuszania granic lasu dla pełnego delegowania protokołu Kerberos, można zablokować delegowanie TGT po zainstalowaniu aktualizacji z marca 2019 r. w przychodzącym zaufaniu, ustawiając flagę netdom EnableTGTDelegation na wartość Nie, w następujący sposób:

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

Delegowanie biletu TGT jest zablokowane w nowych i istniejących budynkach zaufania lasów oraz zewnętrznych budynkach zaufania po zainstalowaniu odpowiednio aktualizacji z maja i lipca 2019 r.

Aby ponownie włączyć delegowanie między relacjami zaufania i powrócić do pierwotnej niebezpiecznej konfiguracji, dopóki nie będzie można włączyć delegowania ograniczonego lub opartego na zasobach, ustaw flagę EnableTGTDelegation na wartość Tak.

Wiersz polecenia narzędzia NETDOM służący do włączania delegowania TGT jest następujący:

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

Składnię funkcji NETDOM umożliwiającą włączenie delegowania biletu TGT można przedstawić w następujący sposób:

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

Składnia funkcji NETDOM umożliwiająca delegowanie biletu TGT użytkownikom fabrakam.com na serwerach contoso.com jest następująca:

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

         Uwagi

• Flaga EnableTGTDelegation powinna być ustawiona w zaufanej domenie (fabrikam.com w tym przypadku) dla każdej zaufanej domeny (takiej jak contoso.com). Po ustawieniu flagi zaufana domena nie będzie już zezwalać na delegowanie biletów TGT do domeny ufającej.
• Stan bezpieczny dla EnableTGTDelegation to Nie.
• Każda aplikacja lub usługa, która opiera się na nieograniczonym delegowaniu między lasami, zakończy się niepowodzeniem, gdy parametr EnableTGTDelegation zostanie ręcznie lub programowo ustawiony na wartość Tak. Po zainstalowaniu aktualizacji z maja 2019 r. i lipca 2019 r. ustawienie EnableTGTDelegation domyślnie ustawia się na wartość NO dla nowych i istniejących relacji zaufania. Aby uzyskać więcej informacji na temat wykrywania tego błędu, zobacz Znajdowanie usług opartych na nieograniczonym delegowaniu. Zobacz oś czasu aktualizacji, aby zapoznać się ze zmianami wpływającymi na sposób zastosowania tego obejścia.
• Aby uzyskać więcej informacji na temat narzędzia NETDOM, zapoznaj się z dokumentacjąNetdom.exe.
• Jeśli musisz włączyć delegowanie TGT w zaufaniu, zalecane jest ograniczenie tego ryzyka przez włączenie funkcji Credential Guard w usłudze Windows Defender na komputerach klienckich. Zapobiega to wszelkiemu nieograniczonemu delegowaniu z komputera, na którym jest włączona funkcja Credential Guard w usłudze Windows Defender.
• Jeśli masz zaufanie lasu lub zewnętrzne i którekolwiek z nich jest skonfigurowane jako poddane kwarantannie, nie można włączyć delegowania biletu TGT, ponieważ dwie flagi mają przeciwną semantykę. Bit kwarantanny wzmacnia granicę zabezpieczeń między uczestniczącymi domenami. Włączenie delegowania TGT powoduje usunięcie granic zabezpieczeń między domenami, dając domenie ufającej dostęp do poświadczeń użytkowników z domeny zaufanej. Nie można korzystać z obu opcji.
  Dodaj flagę kwarantanna:no do składni wiersza poleceń NETDOM, jeśli flaga kwarantanny jest obecnie włączona.
• Jeśli parametr EnableTGTDelegation został zmieniony na wartość Tak, usuń w razie potrzeby bilety protokołu Kerberos dla wywołujących inicjujących i pośrednich. Odpowiednim biletem do usunięcia jest TGT polecenia klienta w ramach odpowiedniego trustu. Może to dotyczyć więcej niż jednego urządzenia, w zależności od liczby przeskoków delegowania w danym środowisku.

Aby uzyskać więcej informacji na temat tej procedury, zobacz następujący artykuł w Centrum Windows IT Pro:

Ochrona pochodnych poświadczeń domeny za pomocą funkcji Windows Defender Credential Guard

Oś czasu aktualizacji

12 marca 2019 r.

Wymuszanie granicy lasu dla pełnego delegowania Kerberos będzie dostępne jako aktualizacja włączająca tę funkcję we wszystkich obsługiwanych wersjach systemu Windows Server wymienionych w sekcji Dotyczy na początku tego artykułu. Zalecane jest ustawienie tej funkcji dla przychodzących relacji zaufania lasów.

W ramach tej aktualizacji funkcja pełnego delegowania wymuszania granicy lasu dla protokołu Kerberos zostanie dodana do następujących systemów:

• Windows Server 2008 R2
• Windows Server 2008

14 maja 2019 r.

Wydano aktualizację dodającą nową bezpieczną konfigurację domyślną do nowego lasu i zewnętrznych relacji zaufania. Jeśli wymagasz delegowania między trustami, flaga EnableTGTDelegation powinna być ustawiona na Yes (Tak ) przed zainstalowaniem aktualizacji z 9 lipca 2019 r. Jeśli delegowanie między trustami nie jest wymagane, nie należy ustawiać flagi EnableTGTDelegation . Flaga EnableTGTDelegation będzie ignorowana do momentu zainstalowania aktualizacji z 9 lipca 2019 r., aby dać administratorom czas na ponowne włączenie nieograniczonego delegowania protokołu Kerberos, gdy będzie to wymagane.

W ramach tej aktualizacji flaga EnableTGTDelegation zostanie domyślnie ustawiona na wartość Nie dla wszystkich nowo utworzonych relacji zaufania. Jest to przeciwieństwo poprzedniego zachowania. Zalecamy, aby zamiast tego administratorzy ponownie skonfigurowali dotknięte problemem usługi, aby używały delegowania ograniczonego w oparciu o zasoby.

Aby uzyskać więcej informacji na temat wykrywania problemów ze zgodnością, zobacz Znajdowanie usług opartych na nieograniczonym delegowaniu.

9 lipca 2019 r.

Wydano aktualizację, która wymusza nowe zachowanie domyślne po stronie przychodzącej zaufania lasów i zewnętrznych. Żądania uwierzytelnienia dla usług korzystających z nieograniczonego delegowania za pośrednictwem wymienionych typów zaufania będą uwierzytelniane, ale bez delegowania. Próba uruchomienia operacji delegowanych przez usługę zakończy się niepowodzeniem.

Aby uzyskać informacje na temat środków zaradczych, zobacz sekcję "Obejście problemu".

Znajdowanie usług opartych na nieograniczonym delegowaniu

Aby przeskanować lasy z przychodzącymi relacjami zaufania zezwalającymi na delegowanie biletu TGT oraz znaleźć wszelkie zabezpieczenia zabezpieczeń zezwalające na nieograniczone delegowanie, uruchom następujące skrypty programu PowerShell w pliku skryptu (na przykład 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 
}

Dane wyjściowe skryptów programu PowerShell zawierają listę podmiotów zabezpieczeń usługi Active Directory w domenach skonfigurowanych do obsługi zaufania przychodzącego z domeny wykonującej, w której skonfigurowano nieograniczone delegowanie. Dane wyjściowe będą podobne do poniższego przykładu.

Wykrywanie nieograniczonego delegowania za pośrednictwem zdarzeń systemu Windows

Po wystawieniu biletu protokołu Kerberos kontroler domeny usługi Active Directory rejestruje następujące zdarzenia zabezpieczeń. Zdarzenia zawierają informacje o domenie docelowej. Za pomocą tych zdarzeń można określić, czy delegowanie nieograniczone jest używane w przychodzących relacjach zaufania.

Rozwiązywanie problemów z niepowodzeniami uwierzytelniania

Gdy delegowanie nieograniczone jest wyłączone, aplikacje mogą mieć problemy ze zgodnością z tymi zmianami, jeśli korzystają z delegowania nieograniczonego. Te aplikacje powinny być skonfigurowane do korzystania z delegowania ograniczonego lub delegowania ograniczonego opartego na zasobach. Aby uzyskać więcej informacji, zobacz Omówienie ograniczonego delegowania protokołu Kerberos.

Aplikacje, które korzystają z uwierzytelniania w obie strony w relacjach zaufania, nie są obsługiwane przez delegowanie ograniczone. Na przykład delegowanie kończy się niepowodzeniem, jeśli użytkownik w lesie A uwierzytelnia się w aplikacji w lesie B, a aplikacja w lesie B próbuje delegować bilet z powrotem do lasu A.