redircmp redirusr Standardcontainer Gruppenrichtlinie: AD-Leitfaden

Was sind Standardcontainer in Active Directory?

Die praktische Frage hinter redircmp redirusr Standardcontainer Gruppenrichtlinie lautet: Wo landen neue Identitäten, und gehört dieser Speicherort zur vorgesehenen Richtlinienstruktur? Active Directory legt bei der Installation der Domäne CN=Computers und CN=Users an. Dies sind Container und keine Organisationseinheiten. Microsoft erläutert ihre Standardfunktion in der Anleitung zur Containerumleitung; die Übersicht zu Gruppenrichtlinien bezeichnet eine OU als die niedrigste AD-Ebene, der Gruppenrichtlinien zugewiesen werden können.

Sie können eine GPO nicht direkt mit diesen Standardcontainern verknüpfen. Das bedeutet nicht, dass deren Computer und Benutzer keine Gruppenrichtlinien erhalten: Mit Standorten und Domänen verknüpfte GPOs können weiterhin gelten, und lokale Richtlinien bleiben relevant. Die Lücke ist enger gefasst. Ein Objekt in CN=Computers liegt außerhalb des Teilbaums einer Richtlinie, die nur mit Ihrer Arbeitsplatz- oder Server-OU verknüpft ist. Die Redircmp-Referenz von Microsoft bestätigt, dass eine direkte Gruppenrichtlinienverknüpfung mit dem Standardcontainer fehlt. Die Regeln für den Geltungsbereich von Standorten, Domänen und OUs beschreibt die oben zitierte Gruppenrichtlinienübersicht.

Dieser Leitfaden trennt vier Fragen: Wo befinden sich Objekte derzeit, wohin führt die künftige Standarderstellung, welche Richtlinien erreichen tatsächlich den Client, und welche Computerkonten erfordern eine Überprüfung ihrer Bereitstellung? Ein Befund zum Standardcontainer beantwortet die erste Frage. Die Umleitung behandelt die zweite. Keines von beiden belegt den LAPS-Zustand des Clients oder die Sicherheit eines vorbereiteten Computerkontos.

Funktionsweise: Zielort und Richtliniengeltungsbereich sind getrennt

Die Standarderstellung folgt einem Verzeichnisverweis

Microsoft dokumentiert die Standardziele im Domänenattribut wellKnownObjects. Ältere Erstellungs-APIs verwenden diese Verweise für Benutzer, Gruppen und Computer. Die Umleitungsprogramme ändern die Verweise auf OUs, die Administratoren auswählen; sie wandeln die ursprünglichen Container nicht in OUs um. Neue Objekte, die über die betroffenen Standardpfade erstellt werden, verwenden anschließend das neue Ziel. KB324949 beschreibt die Verweise und die davon abhängigen Vorgänge.

Ein Beitrittsablauf kann ein Ziel auch ausdrücklich angeben. Die Referenz zu netdom join dokumentiert /ou und erklärt, dass die Kontoerstellung das Standardcomputerziel der Domäne verwendet, wenn diese Option fehlt. Bei einer normalen Installation ohne Umleitung ist dies CN=Computers; nach der Umleitung kann es die festgelegte OU sein. Ein bestehendes Konto, das für einen Beitritt wiederverwendet wird, ist ein weiterer Fall. Gehen Sie daher nicht davon aus, dass jeder Beitritt zwangsläufig ein neues Objekt im Standardcontainer erstellt.

Bei Benutzern beeinflusst redirusr den Standarderstellungsort von Benutzern, Gruppen und Vertrauensbenutzerkonten, die über die dokumentierten APIs erstellt werden. Die Platzierung einer Gruppe bedeutet nicht, dass die Gruppe selbst die Benutzerkonfiguration wie ein angemeldeter Benutzer verarbeitet. Trennen Sie Kontoinventar und Richtlinienverarbeitung, und erhalten Sie die Standardkonten, sofern keine gesondert geprüfte Änderung etwas anderes verlangt. S1 beschreibt die umfassendere Menge von Objekten, die vom Users-Ziel betroffen sind.

Die OU-Platzierung schafft einen möglichen Richtlinienpfad, keine abgeschlossene Schutzmaßnahme

