AD Rechte fuer validierte DNS Hostnamen: ACE vor Delegierung prüfen

Was AD Rechte fuer validierte DNS Hostnamen bedeuten

AD Rechte fuer validierte DNS Hostnamen regeln eine eingeschränkte Aktualisierung von dNSHostName auf einem Verzeichnisobjekt. Eine ACE mit der zugehörigen GUID ist ein Anlass, eine Delegierung zu untersuchen. Klären Sie vor einer Änderung, wer die Berechtigung erhält, ob die Maske tatsächlich das validierte Schreiben gewährt, ob der Eintrag auf den Computer zutrifft und welcher Bereitstellungsvorgang ihn benötigt.

Microsoft kennzeichnet Validated-DNS-Host-Name mit der GUID 72e39547-7b18-11d1-adef-00c04fd8d5cd. Die Berechtigung erlaubt einen DNS-Hostnamen, der den Namensvorgaben für Computer und Domäne entspricht. Sie begründet keine Berechtigung zur Bearbeitung einer DNS-Zone und belegt nicht, dass jemand Datenverkehr umgeleitet hat.

Das nützliche Ergebnis dieser Prüfung ist eine dokumentierte Entscheidung: eine genehmigte Delegierung, eine nachweislich unnötige Berechtigung, die entfernt werden soll, oder eine offene Frage zur Erfassung oder Autorisierung. Eine Liste übereinstimmender GUIDs allein kann diese Entscheidung nicht liefern. Halten Sie die Identität des Computerobjekts, die ACE und den legitimen Arbeitsablauf während der gesamten Untersuchung zusammen.

Funktionsweise: validiertes Schreiben gegenüber WriteProperty

Die MS-ADTS-Semantik für validiertes Schreiben unterscheidet gewöhnlichen Zugriff über RIGHT_DS_WRITE_PROPERTY von validiertem Schreiben. Gewöhnlicher Schreibzugriff auf Eigenschaften erlaubt Werte, die das Attributschema zulässt, ohne die zusätzlichen Wertprüfungen des validierten Schreibens. Eine ACE für validiertes Schreiben kombiniert das Zugriffsmaskenbit RIGHT_DS_WRITE_PROPERTY_EXTENDED mit einer kennzeichnenden GUID in ObjectType; eine ACE ohne ObjectType-GUID kann alle validierten Schreibvorgänge auf dem Objekt abdecken.

Die GUID ist zugleich der Schema-Bezeichner des Attributs dNSHostName. Folglich lässt sich allein anhand der GUID nicht unterscheiden, ob eine ACE das Schreiben dieser Eigenschaft oder deren validierten Schreibvorgang betrifft. Interpretieren Sie Maske und Geltungsbereich gemeinsam.

Für den validierten Pfad legt MS-ADTS die dNSHostName-Vorgaben fest: Das Objekt muss ein Computer oder Server oder eine Unterklasse davon sein; in AD DS setzt sich der Hostname aus dem aktuellen sAMAccountName ohne abschließendes Dollarzeichen und dem DNS-Namen des Domänen-Namenskontexts oder einem zulässigen Wert aus msDS-AllowedDNSSuffixes zusammen. Der Anforderer muss das Recht für validiertes Schreiben besitzen. Prüfen Sie diese Eingaben zur Namensbildung, wenn Sie den vorgesehenen Vorgang beurteilen.

Für die umfassendere Untersuchung von Eigentümer und DACL nutzen Sie die Prüfung von DACL und Eigentümerschaft bei Computerobjekten. Die vorliegende Prüfung konzentriert sich auf die konkrete Autorisierung zum validierten Schreiben. DNS-Zonentransfers und die Konfiguration dynamischer Updates betreffen eine andere Angriffsfläche; die Änderung einer ACE auf einem Computerobjekt überprüft diese Zoneneinstellungen nicht.

Erkennung: Objekt erfassen und die vollständige ACE prüfen

