ms-DS-MachineAccountQuota auf 0 setzen, Beitritte delegieren

Standardmäßig kann jeder authentifizierte Benutzer in einer Active-Directory-Domäne bis zu zehn Computerkonten erstellen. Das Limit ist im Attribut ms-DS-MachineAccountQuota am Domänenkopf gespeichert, und die Berechtigung stammt aus dem Benutzerrecht „Add workstations to domain“ (Hinzufügen von Arbeitsstationen zur Domäne), das die Default Domain Controllers Policy den Authenticated Users gewährt. Es war eine Bequemlichkeit aus der Zeit, als Benutzer ihre PCs selbst in die Domäne aufnahmen. Heute liefert es Angreifern vor allem einen kostenlosen Domänenprinzipal mit bekanntem Kennwort und steuerbarem SPN – genau das, was RBCD-Missbrauch, Relay-zu-LDAP-Ketten und mehrere AD-CS-Vorlagenangriffe benötigen.

Das ist eine der einfachsten Härtungsänderungen in AD: ein Attribut und ein Benutzerrecht. Die Arbeit liegt darin, herauszufinden, wer stillschweigend vom Standard abhängt, und diesen Stellen stattdessen eine ordentliche, eingegrenzte Delegierung zu geben.

Warum ein kostenloses Computerkonto zählt

Ein Benutzerkonto allein ist für mehrere AD-Angriffe ein schwacher Brückenkopf. Viele davon brauchen einen Prinzipal mit Service Principal Name, einem dem Angreifer bekannten Kennwort und dem Recht, Kerberos-Tickets als Dienst anzufordern. Computerkonten haben alle drei, und das Kontingent erlaubt jedem authentifizierten Benutzer, eines von jedem domänenangehörigen oder sogar nicht angehörigen Rechner mit Netzwerkzugang zu einem DC zu erstellen – mit nichts weiter als Standard-LDAP- oder -SAMR-Aufrufen. Offensive Toolkits wie Impacket und Powermad enthalten dafür einen Einzeiler.

Was dieses Konto ermöglicht, hängt vom Rest Ihrer Konfiguration ab – deshalb taucht das Kontingent in so vielen Angriffsketten auf:

• Ressourcenbasierte eingeschränkte Delegierung. Kann der Angreifer msDS-AllowedToActOnBehalfOfOtherIdentity auf einem Ziel schreiben, direkt oder über ein NTLM-Relay zu LDAP, verweist er es auf sein neues Computerkonto und imitiert Benutzer gegenüber dem Ziel.
• AD-CS-Vorlagen, für die Domain Computers registrieren dürfen. Das neue Konto ist automatisch Mitglied von Domain Computers und kann sich daher für die Standardvorlage Machine und jede benutzerdefinierte Vorlage mit denselben Berechtigungen registrieren. In Kombination mit anderen Fehlkonfigurationen von Vorlagen wird das zu einem Pfad, sich als jemand anderes zu authentifizieren.
• Fehler in der Kerberos-Implementierung. Die sAMAccountName-Spoofing-Probleme von 2021 (CVE-2021-42278 und CVE-2021-42287) setzten ein Computerkonto voraus, das der Angreifer umbenennen konnte. Die Patches haben diese konkreten Fehler behoben, aber der nächste wird wahrscheinlich dieselbe Voraussetzung haben.
• Persistenz. Ein während eines Einbruchs erstelltes Computerkonto fällt selten auf, läuft selten ab und behält ein gültiges Kennwort, so lange der Angreifer will.

Keiner dieser Angriffe braucht das Kontingent, wenn der Angreifer bereits Erstellungsrechte auf OU-Ebene hat – deshalb betrachtet die Prüfung unten auch, wer diese besitzt.

Messen: aktuelles Kontingent und wer es genutzt hat

Lesen Sie den aktuellen Wert und prüfen Sie, wer das Benutzerrecht auf Domänencontrollern besitzt.

Import-Module ActiveDirectory

$domainDN = (Get-ADDomain).DistinguishedName
Get-ADObject -Identity $domainDN -Properties 'ms-DS-MachineAccountQuota' |
    Select-Object DistinguishedName, 'ms-DS-MachineAccountQuota'

