Benutzer anderer Domänen bearbeiten – mit PowerShell
Der erfahrene AD-Admin kennt die PowerShell cmdLets „Get-ADUser“ und „Set-ADUser“ und nutzt diese für viele automatisierte Prozesse in der Domäne. Doch was tun, wenn ich Nutzer aus einer anderen Domäne im Forest bearbeiten will?
Inhaltsverzeichnis
User aus anderer Domäne editieren – Drei Fragen
Wie kann ich einfach Benutzer anderer Domänen bearbeiten? Generell ist die Antwort darauf „Einfach in die andere Domäne wechseln und das Skript dort ausführen!“. Das würde natürlich funktionieren. Es ist jedoch für automatisierte Prozesse recht umständlich. Das gleiche Skript müsste dann auf jeder Domäne im Forest ausgeführt werden. Doch es geht auch einfacher.
Um ein PS-Skript für andere Domänen einsetzen zu können, müssen drei Fragen beantwortet werden:
- Woher bekomme ich den Nutzer?
- Woher weiß ich, von welcher Domäne er stammt?
- Wie speichere ich Änderungen in der entsprechenden Domäne?
Der Global Catalog
Die erste Antwort ist klar, wenn man sich schon einmal mit mehreren Domänen in einem Forest beschäftigt hat:
Der Global Catalog (GC).
Der GC ist eine eigene Partition eines Domänencontrollers (DC), in dem Objekte aus allen Domänen im Forest gespeichert werden. Auf dem Domänencontroller muss der GC aktiviert sein. Ist dieser aktiviert, wird der DC zum Global Catalog Server.
Theoretisch ist es egal, welchen Domänencontroller ich in meiner Domäne anspreche. Entscheidend ist nur, dass der Domänencontroller ebenfalls ein GC-Server ist. Der Global Catalog ist überall der gleiche.
Praktisch hängt dies allerdings von der Replikationsgeschwindigkeit ab. Diese wiederum ist abhängig von Größe und Anzahl der Objekte, Netzwerkgeschwindigkeit etc.
Den Global Catalog eines DCs bzw. Forests mit PowerShell anzusprechen, ist recht einfach.
Es werden zwei Informationen benötigt:
- Der Name des Servers
- Der Port der GC-Verbindung
Im Grunde führt „Get-ADUser“ eine LDAP-Abfrage im Hintergrund aus. Standardmäßig ist das für Abfragen gegen die Domäne der Port 389. Für Abfragen gegen den Global Catalog wird dagegen Port 3268 (oder 636 respektive 3269 für SSL-Verbindungen) verwendet. Das gebe ich einfach in der Server-Eigenschaft zusammen mit dem Servernamen in dem Get-ADUser Kommando an:
|
1 |
$user = Get-ADUser -Identity "hans.wurst " -Server "srv2012r2b.demofa2.net:3268" |
Vorsicht mit Objekten aus dem Global Catalog
Das erhaltene Nutzer-Objekt sieht nun fast genauso aus, als hätte ich es von der Domäne selbst abgefragt. „Fast“ ist hier allerdings entscheidend – denn das Objekt enthält nicht alle Eigenschaften, die aus der Quelldomäne stammen. Active Directory repliziert nicht den kompletten User in den GC, sondern nur bestimmte, voreingestellte Eigenschaften.
Beispiel Domänenzugriff
Der Nutzer wird direkt von der Domäne abgefragt und es wird auf das Department-Attribut zugegriffen
Beispiel Global Catalog Zugriff
Unser Benutzer wird abgefragt, aber das Attribut Department liefert keinen Wert zurück
Das Department-Attribut wird nicht mit in den GC repliziert. Aus diesem Grund ist es in der zweiten Abfrage leer. Das Skript wirft hier allerdings keinen Fehler, da das Attribut grundsätzlich existiert – nur ohne Wert. Wenn es allerdings Attribute gibt, die Sie unbedingt benötigten und die im Standard nicht im GC enthalten sind, können Sie diese auch in den GC replizieren lassen.
Damit haben wir unser Nutzerobjekt und können die verschiedenen Attribute bearbeiten, wie wir es in PowerShell gewohnt sind.
Änderungen können nicht im GC gespeichert werden
Jetzt möchte ich natürlich die Änderungen speichern. Der GC ist allerdings von außen Read Only – aus guten Gründen. Wäre es möglich, AD-Objekte direkt im GC zu editieren, wären zahlreiche Replikationsfehler und Synchronitätsprobleme vorprogrammiert. Ich muss also zum Editieren zurück auf die Domäne, aus der der Nutzer stammt. Zuerst muss ich allerdings herausfinden, welche das ist. Leider steht dies nicht direkt in einer Eigenschaft am Nutzer.
Die richtige Domäne finden
Es gibt hier sicherlich viele Tricks und Kniffe. Ich möchte einen simplen – fast rudimentären – davon zeigen. Die Domäne steht implizit immer mit am User Object. Man findet sie in einem Attribut, was jeder Nutzer hat und was diesen auch eindeutig in der Domäne identifiziert. Die Rede ist natürlich vom DistinguishedName. Alles, was in dessen „DC=“-Teilen enthalten ist, ist Teil des FQDN (Fully-Qualified Domain Name) der Domäne, aus der er stammt. Wir müssen folglich nur herausfinden, wo der Domänen-Teil im DistinguishedName beginnt und diesen entsprechend den FQDN formatieren.
“DC=” Substring auslösen und verarbeiten
Dazu eignet sich eine simple String-Bearbeitung. Ich suche den Index des ersten Vorkommens von „DC=“ im String und lösen dann den Substring, der danach kommt, heraus. Dann lösche ich alle Kommas und ersetze die restlichen „DC=“ mit einem Punkt. Und schon habe ich meinen benötigten FQDN.
So sieht das Ganze in PowerShell aus:
|
1 2 3 4 |
$idx = $user.DistinguishedName.indexOf("DC=") + 2 $fqdn = $user.DistinguishedName.Substring($idx+1) $fqdn = $fqdn.Replace(",", "") $fqdn = $fqdn.Replace("DC=", ".") |
Und so in Aktion, wenn man die Zwischenschritte mit ausgibt:
Änderungen in die richtige Domäne schreiben
Nun wissen wir also, wohin der Nutzer muss. Die letzte Frage ist damit ganz einfach beantwortet. Ich speichere meine Änderungen, indem ich dem Set-ADUser den soeben ermittelten FQDN in der Server-Eigenschaft mit übergebe:
|
1 |
Set-ADUser -Identity $user -Description "Skript-Test" -Server $fqdn |
Mit diesem einfachen Skript können Sie von einer Domäne aus jeden Nutzer jeder Domäne in Ihrem Forest bearbeiten, ohne vorher wissen zu müssen, aus welcher Domäne er eigentlich stammt.
Komplettes Skript: Benutzer anderer Domänen bearbeiten
Hier noch einmal das gesamte Skript zum Kopieren:
|
1 2 3 4 5 6 7 8 |
$user = Get-ADUser -Identity "hans.wurst" -Server "srv2012r2b.demofa2.net:3268" $idx = $user.DistinguishedName.indexOf("DC=") + 2 $fqdn = $user.DistinguishedName.Substring($idx+1) $fqdn = $fqdn.Replace(",", "") $fqdn = $fqdn.Replace("DC=", ".") Set-ADUser -Identity $user -Description "Skript-Test" -Server $fqdn |
In dieser Form verwenden wir diese Funktionalität auch oft in unserem FirstWare IDM-Portal.
Dank unseres PowerShell-Providers haben wir die Möglichkeit, Skripte an verschiedene Prozesse anzuknüpfen. Wird ein Nutzer auf der Web-Oberfläche angelegt oder geändert, kann im Anschluss ein solches Skript laufen. Dieses bildet basierend auf den Änderungen automatisch Attribute. Ein Beispiel dafür wäre, dass bei einem neuen Nutzer Vor- (givenName) und Nachname (sn) eingetragen werden und nach dem Abspeichern einem Skript automatisiert als Parameter übergeben werden. Das Skript kann basierend darauf Attribute, wie zum Beispiel eine E-Mail-Adresse bilden und setzen. Da das IDM-Portal multidomänenfähig ist, können unsere PowerShell-Skripte auch Benutzer anderer Domänen bearbeiten.
Leave a Reply