• Active Directory
    • AD Consulting
    • AD Design
      • Domain Name festlegen
      • Domain Struktur einrichten
      • Forest Struktur definieren
    • AD Management
    • AD Automation
      • Dynamic Access Control (DAC)
    • AD Federation Services
      • ADFS Betrieb
      • ADFS und Office365
      • ADFS und Cisco Unified Communications Manager
      • SAML und ADFS 2.0
  • Azure / M365
    • Azure AD
    • Microsoft 365 (O365)
  • Migration
    • Active Directory Migration
    • Exchange Migration
    • File Server Migration
    • Lotus Notes Migration
    • Novell Migration
  • Wissen
    • Alle Beiträge
    • Administration
    • PowerShell
    • Migration
    • Exchange
    • Tools
  • Kontakt
    • Wir über uns
    • Kontakt
  • EN
info@firstattribute.com
by FirstAttribute
Active Directory FAQActive Directory FAQ
  • Active Directory
    • AD Consulting
    • AD Design
      • Domain Name festlegen
      • Domain Struktur einrichten
      • Forest Struktur definieren
    • AD Management
    • AD Automation
      • Dynamic Access Control (DAC)
    • AD Federation Services
      • ADFS Betrieb
      • ADFS und Office365
      • ADFS und Cisco Unified Communications Manager
      • SAML und ADFS 2.0
  • Azure / M365
    • Azure AD
    • Microsoft 365 (O365)
  • Migration
    • Active Directory Migration
    • Exchange Migration
    • File Server Migration
    • Lotus Notes Migration
    • Novell Migration
  • Wissen
    • Alle Beiträge
    • Administration
    • PowerShell
    • Migration
    • Exchange
    • Tools
  • Kontakt
    • Wir über uns
    • Kontakt
  • EN

Benutzer anderer Domänen bearbeiten – mit PowerShell

Feb 21, 2019 (Letztes Update) | Posted by Steve König Administration, KnowHow, PowerShell |

 

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

  • 1 User aus anderer Domäne editieren – Drei Fragen
  • 2 Der Global Catalog
  • 3 Vorsicht mit Objekten aus dem Global Catalog
    • 3.1 Beispiel Domänenzugriff
    • 3.2 Beispiel Global Catalog Zugriff
    • 3.3 Änderungen können nicht im GC gespeichert werden
  • 4 Die richtige Domäne finden
    • 4.1 „DC=“ Substring auslösen und verarbeiten
    • 4.2 Änderungen in die richtige Domäne schreiben
  • 5 Komplettes Skript: Benutzer anderer Domänen bearbeiten

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:

  1. Woher bekomme ich den Nutzer?
  2. Woher weiß ich, von welcher Domäne er stammt?
  3. 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:

PowerShell
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

Abfrage Department aus dem AD

Beispiel Global Catalog Zugriff

Unser Benutzer wird abgefragt, aber das Attribut Department liefert keinen Wert zurück

Abfrage_Department

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:

PowerShell
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:

Domain_aus_DN

Ä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:

PowerShell
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:

PowerShell
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.Active-Directory-Delegation-Powershell

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.

 

Artikel weiterempfehlen:
  • teilen
  • tweeten
  • sharen
  • xingen
  • mailen
Artikel erstellt am: 11.08.2016
Tags: ForestGet-ADUserGlobal CatalogReplikationSet-ADUser
0

You also might be interested in

AD-PowerShell-Linux-Attribute

Linux Attribute am AD-User ändern (Powershell)

Nov 30, 2015

Will man die Linux Attribute gidNumber, uid und uidnumber per[...]

snippet-inkonsistene-berechtigung

Inkonsistente Berechtigungen im Global Catalog

Jan 29, 2015

Wer mit Hilfe von Active Directory Gruppen Berechtigungen auf Ressourcen[...]

Phantom Objekte im Active Directory – Infrastruktur Master Rolle und Globaler Katalog

Sep 5, 2011

Infrastructure Master Role und Global Catalog Microsoft empfiehlt, dass man[...]

Leave a Reply

<p>Danke für Ihre Anregungen, Fragen und Hinweise.<br/>Infos zum <a href="https://www.active-directory-faq.dekontakt/">Datenschutz</a></p>
Cancel Reply

FirstWare IDM-Portal im Test: IT-Administrator 08-2022

 

ADFAQ-FirstAttribute

Wer schreibt ?

Team der FirstAttribute AG

Consultants und Entwickler der FirstAttribute arbeiten seit mehr als 20 Jahren in IAM- und Cloud-Transition-Projekten.
Zusammen verfügen Sie über einen wertvollen Erfahrungsschatz im Bereich Active Directory und Azure AD und teilen diesen auf Active Directory FAQ.

Neueste Artikel

  • 8 Tipps für mehr Sicherheit in Active Directory und Backups von AD
  • Azure AD Custom Security Attributes ermöglichen flexible Berechtigungsstrukturen
  • Dateiberechtigungen in MS Teams und SharePoint Online verwalten – So funktioniert es
  • AD-Gruppen in Microsoft Teams verwenden – Dynamische Gruppen in der Praxis
  • Verbindung zwischen Microsoft 365 und SharePoint Online zu Azure AD

Unsere IAM-Lösungen

Ihre IAM-Lösung: FirstWare IDM-Portal

 

my-IAM für Cloud Identity Management in Microsoft Teams

Kontakt aufnehmen

Sie haben eine Frage oder Anmerkung? Schicken Sie uns schnell eine Nachricht.

Nachricht senden
Jetzt AD Tasks vereinfachen und delegieren: FirstWare IDM-Portal

Folgen Sie uns

Kontakt

  • FirstAttribute AG
  • Am Büchele 18, 86928 Hofstetten, Germany
  • +49 89 215 442 400
  • https://www.firstattribute.com

Schlagwörter

.Net ACL Active Directory AD LDS AD Objekt Azure AD Berechtigung Cloud cmdlets Delegation Domain Controller dynamicgroup dynamische Gruppen Exchange Exchange-Ordner Exchange-Postfach Exchange Migration Federation FirstWare Get-Mailbox Global Catalog Group Policy Gruppen Gruppenmitgliedschaft IDM-Portal LDAP m365 Microsoft Azure Migration New-ADUser Novell NTFS Office 365 PowerShell QMM QMM AD QMM Exchange Quest Migration Manager Schema Set-ADUser SID SID History Update Windows 10 Windows Server 2012 R2

Neueste Kommentare

  • activedirectoryfaq.com sharepoint login - infoslist bei Windows 365 und Azure AD verstehen in Theorie und Praxis
  • Domäne Letzte Anmeldung - ObenGesichert.com bei LastLogon vs. LastLogonTimestamp
  • Teams Code Zur Anmeldung - ObenGesichert.com bei Authentifizierung für MS Teams in hybriden Netzwerken
Login
Impressum
Datenschutzerklärung

© 2023 · Active-Directory-FAQ by firstattribute.com

Prev Next