Der alte Default

In vielen Domänen dürfen authentifizierte Benutzer standardmäßig Computerobjekte anlegen. Das war historisch bequem, passt aber selten zu heutigen Sicherheitsmodellen.

Für AD-Security ist die Frage einfach: Wer darf neue Identitäten in die Domäne bringen, und wer kontrolliert danach deren Rechte, SPNs und Lebenszyklus?

Sauberes Zielbild

  • ms-DS-MachineAccountQuota auf 0 setzen.
  • Domain Join über delegierte Gruppen, Prozesse oder Provisioning-Tools abbilden.
  • Computerobjekte in kontrollierten OUs erzeugen.
  • Rechte auf Join, Delete, Reset und Move getrennt betrachten.
  • Änderungen an der Quota überwachen.

Worauf ich achten würde

MachineAccountQuota ist nur ein sichtbarer Einstieg. Danach zählen Delegationen auf OUs, alte Join-Konten, überbreite Helpdesk-Rechte und unklare Prozesse für Re-Imaging oder Autopilot/Hybrid Join.

Was dadurch besser wird

  • Normale Benutzer können nicht mehr unkontrolliert neue Computeridentitäten erzeugen.
  • Domain Join wird Teil eines nachvollziehbaren Prozesses mit Delegation, Logging und Ownership.
  • Angriffspfade über selbst erstellte Computerobjekte werden reduziert.

Wo es weh tun kann

  • Helpdesk- und Deployment-Prozesse brechen, wenn niemand die legitimen Join-Szenarien vorher inventarisiert.
  • Zu breite Ersatzdelegationen schaffen dasselbe Problem an anderer Stelle.
  • Hybrid Join, Autopilot oder Re-Imaging brauchen klare Ausnahmeprozesse.

Checks vor dem Rollout

  1. Wer jointe bisher Maschinen und über welchen Prozess?
  2. Welche OUs erlauben Join, Move, Reset oder Delete?
  3. Welche Join-Konten sind alt, geteilt oder zu breit berechtigt?
  4. Wie wird eine Quota-Änderung überwacht?

Kurz gesagt

Neue Computerobjekte sind neue Identitäten. Wer sie erstellen darf, gehört genauso kontrolliert wie jede andere privilegierte Operation.