Novosti za TGT delegiranje preko dolaznih poverenja u Windows Server

Rezime

Poverenja šume omogućavaju resursima u Active Directory šuma da veruju identitetima iz druge šume. Ovo poverenje može da se konfiguriše u oba smera. Pouzdana šuma je izvor identiteta korisnika. Pouzdana šuma sadrži resurs pomoću kojeg korisnici vrše potvrdu identiteta. Pouzdana šuma može da potvrdi identitet korisnika šume poverenja bez dopuštanja da se dogodi suprotno.

Neograničeno Kerberos delegiranje je mehanizam u kojem korisnik šalje svoje akreditive usluzi da bi joj omogućio da pristupi resursima u ime korisnika. Da biste omogućili neograničeno Kerberos delegiranje, nalog usluge u usluzi Active Directory mora da bude označen kao pouzdan za delegiranje. To stvara problem ako korisnik i usluga pripadaju različitim šumama. Šuma usluga je odgovorna za omogućavanje delegiranja. Delegiranje uključuje akreditive korisnika iz šume korisnika.

Ako jednoj šumi dozvolite da donosi bezbednosne odluke koje utiču na naloge druge šume, krši se bezbednosna granica između šuma. Napadač koji poseduje pouzdanu šumu može da zahteva delegiranje TGT-a za identitet iz pouzdane šume, dajući joj pristup resursima u pouzdanoj šumi. Ovo se ne odnosi na ograničeno delegiranje protokola Kerberos (KCD).

Windows Server 2012 je uveo sprovođenje granice šume za Kerberos punu delegaciju. Ova funkcija je dodala smernice pouzdanom domenu radi onemogućavanja neograničenog delegiranja po poverenju. Podrazumevana postavka za ovu funkciju dozvoljava neograničeno delegiranje i nije bezbedna.

Novosti koje pružaju bezbednosno ojačavanje postoje za sledeće verzije sistema Windows Server:

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

Ova funkcija, zajedno sa promenama u bezbednosnom ojačavanju, vraćena je u sledeće verzije:

• Windows Server 2008 R2
• Windows Server 2008

Ove bezbednosne ispravke prave sledeće promene:

• Neograničeno Kerberos delegiranje podrazumevano je onemogućeno u novoj šumi i novim spoljnim poverenjima kada instalirate ispravku od 14. maja i novije ispravke.
• Neograničeno Kerberos delegiranje je onemogućeno za šume (i nove i postojeće) i spoljna poverenja kada instalirate ispravku od 9. jula 2019. i novije ispravke.
• Administratori mogu da omoguće neograničeno Kerberos delegiranje pomoću modula NETDOM i AD PowerShell iz maja ili novijih verzija.

Ispravke mogu da izazovu konflikte sa kompatibilnošću za aplikacije koje trenutno zahtevaju neograničeno delegiranje u šumi ili spoljnim poverenjima. Ovo posebno važi za spoljno poverenje za koje je zastavica karantina (poznato i kao SID filtriranje) podrazumevano omogućena. Tačnije, zahtevi za potvrdu identiteta za usluge koje koriste neograničeno delegiranje preko navedenih tipova pouzdanosti neće uspeti kada zatražite nove tikete.

Datume izdavanja potražite na vremenskoj osi Novosti.

Privremeno rešenje

Da biste obezbedili bezbednost podataka i naloga u verziji Windows Server koja ima funkciju "Nametanje za granicu šume za Kerberos" Potpuno delegiranje, možete da blokirate TGT delegiranje nakon instaliranja ispravki iz marta 2019. u dolaznom poverenju tako što ćete postaviti oznaku netdom zastavice EnableTGTDelegation na opciju "Ne", na sledeći način:

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

TGT delegiranje je blokirano za nove i postojeće šume i spoljne poverenja nakon instaliranja ispravke iz maja i jula 2019.

Da biste ponovo omogućili delegiranje između poverenja i vratili se na prvobitnu nebezbednu konfiguraciju dok ne bude moguće ograničiti delegiranje ili delegiranje zasnovano na resursima, postavite zastavicu EnableTGTDelegation na vrednost "Da".

NETDOM komandna linija za omogućavanje TGT delegiranja glasi ovako:

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

NETDOM sintaksu za omogućavanje TGT delegiranja možete da posmatrate na sledeći način:

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

NETDOM sintaksa za omogućavanje TGT delegiranja fabrakam.com korisnika na contoso.com serverima je sledeća:

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

         Beleške

• Zastavica EnableTGTDelegation treba da bude podešena u pouzdanom domenu (fabrikam.com u ovom slučaju) za svaki pouzdani domen (kao što je contoso.com). Kada se zastavica postavi, pouzdani domen više neće dozvoljavati da se TGT-ovi delegiraju pouzdanom domenu.
• Bezbedno stanje za EnableTGTDelegation je br.
• Sve aplikacije ili usluge koje se oslanjaju na neograničeno delegiranje u šumama neće uspeti kada se EnableTGTDelegation ručno ili programski postavi na "Da". EnableTGTDelegation podrazumevano ima vrednost NE za nove i postojeće poverenja kada instalirate ispravke iz maja 2019. i jula 2019. Više informacija o tome kako da otkrijete ovu grešku potražite u članku Pronalaženje usluga koje se oslanjaju na neograničeno delegiranje. Pogledajte vremensku osu Novosti da biste videli vremensku osu promena koje utiču na način na koji se ovo privremeno rešenje može primeniti.
• Više informacija o alatki NETDOM potražite u Netdom.exe dokumentaciji.
• Ako morate da omogućite TGT delegiranje za poverenje, preporučuje se da smanjite taj rizik tako što ćete omogućiti Credential Guard za Windows zaštitnik na klijentskim računarima. Ovo sprečava neograničeno delegiranje sa računara koji ima omogućen i pokrenut Windows Defender Credential Guard.
• Ako imate šumu ili spoljno poverenje i bilo koji od njih je konfigurisan kao u karantinu, TGT delegiranje nije moguće omogućiti zato što ove dve zastavice imaju suprotnu semantiku. Bit karantina jača bezbednosnu granicu između domena koji učestvuju. Omogućavanje TGT delegiranja briše bezbednosne granice između domena tako što pouzdanom domenu daje pristup akreditivima korisnika iz pouzdanog domena. Ne možete imati oba načina.
  Dodajte zastavicu quarantine:no u NETDOM sintaksu komandne linije ako je zastavica karantina trenutno omogućena.