Der Geltungsbereich von Gruppenrichtlinien folgt Verknüpfungen an Standorten, Domänen und OUs einschließlich der relevanten Hierarchie übergeordneter OUs. Das Verschieben eines Computers in die vorgesehene OU kann ihn dieser Hierarchie unterstellen; dennoch müssen die Verarbeitung und die beabsichtigten Einstellungen geprüft werden. Die Übersicht von Microsoft beschreibt den standortabhängigen Geltungsbereich und die Verarbeitung auf dem Client.

Unser Leitfaden zur GPO-Sicherheitsfilterung behandelt die nächste Ebene: den Geltungsbereich der Verknüpfung, Read für Computer, Apply für Benutzer und die Unterscheidung zwischen dem Erlauben des Abrufs und dem Erweitern der Zielgruppe. Seine Kernaussage lautet, dass der richtige Speicherort und eine verknüpfte Richtlinie ohne die erforderlichen Berechtigungen und Verarbeitungsbedingungen nicht ausreichen. Verwenden Sie diese Prüfung nach der Korrektur der Platzierung.

LAPS hat eigene Bereitstellungsanforderungen. Microsoft trennt in seinem Verfahren für AD-gestütztes Windows LAPS die Schreibberechtigung des Geräts, die Berechtigung zum Kennwortabruf, die Geräterichtlinie und die Überprüfung von Verzeichnisaktualisierungen. Ein Computer außerhalb einer OU, die die einzige Quelle seiner LAPS-Richtlinie ist, kann daher eine Abdeckungslücke aufweisen; ein Computer, der eine gleichwertige Richtlinie über einen anderen unterstützten Weg erhält, möglicherweise nicht.

Der zugehörige Leitfaden zu LAPS-Abdeckungslücken untersucht Teilbereitstellungen, ältere Speicherung, übermäßige Wiederherstellungsrechte und die Nachweise zur Prüfung der Rotation. Er bietet die anschließende Prüfung, wenn die Platzierung eine mögliche Lücke aufzeigt. Die Anzahl der Computer in CN=Computers misst nicht die Anzahl der Computer ohne LAPS.

Platzierung messen, bevor Sie Standardziele ändern

1. Computer im Standardcontainer inventarisieren

Verwenden Sie eine festgelegte Domäne und erfassen Sie Suchbasis, Erfassungszeit, Aktivierungsstatus und Objektkennungen. Das folgende Beispiel für Leser passt die dokumentierten Parameter Filter, SearchBase, SearchScope und Properties von Get-ADComputer an. Die Domänen- und Objektnamen in diesem Leitfaden sind fiktive Platzhalter.

Get-ADComputer -Filter * -SearchBase 'CN=Computers,DC=contoso,DC=com' -SearchScope OneLevel -Properties Enabled,userAccountControl

Ziel ist es, direkte untergeordnete Objekte für eine Platzierungsprüfung aufzulisten. Diese Abfrage enthält deaktivierte Konten, während der geprüfte EtcSec-Platzierungsdetektor sie ausschließt. Halten Sie diese Mengen beim Ergebnisvergleich auseinander. Ein administratives Inventar und die Anzahl eines Detektors müssen nicht identisch sein, weil ihre Prüfbedingungen abweichen.

Eine Containeranzahl misst die Verzeichnisplatzierung, nicht die Schutzabdeckung. Entscheiden Sie, welche Objekte zur Produktion gehören, welche genehmigte Bereitstellungskonten sind und welche untersucht werden müssen. Erfassen Sie für jedes Objekt das vorgeschlagene Ziel und den verantwortlichen Eigentümer. Dies sind Prüfentscheidungen; der Befehl liefert Verzeichnisdaten und keine Bewertung des Endpunktschutzes.

2. Benutzer inventarisieren, ohne den Container als eine einzige Kontoklasse zu behandeln

Das folgende Beispiel setzt den Standardcontainer Users in das dokumentierte Suchmuster für Container ein und fordert den Aktivierungsstatus über Properties an. Get-ADUser dokumentiert beide Parameter:

Get-ADUser -Filter * -SearchBase 'CN=Users,DC=contoso,DC=com' -Properties Enabled

