AD-PowerShell

Achtung
Auch wenn mit den AD Commandlets sehr schnell und einfach Felder an AD-Objekten zu ändern sind, so sollten Sie alle Exchange Veränderungen weiterhin mit den Exchange Commandlets durchführen.

Als Alternative für eine einfache DOS-Box eignen sich DSAdd etc.

Mit Windows 2008 R2 hat Microsoft endlich auch einige PowerShell Commandlets für die Verwaltung des Active Directory mitgeliefert. Vorher war nur der Weg direkt per ADSI, LDAP oder eben mit Drittherstellerskripten (Hier namentlich Quest PowerPack für Active Directory) möglich.

Wer nun aber glaubt, dass er nur ein PowerShell Addin installieren und laden muss, sieht sich getäuscht. Es gilt ein paar Fakten zu können

  • Commandlets nur auf Windows 2008R2 oder Windows 7
    Die Installation der PowerShell-Module auf einem anderen Betriebssystem ist nicht möglich. Wer also von Windows XP, Windows 2003 oder selbst Windows 2008 RTM diese Commandlets nutzen will, kann die maximal über eine "Remote PowerShell" auf einen Windows 2008R2 Server durchführen. (Siehe auch PSRemote)
  • Backend Server
    Aber selbst wenn Sie z. B. auf einem Windows 2008R2 oder Windows 7 Client die Module installiert haben, dann arbeiten diese Commandlets nicht per LDAP direkt gegen einen beliebigen DC, sondern Sie nutzen die Active Directory Gateway Services, welche Sie per TCP ansprechen. Diese sind auf einem Windows 2008 R2 DC mit installierbar aber auch für Windows 2003 und Windows 2008 RTM verfügbar. müssen aber getrennt herunter geladen und installiert werden.

Wer also unbedingt von einem Windows XP, Windows 2003 oder Windows 2008 per PowerShell die Befehle ausführen will, kann dies nur per Remote PowerShell gegen einen Windows 2008R2 Server machen, der seinerseits gegen eine Windows DC geht, auf dem die Active Directory Gateway Services installiert sind.

Active Directory Gateway Services.

Allerdings benötigen Sie dazu mindestens einen Windows 2008 R2 Domain Controller in ihrer Domäne. Hintergrund ist, dass die PowerShell-Commandlets auf die Active Directory Web Services über Port 9389 gehen, wie in einem Netmon Mitschnitt gegen einen Windows 2003 DC gut zu sehen ist.

Dieser ist auf dem Port 9389 mal taub und lehnt die Verbindung ab. Dieser wird erst auch auf Windows 2008 und 2003 erreichbar, wenn die Active Directory Web Services installiert sind.

Active Directory Management Gateway Service (Active Directory Web Service für Windows Server 2003 and Windows Server 2008)
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=008940c6-0296-4597-be3e-1d24c1cf0dda

Für den Einsatz auf Windows 2003 SP2 ist aber noch ein Hotfix erforderlich.

  • 969429 Windows 7 clients cannot locate the Active Directory Management Gateway service that is installed on Windows Server 2003-based domain controllers
  • 969166 A hotfix rollup package für Active Directory Web Service is available für the .NET Framework 3.5 SP1

Erst dann sind auch Windows 2008 und Windows 2003 Server bereit, die Anfragen der Active Directory PowerShell Module anzunehmen. Sie sollten dann in den Diensten auch die Active Directory Web Services sehen

Der Zugriff erfolgt über Port 9389, so dass hier eventuell auch noch Firewall-Einstellungen erforderlich sind.

Installation auf Windows 2008R2

Hier ist die Funktion einfach über die Funktion "Windows Features" nach zu installieren und dann in der PowerShell einzubinden

Import-Module ServerManager
Add-WindowsFeature RSAT-AD-PowerShell

Installation auf Windows 7

Sie können aber auch auf Windows 7 Clients mit der PowerShell und den Commandlets arbeiten. Voraussetzung ist aber Windows 7 Enterprise, Professional, oder Ultimate. Auf allen anderen Versionen kann das Paket nicht installiert werden