• Ako ste promenili EnableTGTDelegation u"Da", izbrišite Kerberos tikete za izvorne i posredne pozivaoce po potrebi. Relevantan tiket za brisanje je TGT preporuke klijenta preko relevantnog poverenja. To može da uključuje više uređaja, u zavisnosti od broja međukoraka delegiranja u datom okruženju.

Više informacija o ovoj proceduri potražite u sledećem članku Windows IT Pro centra:

Zaštita izvedenih akreditiva domena pomoću funkcije Windows Defender Credential Guard

Vremenska osa Novosti

12. mart 2019.

Nametanje za granice šume za Kerberos punu delegaciju biće dostupno u vidu ispravke za omogućavanje ove funkcije na svim podržanim verzijama sistema Windows Server koje su navedene u odeljku "Odnosi se na" na vrhu ovog članka. Preporučujemo da podesite ovu funkciju na dolaznim šumskim poverenjima.

Ova ispravka će dodati funkciju sprovođenja za granice šume za Kerberos potpune delegacije sledećim sistemima:

• Windows Server 2008 R2
• Windows Server 2008

14. maj 2019.

Objavljena je ispravka koja dodaje novu bezbednu podrazumevanu konfiguraciju u novu šumu i spoljna poverenja. Ako zahtevate delegiranje u više poverenja, zastavica EnableTGTDelegation treba da bude postavljena na "Da " pre nego što se ispravka od 9. jula 2019 instalira. Ako ne zahtevate delegiranje između poverenja, ne bi trebalo da podesite zastavicu "EnableTGTDelegation ". Zastavica EnableTGTDelegation biće zanemarena dok se ne instalira ispravka od 9. jula 2019. kako bi administratori imali vremena da ponovo omoguće neograničeno Kerberos delegiranje kada je to potrebno.

Kao deo ove ispravke, zastavica EnableTGTDelegation će biti podrazumevano postavljena na "Ne " za sva novokreirana poverenja. To je suprotno od prethodnog ponašanja. Preporučujemo da administratori umesto toga ponovo konfigurišu usluge na koje ovo utiče tako da koriste ograničeno delegiranje zasnovano na resursima.

Više informacija o tome kako da otkrijete probleme sa kompatibilnošću potražite u članku "Pronalaženje usluga koje se oslanjaju na neograničeno delegiranje.

9. jul 2019.

Objavljena je ispravka koja nameće novo podrazumevano ponašanje na ulaznoj strani šume i spoljnih poverenja. Zahtevi za potvrdu identiteta za usluge koje koriste neograničeno delegiranje preko navedenih tipova pouzdanosti biće potvrđeni, ali bez delegiranja. Usluga neće uspeti kada pokuša da pokrene delegirane operacije.

Za ublažavanje pogledajte odeljak "Zaobilaženje problema".

Pronalaženje usluga koje se oslanjaju na neograničeno delegiranje

Da biste skenirali šume koje imaju dolazna poverenja koja omogućavaju TGT delegiranje, kao i da biste pronašli principale bezbednosti koji omogućavaju neograničeno delegiranje, pokrenite sledeće PowerShell skripte u datoteci skripte (na primer, 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 
}

Izlaz PowerShell skripti navodi Active Directory principale bezbednosti u domenima koji su konfigurisani za dolazno poverenje iz izvršnog domena koji ima podešeno neograničeno delegiranje. Rezultat će izgledati kao u sledećem primeru.

Otkrivanje neograničenog delegiranja putem Windows događaja

Kada se izda Kerberos tiket, Active Directory kontroler domena evidentira sledeće bezbednosne događaje. Događaji sadrže informacije o ciljnom domenu. Događaje možete da koristite da biste utvrdili da li se neograničeno delegiranje koristi u svim dolaznim poverenjima.

Rešavanje problema sa greškama prilikom potvrde identiteta

Kada je neograničeno delegiranje onemogućeno, aplikacije mogu imati problema sa kompatibilnošću sa ovim promenama ako se aplikacije oslanjaju na neograničeno delegiranje. Ove aplikacije treba da budu konfigurisane da koriste ograničeno delegiranje ili ograničeno delegiranje koje je zasnovano na resursima. Više informacija potražite u članku Pregled ograničenog delegiranja protokola Kerberos.

Aplikacije koje se oslanjaju na povratnu potvrdu identiteta u više poverenja nisu podržane pomoću ograničenog delegiranja. Na primer, delegiranje ne uspeva ako korisnik u šumi A potvrdi identitet aplikaciji u šumi B, a aplikacija u šumi B pokušava da delegira tiket nazad u šumu A.