Diesen Umstand kann man sich zunutze machen, wenn man zusätzliche Informationen über alle Mitglieder einer bestimmten Gruppe benötigt. Hilfreich ist hierbei ein Client, der benutzerdefinierte Suchabfragen an Active Directory stellen kann, z.B. mein Tool Carmen.

Im ersten Schritt besorgt man sich mit Carmen den DN der Gruppe, um die es geht. Dazu eignet sich eine Abfrage mit der Ambiguous Name Resolution, etwa so:

SELECT * FROM <so lassen> WHERE anr='Anzeigename-der-Gruppe'

Wichtig sind die einfachen Anführungsstriche (Apostrophe, oben auf der #-Taste) um das Suchkriterium. In dieser Abfrage reicht auch ein Teil (= der Anfang) des Namens, z.B. "Cons" für "Consulting". Den so erhaltenen DN (ohne das "LDAP://") nutzt man nun in einer zweiten Abfrage. Diese sucht nach allen Objekten, die die betreffende Gruppe in ihrem "memberOf"-Attribut stehen haben. Von diesen Objekten lassen sich dann beliebige Felder ausgeben.

SELECT adsPath,givenName,sn
FROM 'LDAP://DC=faq-o-matic,DC=net'
WHERE memberOf='CN=Superhelden,OU=Benutzer,DC=faq-o-matic,DC=net'

Für einfachere Abfragen von Gruppenmitgliedern siehe auch unseren Artikel:

http://www.faq-o-matic.net/2004/07/30/wie-kann-ich-die-mitglieder-einer-gruppe-in-eine-datei-schreiben/

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:

So geht's:

• cipher überschreibt nur freie Datenbereiche. Zuerst müssen also alle unerwünschten Daten auf normalem Wege (z.B. Explorer) gelöscht werden.
• Dann sollte man alle Applikationen und nicht benötigten Dienste beenden, damit evtl. noch gesperrte Daten freigegeben werden.
• Nun öffnet man ein CMD-Fenster (mit einem ausreichend berechtigten Konto, der Einfachheit halber z.B. ein Adminkonto) und tippt ein:
  cipher /W:C:\
  Dabei steht C:\ für das Laufwerk, das bereinigt werden soll. Die Angabe muss natürlich angepasst werden, wobei es immer um das gesamte Laufwerk geht, auch wenn man einen Unterordner angibt.
• Der Vorgang dauert eine beträchtliche Zeitspanne, weil zunächst binäre Nullen, dann binäre Einsen und schließlich noch einmal Zufallswerte über alle (!) freien Blöcke geschrieben werden (siehe Bild).
• Das funktioniert mit Windows 2000 Server/Professional, XP Professional, Windows Server 2003, Vista Business/Enterprise/Ultimate und Windows Server 2008.

Viele Programme nutzen ANR automatisch. Dazu gehören das Outlook-Adressbuch oder auch die einfache Suchfunktion im "Name"-Feld des Verwaltungsprogramms "Active Directory-Benutzer und -Computer". Man kann ANR aber auch selbst anfordern. Hier ein Beispiel, wie man es als benutzerdefinierte Suche im eben genannten Verwaltungsprogramm nutzen kann:

Doch auch andere Programme lassen die ANR-Suche zu, beispielsweise AdFind von Joe Richards:

AdFind -b DC=faq-o-matic,DC=net -f "(anr=Nils)"

Dieses Kommando findet alle Objekte in der angegebenen Domäne, die in einem der ANR-Attribute einen Wert haben, der mit "Nils" beginnt. Dazu wird ein LDAP-Suchfilter genutzt, der das "virtuelle" Datenfeld "ANR" abfragt (hier: "anr=Nils"). Um die Suche etwa auf Benutzer einzugrenzen, kann man den Filter auch erweitern: (&(anr=Nils)(objectClass=user)(objectCategory=person)). Mehr zu LDAP-Grundlagen findet sich hier:

[faq-o-matic.net » LDAP-Grundlagen für Active Directory]
http://www.faq-o-matic.net/2008/01/13/ldap-grundlagen-fuer-active-directory/

Ebenso lässt sich ANR natürlich gut in eigenen Skripten einsetzen, um eine komfortable Objektsuche für den Benutzer zu ermöglichen. Eine ANR-Abfrage lässt sich dabei nicht nur in LDAP formulieren, sondern auch in dem SQL-Dialekt, den AD versteht. Dadurch kann man es z.B. mit meinem kleinen Suchclient "Carmen" nutzen:

[faq-o-matic.net » Carmen: Mit SQL das AD abfragen]
http://www.faq-o-matic.net/2004/10/20/carmen-mit-sql-das-ad-abfragen/

Eine SQL-Suchabfrage könnte dann so aussehen:

SELECT * FROM 'LDAP://DC=faq-o-matic,DC=net' WHERE anr='Nils'

Eine Einschränkung sollte man aber beachten: Auch wenn Active Directory für diese Sorte von Suchanfragen vorbereitet und optimiert ist, sollten Features wie ANR nur sparsam genutzt werden. Eine "unscharfe" Suche belegt natürlich mehr Ressourcen als eine genaue.

Mehr zu ANR:

[Mehrdeutige Namensauflösung für LDAP in Windows 2000]
http://support.microsoft.com/kb/243299

[Harnessing the power of Ambiguous Name Resolution (ANR)]
http://www.msexchange.org/articles/Ambiguous-Name-Resolution.html

Warum das so ist, erläutern zwei Artikel sehr schön:

[TechNet Team Blog Austria : Hotfix Installationen, Remote Desktop, Reboot - und keine Verbindung mehr]
http://blogs.technet.com/austria/archive/2008/06/09/hotfix-installationen-remote-desktop-reboot-und-keine-verbindung-mehr.aspx

[Ask the Performance Team : Hotfix Installs, Remote Desktop and the Reboot that wasn't ...]
http://blogs.technet.com/askperf/archive/2008/03/18/hotfix-installs-remote-desktop-and-the-reboot-that-wasn-t.aspx

Nach etwas Suchen fand ich die Lösung: Beim ADO-Zugriff auf Textdateien (dafür ist der Jet-Datenbanktreiber zuständig) erwartet XP, dass die Datei im ASCII-Format (bzw. ANSI) vorliegt. Ist die Datei als Unicode gespeichert, kann XP sie nicht richtig auswerten. Vista ist da offenbar toleranter. Und genau das war das Problem: Die Daten, die mein Skript unter Vista erzeugt und gelesen hatte, akzeptierte dasselbe Skript in XP nicht.

Lösung: Beim Erzeugen der Textdateien habe ich nun ausdrücklich das ASCII-/ANSI-Format erzwungen. Das geht bei der Methode CreateTextFile über den dritten Parameter, der "false" sein muss. Folgendermaßen sieht die Zeile nun in der Fassung aus, die sowohl mit Vista als auch mit XP funktioniert:

Set objExport = objFSO.CreateTextFile(strExportPfad, vbTrue, vbFalse)

Die Teilnahme ist kostenlos, aber nicht unbegrenzt: Aus allen Bewerbungen werden die tatsächlichen Teilnehmer durch die Veranstalter ausgelost und benachrichtigt. Wer Lust hat, teilzunehmen, kann sich bei Microsoft bewerben. Na dann: Mach mal blau!

Unser Autor Pegasus hat in einer Newsgroup-Diskussion eine Batch-Lösung dafür entwickelt, die sehr flexibel ist. Sie benötigt das Tool shortcut.exe von folgender Webseite:

[Optimum X Download Page]
http://www.optimumx.com/download/#Shortcut

Hier das Skript. Die Zeilennummern bitte manuell entfernen und Zeilenumbrüche korrigieren. Außerdem bitte ggf. den Ursprungspfad in Zeile 3 an die Windows-Version sowie den Speicherort von shortcut.exe anpassen.

01. @echo off
02. set Exe=wegmtal.exe
03. for /F "delims=" %%a in ('dir /b /s "c:\Documents and Settings\*.lnk"')
do call :Sub %%a
04. goto :eof
05.
06. :Sub
07. set found=false
08. for /F %%a in ('c:\Tools\shortcut.exe /f:"%*" /a:q ^| find /i "%Exe%"')
do if not "%%a"=="" set found=true
09. if %found%==true echo del "%*"

Das Skript ist zunächst im Testmodus. Wenn es korrekt die Links ausgibt, die gelöscht werden sollen, muss in Zeile 9 das "echo" gelöscht werden, um das Skript scharfzuschalten.

Bis zum 15. Juni läuft der Early Bird: Wer sich in dieser Zeit anmeldet, nimmt an der Verlosung wertvoller Preise teil - unter anderem ein Windows Server 2008!