Teabevärskendused Windows Server sissetulevate usalduste üleselt TGT delegeerimist

Kokkuvõte

Metsausaldused võimaldavad Active Directory mets ressurssidel usaldada teise metsa identiteete. Seda usaldust saab konfigureerida mõlemas suunas. Usaldusväärne mets on kasutajaidentiteedi allikas. Usaldav mets sisaldab ressurssi, millele kasutajad autendivad. Usaldusväärne mets saab kasutajaid usaldusväärses metsas autentida ilma vastupidist toimumist lubamata.

Piiranguteta Kerberose delegeerimine on mehhanism, mille korral kasutaja saadab teenusele identimisteabe, et võimaldada teenusel kasutaja nimel ressurssidele juurde pääseda. Piiranguteta Kerberose delegeerimise lubamiseks peab teenuse konto Active Directorys olema märgitud delegeerimiseks usaldusväärseks. See tekitab probleemi, kui kasutaja ja teenus kuuluvad erinevatesse metsadesse. Teenistusmets vastutab delegeerimise lubamise eest. Delegeerimine sisaldab kasutajate identimisteavet kasutaja metsast.

Ühe metsa lubamine teha teise metsa kontosid mõjutavaid turbeotsuseid rikub metsade vahelist turvapiiri. Usaldusväärse metsa omav ründaja võib taotleda TGT delegeerimist usaldusväärsest metsast identiteedi saamiseks, andes talle juurdepääsu usaldusväärse metsa ressurssidele. See ei kehti Kerberose piirangutega delegeerimise kohta.

Windows Server 2012 kehtestas Kerberose täieliku delegatsiooni metsapiiri jõustamise. See funktsioon lisas usaldusväärsele domeenile poliitika piiranguteta delegeerimise keelamiseks usalduse alusel. Selle funktsiooni vaikesäte lubab piiranguteta delegeerimist ja on ebaturvaline.

Teabevärskendused, mis pakuvad turbekõrgenemist, on olemas järgmiste Windows Server versioonide jaoks:

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

See funktsioon koos turbekärpimise muudatustega anti tagasi järgmistesse versioonidesse:

• Windows Server 2008 R2
• Windows Server 2008

Need turbevärskendused muudavad järgmisi muudatusi.

• Piiranguteta Kerberose delegeerimine keelatakse vaikimisi pärast 14. mai värskenduse ja uuemate värskenduste installimist uuele metsale ja uutele välisusaldustele.
• Piiranguteta Kerberose delegatsioon keelatakse metsades (nii uutes kui ka olemasolevates) ja välisusaldustes pärast 9. juuli 2019 värskenduse ja uuemate värskenduste installimist.
• Administraatorid saavad lubada piiranguteta Kerberose delegeerimise NETDOM-i ja AD PowerShelli mooduli mai või uuemate versioonide abil.

Värskendused võivad põhjustada ühilduvuskonflikte rakendustes, mis nõuavad praegu piiranguteta delegeerimist metsa- või välisusaldustesse. See kehtib eriti välise usalduse kohta, mille jaoks on karantiinilipp (ehk SID filtreerimine) vaikimisi lubatud. Täpsemalt öeldes nurjuvad autentimistaotlused teenuste jaoks, mis kasutavad piiranguteta delegeerimist loetletud usaldustüüpide kaudu, kui taotlete uusi pileteid.

Väljaandmiskuupäevade kohta leiate teavet teemast ajaskaala Teabevärskendused.

Ajutine lahendus

Andmete ja konto turvalisuse pakkumiseks Windows Server versioonis, millel on Kerberose täieliku delegeerimise funktsioon Metsapiiri jõustamine, saate TGT delegeerimise blokeerida pärast seda, kui olete installinud 2019. aasta märtsi värskendused sissetuleva usalduse ulatuses, määrates netdom-i lipu EnableTGTDelegation väärtuseks Ei järgmiselt.

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

Pärast 2019. aasta mai ja juuli värskenduste installimist blokeeritakse TGT delegeerimine uutele ja olemasolevatele metsa- ja välisusaldustele.

Mitmes usalduses delegeerimise uuesti lubamiseks ja algse ebaturvalise konfiguratsiooni taastamiseks kuni piirangute või ressursipõhise delegeerimise lubamiseni seadke lipu EnableTGTDelegation väärtuseks Jah.

TGT-delegeerimise lubamiseks on NETDOM-i käsurida järgmine:

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

TGT-delegeerimise lubamise NETDOM-i süntaksit saab kontseptuaalselt välja mõelda järgmiselt.

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

NETDOM-i süntaks fabrakam.com kasutajate TGT delegeerimise lubamiseks contoso.com serverites on järgmine.

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

         Märkused

