Active Directory

Utilisation de réception-toutes les sous-réseaux dans Active Directory

John Policelli

À une vue d'ensemble :

• Du localisateur de contrôleur de domaine
• La topologie hub and spoke
• L'implémentation d'un sous-réseau catch-tous

Contenu

Comment clients rechercher les contrôleurs de domaine
Le problème
Le sous-réseau de réception-tout
Conclusion

Dans un monde idéal, les utilisateurs sont dirigés vers le contrôleur de domaine approprié pour l'authentification Active Directory. Toutefois, ce n'est pas nécessairement le cas dans la plupart des organisations en raison d'informations de sous-réseau IP n'est pas correctement défini dans Active Directory. Par conséquent, un nombre d'utilisateurs s'authentifier sur un contrôleur de domaine arbitraire, qui n'est pas optimal pour l'authentification Active Directory.

Dans cet article, je fournir une solution potentielle pour garantir les utilisateurs localiser le contrôleur de domaine approprié pour l'authentification lors de la informations sous-réseau IP ne sont pas entièrement définies dans Active Directory.

Comment clients rechercher les contrôleurs de domaine

Lorsqu'un ordinateur tente de trouver un contrôleur de domaine, un processus appelé du localisateur de contrôleur de domaine (Locator) est lancé pour le contrôleur de domaine Active Directory approprié être situé. Localisateur utilise les informations qui sont stockée dans Active Directory et DNS pour tenter de trouver un contrôleur de domaine avec les rôles souhaités et qui se trouve dans un site le plus proche du client.

Le localisateur utilise les informations qui sont définies dans le conteneur Configuration le domaine racine de forêt, qui est répliqué sur chaque contrôleur de domaine de la forêt. Objets de site, les objets de sous-réseau et objets du serveur contrôleur de domaine sont tout impératives du localisateur trouver le contrôleur de domaine le plus proche pour un ordinateur client. Objets de site sont utilisés pour représenter les sites Active Directory. Objets de sous-réseau sont utilisés pour représenter les segments d'adresse IP et sont associés à l'objet de site approprié. Objets du serveur contrôleur de domaine sont utilisés pour représenter les contrôleurs de domaine et sont associés à un objet de site.

Les contrôleurs de domaine Active Directory inscrivent des enregistrements DNS qui spécifient le site dans lequel réside le contrôleur de domaine. Le nombre d'enregistrements DNS que chaque contrôleur de domaine inscrit dépend des rôles que le contrôleur de domaine. Par exemple, un contrôleur de domaine qui est un serveur de catalogue global s'enregistrer un enregistrement DNS supplémentaire qui publie lui-même en tant que tel. De même, un contrôleur de domaine qui détient un rôle de maître d'opérations s'inscrire un enregistrement DNS qui publie lui-même en tant que cela.

Le processus d'un ordinateur client localiser un contrôleur de domaine est comme suit :

1. Le localisateur est lancé sur l'ordinateur client en tant qu'un appel de procédure distante (RPC) au service d'ouverture de session réseau local.
2. Le client recueille les informations qui sont nécessaire pour sélectionner un contrôleur de domaine et transmet les informations sur le service d'ouverture de session réseau.
3. Le service d'ouverture de session réseau sur l'ordinateur client utilise les informations collectées pour créer une requête pour envoyer à DNS pour identifier le contrôleur de domaine approprié.
4. Le service d'ouverture de session réseau sur l'ordinateur client envoie un datagramme aux contrôleurs de domaine découvert.
5. Le service d'annuaire intercepte la requête et le transmet au service d'ouverture de session réseau sur le contrôleur de domaine.
6. Le service d'ouverture de session réseau sur le contrôleur de domaine recherche l'adresse IP client dans sa table de mappage sous-réseau à site en recherchant l'objet de sous-réseau qui correspond le mieux à cette adresse IP du client et le renvoie puis les informations suivantes pour le client : le nom d'un le site où se trouve le client ou le site qui correspond le mieux à l'adresse IP du client, le nom du site dans lequel le contrôleur de domaine actif se trouve ; et un bit qui indique si le contrôleur de domaine trouvé se trouve dans le site le plus proche du client.
7. Le client recherche les informations pour déterminer si elle doit tenter de trouver un contrôleur de domaine mieux. La décision est prise comme suit : si le contrôleur de domaine renvoyé est dans le site le plus proche, le client utilise ce contrôleur de domaine si le client a trouvé un contrôleur de domaine dans le site dans lequel le contrôleur de domaine prétend le client se trouve, le client utilise ce contrôleur de domaine ; si le contrôleur de domaine se trouve pas dans le site le plus proche, le client met à jour ses informations de site et envoie une nouvelle requête DNS pour rechercher un nouveau contrôleur de domaine dans le site. Si la deuxième requête est réussie, le nouveau contrôleur de domaine est utilisé. Si la deuxième requête échoue, le contrôleur de domaine d'origine est utilisée.
8. Si le domaine qui est interrogé par le client est le même que le domaine auquel est joint l'ordinateur, le site dans lequel se trouve l'ordinateur est stocké dans le Registre sur l'ordinateur client.
9. Une fois que le client a localisé un contrôleur de domaine, l'entrée du contrôleur de domaine est mis en cache. Si le contrôleur de domaine n'est pas dans le site optimal, le client vide le cache après quinze minutes et ignore l'entrée de cache. Elle tente ensuite de trouver un contrôleur de domaine optimal dans le même site que le client.

