AD-Adressen im Sekretariat bearbeiten lassen

Active Directory ist in vielen Unternehmen die zentrale Adressdatenbank für alle Mitarbeiterinnen und Mitarbeiter – vor allem, wenn Exchange eingesetzt wird. Dadurch tritt aber schnell ein Rollenkonflikt auf: Änderungsrechte im AD hat meist nur die IT-Abteilung. Die Pflege der internen Adressdaten ist aber in den meisten Firmen eigentlich eine Aufgabe der Personalabteilung oder des Sekretariats.

Kein Problem – schließlich kennt Active Directory ein sehr umfassendes Berechtigungskonzept. Schnell den zuständigen Mitarbeitern die nötigen Rechte gegeben, und schon ist der Admin die lästige Adresspflege los.

Kein Problem? Doch. Denn ganz so einfach ist es meist nicht. Zunächst einmal müssen die nötigen Berechtigungen überhaupt identifiziert werden. Dann muss man sie zuweisen. Und schließlich benötigt die Personalabteilung, das Sekretariat oder wer eben zuständig sein soll, eine passende Eingabemöglichkeit zur Pflege der Daten. Gut, also frisch ans Werk!

Schritt 1: Datenfelder identifizieren

Die eigentliche Identifikation, welche Daten denn bearbeitet werden sollen, kann nur innerhalb der jeweiligen Firma vorgenommen werden, idealerweise von den Personen selbst, die die Daten pflegen müssen (bzw. die die Verantwortung dafür tragen). Die Zuordnung, welche Felder bzw. Attribute in Active Directory dahinter stehen, geschieht dann wiederum durch die IT-Abteilung. Es gibt eine ganze Reihe von Übersichten, welche Einträge in den Verwaltungsprogrammen oder in Outlook von Active Directory mit welchen Namen angesprochen werden. Hier eine Auswahl:

[faq-o-matic.net » Active Directory: LDAP-Feldnamen]
http://www.faq-o-matic.net/2002/09/21/active-directory-ldap-feldnamen/

[MSXFAQ.DE – AD LDAPFelder]
http://www.msxfaq.de/code/adfelder.htm

[SelfADSI : Attribute für ADS User]
http://www.selfadsi.de/attadus.htm

Schritt 2: Berechtigungen setzen

Berechtigungen sollten in Active Directory möglichst sparsam gesetzt werden: Jeder Berechtigungseintrag wird in der AD-Datenbank gespeichert und mit ihr repliziert. Unnötige Einträge verursachen also unnötige Last. Umgekehrt sollten Berechtigungen natürlich möglichst gezielt erteilt werden nach dem Prinzip „Least Privilege“ – also nur das erlauben, was wirklich benötigt wird.

In Produktionsumgebungen hat es sich bewährt, AD-Berechtigungen mit dem Kommandozeilenwerkzeug dsacls.exe zu setzen. Dies kann per Skript geschehen – was den unschätzbaren Vorteil birgt, dass das Skript gleichzeitig eine hervorragende Dokumentation ist. Zudem kann so ein Skript zunächst in einem Testlabor entwickelt und geprüft werden, bevor man dann die fertige Fassung auf das Produktionsnetzwerk loslässt – das geht mit grafischen Tools natürlich nicht.

dsacls.exe ist in Windows Server 2008 enthalten. In älteren Windows-Versionen kann es mit den Support Tools nachgerüstet werden. Ein Ausschnitt aus einem dsacls-Skript, das gezielt Berechtigungen auf der Attributebene erteilt, folgt hier:

@echo off
set OURoot="OU=Vertrieb,OU=Benutzer,DC=ad2008,DC=faq-o-matic,DC=net"
set GROUP=AD2008\Adressbearbeitung
set PERM=RPWP 

dsacls %OURoot% /I:S /G %GROUP%:%PERM%;displayName;user
dsacls %OURoot% /I:S /G %GROUP%:%PERM%;givenName;user
dsacls %OURoot% /I:S /G %GROUP%:%PERM%;sn;user
dsacls %OURoot% /I:S /G %GROUP%:%PERM%;telephoneNumber;user

Zunächst definiert das Skript drei Variablen, damit der folgende Aufbau möglichst flexibel bleibt. Die erste ist die Basis-OU: Meist sollen Berechtigungen für alle Objekte unterhalb eines bestimmten AD-Astes erteilt werden – hier ist das die OU „Benutzer/Vertrieb“ in der eigenen Domäne. Als zweites wird die Gruppe definiert, die die Berechtigungen erhalten soll (hier: Adressbearbeitung). Als drittes folgt dann ein Kürzel für die Berechtigung, die erteilt werden soll: RPWP steht für „Read Property, Write Property“, also Lese- und Schreibrechte für ein einzelnes Attribut. Durch diese Vordefinition lässt sich das Skript später leicht anpassen.

Die eigentlichen dsacls-Kommandos erfolgen dann einzeln für jedes Attribut und nutzen die vorher definierten Variablen. Als erstes erwartet dsacls die Angabe des Objekts, das zu bearbeiten ist (hier in der Variablen %OURoot% abgelegt, also konkret die OU „Benutzer/Vertrieb“). Danach steht mit dem Parameter /I die Angabe der Vererbung; „S“ steht für „Subobjects“, die Berechtigungen werden also nur auf untergeordnete Objekte vergeben, nicht aber auf die OU selbst. Mit /G gibt man dann die zu erteilende (G für „grant“) Berechtigung als vierteiligen String an: Zuerst die zu berechtigende Gruppe (Variable %GROUP%), nach einem Doppelpunkt folgt dann in drei Teilen die Berechtigung. Das erste Element ist der Berechtigungscode, der hier über die zuvor definierte Variable %PERM% definiert ist. Nach einem Semikolon steht das Objekt oder Attribut, für das die Berechtigung gilt – hier also der LDAP-Name des jeweiligen Attributs. Nach dem letzten Semikolon steht noch, für welche Objektklasse dies anzuwenden ist: uns geht es nur um Benutzerobjekte. Diese letzte Angabe ist optional.