Schritt 1: Die Erfassungsgrenze festlegen

Beginnen Sie mit dem betroffenen DN und dem vorgesehenen Computerbestand. Dokumentieren Sie den Domänencontroller, den Erfassungszeitpunkt, die zum Lesen verwendeten Anmeldedaten, die Suchbasis und ausgeschlossene OUs. Gleichen Sie den Bestand mit dem vom Administrator vorgesehenen Umfang ab. Das erfolgreiche Lesen eines Objekts sagt nichts über Computer aus, die im Inventar fehlen.

Verwenden Sie für das Lesen der Objekte eine Windows-Administrationsarbeitsstation mit dem PowerShell-Modul ActiveDirectory. Das folgende dokumentationsbasierte Beispiel nutzt die unterstützten Parameter Identity, Server und Properties von Get-ADObject, mit beispielhaften Werten, die Sie für Ihre Umgebung ersetzen müssen:

Get-ADObject -Identity "CN=APP01,OU=Servers,DC=example,DC=com" -Server "dc01.example.com" -Properties objectClass,sAMAccountName,dNSHostName,nTSecurityDescriptor

Bestätigen Sie den zurückgegebenen DN und die Klasse, bevor Sie Berechtigungen interpretieren. Bewahren Sie den Deskriptor zur detaillierten Untersuchung zusammen mit den Konto- und Hostnamenwerten auf. Bezeichnen Sie einen nicht verfügbaren Deskriptor nicht als leere DACL. Dokumentieren Sie fehlgeschlagene Lesevorgänge separat und wiederholen Sie sie mit einer autorisierten Erfassungsidentität, bevor Sie eine Aussage zur Abdeckung treffen.

Schritt 2: Die ACL inventarisieren

Microsofts Dsacls-Referenz beschreibt die Anzeige der ACEs eines Objekts durch Angabe seines DN in Anführungszeichen ohne Änderungsschalter. Führen Sie den Befehl in einer Windows-Eingabeaufforderung mit erhöhten Rechten und Leseberechtigungen für das Verzeichnis aus:

dsacls "\\dc01.example.com\CN=APP01,OU=Servers,DC=example,DC=com"

Dies ist ein Syntaxbeispiel für einen beispielhaften Computer-DN, keine ausgeführte Umgebungsprüfung. Untersuchen Sie die vollständigen Berechtigungseinträge und nutzen Sie bei Bedarf die Registerkarte Sicherheit des Objekts zur detaillierten Prüfung des Geltungsbereichs. Dokumentieren Sie SID und aufgelöste Identität jedes Berechtigten, ACE-Typ, Zugriffsmaske, ObjectType, Vererbungsquelle und Anwendbarkeit. Bewahren Sie den ursprünglichen Deskriptor auf, statt nur eine gefilterte Anzeige der GUID zu behalten.

Schritt 3: Maske, Berechtigten und Vererbung auflösen

Microsofts Leitfaden zu Domänenbeitrittsberechtigungen zeigt die ACE für validiertes DNS-Schreiben mit der Maske 0x00000008, bezeichnet als ACTRL_DS_SELF, und der DNS-Hostname-GUID. Dieser Maskenname ist vom Berechtigten namens SELF zu unterscheiden: Auch ein Beitrittskonto kann das Bit für validiertes Schreiben erhalten. Prüfen Sie, ob das relevante Bit in der erfassten Maske vorhanden ist; eine andere oder kombinierte Maske benötigt eine eigene Interpretation.

MS-ADTS Checking Access erläutert Principal Self, SID S-1-5-10: Auf einem Sicherheitsprinzipalobjekt steht er für den Prinzipal dieses Objekts und wird bei der Zugriffsprüfung durch dessen SID ersetzt. Der DC bewertet den Sicherheitskontext des Anforderers, den angeforderten Zugriff und den passenden Deskriptor. Das Auflösen eines Anzeigenamens oder das Vorhandensein einer erlaubenden ACE ersetzt diese vollständige Bewertung nicht.

