Gorodenkoff - stock.adobe.com

So ändern Sie das AdminCount-Attribut in geschützten Konten

Das AdminCount-Attribut ist wichtig für die Sicherheit von Active-Directory-Konten mit weitreichenden Berechtigungen. Wir erklären, wie Sie es mit PowerShell bearbeiten.

„With great power comes great responsibility“ – das gilt nicht nur für Spiderman, sondern auch für Administratoren. Beim Verwalten von Benutzern mit weitreichenden Rechten müssen Sie sorgfältig vorgehen, um unternehmensweites Chaos zu vermeiden.

Privilegierte Benutzer in Active Directory steuern die Schlüssel zum Zuweisen von Berechtigungen an andere Objekte, darunter sich selbst und privilegierte Gruppen. Als Administrator sollten Sie daher genau wissen, wo Sie Berechtigungen in geschützten Konten finden und wie Sie sie anpassen. Wir erklären, wie Sie mit PowerShell das sogenannte AdminCount-Attribut finden und ändern, um diese Rechte zu konfigurieren.

Was ist ein privilegierter Benutzer und eine privilegierte Gruppe?

Active Directory besteht aus einem Benutzerregister und eine Reihe von Diensten mit Kontrolle über 12 verschiedene Objekttypen, darunter Domänencontroller, Benutzer und Drucker. Administratoren gewähren Schlüsselbenutzern und Gruppen unterschiedlich weitreichende Rechte und Erlaubnisse zum Verwalten dieser Objekte.

Es gibt vier voreingestellte Gruppen in Active Directory, die über höhere Berechtigungen als jede andere Gruppe verfügen: Administratoren, Domänen-Admins, Organisations-Admins sowie Schema-Admins. Diese Gruppen haben die höchste Berechtigungsstufe und können fast alle anderen Objekte in Active Directory ändern.

Theoretisch könnte jemand versehentlich oder aus böswilliger Absicht Berechtigungen von diesen Gruppen entfernen. Damit würden sie die Kontrolle über Active Directory verlieren, was wiederum Chaos im gesamten Unternehmen sähen könnte. Da diese privilegierten Gruppen für Active Directory so wichtig sind, gelten sie als geschützte Gruppen.

Was sind geschützte Konten?

Active Directory enthält eine Reihe von Konten und Gruppen, die den Kern des Verzeichnisses darstellen. Sie können Active Directory nicht ohne diese Standardkonten und -gruppen verwalten.

Der Builtin-Container und der Users-Container in Active Directory enthalten viele dieser Konten. Es gibt 10 Standardsicherheitsgruppen – Konten-Operatoren, Administratoren, Sicherungs-Operatoren, Zertifikatsherausgeber, Domänen-Admins, Domänencontroller, Organisations-Admins, Druck-Operatoren, Schema-Admins und Server-Operatoren – und drei geschützte Konten – Administrator, KRBTGT und Replikator.

Screenshot der Sicherheitsgruppen im Active Directory
Abbildung 1: Im Buildin-Container in Active Directory finden Sie die Standardsicherheitsgruppen.

Geschützte Gruppen haben Berechtigungssätze, die Sie nicht einfach ändern können; Active Directory setzt alle Änderungen stündlich automatisch auf ihre Standardberechtigungen zurück. Das garantiert, dass geschützte Gruppen niemals die Kontrolle über Active Directory oder die Fähigkeit verlieren, die anderen Konten zu verwalten.

Was die Werte im AdminCount-Attribut bedeuten

Ein integrierter Prozess in Active Directory scannt die integrierten Gruppen und kennzeichnet die Benutzer in diesen Gruppen als Sonderkonten oder Administratorkonten, die eine andere Behandlung als andere Konten erfordern.

Alle Active-Directory-Objekte haben ein verstecktes Attribut namens AdminCount, das standardmäßig auf Null gesetzt ist. Bei den genannten speziellen Konten ist der AdminCount-Wert auf 1 festgelegt, wodurch die Vererbung für das Objekt deaktiviert und die Sicherheit vom AdminSDHolder-Objekt verwaltet wird.