Die dsacls-Syntax ist sehr umfassend und stark gewöhnungsbedürftig. Daher sollte man seine Skripts in einer separaten Laborumgebung gut testen. Praktischerweise kennt dsacls auch einen Schalter, mit dem man alle Berechtigungen für einen AD-Zweig wieder auf den Installationsstandard zurücksetzen kann:

dsacls "OU=Vertrieb,OU=Benutzer,DC=ad2008,DC=faq-o-matic,DC=net" /S

Schritt 3: Adressen bearbeiten

Bleibt die Frage: Wie kann die Personalchefin oder der Praktikant im Sekretariat denn die Adressen nun bearbeiten? Dafür gibt es mehrere Möglichkeiten. Eine davon ist das AD-Verwaltungsprogramm: Man könnte dem Benutzer eine angepasste MMC-Konsole geben, die das Snap-in „Active Directory-Benutzer und -Computer“ enthält und auf die gewünschte OU-Ebene fokussiert ist. Das Snap-in lässt tatsächlich nur die Bearbeitung der Felder zu, für die der angemeldete Benutzer Berechtigungen hat. Andere Felder sind (größtenteils) ausgegraut. Nachteil: Es sind eben nicht alle Felder inaktiv, die der Benutzer nicht bearbeiten darf – bei manchen kann er zunächst einen Eintrag machen und bekommt erst nach dem „OK“-Klick die Fehlermeldung, dass der Zugriff verweigert wurde. Außerdem lassen sich die Registerkarten der MMC nicht sinnvoll anpassen – die Datenfelder sind also auf mehrere Karten verteilt, und ganz nebenbei kann der Bearbeiter auch Dinge sehen, die ihn eigentlich nichts angehen (z.B. Gruppenmitgliedschaften oder Konto-Optionen).

Eine sinnvolle Lösung besteht in einem angepassten Skript, das dem Bearbeiter nur die Felder und Inhalte zeigt, die in seiner Situation von Interesse sind. Einen Prototyp eines solchen Skripts stellen wir hier zur Verfügung. Es gewährt Zugriff auf einige wichtige Adressfelder und ist leicht erweiterbar oder auch um zusätzliche Logik und Funktionen zu ergänzen – beispielsweise eine Logging-Funktion, die alle Änderungen aufzeichnet, um Fehler leichter beheben zu können.

Bedienung

Nach dem Aufruf der Datei „faq-o-matic.net-Adressbearbeitung.hta“ öffnet sich ein Fenster mit einem Eingabefeld. Hier kann man einen gesuchten Namen eingeben (bzw. einen Teil davon) und dann auf „Benutzer finden“ klicken (Tastaturkürzel: Alt-F; bitte nicht Return drücken). Das Skript präsentiert dann die gefundenen Objekte; das passende wählt man mit dem Button „Benutzer auswählen“ aus.

Nun zeigt das Skript die Adressdaten des gewählten Benutzers an und lässt die Bearbeitung zu; alle geänderten Felder werden gelb hinterlegt. Ein Klick auf „Änderungen speichern“ schreibt die bearbeiteten Daten zurück ins Active Directory (natürlich nur, wenn der ausführende Benutzer dies darf).

Erweiterung

Das Skript ist bewusst nur als Prototyp aufgebaut. Es ist aber recht leicht zu erweitern:

• Zusätzliche Felder (Attribute) zum Anzeigen und Bearbeiten kann man im Skriptcode einfach hinterlegen. Dazu öffnet man die HTA-Datei mit einem Texteditor. Alle anzuzeigenden Felder sind als Array mit zwei Dimensionen angegeben. Beispiel:
  arrFeld(6, 0) = „streetAddress“
  arrFeld(6, 1) = „Straße“
  Die erste Angabe (0 in der zweiten Array-Dimension) ist der LDAP-Feldname des Attributs. Die zweite Angabe (1 in der zweiten Array-Dimension) ist der Text, der in der Benutzermaske angezeigt werden soll.
  Auf diese Weise kann man zusätzliche Felder recht simpel hinzufügen – einfach erst den LDAP-Feldnamen, dann die Bezeichnung. Zweierlei ist zu beachten:
  1. Die erste Array-Dimension gibt die Reihenfolge in der Maske vor (im Original von 0 (Anzeigename) bis 11 (Fax)); für eine andere Reihenfolge kann man die Nummerierung einfach ändern.
  2. Wenn man zusätzliche Felder hinzufügt, muss die Gesamtzahl im Skript geändert werden. Dazu folgende Zeile bearbeiten:
  Dim arrFeld(11,1)
  Hier die erste Zahl ändern, sodass sie 1 geringer ist als die Zahl der Felder (bei 23 Feldern also „Dim arrFeld(22,1)“).
• Weitere Funktionen zu ergänzen, setzt natürlich etwas Scripting-Erfahrung und Beschäftigung mit dem Code voraus. Denkbar ist z.B. eine Protokollierung aller Änderungen (dürfte z.B. in der Prozedur „speichereDaten()“ leicht einzubauen sein) oder auch eine Plausibilitätsprüfung für einzelne Felder.

Hier ist der Download des Skripts:

  AD-Adressbearbeitung (12,1 KiB, 10.596-mal heruntergeladen, letzte Änderung am 25. Juni 2008)