Für das Benutzerrecht öffnen Sie die mit der OU Domain Controllers verknüpfte GPO (normalerweise Default Domain Controllers Policy) und sehen nach unter:

Computer Configuration > Policies > Windows Settings > Security Settings >
  Local Policies > User Rights Assignment > Add workstations to domain

Der Standardwert ist Authenticated Users. Auf einem DC können Sie die effektive Einstellung mit gpresult /h bestätigen oder die lokale Sicherheitsrichtlinie mit secedit /export /cfg exportieren, wo das Recht SeMachineAccountPrivilege heißt.

Suchen Sie dann Computerobjekte, die über das Kontingent erstellt wurden. Erstellt ein nicht privilegierter Benutzer ein Computerkonto über SeMachineAccountPrivilege, trägt der DC die SID des Erstellers in mS-DS-CreatorSID ein. Von Admins oder über OU-Delegierung erstellte Konten tragen dieses Attribut nicht.

Get-ADComputer -LDAPFilter '(mS-DS-CreatorSID=*)' `
    -Properties mS-DS-CreatorSID, whenCreated, operatingSystem, lastLogonTimestamp, enabled |
    ForEach-Object {
        $sid = $_.'mS-DS-CreatorSID'
        $creator = try { (New-Object Security.Principal.SecurityIdentifier($sid, 0)).Translate(
                        [Security.Principal.NTAccount]).Value } catch { "$sid (unresolved)" }
        [PSCustomObject]@{
            Computer   = $_.Name
            Creator    = $creator
            Created    = $_.whenCreated
            OS         = $_.operatingSystem
            Enabled    = $_.Enabled
            LastLogon  = if ($_.lastLogonTimestamp) { [datetime]::FromFileTime($_.lastLogonTimestamp) }
            DN         = $_.DistinguishedName
        }
    } | Sort-Object Created -Descending | Export-Csv .\quota-created-computers.csv -NoTypeInformation

Achten Sie auf Computer ohne Betriebssystemwert und ohne Anmeldung: Dieses Muster bedeutet oft ein Konto, das von einem Skript oder Werkzeug erstellt wurde, nicht durch einen echten Beitritt. Neue Einträge, die von Standardbenutzern erstellt wurden, sind entweder ein undokumentierter Helpdesk-Prozess oder ein Fall für die Incident Response.

Prüfen: wer Rechner legitimerweise aufnimmt

Werten Sie über einige Wochen das Ereignis 4741 (ein Computerkonto wurde erstellt) auf den DCs aus. Die Subject-Felder zeigen, welches Konto das jeweilige Computerobjekt erstellt hat. Gruppieren Sie nach Ersteller, um zu sehen, welche Personen und Dienstkonten Rechner aufnehmen und wie oft.

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4741 } -MaxEvents 5000 |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        $d = @{}; $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        [PSCustomObject]@{ Creator = "$($d.SubjectDomainName)\$($d.SubjectUserName)"; Computer = $d.TargetUserName }
    } | Group-Object Creator | Sort-Object Count -Descending | Select-Object Count, Name

Führen Sie das auf jedem DC aus oder besser auf Ihrem zentralen Collector (siehe AD-Überwachung und -Erkennung). Typische legitime Ersteller sind: das Bereitstellungsdienstkonto der SCCM-/MDT-Tasksequenzen, der Intune Connector for Active Directory für hybride Autopilot-Beitritte, einige Serveradministratoren und Helpdesk-Techniker. Alles außerhalb dieser Gruppen kommt auf die Liste der zu führenden Gespräche.

Durchsetzen: Kontingent auf 0 setzen und korrekt delegieren

Zuerst die delegierten Beitrittsrechte anlegen

Erstellen Sie eine Gruppe, zum Beispiel GG-Workstation-Join, und geben Sie ihr Beitrittsrechte nur auf der Ziel-OU. Der minimale Satz auf der OU ist:

• Create Computer objects und Delete Computer objects auf der OU (dieses Objekt und untergeordnete Objekte).
• Auf untergeordneten Computerobjekten: Reset password, Read and write Account Restrictions, Validated write to DNS host name und Validated write to service principal name.

Das können Sie mit dem Assistenten zum Zuweisen der Objektverwaltung gewähren (benutzerdefinierte Aufgabe, „Only the following objects in the folder: Computer objects“) oder per Skript mit dem ActiveDirectory-Provider:

$ou      = 'OU=Workstations,DC=corp,DC=example,DC=com'
$group   = Get-ADGroup 'GG-Workstation-Join'
$sid     = [Security.Principal.SecurityIdentifier]$group.SID
$computer = [guid]'bf967a86-0de6-11d0-a285-00aa003049e2'   # Klasse computer
$resetPw  = [guid]'00299570-246d-11d0-a768-00aa006e0529'   # Reset Password
$acctRes  = [guid]'4c164200-20c0-11d0-a768-00aa006e0529'   # Account Restrictions
$dnsHost  = [guid]'72e39547-7b18-11d1-adef-00c04fd8d5cd'   # Validated write to DNS host name
$spn      = [guid]'f3a64788-5306-11d1-a9c5-0000f8036d4d'   # Validated write to SPN

$R = [System.DirectoryServices.ActiveDirectoryRights]
$A = [System.Security.AccessControl.AccessControlType]::Allow
$I = [System.DirectoryServices.ActiveDirectorySecurityInheritance]

$acl = Get-Acl "AD:\$ou"
$acl.AddAccessRule((New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, ($R::CreateChild -bor $R::DeleteChild), $A, $computer, $I::All)))
$acl.AddAccessRule((New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, $R::ExtendedRight, $A, $resetPw, $I::Descendents, $computer)))
$acl.AddAccessRule((New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, ($R::ReadProperty -bor $R::WriteProperty), $A, $acctRes, $I::Descendents, $computer)))
$acl.AddAccessRule((New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, $R::Self, $A, $dnsHost, $I::Descendents, $computer)))
$acl.AddAccessRule((New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, $R::Self, $A, $spn, $I::Descendents, $computer)))
Set-Acl -Path "AD:\$ou" -AclObject $acl

Beschränken Sie das auf Staging-OUs für Arbeitsplätze und Server, niemals auf die OU Domain Controllers oder eine OU mit Tier-0-Assets. Nehmen Sie die Bereitstellungsdienstkonten, das Konto des Intune-Connectors und die Helpdesk-Beitrittsgruppe auf, und geben Sie jedem eine eigene Gruppe, wenn sie unterschiedliche OUs ansprechen.

Für Rechner, die von einer bestimmten Person ohne weitergehende Rechte aufgenommen werden sollen, legen Sie das Computerobjekt vorab an und verwenden in Active Directory-Benutzer und -Computer „The following user or group can join this computer to a domain“ – oder nutzen Sie den Offline-Domänenbeitritt mit djoin.exe /provision, ausgeführt von einem Administrator.

Das Kontingent auf 0 setzen

Set-ADDomain -Identity (Get-ADDomain) -Replace @{ 'ms-DS-MachineAccountQuota' = 0 }

Das Ändern des Attributs erfordert Schreibzugriff auf den Domänenkopf, normalerweise Domain Admins. Es wirkt, sobald es repliziert ist; ein Neustart ist nicht nötig.

Authenticated Users aus dem Benutzerrecht entfernen

Mit einem Kontingent von 0 ist das Benutzerrecht für Standardbenutzer harmlos, aber es zu entfernen ist Defense in Depth und macht die Absicht explizit. Setzen Sie in der GPO der Domain Controllers Add workstations to domain nur auf Ihre Beitrittsgruppe oder lassen Sie es leer, wenn alle Beitritte über OU-Delegierung laufen (OU-Berechtigungen hängen nicht von diesem Recht ab).

Bereinigen, was das Kontingent erstellt hat

Arbeiten Sie die CSV-Datei aus dem Messschritt ab. Verschieben Sie jedes legitime Gerät in die richtige OU, bestätigen Sie, dass der Besitzer Domain Admins oder Ihre Bereitstellungsgruppe ist, und entfernen Sie die expliziten ACEs, die dem ursprünglichen Ersteller gewährt wurden: Der Benutzer, der das Objekt erstellt hat, behält Schreibrechte darauf (einschließlich des Eigenschaftssatzes Account Restrictions), lange nachdem das Gerät den Besitzer gewechselt hat. Deaktivieren Sie Konten ohne passendes Gerät, warten Sie einen Zyklus und löschen Sie sie dann.

Beachten Sie die mit den Updates vom Oktober 2022 eingeführte Härtung des Domänenbeitritts (KB5020276): Die Wiederverwendung eines bestehenden Computerkontos beim Beitritt wird nun blockiert, sofern das beitretende Konto es nicht selbst erstellt hat, kein privilegiertes Konto ist oder nicht über die Richtlinie „Domain controller: Allow computer account re-use during domain join“ zugelassen ist. Das Korrigieren der Besitzverhältnisse während der Bereinigung vermeidet dort Überraschungen, wenn Geräte neu aufgesetzt werden.

Überprüfen

# Kontingent ist 0
(Get-ADObject (Get-ADDomain).DistinguishedName -Properties 'ms-DS-MachineAccountQuota').'ms-DS-MachineAccountQuota'

# Keine neuen über das Kontingent erstellten Computer seit der Änderung
$changeDate = Get-Date '2026-01-15'   # Datum, an dem das Kontingent auf 0 gesetzt wurde
Get-ADComputer -LDAPFilter '(mS-DS-CreatorSID=*)' -Properties whenCreated |
    Where-Object { $_.whenCreated -gt $changeDate } |
    Select-Object Name, whenCreated

Testen Sie einen Beitritt mit einem Standardbenutzerkonto: Er sollte mit einer Fehlermeldung scheitern, dass der Benutzer die maximale Anzahl an Computerkonten überschritten hat. Testen Sie einen Beitritt mit einem Mitglied der delegierten Gruppe in die Staging-OU: Er sollte gelingen. Alarmieren Sie weiterhin bei 4741, wenn der Ersteller kein bekanntes Bereitstellungskonto ist. Die meisten Assessment-Werkzeuge melden ein Kontingent ungleich null, daher sollte Ihr nächstes PingCastle-Assessment diese Regel nicht mehr auslösen.

Was dabei bricht

• Benutzer, die ihre eigenen Rechner aufnehmen, mit ihrem normalen Domänenkonto, einschließlich Entwicklern, die Labor-VMs in das produktive AD aufnehmen. Sie brauchen nun die delegierte Gruppe oder ein vorab angelegtes Objekt.
• Bereitstellungsprozesse, die ein einfaches Benutzerkonto ohne OU-Delegierung verwendet haben, oft eine alte MDT-JoinDomain-Anmeldeinformation in CustomSettings.ini oder ein Netzwerkbeitrittskonto einer Tasksequenz. Sie scheitern beim Beitrittsschritt, bis das Konto der delegierten Gruppe hinzugefügt ist.
• Drittanbieterwerkzeuge, die Computerobjekte erstellen, für Linux-Hosts (realmd/SSSD, Samba), NAS-Appliances oder VDI-Broker, sofern sie mit einem Standardkonto konfiguriert sind. Geben Sie jedem ein dediziertes Dienstkonto mit Delegierung auf seiner eigenen OU.
• Hybrid Autopilot, wenn das Computer- oder Dienstkonto des Intune-Connectors nicht auf der Ziel-OU delegiert wurde; die Dokumentation verlangt das bereits, aber Mandanten, bei denen es „einfach funktionierte“, verließen sich oft auf das Kontingent.
• Neuaufsetzen mit Wiederverwendung vorhandener Namen kann an der Beitrittshärtung von 2022 scheitern, wenn die Besitzverhältnisse nicht bereinigt wurden.

Weiterführende Lektüre: das Thema Delegierung und der Grundlagenleitfaden zur Delegierung in Active Directory, der Glossareintrag Machine Account Quota und AD-CS-Vorlagen prüfen, wo Maschinenvorlagen, für die Domain Computers registrieren dürfen, jeden vom Angreifer erstellten Computer in ein Zertifikat verwandeln.