Sie können den AdminCount für jedes Konto in einer Domäne entweder über ein GUI-Tool (Grafische Benutzeroberfläche, Graphic User Interface) oder mit PowerShell auf 1 setzen.

Wozu dienen das AdminSDHolder-Objekt und der SDProp-Prozess?

Das AdminSDHolder-Objekt in Active Directory ist in der Standardansicht des Snap-Ins Active-Directory-Benutzer und -Computer (ADUC) der Microsoft Management Console (MMC) nicht sichtbar. Aktivieren Sie die erweiterte Ansicht, um die Systempartition anzuzeigen, die einen Untercontainer namens AdminSDHolder enthält.

Screenshot der erweiterten Ansicht
Abbildung 2: In der erweiterten Ansicht sehen sie den System-Container und AdminSDHolder.

Klicken Sie mit der rechten Maustaste auf den Container, um die Sicherheitseinstellungen anzuzeigen. Die Berechtigungen in diesem Objekt sind der Standardberechtigungssatz, der allen Konten in allen Sicherheitsgruppen sowie allen Konten zugewiesen wird, deren AdminCount-Wert auf 1 festgelegt ist.

Sie können die Einstellungen im AdminSDHolder-Objekt ändern, indem Sie die Berechtigungen mit dem Dienstprogramm ADSIEdit bearbeiten.

Die Kombination aus dem AdminSDHolder-Objekt und dem SDProp-Prozess schützt die Sicherheitsgruppen und Benutzer in diesen Gruppen vor versehentlichen Änderungen der Berechtigungen.

Das AdminSDHolder-Objekt wendet Standardberechtigungen auf die wichtigen Gruppen an. Der SDProp-Prozess startet alle 60 Minuten; Er vergleicht die Berechtigungen für das AdminSDHolder-Objekt der Domäne mit den Berechtigungen für die geschützten Konten und Gruppen in der Domäne und setzt geänderte Berechtigungen auf einen Standardsatz von Berechtigungen zurück.

Als zusätzliche Sicherheitsmaßnahme deaktiviert Active Directory die Vererbung von Berechtigungen für geschützte Gruppen und Konten. Selbst wenn die Konten und Gruppen an einen anderen Ort im Verzeichnis verschoben werden, erben sie keine Berechtigungen von ihren neuen übergeordneten Objekten. Active Directory unterbindet zudem die Vererbung für das AdminSDHolder-Objekt, sodass Berechtigungsänderungen an übergeordneten Objekten die Berechtigungen von AdminSDHolder nicht ändern.

Was sind die Nachteile geschützter Objekte?

All dieser integrierte Schutz ist großartig, aber was ist, wenn Sie die Berechtigungssätze ändern möchten? Das ist fast unmöglich, wenn Sie nicht wissen, wie Sie den AdminSDHolder-Berechtigungssatz aktualisieren.

Wenn Sie den AdminCount-Wert von 0 auf 1 ändern, wird die Vererbung von diesen Objekten automatisch entfernt. Wenn Sie möchten, dass Gruppen Berechtigungen von Organisationseinheiten (OUs) oder anderen Quellen erben, müssen Sie in die Trickkiste greifen. Sie können den AdminCount für jedes Konto in der Domäne auf 1 setzen, doch dadurch werden auch Sicherheitsmaßnahmen für Konten geändert, die Sie nicht beeinträchtigen möchten.

Außerdem können Sie die Kennwörter von Konten, bei denen AdminCount auf 1 gesetzt ist, nicht auf den Standardwert zurücksetzen. Sie müssen also entweder dem AdminSDHolder die Berechtigung zum Zurücksetzen des Kennworts hinzufügen oder Sie richten Konten mit mehr Rechten für diese Benutzer ein und platzieren sie in alternativen Organisationseinheiten. Ich empfehle letzteres, was aus Sicherheitsgründen ein Best Practice ist. In kleineren IT-Abteilungen fehlen dazu aber mitunter die Kenntnisse zur Umsetzung dieser komplexeren Lösung.