Damit werden Benutzer abgerufen, nicht sämtliche Gruppen und besonderen Objekte im Container inventarisiert. Microsoft behandelt in der Umleitungsanleitung ausdrücklich Standardgruppen und Vertrauensbenutzerkonten. Unterscheiden Sie vor der Migration gewöhnliche Benutzer von integrierten oder anwendungsabhängigen Konten und bestimmen Sie, welche Objekte an ihrem Ort bleiben müssen.

Prüfen Sie Quelle und Ziel gemeinsam. Ein Benutzer, der in eine andere OU verschoben wird, kann in eine andere Benutzerrichtlinienhierarchie gelangen, ebenso wie ein Computer in eine andere Computerrichtlinienhierarchie gelangen kann. Ermitteln Sie die erwartete Änderung anhand des Modells zum Gruppenrichtliniengeltungsbereich, bevor Sie das Objekt verschieben. Ein aufgeräumteres Verzeichnis ist kein ausreichendes Abschlusskriterium.

3. Das Signal zur Computerkontobereitstellung gesondert prüfen

Ein Computer kann in einer geeigneten OU vorbereitet sein und trotzdem eine Prüfung erfordern. Umgekehrt muss ein aktiver Computer im Standardcontainer nicht das Bereitstellungssignal erfüllen. Um das zugrunde liegende Attribut abzurufen, verwendet dieses Beispiel den dokumentierten Parameter Properties von Get-ADComputer:

Get-ADComputer -Filter * -Properties userAccountControl

Microsoft weist in seiner UserAccountControl-Referenz PASSWD_NOTREQD den Wert 0x20 und WORKSTATION_TRUST_ACCOUNT den Wert 0x1000 zu. Der Collector kombiniert diese zu 0x1020, dezimal 4128, und prüft, ob beide Bits gesetzt sind. Die genaue Prüfbedingung wird unten erläutert; ersetzen Sie sie nicht durch einen Gleichheitsvergleich mit dem gesamten Attribut.

Fragen Sie bei passenden Konten, wer das Objekt erstellt hat, welchem Bereitstellungsauftrag es dient, ob der vorgesehene Computer beigetreten ist und welche unabhängigen Aktivitätsnachweise vorliegen. Legen Sie mit dem Kontoeigentümer einen lokalen Prüfzeitraum fest. Der Detektor liefert weder eine Altersgrenze noch eine verifizierte Beitrittshistorie; beides darf daher nicht als angebliches Detektorergebnis erscheinen.

Erkennung: Verzeichnissignale mit Clientergebnissen abgleichen

Ein falsch platziertes Objekt ist ein Kandidat für eine Prüfung des Geltungsbereichs

Behandeln Sie die Platzierung als Signal zur Untersuchung der beabsichtigten Richtlinienbeziehung. Erfassen Sie die für den Computer erwarteten Basis-GPOs, deren Verknüpfungsorte und die tatsächlichen Clientergebnisse. Die gpresult-Dokumentation definiert die Berichte zum Richtlinienergebnissatz sowie die hier verwendeten Schalter für Computerbereich und Zusammenfassung:

gpresult /scope computer /r

Führen Sie die dokumentierte Prüfung mit dem entsprechenden Zugriff auf dem betroffenen Computer aus. Vergleichen Sie die angewendeten GPOs mit der erwarteten Basis und prüfen Sie anschließend die relevanten Einstellungen. Ein Bericht über die Richtlinienanwendung ist ein anderer Nachweis als eine erfolgreiche LAPS-Sicherung oder der wirksame Zustand einer Überwachungseinstellung. Dieser Artikel behauptet keine Ausgabe aus einer realen Domäne.

Für natives AD-gestütztes Windows LAPS nennt Microsofts Bereitstellungsverfahren das Ereignis 10018 als Nachweis, dass ein neues Kennwort erfolgreich in AD aktualisiert wurde. Verwenden Sie es bei einer entsprechenden Bereitstellung als gesonderte Ergebnisprüfung. Ein fehlendes Ereignis erfordert eine Untersuchung des Zeitpunkts und der verfügbaren Protokolle; es ist kein aus dem DN des Objekts abgeleiteter Beweis.

Historische Standardkennwörter erfordern Versionskontext