Dans le cas où un ordinateur client utilise une adresse IP qui n'est pas représentée dans la table de sous-réseau à site mappage, le contrôleur de domaine renvoie un nom de site NULL et le client utilise le contrôleur de domaine renvoyé, qui peut se trouver dans n'importe quel site Active Directory.

Le problème

Si le contrôleur de domaine ne peut pas déterminer le site le plus proche, en raison pour les informations de sous-réseau IP n'est pas définis dans Active Directory, authentification puis utilise un contrôleur de domaine qui n'est pas optimal.

la figure 1 illustre une conception de site Active Directory exemple qui utilise une topologie hub and spoke. Les utilisateurs qui ouvrent une session à partir d'un ordinateur qui est sur un des sous-réseaux sont définis dans Active Directory sont dirigés vers un contrôleur de domaine leur site Active Directory le plus proche pour l'authentification. Toutefois, les utilisateurs qui ouvrent une session à partir d'un ordinateur qui est sur n'importe quel autre sous-réseau, par exemple 10.1.4.0/24, sont dirigés vers un contrôleur de domaine arbitraire.

Figure 1 site de topologie concentrateur et spoke de modèles de conception

Le correctif approprié pour résoudre ce problème, bien sûr, est pour définir les sous-réseaux supplémentaires dans Active Directory et les associer le site approprié. Toutefois, les organisations (particulièrement moyennes et grandes entreprises) souvent des problèmes face obtenir les informations nécessaire d'ajouter ces autres sous-réseaux à Active Directory. Plus précisément, administrateurs Active Directory généralement être conscient de l'existence des sous-réseaux supplémentaires via les erreurs et les fichiers journaux, mais ne savez pas quel office physique ces sous-réseaux appartient à, les empêchant d'identifier le site à associer au sous-réseau avec.

Le sous-réseau de réception-tout

Une solution plus pratique pour le problème consiste à utiliser un ou plusieurs sous-réseaux catch-tout dans Active Directory. Un sous-réseau catch-tout est un sous-réseau Active Directory qui est utilisé pour intercepter l'authentification de clients qui sont sur des sous-réseaux, qui n'est pas définis dans Active Directory. Un sous-réseau catch-tout est essentiellement un super-subnet.

Comme le montre la figure 1 , le sous-réseau 10.1.1.0/24 est défini dans Active Directory et associé au site Toronto Active Directory. Imaginons que vous constatez qu'un nombre de clients sur les sous-réseaux 10.1.4.0/24 et 10.1.5.0/24 s'authentifient par rapport à Active Directory. Vous pensez que ces sous-réseaux êtes au bureau Toronto selon le préfixe (10.1.x.x). Vous voulez vous assurer que les ordinateurs sur ces sous-réseaux, ainsi que d'autres sous-réseaux qui utilisent le préfixe 10.1.x.x, s'authentifier par rapport à un contrôleur de domaine dans le site Toronto. Ainsi, vous créez un sous-réseau catch-tout, qui utilise le préfixe 10.1.0.0/16, pour diriger authentification à partir de tous les sous-réseaux que vous pensez à être situé dans le bureau Toronto, et vous vous assurer de que l'authentification utilise un contrôleur de domaine dans le site Toronto. Le mappage du sous-réseau catch-tout pour cet exemple montre comment apparaît en texte en rouge dans la figure 2 .

La figure 2 à l'aide d'un sous-réseau catch-tous les sites de concentrateur

