Ausgangslage: Ein Domain Join provisioniert eine Identität

Der Beitritt eines Windows-Geräts zu einer Active-Directory-Domäne wirkt im Alltag wie ein Installationsschritt. Tatsächlich wird damit eine neue Sicherheitsidentität erzeugt oder eine vorhandene übernommen. Das Computerobjekt erhält ein Kennwort, SPNs, einen DNS-Namen, Gruppenmitgliedschaften, OU-basierte Richtlinien und möglicherweise Rechte auf weitere Systeme. Wer diesen Vorgang steuert, beeinflusst damit mehr als nur die Erreichbarkeit eines Clients.

In gewachsenen Umgebungen ist der Join-Pfad häufig unnötig breit:

  • Authenticated Users dürfen über ms-DS-MachineAccountQuota eigene Computerobjekte erzeugen.
  • Ein Deployment-Konto ist Domain Admin, weil damit jeder Join funktioniert.
  • Computer landen im Standardcontainer CN=Computers statt in einer verwalteten OU.
  • Helpdesk, Softwareverteilung und Serverbetrieb verwenden dasselbe Join-Konto.
  • Pre-Staging, eigentlicher Join und spätere Wiederverwendung haben keine getrennten Rollen.
  • Alte Computerobjekte werden ohne Owner-, ACL- oder Abhängigkeitsprüfung zurückgesetzt.
  • Kennwörter stehen in Task Sequences, Antwortdateien, Skripten oder Installationslogs.
  • Fehlgeschlagene Wiederverwendung wird mit einem Kompatibilitäts-Workaround statt mit Ursachenanalyse beantwortet.

Dabei sind zwei Vorgänge zu unterscheiden. Existiert noch kein Objekt mit dem Gerätenamen, muss ein Computerobjekt erzeugt werden. Existiert es bereits, verändert der Join unter anderem Kennwort, DNS-Hostnamen, SPNs und Kontostatus. Für die Wiederverwendung gelten deshalb sowohl AD-Berechtigungen als auch die seit 2022 verschärften Eigentümerprüfungen.

Aktuelle Windows-Systeme blockieren die Wiederverwendung eines vorhandenen Computerobjekts, wenn Ersteller, Owner und Join-Identität nicht zum erlaubten Modell passen. Der Fehler 0xaac / NERR_AccountReuseBlockedByPolicy ist dann keine zufällige Störung, sondern eine wirksame Sicherheitskontrolle. Der frühere Registry-Workaround NetJoinLegacyAccountReuse wird seit den Updates vom August 2024 nicht mehr unterstützt. Eine belastbare Lösung korrigiert Rollen, Owner, ACLs und die zentrale Allowlist – nicht den Client.

MachineAccountQuota = 0 bleibt eine wichtige Basis, ist aber nicht das gesamte Domain-Join-Hardening. Delegierte Rechte auf OUs funktionieren unabhängig davon weiter. Entscheidend ist daher, wer welche Computerobjekte an welchem Ort erzeugen, übernehmen, verändern und löschen darf.

Zielbild: Provisioning, Join und Wiederverwendung sind getrennt kontrolliert

