Funzionamento delle relazioni di trust per le foreste in Active Directory

Dominio di Active Directory 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 percorso di attendibilità viene implementato dal servizio Accesso rete tramite 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.

Per una panoramica del modo in cui si applicano i trust a Servizi di dominio, vedere Concetti e funzionalità della foresta.

Per iniziare a usare i trust in Servizi di dominio, creare un dominio gestito che usa trust tra foreste.

Flussi di relazione di trust

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

Il flusso di comunicazione sui trust è determinato dalla direzione dell'attendibilità. I trust possono essere unidirezionale o bidirezionale e possono essere transitivi o non transitivi.

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

Trust unidirezionale e bidirezionale

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 nel dominio A possono accedere alle risorse nel dominio B. Tuttavia, gli utenti nel dominio B non possono accedere alle risorse nel dominio A.

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

In un trust bidirezionale, il dominio A considera attendibile il dominio B e il dominio B considera attendibile 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 passano verso l'alto attraverso un albero di dominio durante il formato, creando trust transitivi tra tutti i domini nell'albero del dominio.

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

I trust tra foreste consentono di gestire infrastrutture di Active Directory Domain Services segmentate e di supportare 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 2 e viene creato un altro trust tra foresta 2 e Foresta 3, la foresta 1 non ha un trust implicito con Foresta 3.

Il diagramma seguente illustra due relazioni di trust tra foreste separate tra tre foreste di Active Directory Domain Services in una singola organizzazione.

Questa configurazione di esempio fornisce l'accesso seguente:

• Gli utenti nella foresta 2 possono accedere alle risorse in qualsiasi dominio nella foresta 1 o nella foresta 3
• Gli utenti nella foresta 3 possono accedere alle risorse in qualsiasi dominio nella foresta 2
• Gli utenti nella foresta 1 possono accedere alle risorse in qualsiasi dominio nella foresta 2

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

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

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

• I membri della foresta 1 possono accedere alle risorse che si trovano nella foresta 2.
• I membri della foresta 2 non possono accedere alle risorse che si trovano nella foresta 1 usando la stessa relazione di trust.

Requisiti di trust tra 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 è presente alcun server DNS radice condiviso e i server DNS radice in ogni spazio dei nomi DNS della foresta usano server d'inoltro condizionale DNS per ogni spazio dei nomi DNS per instradare le query per i nomi nell'altro spazio dei nomi.

  Importante

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

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

Per creare un trust tra foreste in Servizi di dominio Active Directory, è necessario essere un membro del gruppo Domain Amministrazione s (nel dominio radice della foresta) o del gruppo Enterprise Amministrazione s in Active Directory. A ogni trust viene assegnata una password che gli amministratori di entrambe le foreste devono conoscere. I membri di enterprise Amministrazione 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 tra foreste in uscita unidirezionale nelle foreste locali. Il trust tra foreste in uscita per Microsoft Entra Domain Services viene creato nell'interfaccia di amministrazione di Microsoft Entra. L'attendibilità della foresta in ingresso deve essere configurata da un utente con i privilegi indicati in precedenza nella Active Directory locale.

Processi di trust e interazioni

Molte transazioni tra domini e inter-foreste dipendono da trust 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 Accesso rete nei controller di dominio per le informazioni di autenticazione e autorizzazione 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 usa anche trust per i servizi di concessione ticket tra aree di autenticazione (TGS) e per convalidare i certificati degli attributi dei privilegi in un canale protetto. Il protocollo Kerberos esegue l'autenticazione tra aree di autenticazione solo con aree di autenticazione Kerberos non basate sul marchio Windows, ad esempio un'area di autenticazione KERBEROS MIT e non deve interagire con il servizio Accesso rete.

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 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 Accesso rete nei controller di dominio per informazioni sull'autenticazione client e sull'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 dell'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 basata su Kerberos delle richieste di autenticazione su trust tra 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 un trust tra foreste, ogni foresta raccoglie tutti gli spazi dei nomi attendibili nella foresta partner e archivia le informazioni in un oggetto 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 ID di sicurezza (SID) usati nell'altra foresta. Gli oggetti TDO vengono replicati nel catalogo globale.

