Serveur DNS

une zone DNS pour tous les

ordinateurs. Comme DNS intégré aux AD n’est disponible que sur les DC,

chaque DC exécute le service DNS afin que la résolution de chaque nom local

soit disponible sur chaque site de gestion. L’intégration de DNS aux AD a

pour avantage un travail de maintenance moindre pour la réplication

DNS.

  Nous nous sommes livrés à  plusieurs tests de performances

pour déterminer si le DNS intégré aux AD serait suffisamment rapide pour

traiter jusqu’à  20.000 entrées dans une seule zone. Les résultats ont

montré que c’était possible et que les temps de réponse restaient rapides.
Mais un problème a surgi : comment les administrateurs locaux feraient-ils

pour traiter des clients statiques (comme des serveurs UNIX ou des serveurs

Web) qui n’exécutent pas Win2K ou qui ne peuvent pas utiliser

l’enregistrement DNS dynamique ? Les administrateurs devraient ajouter

manuellement ces machines à  la zone DNS, mais le droit leur permettant
cela leur permettrait également de supprimer accidentellement une entrée.

Vous pensez peut-être que la solution évidente consiste à  donner aux

administrateurs l’autorisation Create All Chil Objects dans le snap-in MMC

DNS. C’est malheureusement faux ! En effet, le snap-in DNS utilise le

groupe DnsAdmins comme un groupe intégré ; par conséquent, il faut être

membre du groupe DnsAdmins pour pouvoir ouvrir et utiliser le snap-in DNS.

Si l’on essaie d’accorder à  un utilisateur qui n’est pas membre du groupe

DnsAdmins l’accès au snap-in DNS, il y a échec. Nous avons essayé de

restreindre le groupe DnsAdmins à  l’accès en lecture (Read) aux

informations de la zone DNS et d’utiliser les autres groupes (Domain

Admins, par exemple) pour traiter l’accès Write. Malheureusement, comme le

snap-in DNS utilise DnsAdmins comme un groupe intégré (c’est-à -dire, avec

son SID intégré unique), les membres du groupe DnsAdmins obtiennent

automatiquement des autorisations Full Control sur la feuille de propriétés

de chaque serveur DNS. Un membre du groupe DnsAdmins peut modifier les
propriétés DNS (définir des retransmetteurs ou activer la supervision,
par exemple) sur n’importe quel DC dans le domaine qui exécute DNS. Par
conséquent, cette restriction nous était impossible. Quand nous avons
signalé cette difficulté à  Microsoft, nous avons appris que ce manque de
fonctionnalité de gestion était voulu : il est impossible de donner à  un

utilisateur une autorisation Read seule sur une zone DNS dans le snap-in
DNS.

  Toutefois, comme Win2K stocke les informations de zone dans

l’AD, on peut utiliser LDAP (Lightweight Directory Access Protocol) pour

accorder des autorisations sur le conteneur et accéder directement aux
informations de la zone. Win2K stocke les informations de zone intégrée
à  l’AD dans le contexte de nom de domaine (domain-naming) à 

LDAP://cn=MicrosoftDNS,cn=System,dc=domain.
Nous envisageons de développer une application qui permettra aux

administrateurs locaux de gérer des entrées client statistiques. En

attendant, seuls les membres du groupe DNS Admins pourront ajouter ou
supprimer des entrées client statistiques.
Au moment où vous lirez cet article, il est probable que Microsoft
aura annoncé une correction pour ce problème de délégation DNS. La

correction ne sera pas présente dans Win2K Service Pack 2 (SP2), mais
vous pourrez la demander au Microsoft Product Support.