Funzionamento delle relazioni di trust per le foreste in Active Directory (anteprima)

Active Directory Domain Services (AD DS) offre sicurezza tra più domini o foreste tramite relazioni di trust tra domini e foreste. Prima che l'autenticazione possa verificarsi tra trust, Windows deve prima verificare se il dominio richiesto da un utente, un computer o un servizio ha una relazione di trust con il dominio dell'account richiedente.

Per verificare la presenza di questa relazione di trust, il sistema di sicurezza di Windows calcola un percorso di attendibilità tra il controller di dominio (DC) per il server che riceve la richiesta e un controller di dominio nel dominio dell'account richiedente.

I meccanismi di controllo di accesso forniti da Servizi di dominio Active Directory e dal modello di sicurezza distribuito di Windows forniscono un ambiente per il funzionamento dei trust tra domini e foreste. Affinché questi trust funzionino correttamente, ogni risorsa o computer deve avere un percorso di attendibilità diretto a un controller di dominio nel dominio in cui si trova.

Il servizio Accesso rete implementa il percorso di attendibilità usando una connessione RPC (Remote Procedure Call) autenticata all'autorità di dominio attendibile. Un canale protetto si estende anche ad altri domini di Active Directory Domain Services tramite relazioni di trust tra domini. Questo canale protetto viene usato per ottenere e verificare le informazioni di sicurezza, inclusi gli identificatori di sicurezza (SID) per utenti e gruppi.

Nota

Domain Services supporta più direzioni di trust tra foreste, tra cui un'anteprima corrente di trust bidirezionali e trust unidirezionali che possono essere in ingresso o in uscita.

Per una panoramica su come i trust si applicano ai Servizi di dominio, vedere Concetti e funzionalità della foresta.

Per iniziare a usare i trust in Domain Services, creare un dominio gestito che usa trust di foresta.

Flussi di relazione di fiducia

Il flusso di comunicazioni protette nei trust determina l'elasticità dei trust. La modalità di creazione o configurazione di un trust determina l'estensione della comunicazione all'interno o tra foreste.

La direzione del trust determina il flusso di comunicazione nei trust. Un trust può essere unidirezionale o bidirezionale e può essere transitivo o non transitivo.

Il diagramma seguente mostra che tutti i domini in albero 1 e albero 2 hanno relazioni di trust transitive per impostazione predefinita. Di conseguenza, gli utenti in Albero 1 possono accedere alle risorse nei domini in Albero 2 e gli utenti in Albero 2 possono accedere alle risorse in Albero 1, quando le autorizzazioni appropriate vengono assegnate alla risorsa.

Trusts unidirezionali e bidirezionali

Le relazioni di trust consentono l'accesso alle risorse possono essere unidirezionale o bidirezionale.

Un trust unidirezionale è un percorso di autenticazione unidirezionale creato tra due domini. In un trust unidirezionale tra Dominio A e dominio B, gli utenti del dominio A possono accedere alle risorse in dominio B. Tuttavia, gli utenti nel dominio B non possono accedere alle risorse in dominio A.

Alcuni trust unidirezionali possono essere transitivi o non transitivi, a seconda del tipo di trust creato.

In un trust bidirezionale, il dominio A considera affidabile il dominio B e il dominio B considera affidabile il dominio A. Questa configurazione significa che le richieste di autenticazione possono essere passate tra i due domini in entrambe le direzioni. Alcune relazioni bidirezionali possono essere non transitive o transitive a seconda del tipo di trust creato.

Tutti i trust di dominio in una foresta di Active Directory Domain Services locale sono trust transitivi bidirezionali. Quando viene creato un nuovo dominio figlio, viene creato automaticamente un trust transitivo bidirezionale tra il nuovo dominio figlio e il dominio padre.

Trust transitivi e non transitivi

La transitività determina se un trust può essere esteso all'esterno dei due domini con cui è stato formato.

• Un trust transitivo può essere usato per estendere le relazioni di trust con altri domini.
• Un trust non transitivo può essere usato per negare relazioni di trust con altri domini.

