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


Galileo Computing

19.2 Namenskonvention für Anmeldenamen und EMail-Adressen  downtop


Galileo Computing

19.2.1 Üblicherweise genutzte Konventionen  downtop

Eine Konvention für einen Anmeldenamen, der aus dem Nachnamen und dem Vornamen gebildet wird und maximal 13 Stellen lang sein soll, würde zu folgenden umständlichen Anmeldenamen führen:


Schlüter, Ulrich schlueterulri
Floren, Karl-Heinz florenkarlhei
Lütke Volksbeck, Martina luetkevolsbec
Müller-Lüdenscheid, Christoph muellerlueden
van Wamelen, Joop wamelenvanjoo

Einprägsamer und mit geringerem Risiko von Tippfehlern behaftet wäre folgende Namenskonvention für Benutzerkennungen:

gp  Anmeldenamen bestehen aus höchstens zehn Buchstaben. Umlaute und Sonderzeichen werden nicht verwendet.
gp  Anmeldenamen werden aus dem Nachnamen gebildet, wobei Titel und Zusätze wie »van«, »von«, »zu« etc. wegfallen.
gp  Bei Namensgleichheit von Nachnamen (Ulrich Schlüter und Ute Schlüter) kann die erste Kennung schlueter, die zweite Kennung schlueteru heißen, also aus bis zu 9 Stellen des Nachnamens und einer Stelle des Vornamens gebildet werden. Durchnummerierungen (schlueter1, schlueter2) sollten vermieden werden, damit sich niemand »degradiert« fühlt. Gibt es mehr als zwei Mitarbeiter mit identischem Vor- und Zunamen (z.B. dreimal den Namen »Ulrich Schlüter«), so heißt die erste Kennung schlueter, die zweite Kennung schlueteru, die dritte Kennung muss in Abstimmung mit dem Anwender gebildet werden (z.B. schluetu, schluetr oder dann auch schlueter3).
gp  Die E–Mail-Adresse wird aus Vornamen und Nachnamen gebildet: z.B. ulrich.schlueter@company.com
gp  Bei Zusätzen wie »van«, »von« oder »zu« wird dem Anwender ein Vorschlag unterbreitet: joop.wamelen@company.com oder joop.van.wamelen@company.com oder wamelen@company.com. Im Zweifelsfall soll der Anwender selbst entscheiden dürfen, wie er nach außen (d.  h. im E–Mail-Verkehr) benannt sein möchte. Bei Namensgleichheit (z.B. zwei Mitarbeiter namens Hans Meier) muss in Absprache mit dem Anwender eine akzeptable Lösung gefunden werden (z.B. hans.meier@company.com für den ersten und h.meier@company.com oder meierh@company.com für den zweiten Anwender). Gleichzeitig muss jedoch geprüft werden, ob beim Versenden von Mails die automatische Namensauflösung zu Konflikten führt. Diese müssen dann durch Umbenennung gelöst werden.
gp  Im Adressbuch von Exchange müssen die Namen in der Form »Nachname, Vorname« oder »Nachname – Vorname« auftauchen. Bei Namensgleichheit kann durch einen Zusatz, z.B. Meier, Hans (Aachen) oder Meier, Hans (Ort, Abteilung), Eindeutigkeit herbeigeführt werden.

Galileo Computing

19.2.2 Anonyme Anmeldekennungen verwenden  downtop

Die oben aufgeführten, oft genutzten Konventionen für Anmeldenamen haben jedoch einige gravierende Nachteile:

gp  Geht der Nachname in die Anmeldekennung ein, so gibt es keine Eindeutigkeit, wenn ein Nachname mehrmals auftaucht.
gp  Ändert sich der Nachname wegen Heirat oder Scheidung, so muss die Kennung umbenannt werden. Die Umbenennung einer Benutzerkennung ist im Snap-In Active Directory-Benutzer und –Computer zwar möglich, doch wird dabei weder das Profilverzeichnis des Benutzers auf dem Server (serverbasiertes Benutzerprofil) noch das lokale auf dem Client unter C:\Dokumente und Einstellungen umbenannt, und auch das Basisverzeichnis (Home Directory) auf dem Server hat nach der Umbenennung immer noch den alten Namen. Wurde in speziellen Skripten die Kennung fest verdrahtet, so tauchen auch dort Probleme auf. Gravierender sind aber oft die Probleme, die sich in anderen Anwendungen ergeben, z.B. dann, wenn die Anmeldekennung redundant in Datenbankanwendungen von Drittanbietern genutzt wird, z.B. in SAP oder Sage KHK.
gp  Oft wird der Fehler begangen, einzelnen Benutzerkennungen Zugriffsberechtigungen auf Ressourcen wie Serververzeichnisse, Personaldaten, Kundendaten usw. zu vergeben. Übernimmt ein anderer oder neu eingestellter Mitarbeiter nun diesen Aufgabenbereich, so müssen alle Berechtigungen für die neue Benutzerkennung manuell eingerichtet werden. Wurde die Kennung des ehemaligen Sachbearbeiters auch noch für die Anmeldung in Datenbanken von Drittprodukten verwendet, so müssen in diesen Datenbanken nun ebenfalls eine neue Kennung angelegt und passende Berechtigungen vergeben werden.
gp  Beschäftigt ein Unternehmen regelmäßig Praktikanten, Auszubildende, Zeitarbeiter oder externe Projektmitarbeiter, so ist die Einrichtung von Benutzerkennungen und das spätere Löschen der Kennungen sehr aufwendig, wenn derartige Kennungen den Nachnamen eines Mitarbeiters enthalten.