Die Gruppe „Geschützte Benutzer“ stärkt die Sicherheit privilegierter Konten

Ab Windows Server 2012 R2 hat Microsoft in Active Directory eine Sicherheitsgruppe mit dem Namen Geschützte Benutzer hinzugefügt. Sie erhält zusätzliche Schutzmaßnahmen wie das Unterbinden des Cachings von Logins.

Die folgenden Eigenschaften gelten für geschützte Benutzer:

  • Credential Delegation (CredSSP) speichert die Klartext-Anmeldeinformationen des Benutzers nicht zwischen, selbst wenn die Gruppenrichtlinieneinstellung Delegierung von Standardanmeldinformationen zulassen aktiviert ist.
  • Ab Windows 8.1 und Windows Server 2012 R2 speichert Windows Digest die Klartext-Anmeldeinformationen des Benutzers nicht zwischen.
  • Das NTLM-Authentifizierungsprotokoll speichert die Klartext-Anmeldeinformationen und den Hash nicht zwischen.
  • Kerberos erstellt keine DES- oder RC4-Schlüssel mehr. Außerdem werden die Klartext-Anmeldeinformationen oder Langzeitschlüssel des Benutzers nicht zwischengespeichert, nachdem das anfängliche Ticket Granting Ticket (TGT) erworben wurde.
  • Beim Anmelden oder Entsperren wird kein zwischengespeicherter Prüfer erstellt, daher wird die Offline-Anmeldung nicht mehr unterstützt.

Konten, die Mitglieder von geschützten Benutzern sind, die sich bei einer Windows Server 2012 R2-Domäne authentifizieren, können nicht:

  • eine Authentifizierung mit NTLM durchführen;
  • DES- oder RC4-Verschlüsselungstypen in der Kerberos-Vorauthentifizierung verwenden;
  • mit uneingeschränkter oder eingeschränkter Delegation arbeiten; oder
  • Kerberos-TGTs über die anfängliche Lebensdauer von vier Stunden hinaus verlängern.

Verwenden Sie PowerShell, um geschützte Konten in Active Directory zu finden

Es gibt mehrere Möglichkeiten, geschützte Konten in Ihrer Organisation zu finden. Sehen wir uns die Eigenschaften des integrierten Administratorkontos an.

Öffnen Sie das Konto im ADUC MMC-Snap-In und gehen Sie zum Attribut-Editor. Diese Ansicht zeigt ein Attribut namens AdminCount mit einem Wert von 1. Dies ist ein geschütztes Konto, und die Sicherheit wird vom AdminSDHolder-Container angewendet.

Die GUI eignet sich hervorragend für einmalige Suchen, doch PowerShell ist das effizientere Tool für Arbeiten, die Hunderte oder Tausende von Konten betreffen. Der folgende PowerShell-Befehl überprüft, ob das Attribut AdminCount den Wert 1 hat und somit geschützt ist.

get-aduser administrator -prop admincount | select Name, Admincount

 

Name          Admincount

----          ----------

Administrator          1

Im Vergleich dazu sehen wir die Ausgabe für ein Standardbenutzerkonto, bei dem AdminCount nicht festgelegt ist, aber einen Wert von Null hat.

get-aduser crivas -prop admincount | select Name, Admincount

Name   Admincount
----   ----------
CRivas

Die folgenden PowerShell-Befehle setzen den AdminCount für ein Konto in der Domäne auf 1 und geben dann die AdminCount-Attribute aus.

get-aduser CRIVAS -property admincount | set-adobject -Replace @{adminCount=1}

get-aduser crivas -property admincount | select Name, Admincount

Name   Admincount
----   ----------
CRivas          1

Um alle Objekte zu finden, deren AdminCount auf 1 gesetzt ist, suchen Sie in PowerShell mit dem LDAPFilter-Parameter oder mit einer spezifischen Prüfung nach Benutzerkonten oder Gruppenobjekten. Nachfolgend finden Sie Beispiele für jedes Suchkriterium.

# Finden Sie alle Konten mit einem LDAPFilter