Ogni volta che si crea un nuovo dominio in una foresta, viene creata automaticamente una relazione di trust transitiva bidirezionale tra il nuovo dominio e il relativo dominio padre. Se i domini figlio vengono aggiunti al nuovo dominio, il percorso di attendibilità passa verso l'alto attraverso la gerarchia di dominio estendendo il percorso di attendibilità iniziale creato tra il nuovo dominio e il relativo dominio padre. Le relazioni di trust transitive si propagano verso l'alto attraverso un albero di dominio mentre viene formato, creando relazioni di trust transitive tra tutti i domini dell'albero.

Le richieste di autenticazione seguono questi percorsi di attendibilità, in modo che gli account di qualsiasi dominio nella foresta possano essere autenticati da qualsiasi altro dominio nella foresta. Con un processo di accesso Single Sign-On, gli account con le autorizzazioni appropriate possono accedere alle risorse in qualsiasi dominio della foresta.

Trust tra foreste

Le relazioni di trust tra foreste consentono di gestire infrastrutture segmentate di Active Directory Domain Services (AD DS) e consentono l'accesso alle risorse e ad altri oggetti in più foreste. I trust tra foreste sono utili per i provider di servizi, le aziende che subiscono fusioni o acquisizioni, extranet aziendali collaborativi e aziende che cercano una soluzione per l'autonomia amministrativa.

Usando i trust tra foreste, è possibile collegare due foreste diverse per formare una relazione di trust transitiva unidirezionale o bidirezionale. Un trust tra foreste consente agli amministratori di connettere due foreste di Active Directory Domain Services con una singola relazione di trust per offrire un'esperienza di autenticazione e autorizzazione senza problemi tra le foreste.

Un trust tra foreste può essere creato solo tra un dominio radice della foresta in una foresta e un dominio radice della foresta in un'altra foresta. I trust tra foreste possono essere creati solo tra due foreste e non possono essere estesi in modo implicito a una terza foresta. Questo comportamento significa che se viene creato un trust tra foresta 1 e foresta 2e viene creato un altro trust tra foresta 2 e foresta 3, foresta 1 non ha un trust implicito con foresta 3.

Il diagramma seguente illustra due relazioni di fiducia separate tra le tre foreste di Active Directory Domain Services all'interno di una singola organizzazione.

Questa configurazione di esempio fornisce l'accesso seguente:

• Gli utenti in Foresta 2 di possono accedere alle risorse in qualsiasi dominio in Foresta 1 di o Foresta 3 di
• Gli utenti in Foresta 3 possono accedere alle risorse in qualsiasi dominio in Foresta 2
• Gli utenti in Foresta 1 possono accedere alle risorse in qualsiasi dominio in Foresta 2

Questa configurazione non consente agli utenti nella foresta 1 di accedere alle risorse nella foresta 3 o viceversa. Per consentire agli utenti nelle due foreste, Foresta 1 e Foresta 3, di condividere le risorse, è necessario creare un trust transitivo bidirezionale tra le due foreste.

Se viene creato un trust unidirezionale tra due foreste, i membri della foresta fiduciaria possono utilizzare le risorse che si trovano nella foresta fiduciante. Tuttavia, l'attendibilità opera in una sola direzione.

Ad esempio, quando viene creato un trust di foresta unidirezionale tra foresta 1 (foresta attendibile) e foresta 2 (foresta fiduciosa):

• I membri di Foresta 1 possono accedere alle risorse che si trovano nella Foresta 2.
• I membri di Foresta 2 non possono accedere alle risorse che si trovano in Foresta 1 usando la stessa fiducia.

Importante

Microsoft Entra Domain Services supporta diversi tipi di trust forestali.

Requisiti per il trust delle foreste

Prima di poter creare un trust tra foreste, è necessario verificare di disporre dell'infrastruttura DNS (Domain Name System) corretta. I trust tra foreste possono essere creati solo quando è disponibile una delle configurazioni DNS seguenti:

• Un singolo server DNS radice è il server DNS radice per entrambi gli spazi dei nomi DNS della foresta. La zona radice contiene le deleghe per ognuno degli spazi dei nomi DNS e gli hint radice di tutti i server DNS includono il server DNS radice.

• Quando non esiste un server DNS radice condiviso, i server DNS radice in ogni spazio dei nomi DNS della foresta utilizzano inoltratori condizionali DNS per instradare le query relative ai nomi nell'altro spazio dei nomi.

  Importante

  Qualsiasi foresta dei Servizi di dominio Microsoft Entra con un trust deve usare la seguente configurazione DNS. L'ospitare uno spazio dei nomi DNS diverso dallo spazio dei nomi DNS della foresta non è una funzionalità di Microsoft Entra Domain Services. I server d'inoltro condizionale sono la configurazione corretta.

• Quando non è presente un server DNS radice condiviso e i server DNS radice in ogni spazio dei nomi della foresta usano zone secondarie DNS, queste vengono configurate in ogni spazio dei nomi DNS per instradare le query per i nomi nell'altro spazio dei nomi.

Per creare un trust di foresta nei Servizi di dominio di Active Directory (AD DS), è necessario essere un membro del gruppo Domain Admins (nel dominio radice della foresta) o del gruppo Enterprise Admins in Active Directory. A ogni trust viene assegnata una password che gli amministratori di entrambe le foreste devono conoscere. I membri di Enterprise Admins in entrambe le foreste possono creare i trust in entrambe le foreste contemporaneamente e, in questo scenario, una password che è crittograficamente casuale viene generata e scritta automaticamente per entrambe le foreste.

Una foresta di dominio gestita supporta fino a cinque trust in uscita unidirezionale verso foreste locali. Il trust tra foreste in uscita per Microsoft Entra Domain Services viene creato nell'interfaccia di amministrazione di Microsoft Entra. Un utente con i privilegi indicati in precedenza in Active Directory Locale deve configurare la relazione di trust della foresta in ingresso.

Processi di trust e interazioni

Molte transazioni tra domini e inter-foreste dipendono da relazioni di fiducia tra domini o foreste per completare varie attività. In questa sezione vengono valutati i processi e le interazioni che si verificano quando si accede alle risorse tra trust e segnalazioni di autenticazione.

Panoramica dell'elaborazione delle segnalazioni di autenticazione

Quando si fa riferimento a una richiesta di autenticazione a un dominio, il controller di dominio in tale dominio deve determinare se esiste una relazione di trust con il dominio da cui proviene la richiesta. La direzione del trust e se l'attendibilità è transitiva o non transitiva deve essere determinata anche prima di autenticare l'utente per accedere alle risorse nel dominio. Il processo di autenticazione che si verifica tra domini attendibili varia in base al protocollo di autenticazione in uso. I protocolli Kerberos V5 e NTLM elaborano riferimenti per l'autenticazione a un dominio in modo diverso

Elaborazione delle segnalazioni Kerberos V5

Il protocollo di autenticazione Kerberos V5 dipende dal servizio Net Logon nei controller di dominio per l'autenticazione e le informazioni di autorizzazione dei client. Il protocollo Kerberos si connette a un Centro distribuzione chiavi (KDC) online e all'archivio account di Active Directory per i ticket di sessione.

Il protocollo Kerberos utilizza anche relazioni di fiducia per i servizi di concessione di ticket tra aree di autenticazione (TGS) e per convalidare i Privilege Attribute Certificates (PAC) attraverso un canale sicuro. Il protocollo Kerberos esegue l'autenticazione inter-realm solo con aree Kerberos di sistemi operativi non Windows, come un'area Kerberos MIT, e non è necessario che interagisca con il servizio Net Logon.