Ein sauberer Zielzustand lässt sich an konkreten Eigenschaften erkennen:

  1. Normale Benutzer erzeugen keine Computerobjekte. ms-DS-MachineAccountQuota steht auf 0; Add workstations to domain wird nicht als allgemeiner Provisioning-Pfad verwendet.
  2. Geräteklassen besitzen eigene OUs. Workstations, Member Server, privilegierte Adminsysteme, VDI und Sondergeräte landen direkt im vorgesehenen Policy- und Delegationsbereich.
  3. Provisioning und Join sind getrennte Rollen. Eine eng begrenzte Identität erzeugt oder pre-staged Computerobjekte; eine andere führt den Join mit den minimal nötigen Rechten aus.
  4. Join-Identitäten sind nicht privilegiert. Sie sind weder Domain Admin noch lokale Standard-Administratoren auf beliebigen Systemen und können keine Benutzer, Gruppen, GPOs oder fremden OUs verändern.
  5. Computerobjekte haben nachvollziehbare Owner und ACLs. Der Ersteller gehört zu einer kleinen Gruppe vertrauenswürdiger Provisioner; verwaiste Owner und individuelle Alt-ACEs werden bereinigt.
  6. Wiederverwendung ist explizit erlaubt. Die DC-Richtlinie Domain controller: Allow computer account re-use during domain join enthält nur vertrauenswürdige Ersteller beziehungsweise Owner – nicht pauschal die ausführende Join-Gruppe.
  7. Offline Domain Join wird gezielt eingesetzt. Wo er zum Bereitstellungsmodell passt, reduziert er die AD-Rechte auf dem Zielgerät. Das Provisioning-Blob wird wie ein Klartextkennwort geschützt.
  8. Jeder Join ist einem Auftrag zuordenbar. Gerätename, Seriennummer, Ziel-OU, Owner, Deployment-ID, ausführende Identität und Zeitpunkt sind korrelierbar.
  9. Wiederanlauf und Stilllegung sind Teil desselben Prozesses. Secure-Channel-Reparatur, Rejoin, Objekt-Quarantäne und Löschung haben dokumentierte Freigaben und Recovery-Schritte.
  10. Telemetrie belegt die Wirksamkeit. Computerobjekt-Ereignisse, Netjoin-Fehler und die DC-Ereignisse zur Reuse-Allowlist werden zentral ausgewertet.

Das Ziel ist kein einzelnes „Join-Konto“. Es ist eine Provisioning-Kette, in der jede Identität nur ihren Schritt und nur die vorgesehene Geräteklasse bearbeiten kann.

Umsetzung: Den Join-Pfad vom Objekt bis zum Gerät neu ordnen

1) Quota, Ziel-OUs, Owner und Altobjekte read-only erfassen

Beginne mit dem tatsächlichen Zustand, nicht mit der Dokumentation des Deployment-Tools. Die folgende Abfrage verändert nichts. Sie zeigt die domänenweite MachineAccountQuota und liefert für eine repräsentative Ziel-OU Ersteller-SID, Objekt-Owner und Betriebsindikatoren:

Set-StrictMode -Version Latest
Import-Module ActiveDirectory -ErrorAction Stop

$domain = Get-ADDomain -ErrorAction Stop
$domainParams = @{
  Identity    = $domain.DistinguishedName
  Properties  = 'ms-DS-MachineAccountQuota'
  ErrorAction = 'Stop'
}
$domainObject = Get-ADObject @domainParams

[pscustomobject]@{
  Domain              = $domain.DNSRoot
  MachineAccountQuota = $domainObject.'ms-DS-MachineAccountQuota'
}

$searchBase = 'OU=Workstations,DC=example,DC=com'
$computerParams = @{
  SearchBase = $searchBase
  Filter     = '*'
  Properties = @(
    'whenCreated'
    'PasswordLastSet'
    'LastLogonDate'
    'ms-DS-CreatorSID'
  )
}