Prüfen Sie gruppenbasierte Berechtigte anhand der tatsächlichen Beitritts- oder Bereitstellungsidentität. Fragen Sie den Verantwortlichen für den Arbeitsablauf, welche Identität jeden Schritt ausführt und welche Maschinen sie verwalten darf. Eine nach der Bereitstellung benannte Gruppe ist kein Beleg dafür, dass jedes Mitglied Zugriff auf jeden Computer benötigt.

Microsofts Vererbungsregeln unterscheiden geerbte ACEs von ACEs, die nur zur Vererbung dienen. Ein solcher InheritOnly-Eintrag gilt nicht für das Objekt, das ihn trägt. Verfolgen Sie den Quellcontainer und den Objektklassenbereich; bewerten Sie den Eintrag so, wie er auf dem Zielcomputer erscheint, statt anzunehmen, dass ein Elterneintrag überall identisch anwendbar ist.

Schritt 4: Erwartete, beobachtete und unbekannte Nachweise getrennt halten

Verwenden Sie dieses Arbeitsblatt für jeden betroffenen Computer. Es ist eine Prüfungsvorlage, kein Bericht über gemessene Ergebnisse:

Behebung: Arbeitsablauf prüfen, dann Delegierung ändern (Remediation)

Schritt 1: Ausgangszustand sichern und Notwendigkeit feststellen

Speichern Sie den ursprünglichen Deskriptor und das Prüfungsarbeitsblatt. Stimmen Sie den erforderlichen Vorgang vor der Bearbeitung mit den Verantwortlichen für Maschinen und Bereitstellung ab. Unterscheiden Sie die Erstellung eines neuen Computerkontos von der Wiederverwendung eines bestehenden. Microsofts Domänenbeitrittsleitfaden zählt die Berechtigung für validiertes DNS-Schreiben zu den Rechten, die die Beitrittsidentität bei der Wiederverwendung eines Kontos benötigt; dieses Recht kann daher absichtlich vorhanden sein.

Dokumentieren Sie für eine beibehaltene Ausnahme die SID des Berechtigten, das genaue Recht, den Objektbestand, die Vererbungsquelle, den Zweck, den Verantwortlichen und das Prüfdatum. Fügen Sie die Nachweise für diese Entscheidung und offene Fragen hinzu. Eine Ausnahme sollte erklären, weshalb die Delegierung auf diesen Computern benötigt wird, statt nur festzuhalten, dass der Scanner sie schon früher gemeldet hat.

Schritt 2: Den nachweislich unnötigen Eintrag entfernen oder einschränken

Bearbeiten Sie die konkrete unnötige Berechtigung auf der Registerkarte Sicherheit des Objekts. Ist sie geerbt, prüfen und korrigieren Sie die Quelldelegierung mit dem OU-Verantwortlichen und prüfen Sie die anderen Empfänger, bevor Sie die Änderung anwenden. Erhalten Sie die für den verbleibenden Arbeitsablauf benötigten Berechtigungen und überprüfen Sie den resultierenden ACE-Geltungsbereich.

dsacls /R entfernt laut Dokumentation alle ACEs für den angegebenen Berechtigten. Es eignet sich nicht dazu, nur den validierten DNS-Schreibzugriff eines Berechtigten zu entfernen, der andere Berechtigungen behalten muss. Ersetzen Sie eine geprüfte ACE-Bearbeitung nicht durch die Entfernung aller Einträge eines Berechtigten und setzen Sie nicht den gesamten Sicherheitsdeskriptor des Objekts zurück, um einen Befund verschwinden zu lassen.

Schritt 3: Berechtigungen und vorgesehenen Vorgang überprüfen