Se il client usa Kerberos V5 per l'autenticazione, richiede un ticket al server nel dominio di destinazione da un controller di dominio nel dominio del proprio account. Il KDC Kerberos funge da intermediario attendibile tra il client e il server e fornisce una chiave di sessione che consente alle due parti di autenticarsi tra loro. Se il dominio di destinazione è diverso dal dominio corrente, il KDC segue un processo logico per determinare se è possibile fare riferimento a una richiesta di autenticazione:

1. Il dominio corrente è considerato attendibile direttamente dal dominio del server richiesto?

   • In caso affermativo, inviare al client una segnalazione al dominio richiesto.
   • In caso contrario, andare al passaggio successivo.

2. Esiste una relazione di trust transitiva tra il dominio corrente e il dominio successivo nel percorso di attendibilità?

   • In caso affermativo, inviare al client una segnalazione al dominio successivo nel percorso di attendibilità.
   • In caso contrario, inviare al client un messaggio di accesso negato.

Elaborazione delle segnalazioni NTLM

Il protocollo di autenticazione NTLM dipende dal servizio Net Logon nei controller di dominio per l'autenticazione dei client e le informazioni di autorizzazione. Questo protocollo autentica i client che non usano l'autenticazione Kerberos. NTLM usa trust per passare le richieste di autenticazione tra domini.

Se il client usa NTLM per l'autenticazione, la richiesta iniziale di autenticazione passa direttamente dal client al server di risorse nel dominio di destinazione. Questo server crea una richiesta di verifica alla quale risponde il client. Il server invia quindi la risposta dell'utente a un controller di dominio nel dominio del suo account computer. Questo controller di dominio controlla l'account utente rispetto al database degli account di sicurezza.

Se l'account non esiste nel database, il controller di dominio determina se eseguire l'autenticazione pass-through, inoltrare la richiesta o negare la richiesta usando la logica seguente:

1. Il dominio corrente ha una relazione di trust diretta con il dominio dell'utente?

   • In caso affermativo, il controller di dominio invia le credenziali del client a un controller di dominio nel dominio dell'utente per l'autenticazione pass-through.
   • In caso contrario, andare al passaggio successivo.

2. Il dominio corrente ha una relazione di trust transitiva con il dominio dell'utente?

   • In caso affermativo, passare la richiesta di autenticazione al dominio successivo nel percorso di attendibilità. Questo controller di dominio ripete il processo controllando le credenziali dell'utente rispetto al proprio database degli account di sicurezza.
   • In caso contrario, inviare al client un messaggio di accesso negato.

Elaborazione delle richieste di autenticazione basata su Kerberos sui trust fra foreste

Quando due foreste sono connesse da un trust tra foreste, le richieste di autenticazione effettuate usando i protocolli Kerberos V5 o NTLM possono essere instradate tra foreste per fornire l'accesso alle risorse in entrambe le foreste.

Quando viene stabilito per la prima volta un trust tra foreste, ogni foresta raccoglie tutti gli spazi dei nomi di cui si fida nella foresta partner e memorizza queste informazioni in un oggetto di dominio attendibile . Gli spazi dei nomi attendibili includono nomi di albero di dominio, suffissi UPN (User Principal Name), suffissi SPN (Service Principal Name) e spazi dei nomi identificativi di sicurezza (SID) usati nell'altra foresta. Gli oggetti TDO vengono replicati nel catalogo globale.

Nota

I suffissi UPN alternativi nei trust non sono supportati. Se un dominio locale usa lo stesso suffisso UPN di Domain Services, l'accesso deve usare sAMAccountName.

Prima che i protocolli di autenticazione possano seguire il percorso di trust tra foreste, il nome dell'entità servizio (SPN) del computer delle risorse della rete deve essere risolto in un nodo nell'altra foresta. Un nome SPN può essere uno dei nomi seguenti:

• Nome DNS di un host.
• Nome DNS di un dominio.
• Nome distinto di un oggetto di punto di connessione a un servizio.

