Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

 << zurück
Integrationshandbuch Microsoft-Netzwerk von Ulrich Schlüter
Windows Server 2003 R2, SBS 2003, ADS, Exchange Server, Windows XP und Microsoft Office
Buch: Integrationshandbuch Microsoft-Netzwerk

Integrationshandbuch Microsoft-Netzwerk
1.008 S., mit CD, 69,90 Euro
Galileo Computing
ISBN 3-89842-847-8

>>Jetzt bestellen!
gp Kapitel 19 Namenskonventionen für Active-Directory-Objekte
  gp 19.1 Generelles zu Namenskonventionen im Active Directory
    gp 19.1.1 Distinguished Name, Relative Distinguished Name, User Principal Name, Full Qualified Name und NetBIOS Name
    gp 19.1.2 Auf Umlaute und Sonderzeichen verzichten
  gp 19.2 Namenskonvention für Anmeldenamen und E–Mail-Adressen
    gp 19.2.1 Üblicherweise genutzte Konventionen
    gp 19.2.2 Anonyme Anmeldekennungen verwenden
    gp 19.2.3 Anonyme E–Mail-Adressen oder Sammel-E–Mail-Adressen verwenden
  gp 19.3 Namenskonvention für Servernamen
  gp 19.4 Namenskonvention für Workstations
  gp 19.5 Namenskonvention für Drucker
  gp 19.6 Namenskonvention für Organisationseinheiten (OUs)
  gp 19.7 Namenskonventionen für persönliche Basisordner, Gruppenverzeichnisse und servergespeicherte Benutzerprofile
  gp 19.8 E–Mail-Verteilerlisten, Ressourcen und externe Kontakte

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.


Galileo Computing

19.1 Generelles zu Namenskonventionen im Active Directory  downtop

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.


Galileo Computing

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

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.


Galileo Computing

19.1.2 Auf Umlaute und Sonderzeichen verzichten  toptop

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.

 << zurück
  
  Zum Katalog
Zum Katalog: Integrationshandbuch Microsoft-Netzwerk
Integrationshandbuch Microsoft-Netzwerk
Jetzt bestellen!
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchtipps
Zum Katalog: Konzepte und Lösungen für Microsoft-Netzwerke






 Konzepte und Lösungen
 für Microsoft-Netzwerke


Zum Katalog: Windows Server Longhorn






 Windows Server
 Longhorn


Zum Katalog: Small Business Server 2003 R2






 Small Business
 Server 2003 R2


Zum Katalog: SharePoint Portal Server 2003 und Windows SharePoint Services






 SharePoint Portal Server
 2003 und Windows
 SharePoint Services


Zum Katalog: Exchange Server 2003 und Live Communications Server






 Exchange Server 2003
 Live Communications
 Server


Zum Katalog: Praxisbuch Netzwerk-Sicherheit






 Praxisbuch
 Netzwerk-Sicherheit


Zum Katalog: VMware und Microsoft Virtual Server






 VMware und
 Microsoft Virtual Server


Zum Katalog: VMware Server und VMware Player






 VMware Server und
 VMware Player


Zum Katalog: Citrix Presentation <br /> Server 4






 Citrix Presentation
 Server 4


Zum Katalog: ITIL






 ITIL


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo





Copyright © Galileo Press 2006
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de