Frissítések a TGT-delegáláshoz bejövő megbízhatósági kapcsolatok között a Windows Server-ben

Összegzés

Az erdőszintű megbízhatósági kapcsolatok lehetőséget biztosítanak az Active Directory erdő erőforrásai számára, hogy megbízzanak egy másik erdőből származó identitásokban. Ez a megbízhatóság mindkét irányban beállítható. A megbízható erdő a felhasználói identitás forrása. A megbízó erdő tartalmazza azt az erőforrást, amelyet a felhasználók hitelesítenek. A megbízható erdő ennek ellenkezőjét nem teszi lehetővé a felhasználók hitelesítésére a megbízó erdő felé.

A korlátozás nélküli Kerberos-delegálás egy olyan mechanizmus, amelyben a felhasználó elküldi a hitelesítő adatait egy szolgáltatásnak annak érdekében, hogy a szolgáltatás hozzáférjen az erőforrásokhoz a felhasználó nevében. A korlátozás nélküli Kerberos-delegálás engedélyezéséhez a szolgáltatás Active Directory-fiókját megbízhatóként kell megjelölni. Ez akkor okoz problémát, ha a felhasználó és a szolgáltatás különböző erdőkhöz tartozik. A kiszolgálóerdő felelős a delegálás engedélyezéséért. A meghatalmazás tartalmazza a felhasználó erdőjéből származó felhasználók hitelesítő adatait.

Ha engedélyezi egy erdő számára, hogy olyan biztonsági döntéseket hozzon, amelyek hatással vannak egy másik erdő fiókjaira, az sérti az erdők közötti biztonsági határt. A megbízó erdő tulajdonosa kérheti egy TGT delegálását egy identitáshoz a megbízható erdőből, így hozzáférést biztosítva számára a megbízható erdő erőforrásaihoz. Ez nem vonatkozik a Kerberos-korlátozott delegálásra (KCD).

A Windows Server 2012 bevezette az erdőhatár érvényesítését a Kerberos teljes delegálása esetén. Ez a szolgáltatás hozzáadott egy házirendet a megbízható tartományhoz, amely letiltja a korlátozás nélküli delegálást megbízhatósági kapcsolatonkénti alapon. A funkció alapértelmezett beállítása engedélyezi a korlátozás nélküli delegálást, és nem biztonságos.

A Windows Server következő verzióihoz biztonsági szigorítást biztosító frissítések érhetők el:

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

Ez a funkció a biztonsági szigorítás változásaival együtt a következő verziókban lett visszaportolva:

• Windows Server 2008 R2
• Windows Server 2008

Ezek a biztonsági frissítések az alábbi módosításokat tartalmazzák:

• A május 14-i és újabb frissítések telepítése után a korlátozás nélküli Kerberos-delegálás alapértelmezés szerint le van tiltva az új erdőkben és az új külső megbízhatósági kapcsolatokban.
• A nem korlátozott Kerberos-delegálás le van tiltva az erdőkben (új és meglévőkben egyaránt) és a külső megbízhatósági kapcsolatokon a 2019. július 9-i frissítés és az újabb frissítések telepítése után.
• A rendszergazdák a NETDOM és az AD PowerShell májusi vagy újabb verzióival engedélyezhetik a korlátozás nélküli Kerberos-delegálást.

A frissítések kompatibilitási ütközéseket okozhatnak azon alkalmazások esetében, amelyek jelenleg korlátozás nélküli delegálást igényelnek erdőbeli vagy külső megbízhatósági kapcsolatok között. Ez különösen igaz a külső megbízhatóságra, amelyeknél a karantén jelző (más néven SID-szűrés) alapértelmezés szerint engedélyezve van. Azaz a korlátozás nélküli delegálást a felsorolt megbízhatósági kapcsolat típusokon használó szolgáltatások hitelesítési kérései sikertelenek lesznek új jegyek kérésekor.

A kiadási dátumokat lásd a Frissítések idővonalán.

Kerülő megoldás

Az erdőhatár érvényesítése a Kerberos teljes delegálása funkcióval rendelkező Windows Server-verzión az adatok és a fiókok biztonsága érdekében letilthatja a TGT-delegálást a 2019. márciusi frissítések telepítése után egy bejövő megbízhatósági kapcsolaton belül, az EnableTGTDelegation netdom jelző Nem értékre állításával, az alábbiak szerint:

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