Quando una workstation in una foresta tenta di accedere ai dati su un computer di risorsa in un'altra foresta, il processo di autenticazione Kerberos contatta il controller di dominio per un ticket di servizio al SPN del computer di risorsa. Dopo che il controller di dominio esegue una query sul catalogo globale e determina che l'SPN non si trova nella stessa foresta del controller di dominio, il controller di dominio fornisce un rinvio per il relativo dominio padre alla workstation. A questo punto, la workstation esegue una query sul dominio padre per il ticket di servizio e continua a seguire la catena di segnalazioni fino a raggiungere il dominio in cui si trova la risorsa.

Il diagramma e i passaggi seguenti forniscono una descrizione dettagliata del processo di autenticazione Kerberos usato quando i computer che eseguono Windows tentano di accedere alle risorse da un computer che si trova in un'altra foresta.

1. User1 accede a Workstation1 usando le credenziali del dominio di europe.tailspintoys.com. L'utente tenta quindi di accedere a una risorsa condivisa in FileServer1 che si trova nella foresta usa.wingtiptoys.com.

2. Workstation1 contatta il KDC Kerberos in un controller di dominio nel suo dominio, ChildDC1, e richiede un ticket di servizio per l'SPN FileServer1.

3. ChildDC1 non trova l'SPN nel database di dominio ed esegue una query sul catalogo globale per verificare se qualcuno dei domini nella foresta tailspintoys.com contenga questo SPN. Poiché un catalogo globale è limitato alla propria foresta, l'SPN non viene trovato.

   Il catalogo globale controlla quindi il database per informazioni su eventuali trust forestali stabiliti con la propria foresta. Se trovato, confronta i suffissi dei nomi elencati nell'oggetto TDO (Trust Trusted Domain Object) della foresta con il suffisso del nome SPN di destinazione per trovare una corrispondenza. Una volta trovata una corrispondenza, il catalogo globale fornisce un'indicazione di inoltro a ChildDC1.

   Gli hint di routing consentono di indirizzare le richieste di autenticazione verso la foresta di destinazione. Gli hint vengono usati solo quando tutti i canali di autenticazione tradizionali, ad esempio il controller di dominio locale e quindi il catalogo globale, non riescono a individuare un nome SPN.

4. ChildDC1 invia un riferimento per il dominio padre a Workstation1.

5. Workstation1 contatta un controller di dominio in ForestRootDC1 (il suo dominio padre) per una segnalazione a un controller di dominio (ForestRootDC2) nel dominio radice della foresta di wingtiptoys.com.

6. Workstation1 contatta ForestRootDC2 nella foresta di wingtiptoys.com per un ticket di servizio al servizio richiesto.

7. ForestRootDC2 contatta il relativo catalogo globale per trovare il nome SPN e il catalogo globale trova una corrispondenza per il nome SPN e lo invia a ForestRootDC2.

8. ForestRootDC2 invia quindi il riferimento a usa.wingtiptoys.com a Workstation1.

9. Workstation1 contatta il KDC su ChildDC2 e negozia il ticket per User1 per ottenere l'accesso a FileServer1.

10. Una volta Workstation1 ha un ticket di servizio, invia il ticket di servizio a FileServer1, che legge User1le credenziali di sicurezza e costruisce di conseguenza un token di accesso.

Oggetto dominio attendibile

Un oggetto TDO (Trusted Domain Object) archiviato nel contenitore System all'interno del dominio rappresenta ogni trust di dominio o foresta all'interno di un'organizzazione.

Contenuti TDO

Le informazioni contenute in un TDO variano a seconda che il TDO sia stato creato da un trust del dominio o da un trust della foresta.

Quando viene creato un trust di dominio, gli attributi come il nome di dominio DNS, il SID di dominio, il tipo di trust, la transitività trust e il nome di dominio reciproco sono rappresentati nel TDO. Gli Oggetti di Dominio Transitivo di Trust tra Foreste archiviano attributi aggiuntivi per identificare tutti i namespace attendibili nella foresta partner. Questi attributi includono nomi di albero di dominio, suffissi UPN (User Principal Name), suffissi SPN (Service Principal Name) e namespace SID (Security ID).

