Applies ToWindows Server 2008 Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2 Windows Server 2016 Windows Server 2019, all editions

Podsumowanie

Relacje zaufania lasu umożliwiają dla zasobów w lesie usługi Active Directory można ufać tożsamości z innego lasu. To zaufanie można skonfigurować w obu kierunkach. Zaufanym lesie jest źródłem tożsamości użytkownika. Lasu ufającego zawiera zasób, do którego użytkownicy są uwierzytelniani. Zaufanym lesie będzie mógł uwierzytelniać użytkowników w zaufanym lesie nie pozwalając na odwrocie występuje.

Nieograniczone delegowania protokołu Kerberos jest to mechanizm, w którym użytkownik wysyła swoje poświadczenia usługi, aby włączyć usługę, aby uzyskać dostęp do zasobów w imieniu użytkownika. Aby włączyć delegowanie Kerberos nieograniczone, konta usługi w usłudze Active Directory muszą być oznaczone jako zaufane w kwestii delegowania. Powoduje to problem, jeśli użytkownik i usługi należą do różnych lasów. Las usługi jest odpowiedzialne za umożliwienie delegowania. Przedstawicielstwo zawiera poświadczeń użytkowników z lasu użytkownika.

Co pozwala jednym lesie do podejmowania decyzji zabezpieczeń, która dotyczy kont w innym lesie narusza granicę zabezpieczeń między lasami. Osoba atakująca, która jest właścicielem lasu ufającego mogą żądać delegowania TGT tożsamości z zaufanego lasu, nadając mu dostęp do zasobów w lesie zaufanym. Nie dotyczy protokołu Kerberos ograniczone delegowanie (KCD).

Windows Server 2012 wprowadzono Wymuszanie dla granicy lasu dla pełnego delegowania protokołu Kerberos. Ta funkcja dodaje zasadę do zaufanej domeny, aby wyłączyć nieograniczone delegowania na zasadzie-trust. Ustawieniem domyślnym dla tej funkcji umożliwia nieograniczone delegowania i niebezpieczne.

Aktualizacje, które zapewniają Zwiększanie zabezpieczeń istnieją dla następujących wersji systemu Windows Server:

  • System Windows Server 2019

  • Windows Server 2016

  • Windows Server 2012 R2

  • Windows Server 2012

Ta funkcja wraz ze zmianami w udoskonalanie zabezpieczeń zostały przeniesione do następujących wersji:

  • Windows Server 2008 R2

  • Windows Server 2008

Te aktualizacje zabezpieczeń należy wprowadzić następujące zmiany:

  • Delegowanie nieograniczone protokołu Kerberos jest domyślnie wyłączone na nowego lasu i nowych zaufań zewnętrznychpo zainstalowaniu14 maja aktualizacji i nowszych aktualizacjach.

  • Nieograniczone delegowania protokołu Kerberos jest wyłączona na lasy (nowych i istniejących) i zewnętrznych relacji zaufania po zainstalowaniu 9 lipca 2019, aktualizacji i nowszych aktualizacjach.

  • Administratorzy mogą włączać nieograniczone delegowanie Kerberos za pomocą maj lub nowszej wersji modułu NETDOM i środowiska AD PowerShell.

Aktualizacje mogą powodować konflikty zgodności dla aplikacji, które obecnie wymagają nieograniczone delegowania całej lasu lub zaufania zewnętrzne. Jest to szczególnie ważne, zaufania zewnętrznego, dla której flaga kwarantanny (znany również jako filtrowania identyfikatorów SID) jest domyślnie włączona. W szczególności żądania uwierzytelniania używające nieograniczone delegowania przez typy zaufania wymienionych usług zakończy się niepowodzeniem, gdy zostanie wysłane żądanie nowych biletów.

Dla daty wydania zobacz aktualizacje osi czasu.

Obejście

Aby zapewnić bezpieczeństwo danych i konto w wersji systemu Windows Server z funkcją wykonanie w odniesieniu do granicy lasu dla pełnego delegowania protokołu Kerberos , można zablokować delegowania TGT, po zainstalowaniu aktualizacji 2019 marca w przypadku przychodzącego zaufania przez ustawienie Flaga Netdom EnableTGTDelegationnr w następujący sposób:

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

TGT delegowania jest zablokowany na nowych i istniejących lasów i zaufań zewnętrznych po zainstalowaniu maja 2019 lipca odpowiednio aktualizuje.

