> Tech > Couvrir les sites sans DC

Couvrir les sites sans DC

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

L'un des meilleurs moyens de simplifier et de gérer plus facilement le déploiement d'AD consiste à  réduire le nombre de DC. En effet, chaque DC ajouté à  la forêt augmente les coûts du matériel, du logiciel et d'exploitation ; sans parler de la latence de réplication et du temps de

Couvrir les sites sans DC

dépannage. Les sites
sans DC ne conviennent vraiment qu’à 
des bureaux satellites avec une bonne
connectivité réseau et un petit nombre
d’utilisateurs. D’où la question : « Pourquoi ne
pas ajouter simplement des subnets de
bureaux satellites au site du bureau
principal ? » Cette question est judicieuse
d’un point de vue AD : les
clients s’authentifieraient vis-à -vis des
DC dans le bureau principal et, comme
il n’existe pas de DC dans le bureau distant,
vous n’auriez pas de problèmes de topologie de réplication à  traiter.
Mais AD n’est pas la seule application
tributaire de la bonne définition des
sites. Par exemple, Microsoft Dfs, la
technologie sur laquelle FRS (File
Replication Service) est fondée, localise
les serveurs proches d’après les définitions
de sites AD. Si le bureau satellite
a un serveur Dfs, vous ne voudrez
certainement pas réduire un site satellite
dans le site du bureau principal.
Supposons que vous ayez une petite
agence de 30 employés reliés par
une ligne T1 fiable au bureau principal.
Il n’y a pas de raison de mettre un DC
dans l’agence parce que le réseau peut
facilement assumer le trafic d’authentification
et de consultation produit par
les 30 stations de travail. Mais une question demeure : quel DC les clients
de l’agence vont-ils utiliser pour s’authentifier
? La réponse se trouve dans la
notion de couverture de site. Les DC
publient des enregistrements SRV à  la
fois génériques et propres aux sites,
afin que les clients puissent trouver un
DC n’importe où dans le domaine ou
dans un site spécifique. Mais, par défaut,
les DC publient également des enregistrements
SRV spécifiques aux sites
pour les sites proches dépourvus de
DC. De sorte qu’un client peut utiliser
une requête DNS spécifique au site
pour trouver un DC même quand il
n’existe pas de DC dans le site du
client.
Les règles permettant de déterminer
quel DC couvrira un site sans DC sont simples. Quand chaque DC démarre,
il recherche dans sa copie d’AD
la présence éventuelle de sites sans
DC. Pour chaque site sans DC, le DC
détermine si son propre site est plus
proche du site sans DC, ce qui est déterminé
par l’information de coût de la
liaison du site dans AD. Si le site du DC
est le plus proche, le DC publie des enregistrements
SRV spécifiques au site
pour le site sans DC. Si le DC détermine
que plus d’un site partage la valeur
de coût de liaison de site la plus
basse, le DC compare le nombre des
DC dans son site au nombre des DC
dans les autres sites. Si le site du DC a
le plus de DC, le DC publie des enregistrements
SRV spécifiques au site
pour le site sans DC. Le fait que le site
ayant le plus de DC couvre le site sans
DC permet de partager la charge du
site sans DC sur un plus grand nombre
de DC. Si les sites ont le même nombre
de DC, celui qui est premier en ordre
alphabétique couvre le site sans DC.
Le fait que tous les DC dans un site
de couverture couvrent le site sans DC
présente un inconvénient. Chaque DC
dans le site de couverture publie les
enregistrements SRV pour le site sans
DC, de sorte qu’un site de couverture
avec 5 DC et 2 GC génèrera 32 enregistrements
SRV de plus (4 enregistrements
SRV spécifiques au site par DC
et 2 enregistrements de plus pour
chaque DC qui est aussi un GC). Si l’on
a une topologie « hub-and-spoke » avec
25 sites satellite sans DC connectés à 
un hub et si l’on a 25 DC et 7 GC dans
le hub, on obtiendra le chiffre énorme
de 3 550 enregistrements SRV de plus
par domaine.
Considérons maintenant que chaque
DC est occupé à  republier ses enregistrements
SRV chaque heure.
(C’est le rythme par défaut de Win2K ;
les DC republient leurs enregistrements
SRV toutes les 15 minutes dans
Windows Server 2003.) On imagine
fort bien le genre de trafic réseau que
ces enregistrements SRV de couverture
de sites vont générer. Et, si l’on a
des zones DNS intégrées à  AD, on sera confronté à  un volume significatif de
trafic de réplication supplémentaire allant
vers chaque DC du domaine. De
plus, AD stocke les enregistrements
SRV avec le même nom dans un attribut
multivaleur d’un objet AD. A cause
de limitations dans les tailles d’attribut,
les zones intégrées à  AD ne peuvent
traiter qu’environ 800 enregistrements
SRV de même nom. Une grande
agence pourrait facilement dépasser
cette limite.
Heureusement, Win2K Service
Pack 2 (SP2) et ultérieur donnent un
moyen de contrôler la couverture de
site au moyen des paramètres de registre.
Tout d’abord, vous pouvez
désactiver la couverture de site automatique
sur le DC. Pour cela, mettez la
valeur AutoSiteCoverage de la sous-clé
de registre HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet\ServicesNetlogon\Parameters à  0. Deuxièmement,
vous pouvez nommer explicitement
les sites qu’un DC couvrira.
Pour cela, donnez à  la valeur
SiteCoverage de la sous-clé HKEY_LOCAL_
MACHINE\SYSTEM\CurrentContr
olSet\Services\Netlogon\Parameters la
liste des sites à  couvrir (utilisez les
RDN (relative distinguished names)
des sites séparés par des espaces). Le
fait de définir cette valeur oblige le DC
à  publier des enregistrements SRV
pour les sites nommés, que ces derniers
contiennent ou non déjà  des DC.
Vous pouvez définir la valeur
GcSiteCoverage de la sous-clé de la
même manière pour contrôler la publication
des enregistrements de localisation
de gestion spécifiques au site.
Vous pouvez utiliser ces paramètres
pour attribuer des DC spécifiques dans
un site hub aux authentifications de
services provenant des sites satellite
sans DC. Cette façon de faire réduit le
nombre d’enregistrements SRV ajoutés
à  DNS et facilite la gestion du système. Il existe une autre manière de réduire
le nombre d’enregistrements
DNS dans votre environnement.
Chaque DC qui héberge une zone DNS
intégrée à  AD publie un enregistrement
NS (Name Server) pour le domaine.
DNS utilise cet enregistrement
pour trouver les serveurs « authoritative
name » pour la zone. S’il y a beaucoup
de DC dans votre domaine, vous
obtiendrez beaucoup d’enregistrements
DNS. Pour empêcher le service
DNS de publier son enregistrement
NS, mettez la valeur DisableNSRecords
AutoCreation de la sous-clé HKEY_LOCAL_
MACHINE\SYSTEM\CurrentContr
olSet\Services\DNS\Parameters à  1.
La désactivation de la publication
des enregistrements NS a un effet subtil.
Quand un serveur reçoit une requête
directe (par exemple, en provenance
d’un client qui liste le serveur
comme résolveur primaire), son service
DNS résout correctement les
noms dans la zone. Mais, comme il
n’existe pas d’enregistrement NS pour
le serveur, les autres serveurs DNS,
traitant des requêtes récursives, ne reconnaîtront
pas le serveur comme serveur
de nom pour le domaine et ne lui
transmettront pas les requêtes. Pour
plus d’informations sur ce processus,
voir l’article Microsoft « Problems with
Many Domain Controllers with Active
Directory Integrated DNS Zones »
(http://support.microsoft.com/?kbid=
267855).

Téléchargez cette ressource

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Villes, intercommunalités, métropoles, départements et régions sont particulièrement exposés aux risques de cybersécurité. Ce livre blanc Stormshield présente les défis cyber que rencontrent les collectivités, les solutions et perspectives pour qu’elles puissent assurer leur mission d’utilité publique, en toute sécurité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010