Lokale Administratoren mit Restricted Groups: Members vor Rollout prüfen

Was Richtlinien für lokale Administratoren mit Restricted Groups tatsächlich steuern

Die Prüfung von Richtlinien für lokale Administratoren mit Restricted Groups beginnt mit einer praktischen Frage: Welche Identitäten müssen auf jeder Arbeitsstation oder jedem Mitgliedsserver administrative Zugriffsrechte behalten? Ein GPO-Eintrag ist nur ein Teil der Nachweise. Bevor Sie eine verbindliche Mitgliedschaftsvorgabe ausrollen, vergleichen Sie den vorgesehenen Personenkreis mit der tatsächlichen Gruppe, prüfen Sie die beiden Mitgliedschaftseigenschaften der Richtlinie und weisen Sie nach, welche Computer sie erhalten.

Dieser Leitfaden beschreibt ein Prüf- und Rolloutverfahren, das am 4. Oktober 2026 anhand der Microsoft-Dokumentation und der Implementierung von etc-collector überprüft wurde. Die Befehle sind Beispiele zur Abfrage durch einen autorisierten Windows-Administrator; keiner wurde für diesen Artikel in einer Domäne ausgeführt. Es werden weder Mitgliedschaftsänderungen noch Ergebnisse eines Rollouts behauptet.

Microsoft dokumentiert zwei unterschiedliche Vorgänge für Restricted Groups:

Microsoft unterstützt diesen Mechanismus für lokale Gruppen, nicht zur Verwaltung der Mitgliedschaft von Domänengruppen. Eine Domänensicherheitsgruppe zur lokalen Gruppe Administrators eines Computers hinzuzufügen ist ein anderer Vorgang als die Mitglieder dieser Domänengruppe selbst zu bearbeiten. Dieses Runbook betrifft Arbeitsstationen und Mitgliedsserver; Domänencontroller benötigen ein separates Administrationskonzept.

Die lokale Gruppe unterscheidet sich außerdem von der Zuweisung von Benutzerrechten. Prüfen Sie GPO-Berechtigungen wie SeDebug und SeTcb getrennt von der lokalen Administrators-Mitgliedschaft. Eine Mitgliedschaftsprüfung kann diese Rechtezuweisungen nicht bestätigen.

Funktionsweise: Die Richtlinie lesen, bevor Sie den Befund interpretieren

Prüfen Sie in den SYSVOL-Dateien der GPO Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf, einschließlich des vollständigen Abschnitts [Group Membership]. Erfassen Sie GPO-GUID, Anzeigenamen, Quelldomänencontroller, Erfassungszeitpunkt und den Erfolg des Dateizugriffs. Bewahren Sie die unveränderten Zeilen zusammen mit der Ansicht des Richtlinieneditors auf.

Das folgende veranschaulichende Template entspricht dem vom Collector gelesenen Schlüsselformat. Werte in spitzen Klammern sind Platzhalter, keine gültigen SIDs und keine ausrollbare Mitgliedschaftsvorgabe:

[Group Membership]
*S-1-5-32-544__Members = *<approved-domain-group-SID>,*<approved-local-account-SID>

Identifizieren Sie den Sicherheitsprinzipal vor __ und prüfen Sie dann, ob die tatsächliche Datei für ihn __Members, __Memberof, beide oder keinen der beiden Schlüssel enthält. Erfassen Sie einen ausdrücklich leeren __Members-Wert getrennt von einem fehlenden Schlüssel. Diese Unterschiede lassen sich aus einem leeren geparsten Mitgliederarray allein nicht rekonstruieren.

Microsofts Verfahren für Sicherheitsvorlagen zeigt die beiden Bearbeitungsbereiche: Members of this group und This group is a member of. Der Artikel beschreibt den historischen Snap-In-Ablauf unter Windows Server 2003; nutzen Sie ihn zum Verständnis der Eigenschaften, statt seine alte Oberfläche oder Plattformliste als aktuelle Bereitstellungsempfehlung zu behandeln.

Bevorzugen Sie eine SID-basierte Prüfung, wenn sich Anzeigenamen zwischen Sprachen unterscheiden. Microsofts Dokumentation zu Sicherheitsbezeichnern weist S-1-5-32-544 als integrierte Gruppe Administrators aus. Halten Sie sowohl die SID als auch den aufgelösten Namen in den Nachweisen fest. Dass ein lokalisierter Name unter Windows gültig ist, bedeutet nicht, dass der Zeichenkettenvergleich eines Collectors ihn erkennt.

