Active Directory

Utilizzo tutti raccolta subnet in Active Directory

John Policelli

In un riepilogo delle:

• L'individuazione di controller di dominio
• La topologia hub e spoke
• Implementazione di una subnet tutti catch

Contenuto

Come client di individuare i controller di dominio
Il problema
La subnet tutti catch
Disposizione dei

In un mondo ideale, gli utenti vengono diretti al controller di dominio appropriato (DC) per l'autenticazione di Active Directory. Tuttavia, questo non è necessariamente il caso nella maggior parte delle organizzazioni a causa di informazioni di subnet IP non correttamente da definiti in Active Directory. Di conseguenza, un numero di utenti autenticati a un controller di dominio arbitrario, che non è ottimale per l'autenticazione di Active Directory.

In questo articolo fornire una soluzione potenziale per garantire che gli utenti individuare il controller di dominio appropriato per l'autenticazione quando non viene definite completamente le informazioni di subnet IP in Active Directory.

Come client di individuare i controller di dominio

Quando un computer tenta di individuare un controller di dominio, un processo denominato individuazione di controller di dominio (Locator) viene avviato il controller di dominio Active Directory appropriato può essere memorizzato. Individuazione utilizza le informazioni che vengono memorizzati in Active Directory e DNS per tentare di trovare un controller di dominio con ruoli desiderati e che si trova nella più vicino al client un sito.

Il Locator utilizza informazioni definito nel dominio principale dell'insieme di strutture che replicato su ogni controller di dominio nell'insieme di strutture di contenitore di configurazione. Oggetti del sito, oggetti subnet e oggetti server di controller di dominio sono tutti imperativi per Locator a trovare il controller di dominio più vicino per un computer client. Gli oggetti sito vengono utilizzati per rappresentare siti di Active Directory. Oggetti subnet vengono utilizzati per rappresentare i segmenti di indirizzo IP e sono associati all'oggetto sito appropriato. Oggetti server di controller di dominio vengono utilizzati per rappresentare i controller di dominio e associati a un oggetto del sito.

Controller di dominio Active Directory registrano i record di DNS che consentono di specificare il sito in cui risiede il controller di dominio. Il numero di record DNS che ciascun controller di dominio registra varia a seconda ruoli che è il controller di dominio. È ad esempio, un controller di dominio è un server di catalogo globale verrà registrare un record DNS aggiuntivo advertises stesso come tale. Un record di DNS advertises stesso come questo verrà registrato in modo analogo, da un controller di dominio che svolge un ruolo di master operazioni.

Il processo per un computer client individuare un controller di dominio è come indicato di seguito:

1. Il Locator viene avviato nel computer client come una chiamata di procedura remota (RPC) al servizio Accesso rete locale.
2. Il client raccoglie le informazioni che sono necessario per selezionare un controller di dominio e passa le informazioni al servizio Accesso rete.
3. Il servizio Accesso rete sul computer client utilizza le informazioni raccolte per creare una query per inviare a DNS per identificare il controller di dominio appropriato.
4. Il servizio Accesso rete sul computer client invia un datagramma nei controller di dominio individuato.
5. Il servizio directory intercetta la query e lo passa al servizio Accesso rete del controller di dominio.
6. Il servizio Accesso rete del controller di dominio cerca l'indirizzo IP client nella relativa tabella mapping subnet per sito per trovare l'oggetto subnet che corrisponde maggiormente l'indirizzo IP e client restituisce quindi le seguenti informazioni per il client: il nome del sito in cui si trova il client o il sito che corrisponde maggiormente l'indirizzo IP del client, il nome del sito in cui il controller di dominio corrente trova; e un bit indicato se il controller di dominio trovato si trova nel sito più vicino al client.
7. Il client controlla se le informazioni per determinare se deve tentare di trovare un controller di dominio migliore. La decisione viene presa come segue: se il controller di dominio restituito è nel sito più vicino, il client di utilizzo di questo controller di dominio; se il client ha trovato un controller di dominio nel sito in cui il controller di dominio dichiara il client è memorizzato, il client utilizza il controller di dominio e se il controller di dominio è non nel sito più vicino, il client aggiorna informazioni il sito e invia una nuova query DNS per trovare un controller di nuovo nel sito. Se la seconda query ha esito positivo, verrà utilizzato il nuovo controller di dominio. Se la seconda query ha esito negativo, viene utilizzato il controller di dominio originale.
8. Se il dominio in cui viene da richiesto dal client corrisponde a quello il dominio a cui il computer, il sito in cui risiede il computer viene memorizzato nel Registro di sistema sul computer client.
9. Dopo che il client di individua un controller di dominio, viene memorizzato nella cache la voce di controller di dominio. Se il controller di dominio non è nel sito ottimale, il client scarica la cache dopo quindici minuti ed elimina la voce della cache. Viene quindi eseguita la ricerca di un controller di dominio ottimale nello stesso sito del client.