Dans la plupart des organisations, informations de sous-réseau IP pour les bureaux à distance sont communiquées aux administrateurs Active Directory. Il existe généralement l'intervalle pour sous-réseaux IP pour central bureaux, emplacements de concentrateur et centres de données. Le sous-réseau catch-tout peut servir à améliorer l'authentification dans ces cas ainsi. Puisque les sous-réseaux IP pour les bureaux distants sont relativement statiques et vous devez généralement une bonne maîtrise sur ces sous-réseaux, vous pouvez créer un sous-réseau catch-tout pour tous les autres sous-réseaux.

Dans cet exemple, vous pouvez créer un sous-réseau catch-tout, qui utilise le préfixe 10.0.0.0/8, pour intercepter l'authentification à partir de tous les sous-réseaux que vous pensez ne pas appartenir à un bureau à distance et garantir l'authentification utilise un contrôleur de domaine dans le site Toronto central. Le mappage du sous-réseau catch-tout pour cet exemple montre comment apparaît en texte en rouge dans la figure 3 . Et vous pouvez même utiliser plusieurs catch-tous les sous-réseaux, comme illustré à la figure 4 , si vous le souhaitez.

La figure 3 un sous-réseau catch-tout pour tous les emplacements

La figure 4 de l'aide de plusieurs sous-réseaux catch-tout

Notez dans la figure 3 et 4 que les sous-réseaux catch-tout utilisent un préfixe qui chevauche les préfixes utilisés dans les sites distants (10.0.0.0/8 couvre 10.1.1.0/24 par exemple). Vous vous demandez peut-être si l'authentification d'ordinateurs dans les bureaux à distance est toujours dirigée vers un contrôleur de domaine dans le Bureau à distance approprié en conséquence. La réponse est Oui. Lorsque sous-réseaux IP qui se chevauchent existe dans Active Directory, le sous-réseau IP au masque de sous-réseau correspondant plus petite est utilisé. Par exemple, 10.1.1.0/24 servira au lieu de 10.0.0.0/8 si l'ordinateur possède une adresse IP de sous-réseau 10.1.1.5/24. Toutefois, 10.1.1.1./32 servira au lieu de 10.1.1.0/24 pour un ordinateur qui possède une adresse IP de 10.1.1.5.

Conclusion

Avant de continuer et mettre en œuvre catch-tous les sous-réseaux, vous devez être conscient que le concept d'un sous-réseau catch-tout n'est pas adapté à tous les environnements. La faisabilité d'une telle solution varie considérablement selon votre modèle d'adresses IP.

Dans les exemples, que j'ai fourni ici, le modèle d'adressage IP est relativement simple. Cependant, que le modèle d'adressage IP devient plus complexe, la faisabilité de l'utilisation catch-tous les sous-réseaux est moins probable que. Par exemple, si votre environnement se compose de plusieurs segments de réseau et que votre modèle d'adresses IP n'est pas séquentielle dans chaque emplacement, il est impossible pratiquement créer catch-tous les sous-réseaux qui fournira n'importe quelle valeur. Comme avec toutes les solutions, vous devez prendre en compte la technique, Entreprise et facteurs environnementaux spécifiques à votre environnement lorsque vous déterminez la viabilité de l'implémentation catch-tous les sous-réseaux.

Et notez que l'utilisation de catch-tous les sous-réseaux ne résout pas le problème des manquantes sous-réseaux entièrement. En fait, si vous introduisez catch-tous les sous-réseaux dans votre environnement, il est encore plus important que vous définissez explicitement tous les sous-réseaux connus dans Active Directory.

L'utilisation de catch-tous les sous-réseaux va augmenter le nombre d'utilisateurs que trouver le contrôleur de domaine le plus proche. Cependant, votre objectif doit être toujours pour adresse de la source du problème et vérifier que les informations appropriées pour tous les ajouts, modifications et suppressions de sous-réseaux réseau s'affichent donc vous pouvez conserver une conception de site Active Directory à jour qui fournit authentification efficace pour tous les utilisateurs.

John Policelli (MVP Microsoft pour les services d'annuaire, MCTS, MCSA, ITSM, iNet +, Network + et A +) est consultant informatique but de solutions avec une décennie de réussite combiné dans architecture, sécurité, planification stratégique et la planification de la récupération après incident. Jean a passé les neuf dernières années concentrées sur la gestion des identités et des accès et fournissant pensé direction pour certains des installations plus grandes d'Active Directory au Canada. Jean conserve un blog à http://policelli.com/blog.