Die Clienten einer Active Directory Domain können bei den Überlegungen
außen vor gelassen werden, da deren DNS-Suffix unabhängig derer
Domainzugehörigkeit ist. Die Domain, der der Rechner angeschlossen
ist, wird in der Registry vermerkt und über diesen Vermerk die
Lokalisierung der Domaindienste reguliert. Somit kann ein Client den
DNS-Suffix "`sub1.domain.tld"' haben, aber der Domäne
"`sub2.domain.tld"' angehören. Einzig die standardmäßige Verknüpfung
der Anpassung des DNS-Suffixes an die zugehörige Domain muss
deaktiviert werden. Dies ist bei den Erweiterten Namenseigenschaften
eines Clienten ein einzelnes Häkchen im System-Feld der
Systemeigenschaften, welches standardmäßig gesetzt ist und entfernt
werden muss.
Die betreffenden Systeme sind also die Domaincontroller einer Domäne,
welche in ihrem eigenen Namensraum lokalisiert werden müssen. Auf
einem Domaincontroller ist der Name der Domain fest mit dem DNS-Suffix
verbunden. Wird ein Windows Server zum Domaincontroller deklariert,
macht er als erstes einen Test, der den DNS-SRV-Record für den
LDAP-Dienst der angegebenen Domain testet. Wird dabei ein zweiter
Rechner neben seinem eigenen Namen geliefert und angegeben, dass er
eine eigene oder andere als der gefundenen Domain kontrollieren soll,
scheitert das Einrichten der Domain. Daher muss also für jede
einzurichtende AD-Domain ein eigener Namensraum geschaffen werden.
Ein weiterer zu beachtender Punkt ist der Umstand, dass Windows bei
hierarchisch gegliederter Domainstruktur automatisch auf eine
Subdomainenstruktur schließt und versucht beziehungsweise davon
ausgeht, dass eine Vertrauensstellung besteht. Sollte also eine
zentrale Baumstruktur angedacht werden, die etwa an der Wurzel
"`ad.tu-chemnitz.de"' lautet, wird bei einer Domain
"`sub.ad.tu-chemnitz.de"' automatisch von einer Subdomain ausgegangen.
Dabei ist Subdomain nicht nur im Sinne von DNS gemeint, sondern im
Sinne von Active Directory.
Solange keine Notwendigkeit von äquivalenten Software Ressource
Records im zentralen DNS dagegen sprechen, kann eine AD-Domain auch im
selben Namensraum liegen wie andere Unix-Dienste oder Rechner ohne
Domaincontrollerfunktionalität. So ist etwa eine zentrale Domäne mit
dem Namen "`tu-chemnitz.de"' denkbar, verursacht aber die stete
Annahme aller anderen Domänen als Subdomänen. Somit könnte eine
Domain names "`ad.tu-chemnitz.de"' oder "`windows.tu-chemnitz.de"'
eine günstige Lösung darstellen, unterhalb derer eine
Subdomainenstruktur auf Windows-Basis wachsen kann. Grundsätzlich
bietet sich zum Beispiel die Übernahme der Struktureinheitenstruktur
als Namenskonvention an, so dass eine Fakultät eine Domain mit dem
Namen "`fakultaet.tu-chemnitz.de"' betreiben kann, ein Lehrstuhl der
Fakultät "`lehrstuhl.fakultaet.tu-chemnitz.de"'. Auch beim Aufbau
einer solchen Struktur ist mit den Randbedingungen zu arbeiten, die
hier bereits erwähnt wurden und noch folgen.
Ein sinnvoller Ansatz der Namensraumgestaltung, der sowohl eine
einheitliche Baumstruktur als auch Insellösungen unterstützt, wäre die
Schaffung eines oben bereits angesprochenen Namensraumes für
Windowsdomänen "`ad.tu-chemnitz.de"', unter dem ein Subdomänenbaum mit
"`fakultaet.ad.tu-chemnitz.de"' und "`lehrstuhl.fakultaet.ad.tu-chemnitz.de"'
sowie den damit verbundenen Vertrauensstellungen, aber auch
Einschränkungen, aufspannt. Inseln könnten dann beispielsweise zur
Kennzeichnung als Windowsdomainen in einem Raum namens
"'ad.lehrstuhl.fakultaet.tu-chemnitz.de"' stehen.
Der Namensraum gibt Randbedingungen für das DNS vor, so dass darauf in
der Folge eingegangen werden soll.