Als sinnvolle Alternative bietet es sich an, anonymisierte Anmeldekennungen zu verwenden und diese Kennungen bezüglich der Berechtigungen an bestimmte Stellen zu binden. So wären z.B. folgende Lösungen denkbar:

gp  User001 bis User999 oder noch einfacher 001 bis 999
gp  Benutzer001 bis Benutzer999
gp  Einkauf001 bis Einkauf999, Verkauf001 bis Verkauf999 usw., d.  h. Kennungen, in die der Name der Abteilung einfließt.
gp  Die Durchwahlen der Telefonanlage als Benutzerkennungen, wenn es sicher ist, dass der jetzige Nummernkreis der Telefonanlage sich nicht ändern wird, wenn das Unternehmen wächst oder die Telefonanlage irgendwann ausgetauscht werden muss.
gp  Die Raumnummern mit einer angehängten fortlaufenden Nummer, wenn es ein klares Gebäudeleitsystem gibt. Die Kennung 312 – 03 ist damit einem Benutzer zugeordnet, der in Raum 312 arbeitet. Diese Lösung ist jedoch schon wieder problematisch, wenn eine Abteilung in einen anderen Raum oder ein anderes Gebäude umzieht.

Derartige anonymisierte Anmeldekennungen haben Vorteile. Ändert sich der Nachname des Benutzers, so muss nicht die Kennung geändert werden, sondern lediglich der Anzeigename oder die Bemerkung und bezüglich der E–Mail-Adresse eventuell die SMTP-Hauptadresse. Wenn z.B. die Kennung User442 eindeutig einer bestimmten Sachbearbeiterstelle im Personalwesen zugeordnet ist und diese Kennung bestimmte Zugriffsrechte auf Gruppenverzeichnisse und Netzwerkdrucker der Personalabteilung hat und wenn diese Kennung ebenso als Anmeldekennung im Modul Personalwesen der kaufmännischen Anwendung genutzt wird, so ist der Aufwand sehr gering, wenn es zu einem Stellenwechsel kommt. Verlässt ein Mitarbeiter das Unternehmen und übernimmt ein neu eingestellter Mitarbeiter dessen Stelle, so arbeitet dieser Mitarbeiter unter derselben Kennung und mit demselben Exchange-Postfach weiter, wobei bezüglich der E–Mail-Adresse überlegt werden muss, ob die SMTP-Hauptadresse den Namen des Mitarbeiters enthalten oder ebenso anonymisiert sein soll.


Galileo Computing

19.2.3 Anonyme EMail-Adressen oder Sammel-EMail-Adressen verwenden  toptop

Bezüglich der E–Mail-Postfächer sind weitere Überlegungen notwendig. Sicherlich ist es sinnvoll, dass jeder Mitarbeiter des Unternehmens jeden anderen Mitarbeiter per E–Mail erreichen und auch auf die öffentlichen Ordner des Exchange Server zugreifen kann, wenn diese intensiv genutzt werden. Doch muss hinterfragt werden, welche Mitarbeiter darüber hinaus die Möglichkeit erhalten sollen, mit externen Stellen und Adressaten per E–Mail zu kommunizieren, und ob bei diesen Mitarbeitern als Absenderadresse eine persönliche SMTP-Adresse verwendet werden soll, die den Namen des Mitarbeiters enthält, oder aber eine anonymisierte Adresse. Bedenken Sie, welche Kosten einzusparen wären und wie drastisch die Risiken von Viren, Spam und Hackerangriffen reduziert werden könnten, wenn nur ausgewählte Mitarbeiter eine eigene Mail-Adresse erhielten. Welcher Mitarbeiter würde noch private E–Mails während der Arbeitszeit verfassen, wenn eine Antwort darauf nur an eine Sammeladresse wie einkauf@company.com möglich und in einem öffentlichen Exchange-Ordner für alle Mitarbeiter des Einkaufs lesbar wäre?

Technisch ist es möglich, unter Exchange Server eine Mitarbeitergruppe anzugeben, die E–Mails in das Internet verschicken oder von dort erhalten kann. Ebenso ist es möglich, z.B. alle für den Einkauf eingehenden E–Mails und Faxe unter einer Sammeladresse in einen öffentlichen Exchange-Ordner einfließen zu lassen.

 << 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