Remote Server Administration Tools für Windows 7
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displaylang=en
64bit 221MB, 32bit 215MB

Nach der Installation können Sie dann analog zum Server die Funktion über Windows Features addieren.

Der "Installer" ist leider nur für Windows 7 RTM verfügbar und verhindert die Installation auf Windows 7 SP1. Sicher wird Microsoft bald eine aktuellere Version der RSAT-Tools bereit stellen. In der Zwischenzeit rät Microsoft dazu, das SP1 zu deinstallieren, dann die Tools zu installieren und danach wieder SP1 aufzuspielen. Ziemlich vor Arbeit und nur möglich, wenn Sie vorher Windows 7 RTM installiert und die Deinstallationsdateien nicht entfernt haben. Prinzipiell funktionieren die Commandlets ja auch auf Windows 7 SP1.

Die Installation verhindert aber nur der Installer selbst. Der Trick besteht also darin, den Installer zu umgehen, indem Sie einfach das Paket entpacken

expand -f:* "amd64fre_GRMRSATX_MSU.msu" %temp%\RSAT

Dann müssen Sie das Paket über den Paketmanager unter Angabe der XML-Datei installieren.

start / WAIT pkgmgr.exe /n:%temp%\RSAT\Windows6.1-KB958830-x64.xml

Durch den Aufruf des PKGMGR mit "Start /Wait" kommt der Befehl erst wieder, wenn der Paketmanager sich auch beendet hat. Eine Bildschirmausgabe gibt es weiter nicht. Wer die Installation ohne "Start /Wait" ausgeführt hat, sollte z.B. im Taskmanager kontrollieren, ob der Prozess pkgmgr.exe schon beendet ist.

Wenn der PKGMR sich beendet hat, dann sollten Sie die Add-ons in der Liste der Windows Features finden und installieren können.

Bedenken Sie aber, dass ein Windows 7 Desktop mit einem permanent lokal angemeldeten Administrator ein hohes Risiko darstellt. Besser ist hier dann die Ausführung mit "RunAs". Beachten Sie auch, dass "User Account Control" auch bei der PowerShell die schreibende Funktion verhindern kann.

Einbinden in PowerShell

Wenn Sie auf ihrem PC auch PowerShell 2 installiert haben, können Sie die neuen Befehle einfach mit einem Import aktivieren

Import-Module  ActiveDirectory

Danach sind die Commandlets direkt erreichbar. Vielleicht fangen Sie erst einmal mit "ungefährlichen" Commandlets an, die mit "Get-" beginnen wie.

# Ausgabe aller benutzer
Get-ADUser Administrator

#Anzeige der Gruppenmitglieder
Get-ADGroupMember administrators

Die PowerShell-Befehle sind allerdings deutlich leistungsfähiger, als allgemein angenommen.

Get-ADGroupMember administrators -recurse

Die Option "Recurse" läuft rekursiv alle Gruppen durch und listet alle Benutzer und Computer (aber keine Gruppen mehr), die Mitglied dieser Gruppe sind. Dabei werden natürlich Schleifen und redundante Einträge eliminiert.

Auch bei der "Suche" können sehr effektive Filter genutzt inklusive Rekursion genutzt werden.