Bearbeiten Sie eine produktive SYSVOL-Datei nicht manuell, um einen Auditbefund verschwinden zu lassen. Prüfen und erstellen Sie die vorgesehene GPO über Ihren genehmigten Verwaltungsprozess und untersuchen Sie anschließend die resultierende Datei sowie das Verhalten der Endgeräte.

Erkennung: Mitgliedschaft, Geltungsbereich und Änderungen nachweisen

Schritt 1 — Den Ausgangszustand des Endgeräts erfassen

Ermitteln Sie auf jeder ausgewählten Arbeitsstation oder jedem Mitgliedsserver die aktuelle direkte Mitgliedschaft, bevor Sie die Richtlinie ändern. Microsoft gibt dieses genaue Get-LocalGroupMember-Beispiel für einen englischen Gruppennamen an:

Get-LocalGroupMember -Group "Administrators"

Für eine sprachunabhängige Gruppenauswahl definiert dieselbe Dokumentation den Parameter -SID. Dieses Abfragebeispiel verwendet den dokumentierten Parameter mit der SID der integrierten Gruppe:

Get-LocalGroupMember -SID 'S-1-5-32-544'

Verwenden Sie einen unterstützten Windows-PowerShell-Kontext; Microsoft weist darauf hin, dass das LocalAccounts-Modul in 32-Bit-PowerShell auf einem 64-Bit-System nicht verfügbar ist. Speichern Sie das Ergebnis mit Computeridentität und Zeitstempel. Falls der Befehl fehlschlägt, bewahren Sie den Fehler auf und kennzeichnen Sie das Gerät als ungeklärt, statt eine leere Gruppe zu erfassen.

Erfassen Sie für jeden zurückgegebenen Sicherheitsprinzipal dessen SID, aufgelöstes Konto oder Gruppe, betrieblich Verantwortlichen und Zugriffsgrund. Ist eine Domänengruppe aufgeführt, prüfen Sie gesondert die Personen und verschachtelten Gruppen, die darüber berechtigt sind. Die Liste direkter lokaler Mitglieder allein beantwortet nicht, wer letztlich über diese Gruppe Zugriff erhält.

Schritt 2 — Nachweisen, dass der Computer die vorgesehene Richtlinie erhält

Prüfen Sie GPO-Verknüpfungen, den Status der Computerkonfiguration, Sicherheitsfilterung, WMI-Filterung und Vererbung. Berücksichtigen Sie repräsentative Geräte aus dem vorgesehenen Geltungsbereich und Geräte, die außerhalb bleiben sollen. Leiten Sie die Anwendung nicht aus einem beschreibenden GPO-Namen oder dem Vorhandensein ihrer Datei in SYSVOL ab.

Microsoft dokumentiert gpresult für Informationen zum Richtlinienergebnissatz. Diese ausschließlich lesenden Beispiele kombinieren die dokumentierten Schalter für Computerbereich und Ausgabe:

gpresult /scope computer /r
gpresult /scope computer /h computer-policy.html

Der erste Befehl zeigt eine Zusammenfassung; der zweite speichert einen HTML-Bericht. Führen Sie sie in einem autorisierten Kontext aus, der Computerrichtliniendaten abrufen kann. Bewahren Sie Nachweise über angewendete und abgelehnte GPOs, den Zeitstempel und mögliche Berichtsfehler auf. Für ARM64 nennt Microsofts Seite die SysWow64-Version von gpresult für die HTML-Option.

Untersuchen Sie Anwendung und Rangfolge mit RSoP und bestätigen Sie anschließend die tatsächliche Mitgliedschaft auf dem Endgerät. Weder ein Bericht noch eine lesbare Vorlage ersetzt diese abschließende Beobachtung.

Schritt 3 — Andere Stellen identifizieren, die Mitgliedschaften ändern

Inventarisieren Sie die Elemente Local Users and Groups der Gruppenrichtlinien-Einstellungen, ihre Aktionen und Zielgruppensteuerung. Microsofts Referenz zu Gruppenrichtlinien-Einstellungen nennt diese Erweiterung als Mechanismus zum Ändern lokaler Benutzer und Gruppen. Fragen Sie auch die Verantwortlichen für die Geräteverwaltung nach Skripten und MDM-Profilen, die dieselbe Gruppe beeinflussen.