Das Voraberstellen kann ein legitimer Ablauf sein. Microsoft beschreibt in seiner Anleitung zu Domänenbeitrittsberechtigungen, wie ein Administrator ein Computerkonto erstellt und eine andere autorisierte Identität es wiederverwendet. Ein vorbereitetes Konto benötigt Lebenszyklusverwaltung, doch die Vorbereitung allein belegt keine Kompromittierung.

Es gibt ein gesondertes historisches Risiko. Die NetProvisionComputerAccount-Referenz dokumentiert eine ausdrückliche Option, die den kleingeschriebenen Computernamen als Anfangskennwort verwendet, und empfiehlt, diese Option nach Möglichkeit zu vermeiden. Dies beschreibt einen bestimmten Bereitstellungsmodus. Die UAC-Maske liest das Geheimnis nicht und kann weder belegen, dass diese Option verwendet wurde, noch dass ein Kennwort leer oder vorhersehbar ist oder dass eine Authentifizierung erfolgreich war.

Die Version ist entscheidend. Microsoft beschreibt unter Neuerungen in Windows Server 2025 zufällig erzeugte Anfangskennwörter für Computerkonten, Kontrollen zur Ablehnung namensbasierter Standardkennwörter und dass ADUC/ADAC die Erstellung von Konten für Versionen vor Windows 2000 nicht mehr erlauben. Die dokumentierte Richtlinie lautet Domain controller: Refuse setting default machine account password. Prüfen Sie Domänencontrollerversionen, Erstellungswerkzeuge und diese Richtlinie, bevor Sie das historische Modell auf aktuelle Konten anwenden. Eine aufgegebene Identität benötigt weiterhin einen Eigentümer und eine Lebenszyklusentscheidung, auch wenn ihr Anfangsgeheimnis zufällig war.

Abhilfemaßnahmen: künftige Erstellung umleiten und vorhandene Objekte migrieren (Remediation)

1. Ziel-OUs und ihre Zuständigkeiten entwerfen

Wählen Sie Ziel-OUs nach Verwaltungs- und Richtlinienanforderungen aus. Entscheiden Sie, ob die Standarderstellung in eine Bereitstellungs-OU oder in die endgültige Produktionshierarchie führen soll, und dokumentieren Sie, wer den Übergang abschließt. Eine OU namens „Staging“ ist nur sinnvoll, wenn ihre vorgesehene Richtlinie und das verantwortliche Team klar sind. Die Gruppenrichtlinienübersicht behandelt das Abwägen von Delegations- und Richtlinienanforderungen.

Die folgenden Befehle passen Beispiel 1 von New-ADOrganizationalUnit an und setzen zwei Zielnamen sowie die fiktive Domäne ein. Das dokumentierte Beispiel erstellt eine OU, deren Schutz vor versehentlichem Löschen implizit aktiviert ist. Jeder Vorgang wird getrennt gezeigt:

New-ADOrganizationalUnit -Name 'MyComputers' -Path 'DC=contoso,DC=com'

New-ADOrganizationalUnit -Name 'MyUsers' -Path 'DC=contoso,DC=com'

Bereiten Sie die vorgesehenen Richtlinien und die Delegation vor, bevor Sie diese OUs als Standardziele verwenden. Die OU-Erstellung ist ein Vorgang zur Objektverwaltung; sie verknüpft keine GPO, autorisiert keine Bereitstellung und belegt nicht, dass ein Gerät eine Basisrichtlinie verarbeitet hat.

2. Die Voraussetzungen für die Umleitung prüfen

KB324949 verlangt eine Domänenfunktionsebene Windows Server 2003 oder höher, eine vorhandene Ziel-OU, Anmeldeinformationen eines Domänenadministrators und einen erreichbaren PDC. Prüfen Sie die tatsächliche Domänenkonfiguration, statt die Funktionsebene aus dem Betriebssystem eines einzelnen Servers abzuleiten.

Die ältere Redircmp-Seite führt historische Versionen der Funktionsebene auf. Verwenden Sie für dieses Verfahren die Anforderung „2003 oder höher“ aus dem aktuellen KB. Die Redircmp-Referenz verlangt außerdem eine Eingabeaufforderung mit erhöhten Rechten. Das Anheben einer Domänenfunktionsebene ist, falls erforderlich, eine gesonderte Kompatibilitätsentscheidung; es sollte in einem Artikel zur Objektplatzierung nicht als beiläufiger Schritt dargestellt werden.