Get-ADComputer @computerParams | ForEach-Object {
  $creatorSid = if ($_.'ms-DS-CreatorSID') {
    [string]$_.'ms-DS-CreatorSID'
  } else {
    $null
  }

  [pscustomobject]@{
    Name              = $_.Name
    DistinguishedName = $_.DistinguishedName
    Owner             = (Get-Acl -Path ('AD:\' + $_.DistinguishedName)).Owner
    CreatorSid        = $creatorSid
    WhenCreated       = $_.whenCreated
    PasswordLastSet   = $_.PasswordLastSet
    LastLogonDate     = $_.LastLogonDate
    Enabled           = $_.Enabled
  }
}

Ersetze den Beispiel-DN und starte OU-weise. Eine leere ms-DS-CreatorSID ist nicht automatisch verdächtig: Bei privilegierter oder explizit delegierter Objekterstellung wird das Attribut nicht in jedem Pfad gesetzt. Ebenso beweisen LastLogonDate und PasswordLastSet allein weder Nutzung noch Stillstand. Sie helfen nur bei der Priorisierung.

Ergänze die Daten um vererbte und explizite ACLs auf OUs und Computerobjekten, Gruppenmitgliedschaften, Delegationsattribute, BitLocker- und LAPS-Recovery-Abhängigkeiten sowie die reale Provisioning-Quelle. Besonders relevant sind individuelle ACEs unbekannter Konten, breite Gruppen mit Create Child, verwaiste Owner und Objekte, deren Name erneut vergeben werden soll.

2) Geräteklassen und Provisioning-Rollen festlegen

Lege getrennte Ziel-OUs für mindestens Workstations, Member Server und privilegierte Geräte fest. VDI, Kiosk, Labor und Appliances benötigen eigene OUs, wenn ihr Lebenszyklus oder ihre Richtlinien abweichen. Der Join-Prozess muss die Ziel-OU explizit angeben; andernfalls landen neue Objekte leicht im Standardcontainer und umgehen zunächst die vorgesehenen GPOs.

Trenne anschließend zwei Funktionen:

  • Computer Account Provisioners dürfen in genau definierten OUs Computerobjekte erzeugen. Löschrechte erhalten sie nur, wenn der automatisierte Lebenszyklus sie wirklich benötigt.
  • Domain Join Executors dürfen ein korrekt pre-staged Objekt übernehmen und die für den Join erforderlichen Eigenschaften verändern.

Für die Wiederverwendung eines vorhandenen Objekts benötigt die ausführende Identität typischerweise Lesen und Auflisten, Allowed to authenticate, Change password, Reset password, validierte Schreibrechte auf DNS-Hostname und SPN sowie Write account restrictions. Soll der Prozess Objekte umbenennen, kommen gezielte Rechte auf sAMAccountName, Anzeigename und Beschreibung hinzu. Übernimm diese Liste nicht blind als OU-weites Full Control. Implementiere sie auf Computerobjekte begrenzt, dokumentiere jede zusätzliche ACE und teste Vererbung sowie effektive Rechte.

Ein einziges Konto, das Objekte in allen Geräte-OUs erzeugen, joinen, zurücksetzen und löschen darf, ist zwar bequem, aber kein Least-Privilege-Modell. Server- und PAW-Provisioning verdienen eine engere Schutzgrenze als Standard-Clients.

3) Freie Objekterstellung schließen und den Standardpfad korrigieren

Setze ms-DS-MachineAccountQuota nach Bestandsaufnahme und Pilot auf 0. Entferne außerdem Authenticated Users aus Add workstations to domain, sofern die Umgebung diesen User-Right-Pfad noch explizit führt. Prüfe beide Kontrollen separat: Eine auf 0 gesetzte Quota hebt delegiertes Create Computer objects auf einer OU nicht auf.

Vermeide neue Geräte im Standardcontainer CN=Computers. Deployment-Systeme sollten immer die Ziel-OU angeben. Alternativ kann der domänenweite Standardpfad kontrolliert mit redircmp auf eine vorbereitete OU gelenkt werden. Vor diesem Change müssen GPO-Verknüpfungen, ACLs, Provisioning-Tools und bestehende Automationen getestet sein; die Umleitung verschiebt keine bereits vorhandenen Objekte.

Neue Delegationen gehören an stabile Sicherheitsgruppen, nicht an persönliche Admin- oder Servicekonten. Gruppenmitgliedschaft, OU-ACL und Zweck sollten als eine Einheit versioniert und regelmäßig rezertifiziert werden.

4) Pre-Staging und Computer-Account-Reuse bewusst gestalten

Pre-Staging bindet Gerätename, Ziel-OU, Gruppen und Owner an einen kontrollierten Auftrag, bevor das Zielgerät die Domäne kontaktiert. Es reduziert Namenskollisionen und macht die spätere Wiederverwendung vorhersehbarer. Es ist aber nur dann sicher, wenn der Ersteller vertrauenswürdig und die Objekt-ACL sauber ist.