Prüfen Sie bei MDM-verwalteten Geräten den LocalUsersAndGroups Policy CSP. Seine Aktion Update kann bestimmte Mitglieder hinzufügen oder entfernen und dabei nicht angegebene Mitglieder beibehalten; Restrict ersetzt die Mitgliedschaft. Nehmen Sie bei der Restrict-Aktion dieses CSP für die integrierte Gruppe Administrators das integrierte Administrator-Konto in die Liste hinzuzufügender Mitglieder auf; Microsoft dokumentiert einen Fehler, wenn ein Ersetzungsvorgang versucht, es zu entfernen. Die Dokumentation warnt, dass die gleichzeitige Anwendung der CSP-Richtlinien LocalUsersAndGroups und RestrictedGroups auf ein Gerät nicht unterstützt wird. Diese Warnung betrifft die beiden benannten CSP-Richtlinien; sie ist keine allgemeine Vorrangregel für jede Kombination aus GPO und MDM.

Dokumentieren Sie, welches System für jede Gerätepopulation die Mitgliedschaft steuert. Klären Sie überlappende Anweisungen vor dem Pilotprojekt; raten Sie nicht, welche Quelle den gewünschten Endzustand hinterlassen wird.

Schritt 4 — Hinzufügungen und Entfernungen überwachen

Microsofts Ereignisseiten bestätigen diese Einträge im Sicherheitsprotokoll unter Audit Security Group Management:

Erfassen Sie die Ereignisse auf den relevanten Endgeräten, nicht nur auf Domänencontrollern. Wählen Sie für diesen Ablauf Ereignisse mit TargetSid gleich S-1-5-32-544 aus und bewahren Sie Computer, Uhrzeit, MemberSid, handelnde Identität und SubjectLogonId auf. Prüfen Sie die erfolgreiche Auditerfassung und Weiterleitung, bevor Sie sich auf das Ausbleiben von Ereignissen verlassen.

Vergleichen Sie Änderungen mit dem Bereitstellungsprotokoll und den Anwendungstests. Eine unerwartete Hinzufügung nach einer Richtlinienaktualisierung kann die Untersuchung einer weiteren Verwaltungsquelle oder einer manuellen Änderung rechtfertigen; sie identifiziert für sich allein weder die verantwortliche GPO noch belegt sie einen Angriff. Diese Ereignisse beschreiben Mitgliedschaftsänderungen, nicht die vollständige aktuelle Mitgliederliste.

Abhilfe: Eine genehmigte Mitgliedschaftsvorgabe ausrollen (Remediation)

Schritt 1 — Den berechtigten Personenkreis genehmigen

Erstellen Sie getrennte Vorgaben, wenn Arbeitsstations- und Serverrollen unterschiedliche Anforderungen haben. Verlangen Sie für jeden beibehaltenen Sicherheitsprinzipal einen Verantwortlichen, Zweck und Geltungsbereich. Bitten Sie bei jeder vorgeschlagenen Entfernung die betroffenen Anwendungs- oder Supportverantwortlichen, die Auswirkungen zu prüfen. Erfassen Sie Ausnahmen mit Gerätepopulation, Begründung und Prüfdatum.

Nutzen Sie das Tier-Verwaltungsmodell zur Festlegung von Verantwortlichen, administrativen Personenkreisen und Anmeldegrenzen. Eine lokale Mitgliedschaftsvorgabe gehört in diese Architektur; sie ersetzt nicht die Entscheidung, wo sich diese Identitäten anmelden dürfen.

Schritt 2 — Einen nutzbaren Wiederherstellungsweg sicherstellen

Testen Sie vor dem Ersetzen den genehmigten Wiederherstellungsprozess auf Pilotgeräten. Bestätigen Sie das vorgesehene lokale Administratorkonto, seine erforderliche Mitgliedschaft und die Fähigkeit des autorisierten Teams, den Zugriff wiederherzustellen, falls die normale Domänenadministration ausfällt. Halten Sie Zugangsdaten aus Exporten der Richtlinienprüfung und gemeinsam genutzten Nachweisdateien heraus.

Windows LAPS verwaltet und sichert Kennwörter lokaler Administratorkonten auf unterstützten eingebundenen Geräten. Prüfen Sie bei einem durch LAPS verwalteten Wiederherstellungskonto die Kennwortverwaltung und den autorisierten Abruf getrennt von der Mitgliedschaft des Kontos und einem nutzbaren Anmeldeweg. Das bloße Vorhandensein einer LAPS-Richtlinie schließt den Wiederherstellungstest nicht ab.

Schritt 3 — Richtlinie und Freigabekriterien für den Piloten vorbereiten

Sichern Sie die bestehende GPO und bewahren Sie die bisherigen Mitgliedschaftsbeobachtungen auf. Bereiten Sie die genehmigte Liste im Richtlinieneditor vor, prüfen Sie die resultierende Vorlage und definieren Sie die genauen Verknüpfungen und Filter des Piloten. Vereinbaren Sie Verantwortlichkeiten für das Zurückrollen und ein Wiederherstellungsverfahren für die Mitgliedschaft, nicht nur für die GPO-Konfiguration.

