Windows Server 2025 / AD-Benutzer, Gruppen und Organisationseinheiten erstellen

Benutzer, Gruppen und Organisationseinheiten in Active Directory (AD) haben unterschiedliche Aufgaben: Das Konto identifiziert den Benutzer, die Organisationseinheit (OU) gliedert Verwaltung und Richtlinienbereich, und eine Sicherheitsgruppe erhält Berechtigungen auf Ressourcen. In dieser Übung erstellen Sie labuser1 und GG_LabUsers in eigenen Labor-OUs. Die Gruppenmitgliedschaft allein gewährt noch keinen Dateizugriff, solange der Gruppe keine entsprechenden Berechtigungen zugewiesen wurden.

Planen Sie eigene OUs für das Labor

Erstellen Sie in der bereits funktionierenden Domäne ad.example.test die OU Lab mit den untergeordneten OUs LabUsers, LabGroups, Workstations und Servers. Behalten Sie diese Namen unverändert bei, damit sie zu den Befehlen passen. Trennen Sie die Laborobjekte von den Standardcontainern Users und Computers. Verschieben Sie integrierte Administratorkonten, Dienstidentitäten und Domänencontroller aus Domain Controllers nicht willkürlich. Arbeiten Sie auf DC1 oder einem berechtigten Verwaltungs-PC mit den Active Directory-Werkzeugen und passenden Erstellungs- und Änderungsrechten an den vorgesehenen Ablageorten.

Entwerfen Sie OUs für Verwaltungsdelegation und benötigte Richtlinien, statt das Organigramm unverändert abzubilden. Tiefe Verschachtelung erschwert die Nachverfolgung von Einstellungen und Zuständigkeiten. Die Hinweise zum OU-Entwurf erläutern diese Kriterien. Lassen Sie den Schutz vor versehentlichem Löschen bei neuen OUs aktiviert. Dieser Schutz ist keine Datensicherung und ersetzt keinen Wiederherstellungsplan.

Erstellen Sie Benutzer und Gruppe über die Oberfläche

1. Öffnen Sie dsa.msc auf DC1 oder dem berechtigten PC mit Active Directory-RSAT. Prüfen Sie, dass ad.example.test ausgewählt ist und das verwendete Konto die Laborobjekte verwalten darf.
2. Klicken Sie mit rechts auf ad.example.test → Neu → Organisationseinheit. Erstellen Sie Lab mit Schutz vor versehentlichem Löschen und darin über Neu → Organisationseinheit die vier OUs LabUsers, LabGroups, Workstations und Servers. Kontrollieren Sie die Hierarchie.
3. Wählen Sie in LabUsers Neu → Benutzer. Verwenden Sie Lab User One als vollständigen Namen sowie labuser1 als Benutzeranmeldenamen mit dem Suffix ad.example.test. Geben Sie ein eindeutiges, richtlinienkonformes Anfangskennwort ein und bestätigen Sie es. Verlangen Sie den Kennwortwechsel bei der nächsten Anmeldung und prüfen Sie, dass das Konto nicht deaktiviert bleibt. Schalten Sie dafür keine Kennwortanforderungen ab.
4. Wählen Sie in LabGroups Neu → Gruppe, geben Sie GG_LabUsers ein und setzen Sie Gruppenbereich Global sowie Gruppentyp Sicherheit. Bestätigen Sie und kontrollieren Sie die Eigenschaften; verwenden Sie nicht Verteiler.
5. Öffnen Sie bei GG_LabUsers Eigenschaften → Mitglieder → Hinzufügen und wählen Sie labuser1. Kontrollieren Sie das gefundene Konto vor dem Speichern. Prüfen Sie anschließend Mitglieder in der Gruppe und Mitglied von in den Benutzereigenschaften; beide müssen die neue Beziehung zeigen.

Verwenden Sie eine Sicherheitsgruppe für Ressourcenberechtigungen. Eine Verteilergruppe dient E-Mail-Verteilerlisten und kann diese Zugriffskontrolle nicht übernehmen. Der Gruppenbereich bestimmt zulässige Mitglieder und Einsatzmöglichkeiten; dieses Labor mit einer Domäne beginnt mit Global. Beachten Sie New-ADGroup und die Übersicht zu Sicherheitsgruppen und Gruppenbereichen. Die Ablage von GG_LabUsers in LabGroups fügt weder Mitglieder noch Ressourcenrechte automatisch hinzu.