Poiché i trust vengono archiviati in Active Directory come TDO, tutti i domini in una foresta hanno una conoscenza delle relazioni di trust presenti in tutta la foresta. Analogamente, quando due o più foreste vengono unite insieme tramite trust tra foreste, i domini radice della foresta in ogni foresta sono a conoscenza delle relazioni di trust in atto in tutti i domini nelle foreste attendibili.

Modifiche della password TDO

Entrambi i domini in una relazione di trust condividono una password, archiviata nell'oggetto TDO in Active Directory. Nell'ambito del processo di manutenzione dell'account, ogni 30 giorni il controller di dominio attendibile modifica la password archiviata nel TDO. Poiché tutti i trust bidirezionali sono in realtà due trust unidirezionali al contrario, il processo si verifica due volte per i trust bidirezionali.

Un fondo fiduciario ha un lato fiduciante e uno fiduciario. Sul lato attendibile, qualsiasi controller di dominio scrivibile può essere usato per il processo. Dal lato affidabile della rete, l'emulatore PDC esegue la modifica della password.

Per modificare una password, i controller di dominio completano il processo seguente:

1. L'emulatore del controller di dominio primario (PDC) nel dominio trusting crea una nuova password. Un controller di dominio nel dominio attendibile non avvia mai la modifica della password. Viene sempre avviato dall'emulatore PDC del dominio attendibile.

2. L'emulatore PDC nel dominio attendibile imposta il campo OldPassword dell'oggetto TDO nel campo attuale NewPassword.

3. L'emulatore PDC nel dominio attendibile imposta il campo NewPassword dell'oggetto TDO sulla nuova password. Mantenere una copia della password precedente consente di ripristinare la vecchia password se il controller di dominio nel dominio attendibile non riesce a ricevere la modifica o se la modifica non viene replicata prima che venga effettuata una richiesta che usa la nuova password di trust.

4. L'emulatore PDC nel dominio che si fida effettua una chiamata remota a un controller di dominio nel dominio di fiducia, chiedendogli di impostare la password dell'account di attendibilità come nuova password.

5. Il controller di dominio nel dominio attendibile modifica la password di attendibilità nella nuova password.

6. Da ciascun lato del rapporto di trust, gli aggiornamenti vengono replicati agli altri controller di dominio. Nel dominio attendibile, la modifica attiva una replica urgente dell'oggetto dominio attendibile.

La password viene ora modificata in entrambi i controller di dominio. La replica normale distribuisce gli oggetti TDO agli altri controller di dominio nel dominio. Tuttavia, è possibile che il controller di dominio nel dominio attendibile modifichi la password senza aggiornare correttamente un controller di dominio nel dominio attendibile. Questo scenario può verificarsi perché non è stato possibile stabilire un canale protetto, necessario per elaborare la modifica della password. È anche possibile che il controller di dominio nel dominio attendibile non sia disponibile in un determinato momento durante il processo e che non riceva la password aggiornata.

Per gestire le situazioni in cui la modifica della password non viene comunicata correttamente, il controller di dominio nel dominio attendibile non modifica mai la nuova password a meno che non sia stata autenticata correttamente (configurare un canale protetto) usando la nuova password. Questo comportamento è il motivo per cui le password precedenti e nuove vengono mantenute nell'oggetto TDO del dominio attendibile.

Una modifica della password non viene finalizzata fino a quando l'autenticazione con la password non ha successo. La vecchia password archiviata può essere usata sul canale protetto fino a quando il controller di dominio nel dominio attendibile non riceve la nuova password, consentendo così un servizio ininterrotto.

Se l'autenticazione con la nuova password non riesce perché la password non è valida, il controller di dominio attendibile tenta di eseguire l'autenticazione usando la vecchia password. Se esegue correttamente l'autenticazione con la vecchia password, riprende il processo di modifica della password entro 15 minuti.