Aby ponownie włączyć delegowanie zaufania i powrócić do oryginalnej konfiguracji niebezpiecznych dopóki nie mogą być włączone delegowanie ograniczone lub opartych na zasobach, należy ustawić flagę EnableTGTDelegation na wartość Tak.

Wiersza polecenia NETDOM , aby włączyć delegowanie TGT jest następująca:

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

Koncepcyjnie można traktować składni polecenia NETDOM umożliwiających TGT delegacji w następujący sposób:

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

Składnia NETDOM, aby włączyć delegowanie TGT użytkowników fabrakam.com na serwerach contoso.com jest następująca:

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

Uwagi

  • Flaga EnableTGTDelegation należy ustawić w domenie zaufanej (fabrikam.com w tym przypadku) dla każdej domeny ufającej (np. contoso.com). Po ustawieniu flagi zaufanej domeny nie będzie już zezwalać TGT może być delegowane do domeny ufającej.

  • Stan zabezpieczeń EnableTGTDelegation jest nie.

  • Każda aplikacja lub usługa, która opiera się na nieograniczone delegowania między lasami zakończy się niepowodzeniem podczas EnableTGTDelegation ręcznie lub programowo ustawiono Tak. Ustawienia domyślne EnableTGTDelegation na wartość nie dla nowych i istniejących relacji zaufania po Zainstaluj aktualizacje maja 2019 i lipca 2019. Aby uzyskać więcej informacji dotyczących sposobu wykrywania tego błędu zobacz Znajdowanie usług, które opierają się na nieograniczone delegowania. Zobacz aktualizacje osi czasu na osi czasu zmian wpływających na to, jak można zastosować to obejście.

  • Aby uzyskać więcej informacji o narzędziu NETDOM zobacz dokumentację Netdom.exe.

  • Należy włączyć delegowanie TGT w zaufaniu, zaleca się ograniczenia tego zagrożenia przez włączenie ochrona poświadczeń systemu Windows Defender na komputerach klienckich. Zapobiega to wszystkie nieograniczone delegowania z komputera, na którym jest Windows Defender poświadczeń straży włączona i uruchomiona.

  • Jeśli masz lasu lub zaufania zewnętrznego, a albo są skonfigurowane jako kwarantannie, delegacja TGT nie można włączyć, ponieważ dwie flagi ma semantykę przeciwległego. Bit kwarantanny wzmacnia granicę zabezpieczeń między domenami uczestniczących. Włączanie delegowania TGT Wymazuje granice zabezpieczeń między domenami, dając prawa dostępu domeny ufającej dla poświadczeń użytkowników z domeny zaufanej. Nie może ona mieć obie strony.

    Dodać flagi kwarantanny: nr składni wiersza polecenia NETDOM, jeśli flaga kwarantanny jest aktualnie włączone.

  • Jeśli zmieniłeś EnableTGTDelegationTak, Usuń biletów Kerberos na wywoływania produktów pochodzących i pośrednich zgodnie z wymaganiami. Właściwego biletu do usunięcia jest skierowanie klienta TGT przez odpowiednie zaufanie. Może to dotyczyć więcej niż jedno urządzenie, w zależności od liczby przeskoków delegacji w danym środowisku.

Aby uzyskać więcej informacji dotyczących tej procedury zobacz następujący artykuł Windows IT Pro Center:

Ochrony poświadczeń domeny pochodnych ze Strażnikiem poświadczeń programu Windows Defender

Oś czasu aktualizacji

12 marca 2019

Wymuszanie dla granicy lasu dla protokołu Kerberos pełne delegowanie będzie dostępna jako aktualizacja w celu włączenia tej funkcji we wszystkich obsługiwanych wersjach systemu Windows Server, które są wymienione w sekcji dotyczy u góry tego artykułu. Zalecane ustawienie funkcji przychodzących zaufań lasu.

Aktualizacja spowoduje dodanie funkcji wymuszania dla granicy lasu dla pełnego delegowania protokołu Kerberos do następujących systemów:

  • Windows Server 2008 R2

  • Windows Server 2008

14 maja 2019 roku.

Aktualizacja została wydana, dodając nowe bezpieczne domyślnej konfiguracji do nowego lasu i zewnętrznych relacji zaufania. Jeśli wymagasz delegowania dla zaufań, Flaga EnableTGTDelegation powinna być równa Tak, przed zainstalowaniem aktualizacji 9 lipca 2019. Jeśli delegowanie zaufania nie jest wymagane, nie należy ustawiać flagi EnableTGTDelegation . Flagi EnableTGTDelegation zostanie zignorowana, aby umożliwić administratorom czas, aby ponownie włączyć nieograniczone delegowania protokołu Kerberos, gdy jest to wymagane jest zainstalowana aktualizacja 9 lipca 2019.