Lesen Sie den Computer und seine ACL erneut vom ausgewählten DC. Vergleichen Sie den resultierenden Deskriptor mit dem Ausgangszustand und dokumentieren Sie genau, welcher Eintrag geändert wurde. Bestätigen Sie, dass der geprüfte Berechtigte die unerwünschte effektive Autorisierung nicht weiterhin durch einen anderen anwendbaren Eintrag besitzt. Nehmen Sie bei geerbten Änderungen Stichproben aus dem relevanten Empfängerbestand und überprüfen Sie die vorgesehene Objektklassengrenze.

Testen Sie den genehmigten Beitritts- oder Bereitstellungsablauf auf einem repräsentativen Testcomputer mit der tatsächlich delegierten Identität. Dokumentieren Sie den ausgeführten Vorgang, seinen Erfolg und Verzeichnisfehler. Auf einem Domänenmitglied bietet Microsofts Test des sicheren Kanals eine zusätzliche Funktionsprüfung, lokal in Windows PowerShell mit erhöhten Rechten ausgeführt:

Test-ComputerSecureChannel -Verbose

Dies überprüft die Domänenbeziehung des Mitglieds; es belegt nicht, dass die Hostnamenbereitstellung funktioniert oder die ACL-Prüfung abgeschlossen ist. Microsoft warnt davor, dass das Cmdlet auf Domänencontrollern falsch positive Fehler zurückgibt. Diese Befehle stammen aus der Dokumentation und wurden nicht in einer Kundenumgebung ausgeführt.

Wie EtcSec dies erkennt

Die etc-collector-Prüfung ACL_COMPUTER_WRITE_VALIDATED_DNS, geprüft am Commit 15fc6399c215eabc415c370b762303cfcd7a353a, erstellt eine Menge erfasster Computer-DNs ohne Beachtung der Groß-/Kleinschreibung. Sie behält ACLEntry-Datensätze, deren ObjectType 72e39547-7b18-11d1-adef-00c04fd8d5cd entspricht und deren ObjectDN zu dieser Menge gehört. Count steht für die unterschiedlichen betroffenen Computer; bei abweichendem Wert erfasst TotalInstances die Anzahl passender Einträge.

Detect() filtert weder SELF noch andere Berechtigte, prüft nicht die Maske für validiertes Schreiben, bewertet nicht die Anwendbarkeit von InheritOnly und berechnet keine effektiven Rechte. Seine Ausgabe ist ein Inventar als Ausgangspunkt für die oben beschriebene Prüfung. Die Beschreibung des Detektors erwähnt DNS-Spoofing und MITM, doch das implementierte Prädikat belegt keines dieser Ergebnisse.

Auch die Erfassung begrenzt die Interpretation. Der LDAP-Provider fordert OWNER, GROUP und DACL mit den Sicherheitsdeskriptor-Flags 0x07 an, ohne die SACL. Er überspringt objektbezogene Fehler und fehlende Deskriptoren; Netzwerkfehler brechen hingegen den Kernaufruf ab und können eine erneute Verbindung und Wiederholung auslösen. Der Parser behält erlaubende Standard- und Objekt-ACEs, einschließlich Maske, Vererbungszustand und InheritOnly, schließt aber verweigernde ACEs aus. Der Detektor nutzt diese Unterschiede nicht, um eine Autorisierungsprüfung abzuschließen.

GetComputers und sein Parser liefern die DNs für die Zuordnung. Ein unvollständiges Computerinventar führt zu einem unvollständigen Detektorbereich. Ein Nullergebnis bedeutet, dass die bereitgestellten Daten keine passenden Einträge enthalten, und belegt weder, dass alle Computer gelesen wurden, noch, dass kein Prinzipal das Attribut ändern kann. Umfassende Einträge für validiertes Schreiben ohne diese konkrete GUID fallen ebenfalls außerhalb des passenden Prädikats. Klären Sie Erfassungsfehler und Umfang, bevor Sie ein Nullergebnis akzeptieren, und dokumentieren Sie die Autorisierungsentscheidung getrennt vom Scannerzählwert.