Auf allen Domain Controllern wird die Richtlinie unter folgendem Pfad konsistent verwaltet:

Computerkonfiguration
  Richtlinien
    Windows-Einstellungen
      Sicherheitseinstellungen
        Lokale Richtlinien
          Sicherheitsoptionen
            Domänencontroller: Wiederverwendung von Computerkonten
            während des Domänenbeitritts zulassen

In die Allowlist gehören kleine Gruppen der vertrauenswürdigen Computerobjekt-Ersteller beziehungsweise Owner. Die Gruppe, die nur den Join ausführt, gehört nicht automatisch hinein. Authenticated Users, Everyone oder eine große Helpdesk-Gruppe würden den Sinn der Eigentümerprüfung aufheben.

Clients und Domain Controller müssen mindestens den konsistenten Update-Stand der September-2023-Härtung besitzen; aktuelle, vollständig unterstützte Patchstände sind das operative Ziel. Prüfe nach der GPO-Verarbeitung die DC-Ereignisse und den erzeugten Wert ComputerAccountReuseAllowList, bearbeite dessen SDDL aber niemals direkt in der Registry.

Schlägt eine Wiederverwendung mit 0xaac fehl, kläre zuerst Objekt-Owner, Erstellergruppe, Join-Identität, ACLs, DC-Policy und Patchstand. Ein Owner-Wechsel allein reicht nicht, wenn alte unerwünschte ACEs auf dem Objekt verbleiben. Ist das Objekt wirklich verwaist, darf es erst nach Prüfung von Gruppen, SPNs, Delegation, LAPS-, BitLocker- und Betriebsabhängigkeiten gelöscht oder neu provisioniert werden.

5) Join-Geheimnisse und Offline-Provisioning schützen

Domain-Admin-Anmeldedaten gehören weder auf einen neuen Client noch in einen Task-Sequence-Schritt. Interaktive Verfahren sollten Kennwörter verdeckt abfragen; Automationen lesen ein dediziertes Geheimnis kurzzeitig aus einem Vault und verhindern dessen Ausgabe in Prozessargumenten, Transkripten und Logs. Das Konto erhält keine interaktive oder RDP-Anmeldung, sofern sein Ausführungsmodell dies nicht braucht.

Offline Domain Join kann die Rechte auf dem Zielsystem weiter reduzieren. Ein Provisioning-System erzeugt dabei das Computerobjekt und ein gerätespezifisches Blob; der Client verarbeitet es lokal ohne AD-Schreibrechte der installierenden Person. Dieses Blob enthält jedoch das Kennwort des Computerkontos und weitere Domänendaten. Es ist daher wie ein Klartextkennwort zu behandeln:

  • ein eigenes Blob pro Gerät und Auftrag,
  • verschlüsselte Ablage und Übertragung,
  • Zugriff nur für Provisioning-Dienst und Zielgerät,
  • keine Aufnahme in Tickets, Images oder allgemeine Paket-Repositories,
  • kurze, definierte Aufbewahrung,
  • Löschung nach erfolgreichem Join und dokumentierte Re-Provisionierung bei Offenlegung.

Offline Join ist kein automatischer Vertrauensnachweis für Hardware, Bootzustand oder Gerätekonformität. TPM-Attestation, Secure Boot, MDM/EDR-Onboarding und Zertifikatsregistrierung bleiben getrennte Kontrollen.

6) Erfolg nicht nur am Neustart messen