A 2019. májusi, illetve júliusi frissítések telepítése után a TGT-delegálás le van tiltva az új és a meglévő erdőbeli és külső megbízhatósági kapcsolatok esetén.

Ha újra engedélyezni szeretné a megbízhatósági kapcsolatok közötti delegálást, és vissza kíván térni az eredeti, nem biztonságos konfigurációhoz, amíg engedélyezni nem tudja a korlátozott vagy erőforrás-alapú delegálást, állítsa az EnableTGTDelegation jelzőt Igen értékre.

A NETDOM parancssora a TGT-delegálás engedélyezéséhez a következő:

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

A TGT-delegálás engedélyezésének NETDOM szintaxisa a következő:

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

A következő NETDOM-szintaxis fabrakam.com felhasználók contoso.com kiszolgálókon történő delegálásának engedélyezéséhez a következő:

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

         Megjegyzések

• Az EnableTGTDelegation jelölőt minden egyes megbízható tartomány (például contoso.com ) megbízható tartományában fabrikam.com(ebben az esetben) kell beállítani. A jelző beállítását követően a megbízható tartomány a továbbiakban nem engedélyezi TGT-k delegálását a megbízó tartománynak.
• Az EnableTGTDelegation biztonságos állapota a Nem.
• Az erdők közötti korlátozás nélküli delegálást használó alkalmazások vagy szolgáltatások sikertelenek lesznek, ha az EnableTGTDelegation manuálisan vagy programozás útján Igen értékre van állítva . A 2019. májusi és 2019. júliusi frissítések telepítése után az EnableTGTDelegation alapértelmezés szerint NEM értéket kap az új és meglévő megbízhatósági kapcsolatok esetén. A hiba észleléséről további információt a Korlátozás nélküli delegálást alkalmazó szolgáltatások megkeresése című témakörben talál. A Frissítések idővonalán megtekintheti azoknak a változásoknak az ütemtervét, amelyek befolyásolják a kerülő megoldás alkalmazását.
• A NETDOM-ról további információt a Netdom.exe dokumentációjában talál.
• Ha engedélyeznie kell a TGT-delegálást egy megbízhatósági kapcsolaton, javasoljuk, hogy csökkentse ezt a kockázatot azzal, hogy engedélyezi a Windows Defender Credential Guard szolgáltatást az ügyfélszámítógépeken. Ez megakadályozza az összes korlátozás nélküli delegálást olyan számítógépről, amelyen engedélyezve van és fut a Windows Defender Credential Guard.
• Ha erdővel vagy külső megbízhatósággal rendelkezik, és bármelyik karanténba van állítva, a TGT-delegálás nem engedélyezhető, mert a két jelző szemantikája ellentétes. A karanténbit megerősíti a biztonsági határvonalat a részt vevő tartományok között. A TGT-delegálás engedélyezése törli a tartományok közötti biztonsági határokat oly módon, hogy hozzáférést ad a megbízható tartományhoz tartozó felhasználók hitelesítő adataihoz. Nincs mindkét lehetősége.
  Ha a karantén jelölő jelenleg engedélyezve van, adja hozzá a quarantine:no jelzőt a NETDOM parancssori szintaxishoz.
• Ha az EnableTGTDelegation beállítástIgen értékre állította, szükség szerint törölje a kezdeményező és köztes hívók Kerberos-jegyeit. A releváns törlési jegy az ügyfél hivatkozási TGT-je a megfelelő bizalmi kapcsolaton keresztül. Ez több eszközt is érinthet, attól függően, hogy egy adott környezetben hány delegálási ugrást hajtottak végre.

Az eljárással kapcsolatos további információért tekintse meg a Windows IT Pro Center következő cikkét:

A származtatott tartományi hitelesítő adatok védelme a Windows Defender Credential Guard segítségével

Frissítések idővonala

2019. március 12.

Az erdőhatár érvényesítése a Kerberos teljes delegálása esetén frissítésként lesz elérhető, hogy engedélyezzük ezt a funkciót a Windows Server összes támogatott verzióján, amelyek a cikk tetején található Hatókör szakaszban vannak felsorolva. Azt javasoljuk, hogy a funkciót bejövő erdőszintű megbízhatóságokra állítsa be.