3. Computer- und Benutzerstandardziele unabhängig ändern

Die nächsten beiden Befehle geben Microsofts Beispiele aus S1 ohne das Präfix der Eingabeaufforderung wieder. Jeder Befehl ändert ein eigenes Standardziel:

redircmp ou=mycomputers,DC=contoso,dc=com

redirusr ou=myusers,DC=contoso,dc=com

Die allgemeine dokumentierte Syntax lautet redircmp container-dn und c:\windows\system32\redirusr container-dn. Das Argument ist der Distinguished Name der Ziel-OU. Setzen Sie das genehmigte Ziel ein; ein erfolgreicher Befehl betrifft die künftige Erstellung über die betroffenen Standardpfade.

Keines der beiden Programme verschiebt vorhandene Objekte. Bearbeiten Sie künftige und bestehende Platzierung als getrennte Aufgaben. Die Bereitstellung mit ausdrücklich angegebener OU und die Kontowiederverwendung müssen ebenfalls eigenständig geprüft werden; sie lassen sich nicht aus dem neuen Standardziel ableiten.

4. Ausgewählte vorhandene Objekte unter Prüfung der Richtlinien migrieren

Bewerten Sie Anwendungsabhängigkeiten, Kontozweck und die erwartete Richtlinienänderung, bevor Sie jedes Objekt auswählen. Der folgende Befehl passt die dokumentierte Syntax für Identity und TargetPath von Move-ADObject an einen fiktiven vorhandenen Computer an:

Move-ADObject -Identity 'CN=PC01,CN=Computers,DC=contoso,DC=com' -TargetPath 'OU=MyComputers,DC=contoso,DC=com'

Wählen Sie tatsächliche Objekte anhand eines geprüften Inventars aus. Verschieben Sie nicht pauschal alles aus CN=Users oder CN=Computers. Der KB zur Umleitung behandelt Abwärtskompatibilität und Standardkonten; die Gruppenrichtlinienübersicht erläutert die Vererbung, durch die eine Zieländerung betriebliche Bedeutung erhält.

Bestätigen Sie nach dem Verschieben den neuen Speicherort des Objekts und wiederholen Sie die Richtlinienprüfung auf dem Client. Schließen Sie die Platzierungsaufgabe mit Verzeichnisnachweisen ab und eine Schutzlücke mit Nachweisen für den jeweiligen Schutz. Diese Prüfungen hängen zusammen, haben aber unterschiedliche Abschlusskriterien.

5. Erstellung, Wiederverwendung und Richtlinienverwaltung gezielt delegieren

Microsoft trennt in seiner Anleitung zur Delegation der Verwaltung Aufgaben wie Computerbeitritt, Benutzerverwaltung und Verwaltung von GPO-Verknüpfungen. Delegieren Sie die erforderlichen Aufgaben im passenden Geltungsbereich. Die Änderung eines Standardziels verleiht der beitretenden Identität dort keine Berechtigung zur Kontoerstellung oder -wiederverwendung.

Prüfen Sie bei wiederverwendeten Computerkonten Eigentümer und erforderliche Berechtigungen anhand des Verfahrens zu Domänenbeitrittsberechtigungen. Untersuchen Sie einen fehlgeschlagenen Beitritt innerhalb dieser Anforderungen. Erweitern Sie nicht lediglich administrative Mitgliedschaften und umgehen Sie keine Eigentümerprüfungen, um einen neu umgeleiteten Ablauf funktionsfähig zu machen.

Für natives AD-gestütztes Windows LAPS dokumentiert das Bereitstellungsverfahren die Berechtigung zur Selbstaktualisierung des Geräts. Dieses Beispiel setzt die genehmigte Computer-OU in diesen Befehl ein:

Set-LapsADComputerSelfPermission -Identity 'OU=MyComputers,DC=contoso,DC=com'

Dies konfiguriert weder die LAPS-Richtlinie noch Kennwortabrufrechte. Prüfen Sie die vorgesehene Richtlinie und eine erfolgreiche Clientaktualisierung gesondert. Prüfen Sie außerdem den genehmigten Kreis zur Wiederherstellung; einen Computer in den Richtliniengeltungsbereich zu bringen, behebt keinen übermäßigen Wiederherstellungszugriff.

