Powershell macht das AD zum Laufwerk
28. Juli 2010
Ab Windows 7 und Windows Server 2008 Release 2 steht für die Verwaltung des Active Directory eine Vielzahl von Erweiterungen bereit. Spezielle Powershell-Cmdlets, 76 an der Zahl, kommen mit dem Active Directory Module for Windows PowerShell ins Spiel. Doch noch intuitiver wird die Arbeit mit dem AD, wenn der Administrator auf den Active Directory Powershell Drive Provider setzt. Sie machen aus dem AD quasi einen Datenträger – und dazu passen die „alten“ Befehle wie dir oder cd.
Die Bedeutung der Powershell für die Verwaltung von Systemen nimmt massiv zu. Diese Aussage gilt nicht nur für die Server- und Desktop-Betriebssysteme von Microsoft und die zugehörigen Server wie Exchange oder Sharepoint. Auch Produkte von Drittherstellern unterstützen diese Skripting-Umgebung, wie zum Beispiel einige Virtualisierungsplattformen.
Für den Bereich der Arbeiten am Active Directory (AD) hatte die erste Version der Powershell leider nicht sonderlich viel zu bieten. Im Grunde gab es von Microsoft nur einen „ADSI Type Accelerator“ und das war `s. Wer mehr Funktionalität benötigte, der musst auf die nativen Dotnet-Klasse zugreifen – eine echte Herausforderung für viele Administratoren. Allerdings gibt es noch Lösungen von Drittherstellern, wie zum Beispiel das AD Powershell Snap-in von Quest Software.
och mit der Vorstellung von Windows Server 2008 Release 2 (R2) und Windows 7 haben sich die Voraussetzungen massiv geändert. Microsoft hat ein AD-Modul für die Powershell und den Powershell „Drive Provider“ freigegeben – eine deutliche Funktionsverbesserung für das Zusammenspiel von AD und Powershell.
Möchte der Administrator einen Domänencontroller auf Basis von Windows Server 2008 R2 installieren, braucht er nur die Rolle der AD DS (Active Directory Domain Services) mit Hilfe des Server Managers aufspielen. Im Zuge dieser Aktion wird das AD-Powershell-Modul gleich mit installiert. In diesem Modul liegen einige neue Cmdlets, Provider, Skripts und ähnliche Objekte.
Soll dieses Modul auf einem Arbeitsplatzsystem mit Windows 7 installiert werden, muss man die Remote Server Administration Tools (RSAT, Remote Server-Verwaltungs-Tools) auf diese Workstation aufspielen. Wenn RSAT auf dem Rechner installiert ist, hat der Administrator zur Systemsteuerung zu gehen und dort die Windows-Features zu aktivieren.
Dann braucht er nur mehr nach unten bis zum RSAT-Knoten zu scrollen. Hier ist dann der der Knoten für das Active Directory Module for Windows PowerShell zu expandieren (wie es in Abbildungen 1 und 2 zu sehen ist). Diese Box muss dann angeklickt werden und mit einem OK ist das Modul hinzuzufügen.
Ist dieses Modul installiert, kann man entweder das Active Directory Module for Windows PowerShell über das Startmenü (Programme, Verwaltung) aufrufen oder aber es lässt sich aus einer bestehenden Powershell-Session hinzufügen. Dazu ist der folgende Befehl nötig:
Import-module ActiveDirectory
Nach kurzer Zeit wird der Kommando-Prompt wieder erscheinen, und danach steht die komplette Funktionalität zur Verfügung, die die Powershell nun für das AD anbietet.
Doch ehe es an den weiteren Einsatz des AD Powershell Modul geht, noch ein Wort zu den Einsatzvoraussetzungen: Dieses neue Modul setzt voraus, dass man zumindest einen Domänencontroller (DC) in der Domäne hat, auf dem die ADWS (Active Directory Web Services) laufen. Die ADWS sind bei der Installation von Windows Server 2008 R2 auf einem DC automatisch – also standardmäßig – installiert. Doch bei DCs auf Basis von Windows Server 2003 oder Windows Server 2008 ist ein spezielles Add-On nötig: der Active Directory-Verwaltungsgatewaydienst.
Liegt in der Domäne kein ADWS-Server, dann bekommt der Administrator eine Fehlermeldung geliefert, wenn er versucht, das AD-Modul in die Powershell zu importieren. Das interessante an ADWS und den Powershell-Cmdlets ist, dass sie generell nicht LDAP (das Lightweight Directory Access Protocol) verwenden, um auf das AD zuzugreifen. Dieser Zugriff erfolgt vielmehr über XML-basierte Webservices.
Damit vollzieht Microsoft eine komplette Abkehr von früheren Werkzeugen im AD-Umfeld. Es wird sich in der Zukunft zeigen, ob Microsoft diesen weg noch mehr ausbaut. Es bleibt aber noch zu erwähnen, dass nach der Installation von ADWS auf DCs, die nicht auf Windows Server 2008 R2 basieren, der Administrator immer noch in der Lage ist, seine Server mit den üblichen LDAP-basierten Tools wie das Snap-in Active Directory Benutzer und -Computer (ADUC, Active Directory Users and Computers) zu verwalten.
Der Einsatz der Cmdlets
Nachdem die Vorbereitungen alle absolviert sind, kann der Administrator damit beginnen, die Fähigkeiten der Powershell in diesem Kontext auszuprobieren. Microsoft bietet zwei grundlegende Werkzeuge, um die Verwaltung des AD weitgehend zu automatisieren.
Beim ersten handelt es sich um einen Satz von Cmdlets, die einem fast alles im AD-Umfeld ermöglichen – vom Suchen nach AD-Objekten über das Anlegen von Computerkonten bis hin zum Ändern von Benutzerkonten. Das zweite ist ein Powershell Drive Provider für das AD. Damit ist der Administrator in der Lage, sich wie in der Struktur eines Dateisystems durch das AD zu hangeln. Diese Funktionalität erweist sich in der Realität als extrem nützlich.
Für den Einstieg in das Arbeiten mit den Cmdlets zum AD, die das AD Powershell Modul bereitstellt, kann sich der Administrator die Details anzeigen lassen. Dazu braucht er nur in der Powershell den folgenden Befehl eingeben:
get-command -module ActiveDirectory
Das wird dazu führen, dass er 76 Namen von Cmdlets aus dem AD-Modul geliefert bekommt. Dabei tauchen selbsterklärende Cmdlets auf, wie etwa Get-ADGroupMember (es liefert die Mitglieder von Gruppen) oder New-ADComputer (damit kann man Computer einer Domäne hinzufügen).
Angenommen der Administrator möchte schnell eine Liste bekommen, die Mitglieder der Gruppe „Marketing Users“ ausgibt, dann hilft ihm das folgende Cmdlet:
Get-ADGroupMember -identity "Marketing Users"
Der Parameter identity wird generell bei allen AD-Cmdlets al seine Methodik verwendet, um eine Referenz auf ein bestimmtes Objekt im AD zu bekommen. Diese Parameter darf dabei verschiedene Formen haben – entweder ein DN (Distinguished Name wie DC=cpandl,DC=com), eine Objekt-GUID, eine SID (Security Identifier) oder ein samAccountName.
Eine weitere sehr mächtige Funktion bildet das Weiterleiten der Ausgabe eines Cmdlets als Eingabe für ein weiteres Cmdlet – über eine so genannte Pipe. Angenommen der Administrator möchte erst ein Benutzer-Objekt im AD finden und es danach deaktivieren. Dabei laute der Benutzernamen kmyer (das ist ein samAccountName). Dann lässt sich die gewünschte Aufgabe mit den folgenden zwei Cmdlets abwickeln:
Get-ADUser -identity kmyer | Set-ADUser -enabled $false
Hier liefert das Cmdlet Get-ADUser das Benutzerkonto mit dem Namen kmyer. Ist es gefunden, wird über die Pipe dieses Objekt an das Cmdlet Set-ADUser gegeben zusammen mit dem Parameter -enabled und dazu das Powershell-Flag $false. Damit wird angewiesen, dass das Konto deaktiviert werden soll.
Dieses einfache Beispiel zeigt schon recht deutlich, wie mächtig und einfach zugleich die AD-Cmdlets der Powershell arbeiten. Da 76 Cmdlets in diesem Modul enthalten sind, kann man sich gut vorstellen, dass man weitaus mehr mit dieser Technik anstellen kann. Ein wichtiges Konzept ist aber auch der Einsatz des Active Directory Powershell Drive.
Der Active Directory Powershell Drive Provider
Die Powershell unterstützt das Konzept, bei dem Ressourcen verwaltet werden als wären sie Laufwerke mit Datenträgern. Wie man in ein Verzeichnis im Dateisystem mit Hilfe von cd wechseln kann, so kann man auch mit Hilfe der Powershell Drives durch die AD-Ressourcen navigieren.
Zum Beispiel hat Microsoft bereits in der Version 1 der Powershell ein Powershell Drive für die Registry eingeführt. Damit konnte man die Registry-Schlüssel und Werte wie Verzeichnisse und Dateien ansprechen. Das Ändern der Verzeichnisse in der Powershell auf HKEY_LOCAL_MACHINE lässt sich damit machen, dann ist das Navigieren durch die Schlüssel möglich, ebenso lassen sich neue Schlüssel oder Werte hinzufügen oder alte entfernen – ganz so wie man das von einem Dateisystem her gewöhnt ist.
Um diese Funktionalität einsetzen zu können, muss der Administrator die Powershell (mit geladenen AD-Modul) öffnen und dann eingeben:
cd AD:
Damit wird auch der Laufwerks-Prompt geändert. Das soll zeigen, von welchem neuen Laufwerk aus man arbeitet. Gibt der Administrator dann noch ein DIR ein, bekommt er eine Liste mit allen Partitionen innerhalb der aktuellen Gesamtstruktur.
Angenommen er möchte in die AD-Domäne navigieren und dort eine neue OU (Organizational Unit, Organisationseinheit) anlegen, dann ist von der obersten AD-Ebene der folgende Befehl einzugeben (wobei man für seine eigene Umgebung die Werte für DC=cpandl,DC=com entsprechend anpassen muss):
cd “DC=cpandl,DC=com”
Hier soll nun die neue OU namens HR unter der OU Marketing angelegt werden. Um zur Marketing-OU zu gehen, ist der folgende Befehl nötig:
cd “OU=Marketing”
und um unter dieser OU die OU HR anzulegen ist einzugeben:
md “OU=HR”
So einfach geht diese Arbeit von der Hand. In Abbildung 3 ist die Ausgabe dieser beiden Befehle zu sehen.
Vereinfachen der AD-Verwaltung
Diese einfachen Beispiele sind in der Tat nur die Spitze des Eisbergs, wenn man das AD Powershell Drive verwendet. Mit dieser Vorgehensweise lassen sich die meisten Aufgaben für das AD quasi im Rahmen des Dateisystems ausführen. Und zudem lassen sich die Powershell-Drive-Befehle auch in Skripts einsetzen, um die AD-Verwaltung weiter zu automatisieren.