A frissítés hozzáadja a Kerberos-erdőhatár érvényesítése teljes delegálás funkciót a következő rendszerekhez:

• Windows Server 2008 R2
• Windows Server 2008

2019. május 14.

Kiadtunk egy frissítést, amely egy új biztonságos alapértelmezett konfigurációt ad hozzá az új erdőkhöz és külső megbízhatósági kapcsolatokhoz. Ha megbízhatósági kapcsolatok közötti delegálást igényel, az EnableTGTDelegation jelzőt Igen értékre kell állítania a 2019. július 9-i frissítés telepítése előtt. Ha nem követeli meg a megbízhatósági kapcsolatok közötti meghatalmazást, ne állítsa be az EnableTGTDelegation jelzőt. A rendszer figyelmen kívül hagyja az EnableTGTDelegation jelzőt a 2019. július 9-i frissítés telepítéséig, hogy elegendő idejük legyen a rendszergazdáknak arra, hogy szükség esetén újra engedélyezzék a korlátozás nélküli Kerberos-delegálást.

A frissítés részeként az EnableTGTDelegation jelző alapértelmezés szerint Nem értékre lesz állítva az újonnan létrehozott megbízhatósági kapcsolatok esetében. Ez a fenti viselkedés ellentéte. Azt javasoljuk, hogy a rendszergazdák ehelyett konfigurálják újra az érintett szolgáltatásokat az erőforrás-alapú korlátozott delegálás használatára.

A kompatibilitási problémák felderítéséről további információt a Korlátozás nélküli delegálást alkalmazó szolgáltatások megkeresése című témakörben talál.

2019. július 9.

Kiadtunk egy frissítést, amely az új alapértelmezett viselkedést kényszeríti az erdők és a külső megbízhatósági kapcsolatok bejövő oldalán. A korlátozás nélküli delegálást a felsorolt megbízhatósági kapcsolati kapcsolatok esetén használó szolgáltatások hitelesítése megtörténik, de delegálás nélkül. A szolgáltatás sikertelen lesz, amikor delegált műveleteket próbál futtatni.

A megoldáshoz tekintse meg a "Kerülő megoldás" című szakaszt.

Korlátozás nélküli delegálást alkalmazó szolgáltatások megkeresése

Ha olyan bejövő megbízhatósági kapcsolattal rendelkező erdőket szeretne keresni, amelyek lehetővé teszik a TGT-delegálást, valamint a korlátozás nélküli delegálást lehetővé tevő rendszerbiztonsági tagokat keresse meg, futtassa a következő PowerShell-parancsfájlokat egy parancsfájlban (például: 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 
}

A PowerShell-parancsfájlok kimenete felsorolja az Active Directory rendszerbiztonsági tagjait azokban a tartományokban, amelyek bejövő megbízhatósági kapcsolatra vannak konfigurálva attól a végrehajtó tartománytól, amelyhez korlátozás nélküli delegálás van konfigurálva. A kimenet az alábbi példához hasonlít.

Korlátozás nélküli delegálás észlelése Windows-eseményeken keresztül

Kerberos-jegy kiadásakor az Active Directory tartományvezérlő a következő biztonsági eseményeket naplózza. Az események információkat tartalmaznak a céltartományról. Az események segítségével megállapíthatja, hogy korlátlan delegálást használnak-e a bejövő megbízhatósági kapcsolatok között.

Hitelesítési hibák elhárítása

Ha a korlátozás nélküli delegálás le van tiltva, az alkalmazásoknál kompatibilitási problémák léphetnek fel a módosításokkal kapcsolatban, ha az alkalmazások korlátozás nélküli delegálást használnak. Ezeket az alkalmazásokat korlátozott vagy korlátozott, erőforrás-alapú delegálás használatára kell konfigurálni. További információt a Kerberos-korlátozott delegálás áttekintése című témakörben talál.

A korlátozott delegálás nem támogatja azokat az alkalmazásokat, amelyek körbejárási hitelesítést használnak a megbízhatósági kapcsolatok között. A delegálás például sikertelen, ha egy felhasználó az "A" erdőben hitelesíti magát a "B" erdőben lévő alkalmazáshoz, a "B" erdőben lévő alkalmazás pedig jegyet próbál visszadelegálni az A erdőbe.