6. Vorbereitete Konten prüfen und künftige Abläufe testen

Halten Sie für jeden Bereitstellungskandidaten Geschäftszweck, Eigentümer, Bereitstellungswerkzeug und die Nachweise für die weitere Verwendung fest. Bestimmen Sie, ob das Konto die Bereitstellung abschließen, in einem genehmigten Vorbereitungsverfahren verbleiben oder in das Stilllegungsverfahren der Organisation übergehen soll. Aus der UAC-Maske werden weder eine universelle Altersgrenze noch eine automatische Löschregel abgeleitet.

Testen Sie nach der Abhilfe einen autorisierten Ablauf für ein neues Konto über den Standardpfad und einen Ablauf zur Wiederverwendung eines vorab erstellten Kontos. Prüfen Sie Zielort, Berechtigungen, erwartete GPO-Anwendung und geltende Dienstergebnisse. Microsofts Beitrittsberechtigungen und netdom-Zielregeln erläutern, weshalb diese Abläufe getrennt betrachtet werden müssen.

Alle Befehle dieses Leitfadens sind dokumentierte Beispiele für Leser oder ausdrücklich gekennzeichnete Anpassungen. Sie wurden für diesen Artikel nicht gegen eine AD-Domäne ausgeführt und belegen keine erfolgreiche Umleitung, Migration oder Rotation.

Wie EtcSec dies erkennt

Die folgenden Beschreibungen geben die geprüften Detect()-Implementierungen im etc-collector-Commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c wieder. Die folgenden Pfade sind relativ zu public/internal/audit/detectors/.

COMPUTER_WRONG_OU in ad/computers/organization/wrong-ou.go:35 überspringt deaktivierte Computer, wandelt den DN in Kleinbuchstaben um und sucht in den Zeilen 39–49 nach ,cn=computers,dc=. Er meldet den Schweregrad Low. Es handelt sich um einen Teilzeichentest, nicht um einen geparsten Vergleich des übergeordneten Objekts mit einer konfigurierten Ziel-OU. Er inventarisiert keine wirksame GPO-Anwendung und belegt nicht das Fehlen von LAPS, Härtung oder Überwachung.

COMPUTER_PRE_CREATED in ad/computers/status/pre-created.go:35 prüft in den Zeilen 38–41 UserAccountControl & 0x1020 == 0x1020. Zusätzliche Bits sind zulässig, einschließlich des deaktivierten Zustands. Sein Medium-Befund enthält keine DN-Bedingung, Altersgrenze, Prüfung der Anmeldehistorie oder Untersuchung des Geheimniswerts. Der Befundname bezeichnet ein Signal zur Bereitstellungsprüfung; die Prüfbedingung beweist nicht, dass der Computer nie beigetreten ist.

Eine benachbarte Kontrolle, SERVER_NO_ADMIN_GROUP, wurde geprüft, ist aber diesem Artikel nicht als Tag zugeordnet. In ad/computers/organization/server-no-admin-group.go:43 wählt sie aktivierte Computer aus, die heuristisch als Server klassifiziert werden, und prüft die Abdeckung durch aktivierte Verknüpfungen zu geparsten Restricted-Groups-Daten mit einer nicht leeren Administrators-Mitgliedschaft. Ihre Hilfsfunktionen befinden sich in den Zeilen 102–186. Sie erkennt nicht gezielt den Aufenthalt in CN=Computers, berechnet keine wirksame Filterung und untersucht nicht die tatsächliche lokale Mitgliedschaft des Servers. Ohne bereitgestellte GPO-Richtliniendaten belegt ihre Nullzählung keine Konformität.

Verwenden Sie diese Befunde, um den nächsten Prüfschritt auszuwählen. Korrigieren Sie die Platzierung, prüfen Sie künftige Bereitstellungen, ermitteln Sie den tatsächlichen Clientschutz und klären Sie die Eigentümerschaft vorbereiteter Konten jeweils gesondert. Eine nicht mehr erfüllte Verzeichnisprüfbedingung ist ein nützlicher Nachweis für genau diese Bedingung; eine erfolgreiche betriebliche Abhilfe benötigt die entsprechenden Ergebnisnachweise.