Ein erfolgreicher Dialog oder Exitcode sagt wenig über den Zielzustand. Prüfe im Pilot mindestens:

  1. Computerobjekt liegt in der richtigen OU und besitzt den erwarteten Owner.
  2. Nur vorgesehene vererbte und explizite ACLs sind vorhanden.
  3. Gerätename, DNS-Hostname und SPNs sind konsistent und eindeutig.
  4. Das Computerkonto ist nur in freigegebenen Gruppen Mitglied.
  5. Secure Channel und Kerberos-Anmeldung funktionieren nach dem Neustart.
  6. Erwartete Computer-GPOs werden angewendet; Server- und PAW-Baselines greifen sofort.
  7. Windows LAPS, BitLocker-Escrow, Zertifikate, EDR und Management-Agenten registrieren sich.
  8. Das Gerätekennwort rotiert im normalen Betriebsfenster.
  9. Ein unerlaubter Reuse-Versuch wird mit 0xaac blockiert und zentral sichtbar.
  10. Rejoin und Recovery funktionieren ohne Domain-Admin-Konto.

Repariere bei einer gestörten Vertrauensstellung zuerst den Secure Channel, statt das Gerät reflexartig aus der Domäne zu nehmen und dasselbe Objekt zurückzusetzen. Ein Rejoin verändert Vertrauensstellungsdaten und Kennwort erneut und kann das eigentliche Problem sowie unerwünschte ACLs verdecken.

7) Computerobjekt- und Reuse-Ereignisse zentral korrelieren

Aktiviere auf Domain Controllern Audit Computer Account Management für erfolgreiche Vorgänge und sammle mindestens:

  • 4741 für neu erzeugte Computerobjekte,
  • 4742 für Änderungen an Computerobjekten,
  • 4743 für Löschungen,
  • 16995 für die wirksame Reuse-Allowlist,
  • 16996 für eine fehlerhafte Allowlist,
  • 16997 für Reuse-Versuche, deren bisheriger Owner nicht mehr existiert,
  • 16998 für abgelehnte Reuse-Anfragen.

Auf den joinenden Clients liefern die Systemereignisse 4100 und 4101 Informationen zu erlaubter beziehungsweise blockierter Wiederverwendung. C:\Windows\Debug\netsetup.log ist für die Fehleranalyse verfügbar, sollte aber wegen seiner Umgebungsdaten nur bedarfsgerecht zentralisiert und angemessen geschützt werden.

Korrelieren solltest du Subjekt, Computername, Ziel-OU, Owner, Deployment-ID, Quellgerät und Change-Fenster. Relevant sind insbesondere Objekterstellung durch unerwartete Konten, neue Geräte außerhalb der Provisioning-Zeit, Serverobjekte in Client-OUs, Änderungen an SPNs oder Delegation, Reuse durch fremde Identitäten und Löschungen ohne zugehörigen Stilllegungsauftrag.

Event 4742 kann im normalen Betrieb viele Kennwort- und Attributänderungen enthalten. Eine Regel nur auf die Event-ID erzeugt deshalb Rauschen. Werte die geänderten Felder, das ausführende Konto, die Geräteklasse und den Lebenszykluszustand gemeinsam aus.

8) Stilllegung und Wiederverwendung als kontrollierten Lifecycle betreiben

Beim Geräte-Retirement wird das Computerobjekt nicht sofort gelöscht. Verschiebe es in eine Quarantäne-OU, deaktiviere es, entferne produktive Gruppenmitgliedschaften und dokumentiere Aufbewahrungsfrist sowie Owner. Prüfe vor der endgültigen Löschung, ob das Objekt noch LAPS-Kennwörter, BitLocker-Recovery-Informationen, Zertifikatszuordnungen, SPNs oder applikationsspezifische ACLs trägt.

Eine spätere Wiederverwendung desselben Namens braucht einen neuen Auftrag. Bewerte, ob das alte Objekt kontrolliert zurückgesetzt werden darf oder ein neues Objekt die sauberere Grenze schafft. Besonders bei Wechsel zwischen Geräteklassen – etwa Client zu Server – ist ein neues Objekt in der richtigen OU meist nachvollziehbarer als die Migration historischer ACLs.

Ausnahmen erhalten Owner, Begründung, Umfang und Ablaufdatum. Eine dauerhafte „Legacy Join“-Gruppe ohne Review wird mit der Zeit zum alternativen Provisioning-System.

