Riepilogo
Trust tra foreste rappresentano un modo per le risorse in un insieme di strutture di Active Directory per considerare attendibile l'identità di un altro insieme di strutture. Questa relazione di trust possono essere configurate in entrambe le direzioni. Insieme di strutture trusted è l'origine dell'identità utente. Insieme di strutture trusting contiene la risorsa a cui gli utenti autenticati. Insieme di strutture trusted è possibile autenticare gli utenti all'insieme di strutture trusting senza consentire il contrario si verifica.
La delega non vincolata Kerberos è un meccanismo in cui un utente invia le credenziali a un servizio per consentire al servizio di accesso alle risorse per conto dell'utente. Per attivare la delega non vincolata Kerberos, l'account del servizio Active Directory deve essere contrassegnato come trusted per delega. Questo costituisce un problema se il servizio e l'utente appartiene a insiemi di strutture diversi. L'insieme di strutture di servizio è responsabile per consentire la delega. La delega include le credenziali degli utenti dalla foresta dell'utente.
Consentendo a un insieme di strutture per le decisioni di protezione che interessa gli account di un altro insieme di strutture viola il limite di protezione tra insiemi di strutture. Un utente malintenzionato che possiede l'insieme di strutture trusting può richiedere la delega di un TGT per un'identità dall'insieme di strutture trusted, attribuendogli l'accesso alle risorse nella foresta trusted. Ciò non si applica alla delega vincolata Kerberos (KCD).
Windows Server 2012 introdotto imposizione per limite di insieme di strutture per la delega di Kerberos completo. Questa funzionalità aggiunta di un criterio per il dominio trusted per disattivare la delega non vincolata in base al attendibilità. L'impostazione predefinita per questa funzionalità consente la delega non vincolata e non è sicura.
Per le seguenti versioni di Windows Server sono disponibili gli aggiornamenti che forniscono protezione avanzata:
-
Windows Server 2019
-
Windows Server 2016
-
Windows Server 2012 R2
-
Windows Server 2012
Questa funzionalità e modifiche per il rafforzamento della protezione sono stati backported alle seguenti versioni:
-
Windows Server 2008 R2
-
Windows Server 2008
Questi aggiornamenti della protezione effettuare le seguenti modifiche:
-
La delega vincolata Kerberos è disabilitata per impostazione predefinita sul nuovo insieme di strutture e nuovi trust esternidopo l'installazioneil 14 maggio update e aggiornamenti successivi.
-
La delega non vincolata Kerberos è disattivata in insiemi di strutture (sia nuovi che esistenti) e i trust esterni dopo l'installazione di luglio 9, 2019, update e aggiornamenti successivi.
-
Gli amministratori possono abilitare la delega non vincolata di Kerberos mediante l'utilizzo di maggio o versioni successive del modulo NETDOM e PowerShell di Active Directory.
Gli aggiornamenti potrebbero causare conflitti di compatibilità per le applicazioni che richiedono la delega non vincolata tra insiemi di strutture o trust esterni. Ciò è particolarmente vero di trust esterno per cui il flag di quarantena (noto anche come il filtraggio dei SID) è abilitato per impostazione predefinita. In particolare, le richieste di autenticazione per i servizi che utilizzano la delega non vincolata su tipi di trust elencati avrà esito negativo quando si richiede nuovi ticket.
Per le date di rilascio, vedere aggiornamenti timeline.
Soluzione alternativa
Per garantire la protezione dei dati e account su una versione di Windows Server e la funzione di imposizione per limite di insieme di strutture per la delega di Kerberos completo , è possibile bloccare la delega TGT dopo aver installato gli aggiornamenti di marzo 2019 attraverso un trust in ingresso mediante l'impostazione di flag Netdom EnableTGTDelegation a No, come segue:
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No
Delega TGT viene bloccata su insiemi di strutture nuovi ed esistenti e i trust esterni dopo l'installazione di maggio e luglio 2019 Aggiorna rispettivamente.
Per riattivare la delega attraverso trust e tornare alla configurazione originale unsafe fino a quando non può essere attivata la delega vincolata o basate sulle risorse, impostare il flag EnableTGTDelegation su Sì.
La riga di comando NETDOM per abilitare la delega TGT è la seguente:
netdom trust <TrustedDomainName > /domain:<TrustingDomainName > /EnableTgtDelegation:Yes
Può essere considerato concettualmente la sintassi 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 NETDOM per abilitare la delega TGT di fabrakam.com utenti sui server contoso.com è il seguente:
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:Yes
Note
-
Impostare il flag EnableTGTDelegation 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à TGT la delega per il dominio trusting.
-
Lo stato di EnableTGTDelegation protezione è No.
-
Qualsiasi applicazione o servizio da cui dipende la delega non vincolata tra insiemi di strutture non riuscirà quando EnableTGTDelegation è impostata a livello di codice o manualmente su Sì. Impostazioni predefinite di EnableTGTDelegation a NO sui trust nuovi ed esistenti dopo l'installazione degli aggiornamenti maggio 2019 e luglio 2019. Per ulteriori informazioni su come rilevare questo errore, vedere ricerca di servizi che utilizzano la delega non vincolata. Per una cronologia delle modifiche che influenzano il modo in cui può essere applicata questa soluzione, vedere aggiornamenti timeline .
-
Per ulteriori informazioni su NETDOM, vedere la documentazione di Netdom.exe.
-
Se è necessario attivare la delega TGT in una relazione di trust, è consigliabile ridurre tale rischio attivando Windows Defender credenziali Guard sui computer client. Ciò impedisce a tutti la delega non vincolata da un computer con Windows Defender credenziali Guard attivati e in esecuzione.
-
Se è un insieme di strutture o di un trust esterno che entrambi siano configurate come messi in quarantena, due flag è opposto alla semantica Impossibile abilitare la delega TGT. Il bit di quarantena aumenta il limite di protezione tra domini partecipanti. Attivazione della delega TGT Cancella i confini di protezione tra domini fornendo l'accesso al dominio trusting per le credenziali degli utenti dal dominio trusted. È possibile che entrambi i modi.
Se il flag di quarantena è attiva, aggiungere il flag di quarantena: no per la sintassi della riga di comando NETDOM.
-
Se si modifica EnableTGTDelegation a Sì, eliminare i ticket Kerberos sui chiamanti di originari e di livello intermedi come richiesto. Il ticket pertinente da eliminare è il riferimento del client TGT all'interno del trust rilevante. Potrebbe essere necessario più di un dispositivo, in base al numero di hop di delega in un determinato ambiente.
Per ulteriori informazioni su questa procedura, vedere il seguente articolo Windows IT Pro Center:
Proteggere le credenziali di dominio derivati con guardia credenziali di Windows Defender
Cronologia aggiornamenti
12 marzo 2019
L'applicazione per il limite di insieme di strutture per Kerberos delega completa sarà disponibile come aggiornamento per attivare questa funzionalità in tutte le versioni supportate di Windows Server elencati nella sezione nella parte superiore di questo articolo si applica a . Si consiglia di impostare la funzionalità per i trust tra insiemi di strutture in ingresso.
L'aggiornamento aggiungerà la funzionalità di imposizione per limite di insieme di strutture per la delega di Kerberos completo per i seguenti sistemi:
-
Windows Server 2008 R2
-
Windows Server 2008
14 maggio 2019.
È stato rilasciato un aggiornamento aggiungendo una nuova impostazione predefinita sicura configurazione al nuovo insieme di strutture e trust esterni. Se è necessaria la delega relazioni di trust, il flag EnableTGTDelegation deve essere impostato su Sì prima di installata l'aggiornamento del 9 luglio 2019. Se non è necessaria la delega relazioni di trust, non impostare il flag EnableTGTDelegation . Il flag EnableTGTDelegation verrà ignorato finché non viene installato l'aggiornamento del 9 luglio 2019 per fornire agli amministratori di tempo per riattivare la delega non vincolata Kerberos quando è necessario.
Come parte di questo aggiornamento, imposterà il flag EnableTGTDelegation su No per impostazione predefinita per tutte le relazioni di trust appena create. Questo è l'opposto del comportamento precedente. È consigliabile che gli amministratori di riconfigurare invece i servizi interessati per utilizzare la delega vincolata in base a risorsa.
Per ulteriori informazioni su come rilevare problemi di compatibilità, vedere ricerca di servizi che utilizzano la delega non vincolata.
9 luglio 2019
È stato rilasciato un aggiornamento che consente di applicare il nuovo comportamento predefinito sul lato in ingresso dell'insieme di strutture e trust esterni. Le richieste di autenticazione per i servizi che utilizzano la delega non vincolata su tipi di trust elencati verranno autenticati ma senza la delega. Il servizio avrà esito negativo durante il tentativo di eseguire operazioni delegate.
Per l'attenuazione, vedere la sezione "Workaround".
Ricerca di servizi che si affidano la delega non vincolata
Per analizzare gli insiemi di strutture che dispongono di trust in ingresso che consentono la delega TGT e per individuare qualsiasi protezione principali che consentono la delega non vincolata, esecuzione di PowerShell seguente script in uno script di file (ad esempio, Get-RiskyServiceAccountsByTrust.ps1 - Raccogliere):
Nota
È inoltre possibile passare il flag - ScanAll per la ricerca di relazioni di trust che non consentono la delega 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
}
L'output degli script di PowerShell elenco identità di protezione di Active Directory nei domini che sono configurati per un trust in ingresso dal dominio in esecuzione che è non vincolato delega configurata. L'output sarà simile all'esempio seguente.
|
dominio |
sAMAccountName |
objectClass |
|
partner.fabrikam.com |
pericolose |
utente |
|
partner.fabrikam.com |
labsrv$ |
computer |
Delega non vincolata rilevamento tramite gli eventi di Windows
Quando viene emesso un ticket Kerberos, un controller di dominio Active Directory registra i seguenti eventi di protezione. Gli eventi contengono informazioni relative al dominio di destinazione. È possibile utilizzare gli eventi per determinare se viene utilizzata la delega non vincolata relazioni di trust in ingresso.
Nota
Controllare gli eventi che contengono un valore TargetDomainName che corrisponde al nome di dominio trusted.
|
Registro eventi |
Origine eventi |
ID evento |
Dettagli |
|
Protezione |
Microsoft-Windows-controllo della sicurezza |
4768 |
È stato emesso un TGT Kerberos. |
|
Protezione |
Microsoft-Windows-controllo della sicurezza |
4769 |
È stato rilasciato un Ticket di servizio Kerberos. |
|
Protezione |
Microsoft-Windows-controllo della sicurezza |
4770 |
È stato rinnovato un Ticket di servizio Kerberos. |
Risoluzione dei problemi relativi a errori di autenticazione
Quando viene disattivata la delega non vincolata, applicazioni potrebbero avere problemi di compatibilità con le modifiche se le applicazioni si basano sulla delega non vincolata. Queste applicazioni devono essere configurate per l'uso vincolato delega o delega basato su risorsa vincolata. Fo ulteriori informazioni, see Panoramica di delega vincolata Kerberos.
Applicazioni che si basano sull'autenticazione di andata e ritorno relazioni di trust non sono supportate tramite la delega vincolata. Ad esempio, una delega ha esito negativo se autentica un utente nell'insieme di strutture a un'applicazione in foresta B e l'applicazione in foresta B tenta di delegare un ticket in foresta A.
