Windows Server 2025 / Lokale Benutzer und Gruppen verwalten

Ein lokaler Benutzer gehört zu einer bestimmten Windows-Server-Installation. Eine lokale Gruppe fasst Konten zusammen, denen dieser Server Berechtigungen und Rechte zuweisen kann. Trennen Sie Konten für den Alltag von Administratorkonten und vergeben Sie nur die für eine Aufgabe erforderlichen Gruppenmitgliedschaften.

Lokale und Domänen-Identitäten unterscheiden

Der lokale Benutzer labuser auf FS1 wird von FS1 verwaltet. Ein gleichnamiges Konto auf einem anderen Server ist eine andere Identität. Domänenkonten werden in Active Directory verwaltet und können sich an Computern der Domäne authentifizieren.

Format Bedeutung
FS1\labuser oder .\labuser Ein lokales Konto auf dem angegebenen Server oder dem aktuellen Computer
AD\user1 Ein Konto in der Domäne mit dem NetBIOS-Kurznamen AD
user1@ad.example.test Ein Anmeldename eines Domänenbenutzers

Führen Sie dieses Labor auf FS1 durch, bevor es zu einem Domänencontroller wird. Ein Controller zeigt die Verwaltung lokaler Konten gewöhnlicher Member-Server nicht auf dieselbe Weise an; ein fehlender Knoten "Lokale Benutzer und Gruppen" auf DC1 ist an sich kein Fehler.

Erstellen Sie den Benutzer und die Gruppe in der GUI

  1. Melden Sie sich auf FS1 mit Desktop Experience als Administrator an und öffnen Sie compmgmt.msc. Verwenden Sie unter Server Core das PowerShell-Verfahren im folgenden Abschnitt.
  2. Öffnen Sie Systemprogramme → Lokale Benutzer und Gruppen → Benutzer. Wählen Sie im Kontextmenü Neuer Benutzer.
  3. Erstellen Sie labuser mit einem eindeutigen Passwort. Wählen Sie Passwortwechselbedingungen, die der geplanten Anmeldemethode und Richtlinie entsprechen.
  4. Öffnen Sie Lokale Benutzer und Gruppen → Gruppen und wählen Sie Neue Gruppe. Erstellen Sie LabReaders und fügen Sie den lokalen Benutzer labuser hinzu; prüfen Sie FS1 als Herkunft. Nehmen Sie ihn nicht in die Administratorengruppe auf.

LabReaders ist Ihr eigener Gruppenname und ändert sich nicht mit der Windows-Benutzeroberflächensprache. Eingebaute Gruppendarstellungsnamen können lokalisiert werden, überprüfen Sie daher Beschreibungen und Mitglieder sowie Namen.

Die Mitgliedschaft allein gewährt weder Dateizugriff noch eine Remoteanmeldung. Sie müssen der Gruppe separat Berechtigungen für eine Ressource oder Rechte in der entsprechenden Anmelderichtlinie zuweisen.

Erstellen Sie die entsprechende Konfiguration mit PowerShell

Erstellen Sie vorhandene Namen aus der grafischen Übung nicht erneut. Verwenden Sie auf einem FS1, auf dem diese Objekte noch nicht existieren, die 64-Bit-Version von Windows PowerShell mit Administratorrechten. New-LocalUser nimmt das Kennwort als SecureString-Objekt entgegen. Read-Host mit -AsSecureString liest es ein, ohne es als sichtbaren Kennworttext in den Quellcode zu schreiben:

$labPassword = Read-Host 'Password for labuser' -AsSecureString
New-LocalUser -Name 'labuser' -Password $labPassword -Description 'Lab standard user'
New-LocalGroup -Name 'LabReaders' -Description 'Lab read access group'
Add-LocalGroupMember -Group 'LabReaders' -Member "$env:COMPUTERNAME\labuser"
Get-LocalGroupMember -Group 'LabReaders'

Der letzte Befehl soll FS1\labuser als Mitglied von LabReaders anzeigen. Die Angabe des Computernamens bei Add-LocalGroupMember verhindert die Verwechslung mit einem gleichnamigen Domänenkonto; dazu erläutert die Dokumentation zu lokalen Gruppenmitgliedschaften die Namensauflösung. Hinterlegen Sie das Kennwort nicht im Quellcode und verwenden Sie kein kennwortloses Konto als Abkürzung. Das Modul LocalAccounts ist in einer 32-Bit-PowerShell auf einem 64-Bit-System nicht verfügbar.

Überprüfen Sie den Kontostatus und die tatsächliche Benutzersitzung

Prüfen Sie die Erstellung getrennt vom tatsächlichen Zugriff. Die ersten beiden Abfragen zeigen den Zustand von labuser und die Gruppenzuordnung; Enabled gibt an, ob das Konto aktiviert ist. Führen Sie whoami und whoami /groups in der tatsächlichen Sitzung des Standardbenutzers aus, nicht im Administratorfenster, um dessen Identität und Gruppen zu prüfen.

Get-LocalUser -Name 'labuser' | Select-Object Name,Enabled,LastLogon
Get-LocalGroupMember -Group 'LabReaders'
whoami
whoami /groups

Eine offene Sitzung kann nach Gruppenänderungen ihr ursprüngliches Zugriffstoken behalten, also die Sicherheitsdaten vom Zeitpunkt der Anmeldung. Melden Sie sich vor dem Vergleich ab und erneut an. Schlägt die Anmeldung fehl, prüfen Sie Kontoaktivierung, Kennwort, Tastaturlayout und lokale beziehungsweise Domänenidentität. Eine Richtlinie zur Verweigerung der Anmeldung kann die Gruppenzuordnung übersteuern; Administratorrechte sind keine allgemeine Fehlerbehebung.

Deaktivieren Sie zunächst, wenn ein Konto nur vorübergehend nicht benutzt wird

Dies sind entgegengesetzte Alternativen: Disable-LocalUser deaktiviert das Konto, Enable-LocalUser aktiviert es wieder. Führen Sie nur die benötigte Zeile aus, nicht beide als zusammenhängenden Ablauf:

Disable-LocalUser -Name 'labuser'
Enable-LocalUser -Name 'labuser'

Prüfen Sie vor dem dauerhaften Entfernen dieser Benutzer- und Gruppenkonfiguration, ob der Gruppe noch Berechtigungen zugewiesen sind. Entfernen Sie zuerst die Mitgliedschaft und löschen Sie Gruppe und Benutzer nur, wenn sie nicht mehr benötigt werden:

Remove-LocalGroupMember -Group 'LabReaders' -Member "$env:COMPUTERNAME\labuser"
Remove-LocalGroup -Name 'LabReaders'
Remove-LocalUser -Name 'labuser'

Ein unter demselben Namen neu angelegtes Konto erhält eine andere Sicherheitskennung (SID, Security Identifier), wie die Dokumentation zu Sicherheitskennungen erklärt. Frühere Berechtigungen werden daher nicht automatisch übernommen. Behalten Sie das Konto, wenn spätere Dateiberechtigungsübungen es benötigen. Prüfen Sie vor dem Deaktivieren eines Administratorkontos einen anderen funktionierenden Administratorzugang.