Get-ADUser `
    -SearchScope Subtree ` 
    -SearchBase "dc=source,dc=net" ` 
    -Filter 'memberOf -RecursiveMatch $sourcegroup.DistinguishedName' ` 
    -Server $SourcedcName:3268 ` 
    -Properties ObjectSID,name,samAccountName,displayName,givenName,surName,telephoneNumber,mail

Auch eine Verkettung ist einfach möglich, wie eine Suche nach AdminCount zeigt (Siehe auch AdminSDHolder)

Get-ADGroup -ldapFilter "(admincount=1)" | Get-ADGroupMember -Recursive | Group-Object

Über die Angabe von Credentials können sogar andere Domänen und Forests direkt angezapft werden.

# Ausnahmeweise Benutzername und Kennwort im Skript 
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist "Admin", "Kennwort"

get-adUser -server dc2 -credential $cred

Alles in allem sind die Windows 2008 PowerShell Add-Ons für Active Directory eigentlich schon ein Pflichtprogramm bei der Installation eines Windows 2008 Servers.

Get-ADGroupMember lügt

Prüfen Sie aber immer wieder mal die Ausgabe von Dateien. Nicht alle Commandlets verhalten sich wie erwartet. Aufgefallen ist mir das bei Get-ADGroupMember, welches ich bei einem Skript mal nutzen wollte, um nur mit Mitglieder einer Gruppe zu exportieren. Das geht mit Get-ADGroupMember recht einfach und auch "-Recurse" erlaubt die Verschachtelung von Gruppen aufzulösen. In der Liste haben mir dann aber doch einige Objekte gefehlt.

Es wäre nicht aufgefallen, wenn es sich nicht gerade um Exchange gehandelt hätte. Dort nutze ich gerne eine Gruppe für die Steuerung, welche Empfänger z.B. aus dem Internet erreichbar sein sollen. Exportiere ich diese Mitglieder und deren ProxyAddresses, habe ich eine schöne Liste zur Weitergabe an einen AntiSpamdienstleiter. Da sollten dann natürlich auch alle Mitglieder der Gruppe enthalten sein.

Get-ADGroupMember liefert überhaupt keine PublicFolder. Anscheinend liefert „Get-ADGroupMember“ nur Objekte mit einer SID zurück.

Objekt Beschreibung Status

AD-Benutzer und InetOrg-Persion

Das war erwartet, dass die Objekte aufgelistet werden. Da gibt es keine Überraschungen

OK

AD-Computer

Ein Computer ist eigentlich auch nur ein Benutzer mit einem "$" im Namen und einer anderen ObjectClass

OK

AD SecurityGroups

Wenn ich nicht die Auflösung der Gruppen über "-recurse" anfordere, dann sehe ich auch die Gruppen in der Liste

OK

Distribution Groups

Das hat mich erst überrascht das eine reine "Verteilergruppe" ja nicht für eine Berechtigungsvergabe genutzt werden kann. Aber zumindest auf meiner Windows 2012R2 Testumgebung hatten auch diese Gruppen eine SID erhalten. Aber Sie erscheint nicht beim NTFS-Dialog.

OK

PublicFolder

Öffentliche Ordner mit einer Mailadresse (Mailenabled Public Folder) können sehr wohl Mitglied einer Gruppe sein. Sie werden aber nicht von Get-ADGroupMember mit ausgegeben

Fehlt

Kontakte

Auch diese Objekte sind z.B. bei Exchange als "MailContacts" legitime Absender und sollten mit Get-ADGroupMember sehr wohl gelistet werden.

Fehlt

Zur Verteidigung muss ich schon schreiben, dass Microsoft diese Einschränkung dokumentiert hat:

The Get-ADGroupMember cmdlet gets the members of an Active Directory group. Members can be users, groups, and computers.
https://docs.microsoft.com/en-us/powershell/module/addsadministration/get-adgroupmember?view=win10-ps

Allerdings bin ich sicher nicht der einzige Admin, der diesen Hinweis eben nicht so verstanden hat, das auch nur genau diese Objekte ausgegeben werden und alle anderen Objekte unterschlagen werden.

Damit stellt sich die Frage, wie ich das Thema anders angehen kann. Natürlich kann ich wieder auf die Tiefen von ADSI herunter gehen und die Gruppe per LDAP binden und die Mitglieder auflisten. Aber es geht zum Glück auch noch anders. Das Commandlet "Get-ADGroup" holt sich ebenfalls die Information über die Gruppe. Per Default wird aber das Property "Member" nicht geladen. Ich muss den Aufruf daher etwas anpassen.

(Get-ADGroup $gruppenname -Properties member).member

So holt sich das Commandlet auch die Mitglieder und gibt sie direkt aus. Ich habe auch extra eine Gruppe mit mehr als 1000 Mitgliedern erstellt, die ebenfalls ohne Probleme ausgelesen wurde. Get-ADGroup kann also auch mit "Paged Read" umgehen.

Weitere Links