Prima che i protocolli di autenticazione possano seguire il percorso di trust tra foreste, il nome dell'entità servizio (SPN) del computer delle risorse deve essere risolto in una posizione 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 punto di connessione del servizio.

Quando una workstation in una foresta tenta di accedere ai dati in un computer di risorse in un'altra foresta, il processo di autenticazione Kerberos contatta il controller di dominio per un ticket di servizio al nome SPN del computer risorse. Dopo che il controller di dominio esegue una query sul catalogo globale e determina che il nome SPN non si trova nella stessa foresta del controller di dominio, il controller di dominio invia una segnalazione 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 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 relativo dominio, ChildDC1 e richiede un ticket di servizio per il nome SPN FileServer1.

3. ChildDC1 non trova il nome SPN nel database di dominio e esegue una query sul catalogo globale per verificare se i domini nella foresta tailspintoys.com contengono questo NOME SPN. Poiché un catalogo globale è limitato alla propria foresta, il nome SPN non viene trovato.

   Il catalogo globale controlla quindi il database per informazioni su eventuali trust tra foreste stabilite con la relativa 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 suggerimento di routing 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 una segnalazione per il dominio padre a Workstation1.

5. Workstation1 contatta un controller di dominio in ForestRootDC1 (dominio padre) per un riferimento a un controller di dominio (ForestRootDC2) nel dominio radice della foresta del wingtiptoys.com foresta.

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

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

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

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

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

Oggetto dominio attendibile

Ogni trust tra domini o foreste all'interno di un'organizzazione è rappresentato da un oggetto TDO (Trusted Domain Object) archiviato nel contenitore system all'interno del relativo dominio.

Contenuto TDO

Le informazioni contenute in un TDO variano a seconda che un oggetto TDO sia stato creato da un trust di dominio o da un trust tra foreste.

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. I TDO di trust tra foreste archiviano attributi aggiuntivi per identificare tutti gli spazi dei nomi attendibili dalla foresta partner. Questi attributi includono nomi di albero di dominio, suffissi UPN (User Principal Name), suffissi SPN (Service Principal Name) e spazi dei nomi ID di sicurezza (SID).

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 hanno una conoscenza delle relazioni di trust applicate 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 unidirezionale in direzione opposta, il processo si verifica due volte per i trust bidirezionali.

Un trust ha un trusting e un lato attendibile. Sul lato attendibile, qualsiasi controller di dominio scrivibile può essere usato per il processo. Sul lato attendibile, 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 sul campo NewPassword corrente.

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 utilizza la nuova password di trust.

4. L'emulatore PDC nel dominio attendibile effettua una chiamata remota a un controller di dominio nel dominio attendibile chiedendo di impostare la password nell'account di attendibilità sulla nuova password.

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

6. In ogni lato dell'attendibilità, gli aggiornamenti vengono replicati negli altri controller di dominio nel 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 riesce. 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 attendibili devono essere replicati nei controller di dominio di entrambi i lati dell'attendibilità 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.

Leggere la sezione Windows Server 2008 e versioni successive dell'articolo supporto tecnico Microsoft Come configurare un firewall per domini e 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 Accesso rete gestisce 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 attendibilità: l'accesso net consente di mantenere le password di attendibilità, raccogliere informazioni di attendibilità e verificare i trust interagendo con il processo LSA e il TDO.

  Per i trust tra foreste, le informazioni di trust includono il record FTInfo (Forest Trust Information), che include il set di spazi dei nomi che una foresta attendibile deve gestire, annotata con un campo che indica se ogni attestazione è considerata attendibile dalla foresta trusting.

• 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 protezione 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, 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

Amministrazione istrator possono usare Dominio di Active Directory e trust, Netdom e Nltest per esporre, creare, rimuovere o modificare trust.

• Dominio di Active Directory e trust è Microsoft Management Console (MMC) usato per amministrare trust di dominio, livelli di funzionalità di dominio e foresta e suffissi del nome dell'entità utente.
• Gli strumenti da riga di comando Netdom e Nltest possono essere usati per trovare, visualizzare, creare e gestire trust. Questi strumenti comunicano direttamente con l'autorità LSA in un controller di dominio.

Passaggi successivi

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