Vorteile

  • Weniger privilegierte Zugangsdaten: Domain-Admin-Kennwörter verschwinden aus Client- und Deploymentpfaden.
  • Begrenzte AD-Schreibrechte: Provisioning- und Join-Identitäten können nur definierte Computerobjekte in vorgesehenen OUs bearbeiten.
  • Schutz vor unsicherer Wiederverwendung: Owner-Prüfung und Allowlist verhindern, dass fremd erzeugte oder manipulierte Objekte still übernommen werden.
  • Richtlinien greifen ab dem ersten Start: Geräte landen sofort in der richtigen OU und erhalten die vorgesehene Baseline.
  • Nachvollziehbare Verantwortlichkeit: Objekt, Owner, Deployment-Auftrag und ausführende Identität lassen sich korrelieren.
  • Sauberere Störungsanalyse: 0xaac, DC-Ereignisse und Netsetup-Log führen zu einer konkreten Ursache statt zu pauschalen Berechtigungen.
  • Besserer Lebenszyklus: Pre-Staging, Join, Rejoin, Quarantäne und Löschung verwenden dieselben Kontrollpunkte.

Nachteile und Grenzen

  • Mehr Prozessaufwand: Rollen, OU-ACLs, Owner-Gruppen und Deployment-Integrationen müssen gepflegt und getestet werden.
  • Bestehende Automationen können scheitern: Alte Tools erwarten häufig ein breit berechtigtes Konto oder unkontrollierte Objektwiederverwendung.
  • Fehlerhafte Delegation führt zu Ausfällen: Ein fehlendes validiertes Schreibrecht oder eine falsche Vererbung stoppt den Join.
  • Pre-Staging schafft Altbestand: Nicht genutzte Aufträge hinterlassen Objekte, wenn keine Ablauf- und Bereinigungslogik existiert.
  • Offline-Join-Blobs sind hochsensitiv: Der geringere AD-Rechtebedarf wird durch ein zu schützendes, gerätespezifisches Geheimnis erkauft.
  • Ein Join beweist keine Gerätesicherheit: Schadsoftware, unsicherer Bootzustand oder fehlendes EDR werden durch Domänenmitgliedschaft nicht behoben.
  • MachineAccountQuota 0 ist nicht ausreichend: Explizit delegierte OU-Rechte und vorhandene Computerobjekt-ACLs bleiben wirksam.
  • Monitoring sieht nicht jeden Kontext: Events zeigen Verzeichnisvorgänge, aber nicht automatisch, ob Seriennummer, Hardware und Auftrag zusammenpassen.

Typische Stolperfallen

  • Deployment-Konto zu Domain Admins hinzufügen: Das löst Berechtigungsfehler mit einer dauerhaft überhöhten Identität.
  • Nur MachineAccountQuota ändern: Breite Create Computer objects-Delegationen bleiben unberührt.
  • Join-Executor in die Reuse-Allowlist aufnehmen: Die Richtlinie vertraut den Erstellern beziehungsweise Ownern des Objekts, nicht pauschal jedem Ausführer.
  • Große Gruppen erlauben: Authenticated Users, Everyone oder allgemeiner Helpdesk heben die Eigentümerkontrolle praktisch auf.
  • NetJoinLegacyAccountReuse setzen: Der alte Client-Workaround wird nicht mehr unterstützt.
  • Owner manuell ändern und ACL ignorieren: Unerwünschte Rechte des früheren Erstellers können bestehen bleiben.
  • Computerobjekt blind löschen: Gruppen, Recovery-Daten, SPNs und Anwendungsrechte gehen verloren oder werden inkonsistent.
  • Alle Geräte in CN=Computers joinen: GPOs und Delegationen der Ziel-OU greifen zu spät oder gar nicht.
  • Ein Konto für Clients, Server und PAWs nutzen: Eine Kompromittierung überschreitet sofort mehrere Schutzklassen.
  • Kennwort in Kommandozeile oder Antwortdatei schreiben: Prozesslisten, Logs, Backups und Supportpakete vervielfältigen das Geheimnis.
  • Offline-Join-Blob als harmloses Konfigurationsfile behandeln: Es enthält das Kennwort des Computerkontos.
  • Nur den positiven Join testen: Blockierung, Reuse, Rejoin, Quarantäne und Recovery bleiben ungeprüft.
  • 4742 pauschal alarmieren: Normale Kennwort- und Attributpflege erzeugt unnötiges Rauschen.
  • SAMRPC-Härtung übersehen: Zu enge Remote-SAM-Policy auf DCs kann die aktuelle Reuse-Prüfung blockieren und muss gezielt mitgetestet werden.

