Benutzer, Computer und Gruppen

Ein Benutzerobjekt repräsentiert eine Identität. Typische konzeptionelle Attribute sind Name, Anmeldename, User Principal Name (UPN), Gruppenmitgliedschaften, Kontostatus und weitere Verzeichnisdaten. Beispiele enthalten keine Passwörter.

Domänenverbundene Computer besitzen normalerweise Computerobjekte und eine eigene Sicherheitsidentität. Sie sind nicht bloß Inventareinträge und können sich für maschinenbezogene Vorgänge gegenüber der Domäne authentifizieren.

Benutzer, Computer und Security Groups können Sicherheitsprinzipale mit einer Security Identifier (SID) sein. Zugriffslisten referenzieren diese SIDs. Nicht jedes AD-Objekt ist ein Sicherheitsprinzipal: Eine OU ersetzt beispielsweise keine Security Group in einer normalen Ressourcen-ACL.

Der Name eines Objekts kann sich ändern, während seine SID innerhalb seiner Lebensdauer die entscheidende Sicherheitsreferenz bleibt. Wird ein Benutzer gelöscht und mit demselben Namen neu erstellt, entsteht ein neuer Sicherheitsprinzipal mit neuer SID. SID-Zeichenfolgen müssen hier nicht auswendig gelernt werden.

Eine Security Group kann für Autorisierung und Zugriffsrechte verwendet werden. Eine Distribution Group ist für Verteilung beziehungsweise Messaging vorgesehen und wird nicht als Windows-Sicherheitsprinzipal für ACL-Berechtigungen eingesetzt.

Global

bildet häufig Konten mit einer Rolle aus derselben Domäne ab

Domain Local

bildet häufig eine Berechtigung auf eine Ressource in einer Domäne ab

Universal

kann Forest-Domänen überspannen und ist für Mehrdomänen-Szenarien nützlich

Diese Rollen sind einsteigerfreundliche Entwurfszusammenfassungen, keine vollständige Liste aller technischen Mitgliedschaftsregeln.

Gruppen dürfen im Rahmen ihrer Typ- und Bereichsregeln Mitglieder anderer Gruppen sein. Dadurch lassen sich berufliche Rollen von Ressourcenrechten trennen, direkte Benutzer-ACLs reduzieren und Wechsel einfacher verwalten. Beliebig tiefe Verschachtelung bleibt unübersichtlich.

Direkte Benutzerberechtigungen sind technisch möglich, werden bei vielen Benutzern aber schwer wartbar. Wo praktikabel, verbindet ein rollenbasierter Gruppenentwurf Least Privilege mit nachvollziehbaren Berechtigungen. Tägliche Arbeit als Domain Admin, pauschales Full Control und geteilte Administratorkonten sind keine geeigneten Standards.

Anna und Ben arbeiten im Support; Clara in der Verwaltung. Entwirf Benutzerobjekte, Rollen- und Ressourcenberechtigungsgruppen: Anna und Ben → GG_Support → DL_Support_Modify → Ändern auf \\fileserver\support. Clara → GG_Verwaltung → DL_Verwaltung_Modify → Ändern auf \\fileserver\verwaltung. Die Namen sind Beispiele, kein universeller Standard.

Ungeeignet wären direktes Full Control für jeden Benutzer, eine eigene Domäne für Support, eine OU als vermeintliche Dateiberechtigung oder eine IP-Adresse als Gruppenmitglied.

Beim Deaktivieren bleibt das Objekt mit seinen Mitgliedschaften erhalten, kann aber normalerweise nicht als aktivierte Identität für interaktive beziehungsweise Domänenauthentifizierung verwendet werden. Beim Löschen wird das Verzeichnisobjekt entfernt. In Offboarding- oder Untersuchungsabläufen kann zuerstiges Deaktivieren den Kontext bewahren.

In einer vorhandenen, autorisierten AD-Umgebung können Get-ADUser, Get-ADComputer und Get-ADGroup optional Informationen lesen. Sie benötigen das PowerShell-Modul ActiveDirectory beziehungsweise RSAT, eine passende AD-Umgebung und ausreichende Leserechte. Modul oder RSAT werden nicht installiert; die Basislektion funktioniert ohne Domain Controller.