Gli aggiornamenti delle password di attendibilità devono essere replicati sui controller di dominio di entrambi i lati del trust entro 30 giorni. Se la password di trust viene modificata dopo 30 giorni e un controller di dominio ha solo la password N-2, non può usare l'attendibilità dal lato attendibile e non può creare un canale sicuro sul lato attendibile.

Porte di rete usate dai trust

Poiché i trust devono essere distribuiti in diversi limiti di rete, potrebbero dover estendersi su uno o più firewall. In questo caso, è possibile eseguire il tunneling del traffico di trust attraverso un firewall o aprire porte specifiche nel firewall per consentire il passaggio del traffico.

Importante

I Servizi di dominio Active Directory non supportano la restrizione del traffico RPC di Active Directory a porte specifiche.

Leggere la sezione Windows Server 2008 e versioni successive dell'articolo del supporto tecnico Microsoft Come configurare un firewall per i domini e i trust di Active Directory per informazioni sulle porte necessarie per un trust tra foreste.

Servizi e strumenti di supporto

Per supportare trust e autenticazione, vengono usate alcune funzionalità aggiuntive e strumenti di gestione.

Accesso rete

Il servizio Net Logon mantiene un canale protetto da un computer basato su Windows a un controller di dominio. Viene usato anche nei processi correlati all'attendibilità seguenti:

• Configurazione e gestione delle attendibilità: Net Logon consente di mantenere le password d'attendibilità, raccogliere informazioni sulle attendibilità e verificare le attendibilità interagendo con il processo LSA e il TDO.

  Per i trust tra foreste, le informazioni sull'attendibilità includono il record delle Informazioni di attendibilità della foresta (FTInfo), il quale include l'insieme di namespace che una foresta considerata attendibile dichiara di gestire, accompagnato da un campo che indica se ogni dichiarazione è considerata attendibile dalla foresta affidante.

• Autenticazione: fornisce le credenziali utente su un canale protetto a un controller di dominio e restituisce i SID di dominio e i diritti utente per l'utente.

• Posizione del controller di dominio: consente di trovare o individuare controller di dominio in un dominio o tra domini.

• Convalida pass-through: le credenziali degli utenti in altri domini vengono elaborate da Net Logon. Quando un dominio attendibile deve verificare l'identità di un utente, passa le credenziali dell'utente tramite Accesso rete al dominio attendibile per la verifica.

• Verifica del certificato dell'attributo dei privilegi : quando un server che usa il protocollo Kerberos per l'autenticazione deve verificare il pac in un ticket di servizio, invia il pac attraverso il canale sicuro al controller di dominio per la verifica.

Autorità di sicurezza locale

L'Autorità di sicurezza locale (LSA) è un sottosistema protetto che gestisce informazioni su tutti gli aspetti della sicurezza locale in un sistema. Collettivamente noto come criteri di sicurezza locali, l'Autorità di Sicurezza Locale (LSA) fornisce vari servizi per la conversione tra nomi e identificatori.

Il sottosistema di sicurezza LSA fornisce servizi sia in modalità kernel che in modalità utente per convalidare l'accesso agli oggetti, controllare i privilegi utente e generare messaggi di controllo. LSA è responsabile della verifica della validità di tutti i ticket di sessione presentati dai servizi in domini attendibili o non attendibili.

Strumenti di gestione

Gli amministratori possono usare domini e trust di Active Directory, netdom e nltest per esporre, creare, rimuovere o modificare trust.

• I domini e i trust di Active Directory è la Microsoft Management Console (MMC) che viene usata per amministrare i trust di dominio, i livelli di funzionalità del dominio e della foresta, e i suffissi dei nomi dell'entità utente.
• È possibile usare gli strumenti da riga di comando Netdom e Nltest per trovare, visualizzare, creare e gestire i trust. Questi strumenti comunicano direttamente con l'autorità LSA in un controller di dominio.

Passaggi successivi

Per iniziare a creare un dominio gestito con una relazione di trust tra foreste, vedere Creare e configurare un dominio gestito dei Servizi di Domain. È quindi possibile Creare un trust tra foreste in uscita a un dominio locale.