Get-ADObject -LDAPFilter "(adminCount=1)"

# Benutzerkonten finden

Get-aduser -Filter *  -prop admincount, Canonicalname | where admincount -eq 1 | select Name, SamAccountName, AdminCount, Canonicalname

# Gruppenkonten finden

Get-ADGroup -Filter *  -prop admincount, Canonicalname | where admincount -eq 1 | select Name, SamAccountName, AdminCount, Canonicalname

Der folgende Code und die resultierende Ausgabe zeigen alle Konten, die in meiner Testumgebung auf AdminCount = 1 gesetzt sind.

et-aduser -Filter *  -prop admincount, Canonicalname | where admincount -eq 1 | select Name, SamAccountName, AdminCount, Canonicalname

 

Name                     SamAccountName AdminCount Canonicalname

----                     -------------- ---------- -------------

Administrator            Administrator           1 mk.lab/Users/Administrator

mkadmin                  mkadmin                 1 mk.lab/Users/mkadmin

krbtgt                   krbtgt                  1 mk.lab/Users/krbtgt

DJacobs                  DJacobs                 1 mk.lab/TestUserAccounts/DJacobs

CRivas                   CRivas                  1 mk.lab/TestUserAccounts/CRivas

Suchen und Ändern des AdminCount-Wert mit PowerShell

PowerShell kann die Ergebnisse aus Ihren Abfragen in einer Variablen speichern und dann die Konten der Reihe nach umgehen und alle AdminCounts, die auf 0 stehen zu 1 ändern oder umgekehrt.

# Erst finden wir die Nutzer

Get-aduser -Filter *  -prop admincount, Canonicalname -searchbase "OU=TestUserAccounts,DC=mk,DC=lab" | where admincount -eq 1 | select Name, SamAccountName, AdminCount, DistinguishedName


Name    SamAccountName AdminCount DistinguishedName
----    -------------- ---------- -----------------
CRivas  CRivas                  1 CN=CRivas,OU=TestUserAccounts,DC=mk,DC=lab
DJacobs DJacobs                 1 CN=DJacobs,OU=TestUserAccounts,DC=mk,DC=lab

#Nun lassen wir die Suche durchlaufen und speichern die Ergebnisse in einer Variable namens $AdminCount.

$AdminCount = Get-aduser -Filter * -prop admincount, Canonicalname -searchbase "OU=TestUserAccounts,DC=mk,DC=lab" | where admincount -eq 1 | select Name, SamAccountName, AdminCount, DistinguishedName

# Wir nehmen jetzt alle Nutzer in $AdminCount und ändern AdminCount von 1 zu 0

$AdminCount | Foreach-Object {set-adobject $_.DistinguishedName -Replace @{adminCount=0}}

#Lassen sie uns nun das Ergebnis prüfen

Get-aduser CRIVAS -prop admincount | select Name, SamAccountName, AdminCount, DistinguishedName

Name   SamAccountName AdminCount DistinguishedName
----   -------------- ---------- -----------------
CRivas CRivas                  0 CN=CRivas,OU=TestUserAccounts,DC=mk,DC=lab


Get-aduser DJACOBS -prop admincount | select Name, SamAccountName, AdminCount, DistinguishedName

Name    SamAccountName AdminCount DistinguishedName
----    -------------- ---------- -----------------
DJacobs DJacobs                 0 CN=DJacobs,OU=TestUserAccounts,DC=mk,DC=lab

Privilegierte Konten und geschützte Benutzer helfen Administratoren dabei, böswilliges Verhalten, versehentliche Kontensperren und Fehler bei Sicherheitsberechtigungen zu stoppen. Es braucht Zeit, diese Konzepte zu lernen und zu richtig einzusetzen.

Implementieren Sie Best Practices, wie von Microsoft beschrieben, und dokumentieren Sie Ihre Änderungen. Dies hilft Ihnen, wenn Sie die Einstellungen überarbeiten, auch noch Jahre später Ihre bisherigen Schritte und die Gründe für diese nachzuvollziehen.

Erfahren Sie mehr über Serverbetriebssysteme