Nel caso in cui un computer client utilizza un indirizzo IP rappresentato nella tabella dei mapping subnet per sito, il controller di dominio restituisce un nome di sito NULL e il client utilizza il controller di dominio restituito, che può risiedere in qualsiasi sito di Active Directory.

Il problema

Se il controller di dominio non può determinare del sito più vicino, a causa delle informazioni di subnet IP non da definiti in Active Directory, quindi l'autenticazione utilizza un controller di dominio non è quella ottimale.

Nella figura 1 è illustrata una struttura di sito Active Directory di esempio che utilizza una topologia hub e spoke. Gli utenti che accedono da un computer che si trova su una delle seguenti le subnet sono definite in Active Directory vengono diretti a un controller di dominio nel loro sito di Active Directory più vicino per l'autenticazione. Tuttavia, gli utenti che accedono da un computer in qualsiasi altra subnet, ad esempio 10.1.4.0/24 vengono diretti a un controller di dominio arbitrario.

Figura 1 esempio hub spoke topologia sito progettare

La correzione appropriata per risolvere il problema è ovviamente, consiste nel definire le subnet aggiuntive in Active Directory e associarli a un sito appropriato. Tuttavia, le organizzazioni (organizzazioni particolarmente medie e grandi dimensioni) spesso problemi faccia ottenere le informazioni è necessario per aggiungere le subnet aggiuntive in Active Directory. In particolare, gli amministratori di Active Directory in genere diventano tenere in considerazione l'esistenza di subnet aggiuntive tramite gli errori e i file di registro, ma non si sa quale ufficio fisico le subnet appartengono, impedendo che identifica il sito per associare la subnet con.

La subnet tutti catch

Una soluzione più pratica per il problema consiste nell'utilizzare uno o più subnet tutti catch in Active Directory. Una subnet tutti catch è una subnet di Active Directory viene utilizzata per rilevare l'autenticazione dai client presenti subnet che non sono definite in Active Directory. Una subnet tutti catch è essenzialmente un super-subnet.

Come illustrato nella Figura 1 , alla subnet 10.1.1.0/24 viene definita in Active Directory e associata al sito Toronto Active Directory. Ad esempio si noterà che un numero di client su subnet 10.1.4.0/24 e 10.1.5.0/24 è l'autenticazione in Active Directory. Si ritiene che le subnet presenti in ufficio Toronto in base al prefisso (10.1.x.x). Si desidera garantire che computer in questi subnet, nonché tutte le subnet che utilizzano il prefisso 10.1.x.x autenticare un DC nel sito di Toronto. Quindi si crea una subnet tutti catch, che utilizza il prefisso 10.1.0.0/16 per indirizzare l'autenticazione da tutte le subnet si ritiene che trovi in ufficio Toronto ed è verificare che l'autenticazione utilizza un controller di dominio nel sito Toronto. Il mapping di subnet tutti catch per questo esempio viene visualizzato nel testo rosso nella Figura 2 .

Nella figura 2 Utilizzo una subnet tutti catch per i siti di hub