Verwenden Sie alternativ PowerShell

Der folgende Block ist eine Alternative zur grafischen Erstellung, kein zusätzlicher Wiederholungsschritt. Verwenden Sie Windows PowerShell auf DC1 oder einem berechtigten Verwaltungs-PC mit installiertem Modul ActiveDirectory und Verbindung zur Domäne. Prüfen Sie vorab, ob die Objekte bereits existieren. Untersuchen Sie gegebenenfalls Identität, Ablageort und Zweck, statt sie zu löschen, zu überschreiben oder den gesamten Block erneut auszuführen. DC=ad,DC=example,DC=test und OU=Lab sind Verzeichnispfade, keine Ordner auf dem Datenträger. Read-Host -AsSecureString fragt das Anfangskennwort ab, ohne es im Code festzuhalten; speichern Sie es nicht im Klartextbericht:

Import-Module ActiveDirectory
$domainPath = 'DC=ad,DC=example,DC=test'
$labPath = 'OU=Lab,' + $domainPath
New-ADOrganizationalUnit -Name 'Lab' -Path $domainPath -ProtectedFromAccidentalDeletion $true
foreach ($ouName in 'LabUsers','LabGroups','Workstations','Servers') {
    New-ADOrganizationalUnit -Name $ouName -Path $labPath -ProtectedFromAccidentalDeletion $true
}
$initialPassword = Read-Host 'Initial password for labuser1' -AsSecureString
New-ADUser -Name 'Lab User One' -SamAccountName 'labuser1' -UserPrincipalName 'labuser1@ad.example.test' -Path ('OU=LabUsers,' + $labPath) -AccountPassword $initialPassword -Enabled $true -ChangePasswordAtLogon $true
New-ADGroup -Name 'GG_LabUsers' -GroupCategory Security -GroupScope Global -Path ('OU=LabGroups,' + $labPath)
Add-ADGroupMember -Identity 'GG_LabUsers' -Members 'labuser1'
Get-ADGroupMember -Identity 'GG_LabUsers'

Die Referenz zur OU-Erstellung erklärt -Path und den Löschschutz. Die Parameter von New-ADUser unterscheiden den Objektnamen Lab User One vom Anmeldenamen labuser1 und vom Benutzerprinzipalnamen labuser1@ad.example.test. -Enabled $true fordert die Aktivierung an, -ChangePasswordAtLogon $true verlangt einen Kennwortwechsel bei der nächsten Anmeldung. Die letzte Abfrage soll labuser1 als direktes Mitglied von GG_LabUsers auflisten. Das belegt noch keine Benutzeranmeldung und keinen Zugriff auf eine Freigabe.

Lehnt die Kennwortrichtlinie das Kennwort ab, kann New-ADUser das Objekt trotzdem angelegt haben, ohne das Konto zu aktivieren. Prüfen Sie Fehler und Enabled: Gehen Sie nicht von einem vollständigen Zurückrollen aus und erstellen Sie denselben Benutzer nicht nochmals. Suchen Sie labuser1 in Active Directory-Benutzer und -Computer, setzen Sie über Kennwort zurücksetzen ein gültiges Kennwort und aktivieren Sie das Konto bei Bedarf; behalten Sie den vorgesehenen Wechsel bei der nächsten Anmeldung bei. Die Referenz zum Zurücksetzen eines AD-Kennworts beschreibt die administrative Alternative. Erzwingen Sie die Aktivierung nicht mit leerem Kennwort oder abgeschalteter Richtlinie.

Verschieben Sie Computer und testen Sie den Standardbenutzer

Kontrollieren Sie vor dem Verschieben, dass fünf OUs vorhanden sind: Lab und seine vier untergeordneten OUs. Das Konto labuser1 muss in LabUsers, GG_LabUsers in LabGroups liegen; die Gruppe muss vom Typ Sicherheit mit Bereich Global sein und die Mitgliederabfrage den erwarteten Benutzer liefern. Fehlt ein Teil, korrigieren Sie den betroffenen Schritt anhand des tatsächlichen Fehlers. Eine erfolgreiche spätere Zeile beweist nicht den Erfolg aller früheren Zeilen.