Gehen Sie nicht davon aus, dass das Entfernen einer GPO-Verknüpfung jedes bei der Durchsetzung entfernte Mitglied wiederherstellt. Verlangen Sie ein getestetes Wiederherstellungsverfahren, das den notwendigen Zugriff zurückbringt und die maßgebliche Quelle für Mitgliedschaftsänderungen berücksichtigt. Pausieren Sie, wenn Erfassung, Zuständigkeit, Namensauflösung oder Geltungsbereich ungeklärt bleiben.

Schritt 4 — Nach der Anwendung validieren

Rollen Sie die Richtlinie über den genehmigten Änderungsprozess auf die Pilotpopulation aus. Wiederholen Sie nach der Richtlinienverarbeitung die oben gezeigten Abfragebefehle für Mitgliedschaft und gpresult. Vergleichen Sie die SIDs vor und nach der Änderung mit der genehmigten Liste und dem dokumentierten Verhalten des integrierten Kontos. Prüfen Sie Hinzufügungen und Entfernungen im Änderungsfenster.

Bitten Sie Anwendungs- und Supportverantwortliche, ihre tatsächlichen administrativen Aufgaben, Wartungsjobs und den Wiederherstellungszugriff zu testen. Wiederholen Sie Beobachtungen nach späterer Richtlinienverarbeitung oder Geräteverwaltungsaktivität, um widersprüchliche Änderungsquellen aufzudecken. Ein nicht erreichbares Gerät oder ein fehlgeschlagener Anwendungstest bleibt ein offenes Freigabekriterium für den Rollout.

Schritt 5 — Nur auf Basis dokumentierter Nachweise erweitern

Erweitern Sie nach Geräterolle oder administrativem Personenkreis, nachdem der Pilotverantwortliche die Ergebnisse akzeptiert hat. Halten Sie Ausnahmen ausdrücklich fest, statt sie in einer größeren Gruppe zu verstecken. Planen Sie spätere Mitgliedschaftsprüfungen und Benachrichtigungen bei Abweichungen vom genehmigten Zustand. Lassen Sie ausgeschlossene und nicht beobachtete Geräte im Bericht sichtbar.

Wie EtcSec dies erkennt

EtcSecs Prüfung M29_LOCAL_ADMIN_NOT_RESTRICTED ist ein Signal zur Konfigurationsprüfung. Der Quellcode von etc-collector wurde am Commit 15fc6399c215eabc415c370b762303cfcd7a353a gelesen, einschließlich m29_local_admin.go:38, gptmpl_parser.go:367 und SMB client.go:154 sowie :214.

Die tatsächlichen Zweige von Detect() sind:

Count 1 ist das Signal dieses Detektors, keine Anzahl betroffener Computer. Der Vergleich akzeptiert keine anderen lokalisierten Namen. Er bewertet weder MembersSIDs noch MemberOfSIDs, den genehmigten Personenkreis, GPO-Verknüpfungen oder Anwendbarkeit oder die tatsächliche Endgerätemitgliedschaft.

Der Parser fasst Members und Memberof in einer Spezifikation pro Sicherheitsprinzipal zusammen und erstellt diese Spezifikation, bevor er das Suffix prüft. Ein leerer Members-Wert und eine fehlende Members-Eigenschaft sind im resultierenden Mitgliederarray nicht unterscheidbar. Eine passende Spezifikation, die nur Memberof enthält, kann den Befund daher unterdrücken, ohne eine Members-Ersatzvorgabe festzulegen.

Der SMB-Provider füllt die Richtlinienwerte, wenn das Lesen von GptTmpl.inf erfolgreich ist. Er fügt auch dann ein Richtlinienobjekt ein, wenn dieser Lesevorgang fehlschlägt. Für diese Prüfung kann ein fehlgeschlagener Lesevorgang wie eine fehlende Konfiguration aussehen; der Befund bietet keine gesonderte Unterscheidung für eine erfolgreiche Erfassung. Ein passender Eintrag in einer GPO außerhalb des effektiven Geltungsbereichs eines Computers kann das Signal ebenfalls unterdrücken.

Die Rolloutentscheidung sollte die genaue Richtlinie, genehmigten Personenkreise, Pilotbeobachtungen, den Wiederherstellungstest und ungeklärte Geräte benennen. Ein stiller Detektor allein reicht nicht als Nachweis aus, um diese Entscheidung abzuschließen.