Aggiornamenti alla delega di TGT tra trust in ingresso in Windows Server

Riepilogo

I trust tra foreste consentono alle risorse di una foresta Active Directory di considerare attendibili le identità di un'altra foresta. Questa attendibilità può essere configurata in entrambe le direzioni. La foresta trusted è l'origine dell'identità dell'utente. La foresta di trusting contiene la risorsa in cui gli utenti eseguono l'autenticazione. La foresta trusted può autenticare gli utenti nella foresta trusting senza consentire che si verifichi il contrario.

La delega Kerberos non vincolata è un meccanismo in cui un utente invia le proprie credenziali a un servizio per consentire al servizio di accedere alle risorse per conto dell'utente. Per abilitare la delega Kerberos non vincolata, l'account del servizio in Active Directory deve essere contrassegnato come attendibile per la delega. Ciò crea un problema se l'utente e il servizio appartengono a foreste diverse. La foresta del servizio è responsabile dell'autorizzazione della delega. La delega include le credenziali degli utenti della foresta dell'utente.

Consentire a una foresta di prendere decisioni di sicurezza che influiscono sugli account di un'altra foresta viola il limite di sicurezza tra le foreste. Un utente malintenzionato proprietario della foresta trusting può richiedere la delega di un TGT per un'identità dalla foresta trusted, concedendogli l'accesso alle risorse nella foresta trusted. Ciò non si applica alla delega vincolata Kerberos (KCD).

Windows Server 2012 ha introdotto l'applicazione per il limite della foresta per la delega completa Kerberos. Questa funzionalità ha aggiunto un criterio al dominio attendibile per disabilitare la delega non vincolata in base all'attendibilità. L'impostazione predefinita per questa funzionalità consente la delega non vincolata ed è pericolosa.

Aggiornamenti per le versioni seguenti di Windows Server sono disponibili aggiornamenti che garantiscono la protezione avanzata:

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

Questa funzionalità, insieme alle modifiche apportate alla protezione avanzata, è stata sottoposta a backporting nelle versioni seguenti:

• Windows Server 2008 R2
• Windows Server 2008

Questi aggiornamenti della sicurezza apportano le modifiche seguenti:

• La delega Kerberos non vincolata è disabilitata per impostazione predefinita nella nuova foresta e nei nuovi trust esterni dopo l'installazione dell'aggiornamento del 14 maggio e degli aggiornamenti successivi.
• La delega Kerberos non vincolata è disabilitata nelle foreste (nuove ed esistenti) e nei trust esterni dopo l'installazione dell'aggiornamento del 9 luglio 2019 e degli aggiornamenti successivi.
• Gli amministratori possono abilitare la delega Kerberos non vincolata utilizzando le versioni May o successive di NETDOM e del modulo AD PowerShell.

Gli aggiornamenti possono causare conflitti di compatibilità per le applicazioni che attualmente richiedono la delega non vincolata tra trust esterni o foreste. Ciò è particolarmente vero per i trust esterni per i quali il flag di quarantena (noto anche come filtro SID) è abilitato per impostazione predefinita. In particolare, le richieste di autenticazione per i servizi che utilizzano la delega non vincolata sui tipi di attendibilità elencati avranno esito negativo quando si richiedono nuovi ticket.

Per le date di rilascio, consulta Sequenza temporale degli aggiornamenti.

Soluzione alternativa

Per garantire la sicurezza dei dati e degli account in una versione di Windows Server con la funzionalità di applicazione del limite della foresta per la delega completa Kerberos, è possibile bloccare la delega TGT dopo l'installazione degli aggiornamenti di marzo 2019 in un trust in ingresso impostando il flag netdom EnableTGTDelegation su No, come indicato di seguito:

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

La delega di TGT viene bloccata per la foresta nuova ed esistente e per i trust esterni dopo l'installazione rispettivamente degli aggiornamenti di maggio e luglio 2019.

Per abilitare nuovamente la delega tra trust e tornare alla configurazione originale non sicura fino a quando non sarà possibile abilitare la delega vincolata o basata sulle risorse, impostare il flag EnableTGTDelegation su Yes.

La riga di comando NETDOM per abilitare la delega TGT è la seguente:

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

Concettualmente si può pensare alla sintassi di NETDOM per abilitare la delega TGT come segue:

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

La sintassi di NETDOM per abilitare la delega TGT degli utenti fabrakam.com nei server contoso.com è la seguente:

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

         Note