W ramach tej aktualizacji flaga EnableTGTDelegation jest równa nr domyślnie nowo utworzonej relacji zaufania. To jest odwrotnością poprzedniego zachowania. Firma Microsoft zaleca, aby administratorzy zamiast ponownie skonfigurować powiązane usługi do użycia delegowanie ograniczone opartych na zasobach.

Aby uzyskać więcej informacji dotyczących sposobu wykrywania problemów ze zgodnością zobacz Znajdowanie usług, które opierają się na nieograniczone delegowania.

9 lipca 2019

Aktualizacja została wydana wymusza nowe zachowanie domyślne po stronie przychodzącego zaufania zewnętrzne i lasu. Żądania uwierzytelniania dla usługi używające nieograniczone delegowania przez typy zaufania wymienionych są uwierzytelniane, ale bez delegowania. Usługi nie powiedzie się, gdy próbuje uruchomić operacje delegowanej.

Ograniczenie zagrożenia znajduje się w sekcji "obejście problemu".

Znajdowanie usług, które opierają się na nieograniczone delegowania

Do skanowania dla lasów, które mają przychodzące relacje zaufania, które zezwalają na delegowanie TGT i znaleźć żadnych zabezpieczeń głównych, które zezwalają na delegowanie nieograniczone, uruchom następujące PowerShell skrypty w skrypcie pliku (na przykład Get-RiskyServiceAccountsByTrust.ps1 - Odbiór):

Uwaga

Można również przekazać flagi - ScanAll , aby przeszukać relacje zaufania, które nie zezwalają na delegowanie TGT.


[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 środowiska PowerShell listy podmiotów zabezpieczeń usługi Active Directory w domenach, które są skonfigurowane dla przychodzącego zaufania z domeny nakaz, która ma nieograniczone delegowania skonfigurowany. Dane wyjściowe będą podobne do następującego przykładu.

domeny

sAMAccountName

objectClass

partner.fabrikam.com

niebezpieczne

Użytkownik

partner.fabrikam.com

labsrv$

komputera

Wykrywanie nieograniczone delegowania za pomocą zdarzeń systemu Windows

Po wystawieniu biletu Kerberos kontrolera domeny usługi Active Directory rejestruje następujące zdarzenia zabezpieczeń. Zdarzenia zawierają informacje o domenie docelowej. Zdarzenia można użyć do określenia, czy nieograniczone delegowania jest używany przez przychodzące zaufania.

Uwaga

Sprawdź, czy zdarzenia, które zawierają wartość Docelowa_nazwa_domeny , która jest zgodna z nazwą zaufanej domeny.

Dziennik zdarzeń

Źródło zdarzenia

Identyfikator zdarzenia

Szczegóły

Zabezpieczenia

Microsoft-Windows-Security inspekcji

4768

Kerberos TGT został wystawiony.

Zabezpieczenia

Microsoft-Windows-Security inspekcji

4769

Bilet usługi Kerberos został wystawiony.

Zabezpieczenia

Microsoft-Windows-Security inspekcji

4770

Odnowienie biletu protokołu Kerberos.

Rozwiązywanie problemów z awariami uwierzytelniania

Po wyłączeniu nieograniczone delegowania aplikacje mogą mieć problemy ze zgodnością z tych zmian, jeśli aplikacje korzystają z delegacji nieograniczone. Aplikacje te powinny być konfigurowane do delegowania ograniczonego użycia lub ograniczone delegowanie, który jest oparty na zasób. F eelub więcej informacji, sOmówienie ograniczone delegowanie Kerberos.

Aplikacje korzystające z uwierzytelniania obie strony zaufania nie są obsługiwane za pomocą delegowania ograniczonego. Na przykład delegacja nie powiedzie się, jeśli użytkownik w lesie A uwierzytelnia się w lesie B aplikacji i aplikacji w lesie B próbuje delegować bilet do lasu A.

Potrzebujesz dalszej pomocy?

Chcesz uzyskać więcej opcji?

Poznaj korzyści z subskrypcji, przeglądaj kursy szkoleniowe, dowiedz się, jak zabezpieczyć urządzenie i nie tylko.

Społeczności pomagają zadawać i odpowiadać na pytania, przekazywać opinie i słuchać ekspertów z bogatą wiedzą.