Tipps & Tricks: Anwender finden mit Get-ADUser

Mit der aktuellen R2-Version des Windows Servers 2008 ist auch eine ganze Reihe neuer und verbesserter PowerShell-Cmdlets mit auf den Server gekommen, durch die einem Administrator die tägliche Arbeit deutlich erleichtert werden kann. Aus der Sammlung diese Cmdlets stellt Mark Minasi hier mit Get-ADUser ein Werkzeug vor, das ganz besonders nützlich ist.

In der elf Jahren, die Windows-Administratoren nun schon mit Active Directory arbeiten, sind auf dem Markt schon eine ganze Reihe von Werkzeugen und Hilfsmittel aufgetaucht, die es ermöglichen, bestimmte Daten aus dem AD zu extrahieren. Wir haben hier auf NT4Admins auch schon einige dieser Tools vorgestellt und besprochen. Heute möchten wir Ihnen ein sehr aktuelles Werkzeug vorstellen, das sich Get-ADUser nennt und zu den PowerShell-Cmdlets gehört, die den Systemverwaltern mit Windows Server 2008 R2 ganz aktuell zur Verfügung gestellt werden. Dieses PowerShell-Cmdlet ist ein sehr mächtiges Werkzeug, weshalb unser Windows-Spezialist Mark Minasi es in diesem Bericht einmal etwas genauer beleuchtet.

Wer dieses Werkzeug nutzen will, muss dazu grundsätzlich ein Windows 7– oder ein Windows Server 2008 R2 Member Server, von denen aus er das Kommando abschickt. Weiterhin wird in der Domäne mindestens ein Domänen-Controller benötigt, der ebenfalls auf Windows Server 2008 R2 basiert, der die Kommandos empfängt und ausführt. Unser Autor hat hier mit Vorbedacht denn Begriff grundsätzlich gewählt, denn einem Administrator stehen grundsätzlich auch Mittel und Wege zur Verfügung, einen Server vor Windows 2008 R2 dazu zu bringen, dass er die entsprechenden Kommandos ausführt. Allerdings erfordert dies etwas umfangreichere Erläuterung, die Mark Minasis versprochen in einem späteren Artikel nachzuliefern.

Wer damit anfangen möchte, User-Objekte in seinem AD mittels des Cmdlets zu finden, muss dazu zunächst einmal ein PowerShell-Fenster öffnen und das AD-Modul importieren. Dazu muss er import-module activedirectory oder die Kurzform dieses Befehls ipmo ac* ausführen (Bild 1). Ein TechNet-Artikel in englischer Sprache bietet weitergehende Erklärungen zu diesem Thema an.

Wer schon häufiger PowerShell-Cmdlets verwendet hat, die mit Get- anfangen, wie beispielsweise get-process oder get-service wird wahrscheinlich seinen ersten Versuch mit diesem Kommando in der folgenden Form starten wollen:

get-aduser

und vermuten, dass ihm die PowerShell dann alle Nutzer in seinem AD anzeigt. Das funktioniert hier aber leider nicht so: Das Cmdlet zeigt einen Prompt an und fordert den Anwender auf, entsprechende Parameter einzugeben. Gibt dann an dieser Stelle die Zeichenfolge !? ein, so wird auch ein – allerdings sehr kurzer – Hilfetext ausgegeben.

Suchen wird mit dem Parameter -filter einfach

Der Parameter, der wohl am häufigsten bei diesem Kommando zum Einsatz kommt, lautet -filter. Mit seiner Hilfe können entsprechende Suchkriterien für den Anwendernamen eingegeben werden, nach dem der Administrator gerade fahndet. Das einfachste dieser Suchkommandos hat daher die folgende Form:

get-aduser -filter *

Damit erhält das Kommando den Befehl, alle Nutzerkonten im AD anzuzeigen (Bild 2). In diesem Zusammenhang ist eine Warnung durchaus angebracht: Wer nicht gerade auf einer sehr eingeschränkten Test-Domäne oder in einem sehr kleinen Netzwerk arbeitet, sollte dieses Kommando nicht auf seinem DC loslassen: Der Domänen-Controller könnte dadurch ansonsten schnell überlastet sein. Es ist sicherlich weitaus sinnvoller, die Suche schon vom Start weg deutlich einzuschränken. Das kann durch einen Aufruf in der folgenden Form geschehen, der alle Anwender mit dem Vornamen Mark findet:

getaduser -f {GivenName -eq ‘Mark‘}

Wird dieses Kommando in einem Netzwerk ausgeführt, in dem kein Nutzer mit dem Vornamen Mark existiert, so gibt die PowerShell einfach einen Prompt ohne weitere Meldungen aus. Auch deshalb wollen wir an dieser Stelle noch etwas genauer auf die Besonderheiten dieses Kommandos eingehen.