• Lipp EnableTGTDelegation tuleks seada iga usaldusväärse domeeni (nt contoso.com) jaoks usaldusväärses domeenis (antud juhul fabrikam.com). Pärast lipu määramist ei luba usaldusväärne domeen enam TGT-sid usaldusväärsele domeenile delegeerida.
• EnableTGTDelegationi turvaolek on Ei.
• Mis tahes rakendus või teenus, mis tugineb piiranguteta delegeerimisel metsade vahel, nurjub, kui EnableTGTDelegation on käsitsi või programmiliselt seatud väärtuseks Jah. EnableTGTDelegation määrab uute ja olemasolevate usalduste vaikeväärtuseks NO pärast 2019. aasta mai ja juuli 2019 värskenduste installimist. Lisateavet selle tõrke tuvastamise kohta leiate teemast Piiranguteta delegeerimisel põhinevate teenuste otsimine. Selle lahenduse rakendamist mõjutavate muudatuste ajaskaala Teabevärskendused leiate teemast ajaskaala.
• NETDOM-i kohta leiate lisateavet Netdom.exe dokumentatsioonist.
• Kui peate TGT delegeerimise usalduses lubama, on soovitatav seda riski vähendada, lubades klientarvutites Windows Defender Credential Guardi. See takistab kogu piiranguteta delegeerimist arvutist, kus windows Defender Credential Guard on lubatud ja töötab.
• Kui teil on mets või välisusaldus ja need on konfigureeritud karantiinis, ei saa TGT delegeerimist lubada, kuna kahel lipul on vastasseremantika. Karantiini bitt tugevdab osalevate domeenide vahelist turbepiiri. TGT delegeerimise lubamisel kustutatakse domeenide vahelised turbepiirid, andes usaldusväärsele domeenile juurdepääsu usaldusväärse domeeni kasutajate identimisteabele. Seda ei saa olla mõlemal viisil.
  Lisage karantiin: no lipp NETDOM-i käsurea süntaksile, kui karantiinilipp on praegu lubatud.
• Kui muutsite EnableTGTDelegationiväärtuseks Jah, kustutage vastavalt vajadusele Kerberose piletid lähte- ja kesktasemel helistajatelt. Kustutamiseks vajalik pilet on kliendi soovitus TGT kogu asjakohase usalduse ulatuses. See võib hõlmata mitut seadet, sõltuvalt delegeerimishüpete arvust antud keskkonnas.

Lisateavet selle toimingu kohta leiate järgmisest Windows IT-spetsialistide keskuse artiklist:

Tuletatud domeeni identimisteabe kaitsmine Windows Defender Credential Guardi abil

Ajaskaala Teabevärskendused

12. märts 2019

Kerberose täieliku delegeerimise metsapiiri jõustamine on saadaval värskendusena, mis lubab selle funktsiooni kõigis Windows Server toetatud versioonides, mis on loetletud selle artikli ülaosas olevas jaotises Rakenduskohased. Soovitame määrata funktsiooni sissetulevatele metsausaldustele.

Värskendusega lisatakse Kerberose täieliku delegeerimise funktsioon Metsapiiri jõustamine järgmistesse süsteemidesse.

• Windows Server 2008 R2
• Windows Server 2008

14. mai 2019

Anti välja värskendus, mis lisas uue turvalise vaikekonfiguratsiooni uutele metsa- ja välisusaldustele. Kui vajate mitmes usalduses delegeerimist, tuleks lipp EnableTGTDelegation määrata enne 2019. aasta 9. juuli värskenduse installimist väärtuseks Jah . Kui te ei nõua mitmes usalduses delegeerimist, ei tohiks te määrata lippu EnableTGTDelegation . Lippu EnableTGTDelegation ignoreeritakse kuni 9. juulini 2019, et anda administraatoritele aega piiranguteta Kerberose delegeerimise uuesti lubamiseks, kui see on nõutav.

Selle värskenduse osana seatakse lipp EnableTGTDelegation vaikimisi kõigile vastloodud usaldustele ei . See on eelmisele käitumisele vastupidine. Soovitame administraatoritel konfigureerida mõjutatud teenused ressursipõhise piiratud delegeerimise kasutamiseks.

Lisateavet ühilduvusprobleemide tuvastamise kohta leiate teemast Piiranguteta delegeerimisel põhinevate teenuste otsimine.

9. juuli 2019

Anti välja värskendus, mis jõustab uue vaikekäitumise metsa- ja välisusalduste sissetuleval poolel. Autentimistaotlused teenustele, mis kasutavad piiranguteta delegeerimist loetletud usaldustüüpide kaudu, autenditakse, kuid delegeerimata. Teenus nurjub, kui see proovib käivitada delegeeritud toiminguid.

Leevenduse kohta leiate teavet jaotisest "Ajutine lahendus".

Piiranguteta delegeerimisel põhinevate teenuste leidmine

Selliste metsade otsimiseks, millel on sissetulevad usaldused, mis lubavad TGT delegeerimist, ja turvasubjektide leidmiseks, mis lubavad piiranguteta delegeerimist, käivitage skriptifailis järgmised PowerShelli skriptid (nt 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 
}

PowerShelli skriptide loendi Active Directory turbesubjektid domeenides, mis on konfigureeritud sissetuleva usalduse jaoks täitmisdomeenist, millel on piiranguteta delegeerimine konfigureeritud. Väljund sarnaneb järgmise näitega.

Piiranguteta delegeerimise tuvastamine Windowsi sündmuste kaudu

Kerberose pileti väljastamisel logib Active Directory domeenikontroller järgmised turbesündmused. Sündmused sisaldavad teavet sihtdomeeni kohta. Sündmuste abil saate kindlaks teha, kas sissetulevate usalduste puhul kasutatakse piiranguteta delegeerimist.

Autentimistõrgete tõrkeotsing

Kui piiranguteta delegeerimine keelatakse, võib rakendustel olla nende muudatustega ühilduvusprobleeme, kui rakendused tuginevad piiranguteta delegeerimisel. Need rakendused peaksid olema konfigureeritud kasutama piiratud delegeerimist või piiratud delegeerimist, mis on ressursipõhine. Lisateavet leiate teemast Kerberose piirangutega delegeerimise ülevaade.

Piiratud delegeerimise abil ei toetata rakendusi, mis kasutavad usalduste kaudu edasi-tagasi autentimist. Delegeerimine nurjub näiteks juhul, kui kasutaja metsas A autendib mõne metsaS B oleva rakendusega ja metsaS B olev rakendus proovib delegeerida piletit tagasi metsale A.