• Il flag EnableTGTDelegation deve essere impostato nel dominio trusted (fabrikam.com in questo caso) per ogni dominio trusting (ad esempio contoso.com). Dopo aver impostato il flag, il dominio trusted non consentirà più la delega dei TGT al dominio trusting.
• Lo stato sicuro per EnableTGTDelegation è No.
• Qualsiasi applicazione o servizio che si basa sulla delega non vincolata tra foreste avrà esito negativo quando EnableTGTDelegation è impostato manualmente o a livello di codice su Sì. Il valore predefinito di EnableTGTDelegation è NO per i trust nuovi ed esistenti dopo l'installazione degli aggiornamenti di maggio 2019 e luglio 2019. Per altre informazioni su come rilevare questo errore, vedere Ricerca di servizi che si basano sulla delega non vincolata. Consulta la sequenza temporale degli aggiornamenti per una sequenza temporale delle modifiche che influiscono sull'applicazione di questa soluzione alternativa.
• Per ulteriori informazioni su NETDOM, vedere la documentazioneNetdom.exe.
• Se è necessario abilitare la delega TGT in un trust, è consigliabile ridurre tale rischio abilitando Windows Defender Credential Guard nei computer client. In questo modo si impedisce tutte le delega non vincolate da un computer in cui Windows Defender Credential Guard è abilitato e in esecuzione.
• Se si dispone di una foresta o di un trust esterno ed entrambi sono configurati come in quarantena, la delega TGT non può essere abilitata perché i due flag hanno una semantica opposta. Il bit di quarantena rafforza il limite di sicurezza tra i domini partecipanti. L'abilitazione della delega TGT cancella i limiti di sicurezza tra i domini concedendo al dominio attendibile l'accesso alle credenziali degli utenti del dominio attendibile. Non puoi avere entrambe le cose.
  Aggiungere il flag quarantine:no alla sintassi della riga di comando NETDOM se il flag quarantine è attualmente abilitato.
• Se EnableTGTDelegation è stato modificato in Sì, eliminare i ticket Kerberos per i chiamanti di origine e intermedi in base alle esigenze. Il ticket pertinente da eliminare è il TGT di riferimento del cliente attraverso il trust pertinente. Ciò potrebbe coinvolgere più dispositivi, a seconda del numero di hop di delega in un determinato ambiente.

Per altre informazioni su questa procedura, vedere l'articolo seguente di Windows IT Center Center per IT:

Proteggere le credenziali di dominio derivate con Windows Defender Credential Guard

Aggiornamenti sequenza temporale

12 marzo 2019

L'applicazione del limite della foresta per la delega completa Kerberos sarà disponibile come aggiornamento per abilitare questa funzionalità in tutte le versioni supportate di Windows Server elencate nella sezione Si applica a all'inizio di questo articolo. È consigliabile impostare la funzionalità sui trust tra foreste in ingresso.

L'aggiornamento aggiungerà la funzionalità di applicazione del limite della foresta per la delega completa Kerberos ai sistemi seguenti:

• Windows Server 2008 R2
• Windows Server 2008

14 maggio 2019

È stato rilasciato un aggiornamento che aggiunge una nuova configurazione predefinita sicura per la nuova foresta e i trust esterni. Se è necessaria la delega tra trust, il flag EnableTGTDelegation deve essere impostato su Sì prima dell'installazione dell'aggiornamento del 9 luglio 2019. Se non è richiesta la delega tra trust, non impostare il flag EnableTGTDelegation . Il flag EnableTGTDelegation verrà ignorato fino all'aggiornamento del 9 luglio 2019 per dare agli amministratori il tempo di riabilitare la delega Kerberos non vincolata quando è necessario.

Come parte di questo aggiornamento, il flag EnableTGTDelegation verrà impostato su No per impostazione predefinita per tutti i trust appena creati. Questo è l'opposto del comportamento precedente. È consigliabile che gli amministratori riconfigurino i servizi interessati per l'uso della delega vincolata basata sulle risorse.

Per altre informazioni su come rilevare i problemi di compatibilità, vedere Ricerca di servizi che si basano sulla delega non vincolata.

9 luglio 2019

È stato rilasciato un aggiornamento che applica il nuovo comportamento predefinito sul lato in ingresso della foresta e dei trust esterni. Le richieste di autenticazione per i servizi che usano la delega non vincolata sui tipi di attendibilità elencati verranno autenticate ma senza delega. Il servizio avrà esito negativo quando tenterà di eseguire operazioni delegate.

Per la mitigazione, vedi la sezione "Soluzione alternativa".

Ricerca di servizi che si basano su una delega non vincolata

Per analizzare le foreste con trust in ingresso che consentono la delega TGT e per individuare eventuali entità di sicurezza che consentono la delega non vincolata, eseguire gli script di PowerShell seguenti in un file di script, ad esempio 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 
}

L'output degli script di PowerShell elenca le entità di sicurezza di Active Directory nei domini configurati per un trust in ingresso dal dominio di esecuzione in cui è configurata la delega non vincolata. L'output sarà simile all'esempio seguente.

Rilevamento della delega non vincolata tramite eventi di Windows

Quando viene rilasciato un ticket Kerberos, un controller di dominio Active Directory registra gli eventi di sicurezza seguenti. Gli eventi contengono informazioni sul dominio di destinazione. È possibile usare gli eventi per determinare se la delega non vincolata viene usata tra trust in ingresso.

Risoluzione dei problemi di autenticazione

Quando la delega non vincolata è disabilitata, le applicazioni potrebbero avere problemi di compatibilità con queste modifiche se le applicazioni si basano sulla delega non vincolata. Queste applicazioni devono essere configurate per l'utilizzo della delega vincolata o della delega vincolata basata sulle risorse. Per altre informazioni, vedere Panoramica della delega vincolata Kerberos.

Le applicazioni che si basano sull'autenticazione di andata e ritorno tra trust non sono supportate tramite la delega vincolata. Ad esempio, una delega non riesce se un utente nella foresta A esegue l'autenticazione in un'applicazione nella foresta B e l'applicazione nella foresta B tenta di delegare un ticket alla foresta A.