Kapitel 19 Namenskonventionen für Active-Directory-Objekte

Ein im Vorfeld sorgfältig geplantes, einheitliches Schema der Namenskonventionen für alle Objekte der Active-Directory-Gesamtstruktur ist unerlässlich, um Wildwuchs zu vermeiden und die langfristigen Kosten der Verwaltung niedrig zu halten. An dieses Namenskonzept müssen sich später alle Administratoren unbedingt halten.

19.1 Generelles zu Namenskonventionen im Active Directory 

Wie wichtig mittel- und langfristig ein sauber durchdachtes Namenskonzept für Active-Directory-Objekte ist, wissen IT-Profis, die viel Erfahrung mit Netzwerk-Migrationen und Serverkonsolidierungen haben. Die konzeptionelle Problematik eines Namenskonzeptes ist dabei vergleichbar der Problematik einer relationalen Datenbank, die aus wenigen großen Tabellen oder vielen kleineren Tabellen mit einer entsprechenden Zahl von Primärschlüsseln und Sekundärschlüsseln bestehen. Wurde die Datenbank-Hierarchie blauäugig erstellt, so lässt sie sich später entweder gar nicht oder nur mit großem Aufwand anpassen oder erweitern.

19.1.1 Distinguished Name, Relative Distinguished Name, User Principal Name, Full Qualified Name und NetBIOS Name 

Bei der Namensvergabe in einer Active-Directory-Gesamtstruktur sind zuerst technische Beschränkungen zu beachten. Definierte Namen (Distinguished Names, DN) müssen eindeutig sein. Innerhalb einer Domäne können definierte Namen für Objekte wie Benutzerkennungen, Computernamen, Namen für Sicherheitsgruppen etc. nur einmal vergeben werden. Auch wenn zwei dieser Objekte in unterschiedlichen Organisationseinheiten (OUs) liegen, können sie nicht denselben Namen haben. Neben dem definierten Namen gibt es den relativ definierten Namen (Relative Distinguished Name, RDN) und den User Principal Name (UPN), der mehr schlecht als recht mit »benutzerfreundlicher Name« ins Deutsche übersetzt wird. Der RDN eines Benutzers besteht aus dem Vornamen und dem Nachnamen. Sein UPN kann z.B. nur der Nachname sein oder sich aus einer Kombination aus Nachnamen und dem ersten Buchstaben des Vornamens zusammensetzen. Besteht eine Gesamtstruktur aus mehreren Domänen, so bedeutet das aber auch im Umkehrschluss, dass die Benutzerkennung Meier mehrfach vorkommen darf, so lange sie in einer Subdomäne nicht mehrfach vorkommt.

Ein Beispiel soll den Unterschied zwischen DN, RDN und UPN veranschaulichen: Der Benutzer Hans Meier ist Mitglied der OU Buchhaltung in der Domäne company.com. Sein DN lautet:

/DC=COM /DC=company /OU=Buchhaltung /CN=Benutzer /CN=Hans Meier

Der RDN des Benutzers Hans Meier lautet Hans Meier.

Der UPN könnte Meier oder MeierH oder Hans.Meier lauten, aber auch ganz anders, z.B. Benutzer123.

Neben dem definierten Namen, dem relativ definierten Namen und dem User Principal Name gibt es aber auch noch den Full Qualified Name (FQN), einen Begriff, der nicht aus dem Microsoft Active Directory, sondern aus der DNS-Welt stammt und sich aus dem UPN und der Domänenzugehörigkeit zusammensetzt. Hans Meier könnte z.B. den FQN meier@company.com oder meierh@company.com haben.

Um die Verwirrung vollständig zu machen, muss auch noch erwähnt werden, dass Computer, Drucker und Gruppen einen NetBIOS-Namen haben. Ein NetBIOS-Name ist eine eindeutige 16-Byte-Adresse, die für die Bezeichnung einer NetBIOS-Ressource in einem Netzwerk verwendet wird. NetBIOS-Namen werden für die Namensauflösung von WINS benötigt. Wenn Sie z.B. den Befehl ping W003 oder den Befehl nslookup S1 eingeben, so muss der DNS-Dienst zusammen mit dem WINS-Dienst den Namen W003 oder S1 eindeutig einer Netzwerkressource zuordnen können. Die WINS-Datenbank bzw. der DNS-Server liefert dazu den Full Qualified Name. Erst dann ist die IP-Adresse der Netzwerkressource bekannt. Der NetBIOS-Name einer Netzwerkressource darf maximal 15 Zeichen haben und ist in der Regel identisch mit dem UPN.

Besteht eine Active-Directory-Gesamtstruktur aus mehreren Subdomänen, so kann es den RDN meierh nun mehrmals in der Gesamtstruktur geben, solange es pro Subdomäne nur einmal den RDN meierh gibt. Die beiden Kennungen meier@xxx.company.com und meier@yyy.company.com haben zwar denselben RDN meierh, sie unterscheiden sich aber sowohl im DN als auch im FQN. Dasselbe gilt für andere Objekte wie Computer-, Server- oder Gruppennamen. Nur innerhalb einer Domäne kann es keine gleichnamigen Benutzerkennungen, Computer- oder Gruppennamen geben.

19.1.2 Auf Umlaute und Sonderzeichen verzichten 

Aus Gründen der Abwärtskompatibilität zu alten Anwendungen und Diensten kann es sinnvoll sein, bei bestimmten Objekttypen keine Namen mit mehr als acht Zeichen zu verwenden und Umlaute, Sonderzeichen und Leerzeichen etc. zu vermeiden. Auch in Hinblick auf den immer wichtiger werdenden Geschäftskontakt mit dem Ausland kann so argumentiert werden. In international operierenden Unternehmen verbieten sich Sonderzeichen in Active-Directory-Objektnamen geradezu, da es z.B. auf einer englischen Tastatur keine Umlaute (ü, ö, ä) und kein »ß« gibt. Aufgrund eines anderen Zeichenvorrats ist nicht einmal sichergestellt, dass ein Name wie Ulrich Schlüter oder René Weißkohl auf einem PC mit US-amerikanischem Betriebssystem richtig angezeigt wird. Da Namen von Servern, Workstations oder Druckern sowie von Sicherheitsgruppen in Batch-Routinen, Skripten, Icon-Verknüpfungen etc. vorkommen können, kann es auch diesbezüglich sinnvoll sein, sich auf eine bestimmte Anzahl von Zeichen zu beschränken und Sonderzeichen nicht zuzulassen. Lange Namen sind fehleranfälliger (Tippfehler), ohne deswegen aussagefähiger sein zu müssen.

Außerdem gibt es bei jedem Active-Directory-Objekt die Möglichkeit, ein Beschreibungsfeld auszufüllen. Folglich muss z.B. der Name eines Servers nicht den exakten Standort (z.B. Zentrale Aachen, 2. Obergeschoss, Raum 202) oder die Funktionen dieses Servers beinhalten (z.B. Domänencontroller, Dateiserver, Exchange Server). Diese Informationen können auch in der Beschreibung untergebracht werden. Dort können sie auch problemlos geändert werden, wenn ein Server eine weitere Funktion übernimmt oder eine Funktion an einen anderen Server übergibt. Es ist jedoch aufwendig und problematisch, wenn nicht unmöglich, den Namen eines Servers umzubenennen, nur weil sein Standort sich ändert oder der Server mit der Zeit andere oder weitere Funktionen übernimmt.