Projekt-Checkliste

  • [ ] ms-DS-MachineAccountQuota und Add workstations to domain getrennt erfassen.
  • [ ] Alle OU-Delegationen für Computerobjekte inklusive Vererbung exportieren.
  • [ ] Join-, Pre-Staging-, Rejoin- und Löschpfade je Deployment-System dokumentieren.
  • [ ] Workstations, Server, PAWs, VDI und Sondergeräte in getrennte Ziel-OUs einordnen.
  • [ ] Standardcontainer CN=Computers aus dem regulären Provisioning-Pfad entfernen.
  • [ ] Gruppen für Provisioner und Join-Executor getrennt anlegen.
  • [ ] Rechte je Geräte-OU und Objektklasse auf das notwendige Minimum begrenzen.
  • [ ] Domain-Admin-, Enterprise-Admin- und breite Helpdesk-Mitgliedschaften aus Join-Konten entfernen.
  • [ ] MachineAccountQuota nach Pilot auf 0 setzen.
  • [ ] Computerobjekt-Owner und individuelle Alt-ACEs bewerten.
  • [ ] Vertrauenswürdige Ersteller-/Owner-Gruppen für die Reuse-Allowlist definieren.
  • [ ] Join-Executor nicht automatisch als vertrauenswürdigen Owner behandeln.
  • [ ] DC-GPO für Computer-Account-Reuse auf allen DCs konsistent ausrollen.
  • [ ] Aktuellen Patchstand von Clients und Domain Controllern verifizieren.
  • [ ] Registry-Workarounds und manuell gesetzte Reuse-SDDL entfernen.
  • [ ] Pre-Staging mit Gerätename, Seriennummer, Ziel-OU und Auftrag verknüpfen.
  • [ ] Join-Geheimnisse aus Skripten, Task-Sequence-Logs und Antwortdateien entfernen.
  • [ ] Vault-Zugriff, Rotation und Sperrung der Provisioning-Identitäten testen.
  • [ ] Offline Domain Join nur mit verschlüsseltem, gerätespezifischem Blob einsetzen.
  • [ ] Löschung beziehungsweise Re-Provisionierung exponierter ODJ-Blobs definieren.
  • [ ] Pilot für Neuanlage, Pre-Staging, erlaubten Reuse und blockierten Reuse durchführen.
  • [ ] Owner, ACL, OU, SPNs, DNS, Secure Channel und GPO-Anwendung nach jedem Pilot prüfen.
  • [ ] LAPS, BitLocker-Escrow, Zertifikate, EDR und Management-Onboarding verifizieren.
  • [ ] Ereignisse 4741, 4742, 4743, 16995 bis 16998 zentral sammeln.
  • [ ] Client-Ereignisse 4100 und 4101 sowie Netsetup-Logs in den Supportprozess integrieren.
  • [ ] Abweichungen mit Deployment-ID, Owner, Quellgerät und Change-Fenster korrelieren.
  • [ ] Secure-Channel-Reparatur vor einem vollständigen Rejoin testen.
  • [ ] Quarantäne-OU, Aufbewahrungsfrist und endgültige Löschprüfung definieren.
  • [ ] Ausnahmen mit Owner, Begründung, Scope und Ablaufdatum führen.
  • [ ] OU-ACLs, Allowlist-Gruppen und ungenutzte Computerobjekte regelmäßig rezertifizieren.