Den meisten Lesern wird sofort aufgefallen sein, dass wir an dieser Stelle nicht den Parameter -filter sondern an seiner Stelle einfach die Abkürzung -f verwendet haben.

Die PowerShell erlaubt es dem Anwender jeden Parameternamen beliebig abzukürzen, solange dabei keine Mehrdeutigkeiten entstehen können. Da aber der einzige Parameter des Cmdlets get-aduser, der mit dem Buchstaben „f“ beginnt, der Schalter -filter ist, können wir hier diese radikale Abkürzung unbesorgt verwenden. Hätte das Kommando beispielsweise einen zweiten Parameter mit dem Namen -finger, so wäre -fil die kürzeste Abkürzung die in diesem Fall möglich wäre und keine Zweideutigkeiten erzeugen würde.

Die nächste Frage, die bei vielen Anwendern dieses Kommandos zunächst einmal auftaucht: Was ist denn eigentlich der GivenName? Die Namen der Anwenderattribute im AD entstammen dem X.500-Standard-Schema. Wahrscheinlich hat es sich bei den Entwicklern von X.500 um europäische Fachleute gehandelt, so dass sie nicht das amerikanische FirstName sondern das englische GivenName für dieses Feld wählten. Eine Tatsache, die bei deutschen Administratoren für weitaus weniger Verwirrung sorgen sollte, als dies scheinbar bei den amerikanischen Kollegen der Fall ist. Wer bisher schon das Tool ASDI Edit (Active Directory Service Interface Editor) eingesetzt hat, der wird dies vielleicht schon wissen.

Was aber viele Systemverwalter sicher noch nicht wissen, ist die Tatsache, dass die Entwickler dieses Cmdlets die Sache noch etwas weiter getrieben haben und für einige der Attribute multiple Versionen zur Verfügung stellen. So lautet beispielsweise die X.500-Abkürzung für den Nachnamen sn – die Abkürzung für surname. Wer ein bisschen mit dem Get-ADUser Cmdlet experimentiert wird herausfinden, dass es sowohl diese Abkürzung als auch den nicht standardmäßigen Begriff surname als gültige User-Attribute akzeptiert.

So bekommt man die komplette Liste der Attribute

Nach all dieser Verwirrung ist es gut, dass es dann doch relativ leicht ist, mittels eines Aufrufes die komplette Liste aller Attribute eines bestimmten Anwenders anzeigen zu lassen:

getaduser – f {name -eq ‘Mark‘} -properties * | get-member

Dies ist ein Aufruf, der eine Übersicht über das Layout der AD-User-Objekte ausgibt, der einem Administrator zudem nützliche Anregungen und Informationen für spätere Suchanfragen zur Verfügung stellt. Es ist also durchaus sinnvoll, das Ergebnis einer solchen Suche entsprechend für die spätere Verwendung abzuspeichern.

Wer schon ein wenig mit der PowerShell gearbeitet wird, der wird sicher erraten haben, dass der Parameter -eq für „equal“ also „ist gleich“ steht. Zur Erinnerung: Ein Aufruf der Form –f {name= ‘Mark‘} funktioniert nicht! Auch der folgende Aufruf wird nicht (wie viele Anwender immer wieder vermuten) alle Anwender mit dem Anfangsbuchstaben M auf den Bildschirm bringen:

getaduser -f {GivenName -eq ‘M*‘}

Auch in diesem Fall antwortet die PowerShell einfach mit einem leeren Prompt, selbst wenn sich Anwender mit dem M als Anfangsbuchstaben in der Datenbank befinden. Eine solche „ungenaue“ Suche wird unter der PowerShell mit dem Parameter -like gestartet:

getaduser -f {GivenName -like ‘M*‘}

Abschließend noch eine Anmerkung: Wir haben in unseren Beispielen immer nach Mark mit einem großen M am Anfang gesucht, genau deshalb weisen wir in diesem Zusammenhang auch noch einmal darauf hin, dass PowerShell case-insensitive sind – sie unterscheiden nicht zwischen Groß- und Kleinschreibung.

Erfahrenere PowerShell-Anwender mögen jetzt vielleicht einwenden, dass es möglich ist dieses Verhalten durch den Operator -ceq dahingehend zu ändern, dass auch hier zwischen Groß- und Kleinbuchstaben unterschieden wird. Das ist grundsätzlich richtig, funktioniert aber nicht bei den AD-Cmdlets: Sie stellen keine Unterstützung für -ceq bereit!

Mark Minasi/ fms