Nella maggior parte delle organizzazioni, le informazioni di subnet IP per gli uffici remoti vengono comunicate agli amministratori di Active Directory. Il divario esiste in genere per subnet per ufficio centrale, hub ubicazioni e centri dati. La subnet tutti catch utilizzabile per migliorare l'autenticazione in questi casi. Poiché le subnet IP per gli uffici remoti sono piuttosto statiche e avere in genere una buona padronanza su questi subnet, è possibile creare una subnet tutti catch per tutte le subnet.

In questo esempio, è possibile creare una subnet tutti catch, che utilizza il prefisso 10.0.0.0/8, per rilevare l'autenticazione da tutte le subnet si ritiene che non appartengono a un ufficio remoto e verificare l'autenticazione utilizza un controller di dominio nel sito centrale Toronto. Il mapping di subnet tutti catch per questo esempio viene visualizzato nel testo rosso nella Figura 3 . Ed è possibile anche utilizzare più subnet tutti catch, come illustrato nella Figura 4 , se si desidera.

Nella figura 3 una subnet tutti catch per tutte le ubicazioni

Nella figura 4 mediante più subnet tutti catch

Si noti nella Figura 3 e 4 che le subnet tutti catch utilizzare un prefisso che si sovrappone i prefissi utilizzati in siti remoti (10.0.0.0/8 copre 10.1.1.0/24 ad esempio). Ci si potrebbe chiedere in essere che se l'autenticazione dai computer degli uffici remoti verrà comunque indirizzato a un controller di dominio in ufficio remoto appropriato di conseguenza. La risposta è Sì. Quando sovrapposte subnet presenti in Active Directory, alla subnet IP con la maschera subnet minimo corrispondente viene utilizzata. Ad esempio, verrà utilizzato 10.1.1.0/24 anziché 10.0.0.0/8 se il computer dispone di un indirizzo IP di 10.1.1.5/24 subnet. Tuttavia, verrà utilizzato 10.1.1.1./32 anziché 10.1.1.0/24 per un computer con un indirizzo IP di 10.1.1.5.

Disposizione dei

Prima di procedere e implementare tutti catch subnet, occorre tenere presente che il concetto di una subnet tutti catch non adatto a tutti gli ambienti. Fattibilità di tale una soluzione dipende notevolmente la combinazione di indirizzo IP.

Negli esempi che sono fornite qui, lo schema di indirizzamento IP è abbastanza semplice. Tuttavia, come lo schema di indirizzamento IP diventa più complesso, fattibilità dell'utilizzo di subnet tutti catch diventa meno probabile che. Ad esempio, se l'ambiente è costituito da più segmenti di rete e la combinazione di indirizzo IP non è sequenza in ciascuna posizione, sarà quasi impossibile da creare subnet tutti catch che fornirà un valore qualsiasi. Come con tutte le soluzioni da considerare i tecnici business e fattori ambientali specifiche di ambiente per determinare l'idoneità di implementazione completa catch subnet.

E annotare l'utilizzo di subnet tutti catch non risolve il problema dei mancanti completamente subnet. Infatti, se si introducono subnet tutti catch nel proprio ambiente, è ancora più importante definire in modo esplicito tutte le note subnet in Active Directory.

L'utilizzo di subnet tutti catch aumenterà il numero di utenti di individuare il controller di dominio più vicino. Tuttavia, l'obiettivo deve essere ancora per risolvere l'origine del problema e assicurare che si ricevano le informazioni appropriate per tutte le aggiunte, modifiche e rimozioni di subnet di rete in modo è possibile mantenere una struttura del sito Active Directory aggiornata che fornisce l'autenticazione efficiente per tutti gli utenti.

John Policelli (Microsoft MVP per Servizi di directory, MCTS, MCSA, ITSM, iNet +, Network + e + A) è consulente IT attivo soluzioni con su un decennio di successo combinato in architettura, protezione, pianificazione strategica e pianificazione del ripristino d'emergenza. John è dedicato negli ultimi nove anni concentrati sulla gestione delle identità e degli accessi e fornire pensato leadership per alcuni le installazioni più grandi di Active Directory in Canada. John gestisce un blog a http://policelli.com/blog.