Verschieben Sie nur Computerobjekte von bereits beigetretenen Domänenmitgliedern. Falls CLIENT1 noch nicht beigetreten ist, führen Sie zuerst die Übung zum Domänenbeitritt des Clients durch. FS1 ist nur vorhanden, wenn Sie ihn schon als Mitgliedsserver aufgenommen haben; andernfalls lassen Sie dessen Verschiebung und Abfrage aus, statt zur Fehlerverdeckung ein Ersatzobjekt anzulegen. Klicken Sie in Active Directory-Benutzer und -Computer mit rechts auf das richtige Computerobjekt und wählen Sie Verschieben: CLIENT1 gehört nach Lab\Workstations, FS1 nach Lab\Servers. Stellen Sie sicher, dass keiner ein Domänencontroller ist, notieren Sie den bisherigen Ablageort und prüfen Sie die Richtlinienwirkung am Ziel. Fragen Sie danach Ablageort und Benutzerstatus ab:

Get-ADComputer -Identity 'CLIENT1' | Select-Object Name,DistinguishedName
Get-ADComputer -Identity 'FS1' | Select-Object Name,DistinguishedName
Get-ADUser -Identity 'labuser1' -Properties Enabled | Select-Object SamAccountName,Enabled,DistinguishedName

DistinguishedName soll bei CLIENT1 OU=Workstations,OU=Lab und bei vorhandenem FS1 als Mitglied OU=Servers,OU=Lab enthalten, jeweils gefolgt von DC=ad,DC=example,DC=test. Prüfen Sie bei labuser1 SamAccountName, Enabled True sowie OU=LabUsers,OU=Lab. Speichern Sie danach Ihre Arbeit und melden Sie sich auf CLIENT1 vollständig ab; bloßes Sperren genügt nicht. Wählen Sie Anderer Benutzer, melden Sie sich als labuser1@ad.example.test an und ändern Sie das Anfangskennwort, wenn verlangt. Whoami soll AD\labuser1 ausgeben. Der Gruppe wurden noch keine Dateirechte zugewiesen; ein verweigerter Freigabezugriff beweist daher allein keinen Fehler bei der Gruppenerstellung.

Benutzer- und Computereinstellungen richten sich nach den jeweiligen Objektpositionen und den dort anwendbaren Richtlinien. Das Verschieben von labuser1 verschiebt CLIENT1 nicht. Auch die Ablage von GG_LabUsers in einer OU versetzt ihre Mitglieder nicht dorthin. Bei unerwarteten Auswirkungen einer Verschiebung prüfen Sie Richtlinienverknüpfungen und Vererbung und erwägen, nur das betreffende Objekt an den dokumentierten ursprünglichen Ort zurückzuverschieben. Verschieben Sie nicht weitere Objekte, um das Ergebnis vermeintlich auszugleichen.

Prüfen Sie Mitgliedschaftsänderungen und Bereinigung

Bestehende Sitzungen können ältere Gruppeninformationen im Zugriffstoken behalten. Dieses Objekt beschreibt den Sicherheitskontext einer Sitzung beziehungsweise eines Prozesses; die Dokumentation zu Zugriffstoken erläutert unter anderem die enthaltenen Gruppeninformationen. Speichern Sie nach einer Mitgliedschaftsänderung die Arbeit, melden Sie sich ab und erneut als labuser1 an. Vergleichen Sie whoami /groups mit der AD-Mitgliedschaft und Get-ADGroupMember. Ein weiteres Fenster innerhalb der alten Sitzung ersetzt keine neue Anmeldung. Prüfen Sie vor Umbenennung oder Löschung von Benutzern und Gruppen abhängige Anwendungen und Dateiberechtigungen.

Behalten Sie die Objekte für die weiteren Übungen. Für eine gezielte Bereinigung erfassen Sie zuerst benötigte Objekte, bisherige Ablageorte, Richtlinienverknüpfungen, Delegation und abhängige Berechtigungen. Verschieben Sie zu erhaltende Objekte an geeignete Orte, bevor Sie eine OU-Löschung erwägen. Der Schutz vor versehentlichem Löschen ist beabsichtigt: Entfernen Sie ihn nur bei einer ausdrücklich ausgewählten und geprüften OU. Entschützen oder löschen Sie nicht rekursiv die gesamte Lab-Struktur. Eine Zugriffsfehlermeldung rechtfertigt weder das Entfernen der Hierarchie noch Änderungen an fremden Administratorkonten.