Pre-Windows-2000-Zugriffsgruppe Active Directory

Was ist die Pre-Windows-2000-Zugriffsgruppe in Active Directory?

Die Pre-Windows-2000-Zugriffsgruppe in Active Directory, deren Gruppenname Pre-Windows 2000 Compatible Access lautet, kann umfassenden Lesezugriff auf das Verzeichnis gewähren. Welche Attribute ein Aufrufer lesen kann, hängt jedoch von den ACEs des Objekts ab. „Verzeichnisweiter Lesezugriff“ bedeutet nicht, dass jedes Geheimnis lesbar ist, und die Mitgliedschaft garantiert keine anonyme LDAP-Enumeration. Microsoft dokumentiert sowohl Objektzugriffsprüfungen als auch eine separate LDAP-Einschränkung. Zugriffsanforderungen für die Netzwerkverwaltung, Einschränkungen für anonymes LDAP.

Pre-Windows 2000 Compatible Access ist die integrierte Sicherheitsgruppe mit der Kennung S-1-5-32-554 unter CN=Builtin in der Domäne. Microsoft beschreibt sie als Kompatibilitätsmechanismus für Clients mit Windows NT 4.0 und älteren Versionen, mit Lesezugriff auf Benutzer- und Gruppeninformationen. Sie wird nicht durch AdminSDHolder geschützt. Laut Microsofts Gruppentabelle kann sie nicht aus ihrem Standardcontainer verschoben werden. Prüfen Sie ihre Mitglieder, statt die Gruppe zu löschen oder zu verschieben. Active-Directory-Sicherheitsgruppen.

Eine sinnvolle Untersuchung beantwortet vier Fragen: Welche Sicherheitsprinzipale sind Mitglieder, welche Berechtigungen erhalten sie, welche Schnittstelle akzeptiert ihre Anfragen und welche Anwendungen benötigen diese Lesezugriffe noch? Halten Sie die Antworten im Änderungsprotokoll getrennt fest. Die Mitgliederzahl liefert den ersten Hinweis; sie beantwortet die anderen drei Fragen nicht.

Legen Sie vor einer Zugriffsänderung die Erfolgskriterien der Prüfung fest. Bei einem unnötigen anonymen Zugriffspfad ist das gewünschte Ergebnis eine dokumentierte Einschränkung dieses Pfads, während erforderliche authentifizierte Funktionen weiterhin arbeiten. Bei einem Dienstkonto kann es darum gehen, umfassende Kompatibilitätsberechtigungen durch verifizierten Zugriff auf die tatsächlich angeforderten Attribute zu ersetzen. Bei einer ungeklärten Abhängigkeit können eine Ausnahme mit benanntem Verantwortlichen und ein Testplan das Ergebnis sein. Dies sind vorgeschlagene betriebliche Ergebnisse, keine Beobachtungen zu Ihrer Domäne und keine Behauptung, dass jede Mitgliedschaft ausnutzbar ist.

Die anfängliche Mitgliedschaft hängt von der Domänenerstellung ab

Die Protokollspezifikation verknüpft die anfängliche Mitgliedschaft mit dem Betriebssystem des ersten Domänencontrollers der Domäne und dem vom Administrator gewählten Berechtigungsmodus. Sie dokumentiert diese Fälle. MS-ADTS 6.1.1.4.12.14.

„Everyone ist immer der Standard“ unterschlägt diese Unterscheidung. Microsofts Anleitung zum Anwendungszugriff erklärt außerdem, dass das Hinzufügen eines Windows-Server-2003-DC zu einer bestehenden Windows-2000-Domäne deren zuvor gewählte Kompatibilitätseinstellung nicht ändert. Eine aktualisierte Domäne kann daher eine ältere Auswahl beibehalten. KB331951: Anwendungen und Autorisierungsinformationen.

Verwenden Sie diese Historie zur Einordnung eines Ausgangszustands, nicht zur Freigabe jedes aktuellen Mitglieds. Ein historischer Standard erfüllt möglicherweise keinen geschäftlichen Bedarf mehr, während eine spätere Ergänzung eine Anwendung unterstützen kann. Die aktuelle Liste verrät nicht, wer einen Eintrag hinzugefügt hat oder warum. Vermerken Sie „Herkunft unbekannt“, wenn Bereitstellungsunterlagen und aufbewahrte Änderungsprotokolle diese Frage nicht beantworten.

Funktionsweise: Mitgliedschaft, ACEs und Protokollbeschränkungen

Everyone allein ist nicht Anonymous

Microsofts NetAPI-Anforderungen verlangen für anonymen Zugriff auf Gruppeninformationen ausdrücklich eine Anonymous-Mitgliedschaft: Das normale anonyme Token enthält die Everyone-SID nicht. Das Verhalten von Windows 2000 und die Einstellung EveryoneIncludesAnonymous=1 sind auf derselben Seite dokumentierte Ausnahmen. Auf einem modernen System mit normalem Tokenverhalten ist Everyone allein nicht gleichbedeutend mit Anonymous Logon. Eine explizite Anonymous-Mitgliedschaft schafft einen Autorisierungspfad, der weiterhin den übrigen Einschränkungen der Schnittstelle unterliegt. Zugriffsanforderungen für die Netzwerkverwaltung.

Lesezugriff und Enumeration haben eigene Voraussetzungen. NetQueryDisplayInformation gibt Informationen zurück, die der Aufrufer lesen darf. Die Funktion erfordert List Contents am Domain-Objekt und Enumerate Entire SAM Domain am SAM-Server-Objekt im System-Container. Dies ist ein konkreter Berechtigungspfad, den es zu untersuchen gilt, keine Zusage, dass jeder Netzwerkclient sämtliche Objekte auflisten kann. NetQueryDisplayInformation.

LDAP hat eine separate Zugriffsbeschränkung

Windows Server 2003 führte eine standardmäßige Sperre für anonyme LDAP-Operationen ein, die über Binds und rootDSE-Suchen hinausgehen. Wird das siebte Zeichen von dsHeuristics auf 2 gesetzt, wird diese Sperre aufgehoben; die Operationen benötigen weiterhin eine ACL-Berechtigung. Das Hinzufügen von Anonymous zu dieser Gruppe ändert dieses Attribut nicht. Umgekehrt belegt die Prüfung der LDAP-Beschränkung nicht die Sicherheit einer anderen Enumerationsschnittstelle. KB326690: anonyme LDAP-Operationen.

Zu diesem separaten Mechanismus lesen Sie anonymer LDAP-Zugriff und die dsHeuristics-Beschränkung. Dort geht es um die LDAP-Einstellung und die Prüfung von Bind- und Suchoperationen. Hier geht es um den Autorisierungspfad der Kompatibilitätsgruppe. Nutzen Sie den verlinkten Artikel zur Untersuchung dieser Beschränkung und überprüfen Sie technische Entscheidungen anhand der Microsoft-Dokumentation.

Woher die geerbten Leseberechtigungen stammen

Der veröffentlichte Standardsicherheitsdeskriptor von Domain-DNS enthält Berechtigungen für RU. Microsofts Referenz für SID-Zeichenfolgen definiert RU als Alias für Pre-Windows 2000 Compatible Access. Dieser Auszug stammt aus dem Abschnitt Windows 2000 Server der Seite. Er zeigt Berechtigungen auf der Wurzelebene und vererbbare Berechtigungen. Vergleichen Sie die passende Version und die tatsächliche DACL Ihrer Domäne, bevor Sie sich darauf stützen. Domain-DNS-Klasse, SID-Zeichenfolgen.

(A;CI;LC;;;RU)
(A;;RC;;;RU)
(OA;CIIO;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)

In SDDL sind A und OA Formen von Zulassungs-ACEs; CI bezeichnet Containervererbung und IO ausschließlich Vererbung. RP bedeutet Read Property, LC List Children, LO List Object und RC Read Control. Die Rechtemaske und die Vererbungsflags sind getrennte Felder. Ein geerbter objektspezifischer Eintrag darf daher nicht als uneingeschränkte Berechtigung auf der Wurzel selbst verstanden werden. ACE-Zeichenfolgen.

Die beiden GUIDs für geerbte Klassen identifizieren User und Group. Computer ist eine Unterklasse von User: Beziehen Sie Computer in die Prüfung ein, ohne in diesem Auszug eine separate, auf Computer gerichtete ACE zu erfinden. Die Klassenreferenzen veröffentlichen versionsabhängige Standarddeskriptoren; der ältere User-Eintrag belegt nicht, dass jeder heutige Benutzer eine identische DACL besitzt. User-Klasse, Group-Klasse, Computer-Klasse.

Der vollständige Domain-DNS-Deskriptor enthält außerdem Lese-ACEs für Eigenschaftensätze von User. Die Sam-Server-Referenz zeigt separat einen RU-Eintrag mit RPLCLORC. Diese Standardwerte erklären zu messende Zugriffspfade; sie ersetzen nicht die Untersuchung von Vererbung, expliziten Einträgen und geschützten Objekten in einer realen Domäne. Domain-DNS-Deskriptor, Sam-Server-Klasse.

Tatsächliche Gruppe und Leseberechtigungen messen

Die folgenden Beispiele passen dokumentierte Cmdlet-Parameter und die Syntax von dsacls an. Sie wurden nicht gegen eine Domäne ausgeführt. Ersetzen Sie den fiktiven Server und die Distinguished Names durch in Ihrer Umgebung aufgelöste Werte. Führen Sie die Befehle von einer geeigneten administrativen Arbeitsstation mit den erforderlichen Werkzeugen und Leseberechtigungen aus. Bewahren Sie Ausgabe und Fehler jedes Befehls getrennt auf, damit eine fehlgeschlagene Abfrage nicht wie ein unauffälliges Ergebnis erscheint.

Schritt 1: Direkte Mitglieder erfassen

Beginnen Sie mit dem bekannten englischen Namen, sofern er vorhanden ist. Dieses Beispiel passt die dokumentierten Parameter Identity und Server des Mitgliedschafts-Cmdlets an. Get-ADGroupMember.

Get-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" -Server "dc01.contoso.com"

Identifizieren Sie die integrierte Gruppe anschließend anhand ihrer stabilen SID und fragen Sie die unverarbeitete Eigenschaft member ab. Microsofts Beispiel für Get-ADGroup verwendet dieses Muster mit einer anderen integrierten SID; diese Anpassung setzt stattdessen SID 554 ein. Get-ADGroup.

Get-ADGroup -Identity "S-1-5-32-554" -Properties member -Server "dc01.contoso.com"

Verwenden Sie diese Identität auch für die Ansicht der direkten Mitgliedschaft. Das Cmdlet akzeptiert eine SID als Identity. Identitätsoptionen von Get-ADGroupMember.

Get-ADGroupMember -Identity "S-1-5-32-554" -Server "dc01.contoso.com"

Vergleichen Sie die aufgelösten Mitglieder mit den unverarbeiteten Referenzen, insbesondere wenn die Auflösung spezieller Identitäten oder fremder Sicherheitsprinzipale fehlschlägt. Erfassen Sie DN und SID der Gruppe, den kontaktierten DC und die Identität jedes Mitglieds. Ein Auflösungsfehler ist keine leere Gruppe. Untersuchen Sie das referenzierte Objekt, bevor Sie eine Schlussfolgerung ziehen oder eine Entfernung vorbereiten.

Bewahren Sie diese direkte Ansicht zum Vergleich mit der Mitgliederzahl des Collectors auf. -Recursive beantwortet eine andere Frage: Das Cmdlet durchläuft die Gruppenhierarchie und gibt Mitglieder ohne untergeordnete Objekte zurück. Eine separat dokumentierte rekursive Prüfung kann bei der Untersuchung verschachtelter Sicherheitsprinzipale helfen, darf aber nicht stillschweigend den direkten Ausgangszustand ersetzen. Rekursives Verhalten von Get-ADGroupMember.

Kennzeichnen Sie im vorgeschlagenen Nachweisprotokoll erfolgreiche Abfragen, fehlgeschlagene Abfragen und nicht aufgelöste Referenzen ausdrücklich. Bewahren Sie die ursprünglichen Rohwerte neben Ihren Anmerkungen auf. So lässt sich ein späterer Vergleich nachvollziehen: Ein verschwundener Anzeigename kann auf eine andere Auflösung zurückgehen, während ein veränderter Rohwert der Mitgliedschaft untersucht werden muss. Machen Sie einen bequem formatierten Bericht nicht zum einzigen aufbewahrten Nachweis, insbesondere wenn ein anderer Prüfer die Entscheidung reproduzieren muss.

Schritt 2: Wurzel und repräsentative Nachfahren untersuchen

Mit dem DN eines Objekts und ohne Änderungsschalter zeigt dsacls dessen ACEs an. Das Werkzeug kann auch Berechtigungen ändern; behalten Sie daher die hier gezeigte reine Leseform bei. Microsofts Referenz verlangt eine Eingabeaufforderung mit erhöhten Rechten und Leseberechtigung auf dem Zielobjekt. Diese vier Befehle sind Anpassungen mit fiktiven Objekten. Dsacls-Referenz.

dsacls "DC=contoso,DC=com"

dsacls "CN=Alice,OU=Users,DC=contoso,DC=com"

dsacls "CN=AppReaders,OU=Groups,DC=contoso,DC=com"

dsacls "CN=PC01,OU=Computers,DC=contoso,DC=com"

Erfassen Sie für jede Stichprobe den berechtigten Prinzipal, den Zulassungs- oder Verweigerungstyp, die Rechte, die Vererbung sowie den Geltungsbereich für Klassen und Eigenschaftensätze. Identifizieren Sie Einträge für SID 554 auch bei lokalisiertem Anzeigenamen. Beziehen Sie Objekte ein, die von den geprüften Anwendungen genutzt werden, sowie Beispiele mit unterschiedlichen Vererbungseinstellungen. Ein einzelnes gewöhnliches Benutzerobjekt ist eine Stichprobe, kein domänenweites Ergebnis zum effektiven Zugriff.

Diese Unterscheidung ist beim Kennwortrückschreiben wichtig: Microsoft dokumentiert erforderliche Berechtigungen an der Wurzel und geerbte Berechtigungen an Nachfahren und fordert Administratoren anschließend auf, die effektiven Berechtigungen des Connectorkontos zu untersuchen. Das Lesen einer DACL und das Testen einer Operation des Aufrufers beantworten unterschiedliche Fragen. Nutzen Sie beides zur Validierung einer Abhängigkeit. Berechtigungen für das Kennwortrückschreiben.

Schritt 3: Abhängigkeiten dokumentieren

Schlagen Sie für jeden beibehaltenen Sicherheitsprinzipal einen Datensatz mit Verantwortlichem, Anwendung und Version, aufrufender Identität, angeforderten Attributen, Protokoll, Zielobjekten und Funktionstest vor. Nehmen Sie den Fehler auf, der eine Rücknahme rechtfertigen würde. Ein Kontoname, der einem Produkt ähnelt, ist ein Untersuchungsansatz, kein Beweis für eine Aktion des Installationsprogramms.

Diese Prüfung unterscheidet sich auch von Everyone und Authenticated Users in privilegierten AD-Gruppen. Dieser Artikel untersucht breit gefasste Identitäten, die direkt in privilegierten Gruppen stehen, und dauerhafte privilegierte Mitgliedschaften. Hier ist die dokumentierte Rolle der Gruppe die Autorisierung kompatibilitätsbedingter Lesezugriffe. Leiten Sie aus ihrer Mitgliederzahl keine Behauptung über direkte administrative Mitgliedschaft ab.

Erkennung: Zustand erfassen und Mitgliedschaftsänderungen überwachen

Kombinieren Sie das SID-basierte Inventar mit einem Änderungsnachweis. Microsofts Dokumentation zu Sicherheitsereignissen ordnet 4732 und 4733 Audit Security Group Management zu, mit einem Ereignis pro hinzugefügtem oder entferntem Mitglied. Sie können auf Domänencontrollern, Mitgliedsservern und Arbeitsstationen entstehen. Wählen Sie die für die Domänengruppe relevanten DC-Datensätze aus. Ereignis 4732, Ereignis 4733.

Eine vorgeschlagene Überwachungsregel sollte TargetSid mit S-1-5-32-554 abgleichen, MemberSid und die Subjektfelder aufbewahren und Änderungen mit genehmigten Arbeiten vergleichen. Der SID-Abgleich vermeidet die Abhängigkeit von einem übersetzten Gruppennamen. Testen Sie die Feldzuordnung in Ihrer Erfassungspipeline, bevor Sie die Regel als Abdeckung ansehen. Die Feldnamen stammen aus den XML-Beispielen der Ereignisse. Diese Regel ist ein betrieblicher Vorschlag, keine bereitgestellte SIEM-Erkennung. Ereignisfelder von 4732.

Diese Ereignisse protokollieren Mitgliedschaftsänderungen. Sie zeigen weder, welche Attribute gelesen wurden, noch entdecken sie jede Anwendungsabhängigkeit oder bestätigen eine erfolgreiche anonyme Enumeration. Fehlende Ereignisse sind ohne funktionierende Überwachungsrichtlinie, Erfassung und Aufbewahrung nicht aussagekräftig. Kombinieren Sie Protokolle mit dem gesicherten Zustand und autorisierten Funktionstests, statt eines davon als vollständige Zugriffsbewertung zu behandeln.

Behebung: Unnötigen Zugriff schrittweise entfernen (Remediation)

Dies ist ein vorgeschlagener Änderungsprozess auf Grundlage der dokumentierten Mechanismen, keine allgemeingültige Microsoft-Anweisung, die Gruppe zu leeren. Sichern Sie den Ausgangszustand, testen Sie Abhängigkeiten und ändern Sie ausgewählte Mitglieder. Die Mitgliedschaftsänderung betrifft eine Domänengruppe: Die Bezeichnung „OU-Pilot“ begrenzt die Wirkung einer Mitgliederentfernung nicht auf eine einzelne OU.

Schritt 1: Historische Standardwerte von späteren Abweichungen trennen

Verwenden Sie das oben erfasste SID-Inventar und die Rohwerte von member. Vergleichen Sie sie mit verfügbaren Erstellungs- und Upgrade-Unterlagen. Ordnen Sie die Einträge dann erklärten Standardwerten, dokumentierten Anwendungsergänzungen oder ungeklärter Mitgliedschaft zu. Prüfen Sie für jede Kategorie gleichermaßen den aktuellen Bedarf. Die Tabelle zur anfänglichen Mitgliedschaft erklärt die Herkunft; sie befreit nicht von der Prüfung. MS-ADTS-Spezifikation zur Mitgliedschaft.

Schritt 2: Dokumentierte Abhängigkeiten vor der Entfernung klären

Die folgenden Quellen liefern konkrete Abhängigkeiten und zu untersuchende Alternativen. Halten Sie deren Grenzen ein, statt sie auf jede Bereitstellung von Fernzugriff oder Synchronisierung auszudehnen.

Quellen: NT4-VPN-Fehlerbehebung, NPS registrieren, TGGAU-Zugriff, Berechtigungen für das Kennwortrückschreiben.

Die NPS-Registrierung belegt keine Anonymous-Anforderung. Bei TGGAU erfordert die Alternative Windows Authorization Access eine eigene Berechtigungsprüfung: Microsofts Anleitung unterscheidet neue Domänen von Domänen mit gemischtem Modus und aktualisierten Domänen, in denen die Gruppe den erforderlichen Zugriff nicht automatisch erhielt. Verwenden Sie nicht ersatzweise eine privilegierte Gruppe, nur um einen Zugriff-verweigert-Fehler zu beseitigen. TGGAU und WAA.

Die Entra-Connect-Anleitung warnt ausdrücklich vor Problemen beim Rückschreiben, wenn Authenticated Users fehlt, insbesondere bei älteren Versionen. Ihr Abschnitt zum SAM-Server unterscheidet außerdem direkte Berechtigungen von Authenticated Users vom Zugriff über diese Gruppe. Diese dokumentierte Abhängigkeit verhindert eine pauschale Empfehlung, jede breit gefasste Identität zu entfernen. Fehlerbehebung beim Rückschreiben.

Exchange bleibt hier als automatische Ursache von Mitgliedschaften unbelegt. Anhang B sagt, dass die Installation von Exchange zusätzliche Konten und Gruppen in Builtin und Users erstellen kann. Er belegt weder automatische Ergänzungen zu SID 554 noch betroffene Versionen. Behandeln Sie Einträge mit Exchange-Namen und Appliances als Fragen, die produktspezifische Nachweise und Funktionstests erfordern. Anhang B.

Schritt 3: Eine ausgewählte Entfernung simulieren

Untersuchen Sie vorrangig Anonymous, danach Everyone unter Berücksichtigung des tatsächlichen Tokenverhaltens sowie Konten ohne bestätigten Bedarf. Behalten Sie Authenticated Users bei, bis die Abhängigkeiten geklärt sind. Wählen Sie das exakt aufgelöste Mitglied und üben Sie in einer repräsentativen Testdomäne, bevor Sie die Änderung der Produktionsdomäne einplanen.

Die folgende Anpassung verwendet dokumentierte SID-Kennungen und -WhatIf. Sie simuliert die Entfernung von Anonymous; der Befehl wurde für diesen Artikel nicht ausgeführt. Validieren Sie zuerst den aufgelösten Sicherheitsprinzipal. Remove-ADGroupMember.

Remove-ADGroupMember -Identity "S-1-5-32-554" -Members "S-1-5-7" -Server "dc01.contoso.com" -WhatIf

Führen Sie nach den Tests und der Änderungsentscheidung des Administrators nur die ausgewählte Entfernung mit normaler Bestätigung durch. Das Cmdlet dokumentiert das Bestätigungsverhalten. Vermeiden Sie eine Schleife, die die Gruppe leert oder die Prüfung jedes Mitglieds unterdrückt. Eine -WhatIf-Vorschau führt die Entfernung nicht aus und beweist nicht, dass sie erfolgreich wäre. Sie kann das Anwendungsverhalten nach einer echten Änderung nicht vorhersagen. Parameter für Entfernung und Bestätigung.

Schritt 4: Funktion, Berechtigungen und Änderungsnachweis prüfen

Schlagen Sie ein Änderungsfenster für die Domäne vor, mit jeweils einem Mitglied und einem benannten Verantwortlichen für die Rücknahme. Lesen Sie nach der Replikation die Mitgliedschaft auf den von betroffenen Diensten verwendeten DCs erneut aus. Wiederholen Sie anschließend die autorisierten Operationen der Anwendung im relevanten Sicherheitskontext. Microsofts Anleitung zum Rückschreiben behandelt ausdrücklich Replikationsverzögerungen und die Verwendung eines bevorzugten DC während der Berechtigungskorrektur. Hinweise zur Replikation.

Prüfen Sie Anwendungszugriffsfehler und 4733 für die beabsichtigte Entfernung. Beobachten Sie 4732 für Ergänzungen, einschließlich einer kontrollierten Rücknahme. Verschlechtert sich die Funktion, stellen Sie im genehmigten Wiederherstellungsprozess nur die geänderte Mitgliedschaft wieder her und untersuchen Sie die Abhängigkeit. Schreiben Sie weder eine willkürliche Überwachungsdauer noch einen allgemeinen DC-Neustart vor: Die Neustartanweisung im NT4-VPN-Dokument gehört zu dessen spezifischem historischem Szenario. 4733, 4732, NT4-Szenario.

Wie EtcSec dies erkennt

Die etc-collector-Prüfung PRE_WINDOWS_2000_ACCESS ist in ad/groups/membership/pre-windows-2000-access.go:24 implementiert. Die geprüfte Funktion Detect() wandelt CN und SAMAccountName jeder Gruppe in Kleinbuchstaben um und wählt dann die erste Gruppe aus, deren Name pre-windows 2000 compatible access enthält. Ihr Count ist len(targetGroup.Members): Alle erfassten Mitglieder zählen, einschließlich Authenticated Users und Anwendungskonten. Der geprüfte Katalog stuft sie als Medium mit Gewicht 1 ein.

Die Funktion gibt auch dann einen Befund zurück, wenn keine passende Gruppe gefunden wird oder die Anzahl null ist. Details und die betroffene Gruppe werden nur aufgenommen, wenn IncludeDetails aktiviert ist, eine Gruppe gefunden wurde und die Anzahl positiv ist. Diese Aussagen beschreiben die geprüfte Implementierung, kein gegen Ihre Domäne ausgeführtes Audit.

Die Prüfung verifiziert nicht die SIDs der Gruppe oder ihrer Mitglieder, untersucht keine ACEs, liest dsHeuristics nicht, löst in dieser Funktion keine verschachtelte Mitgliedschaft auf und testet keinen Anwendungszugriff. Der Abgleich mit einer englischen Teilzeichenfolge kann lokalisierte Namen übersehen und einen unbeabsichtigten passenden Namen auswählen. Fehlende Eingabedaten können ebenfalls null ergeben. Nutzen Sie SID-basierte Messungen, um das Signal einzuordnen. Eine positive Anzahl beweist keine Anonymous-Mitgliedschaft, und null beweist nicht, dass jeder Lesezugriffspfad eingeschränkt ist.

COMPUTER_PRE_WINDOWS_2000 liegt ausdrücklich außerhalb des Umfangs und der Tags dieses Artikels. Dessen separat geprüfte Funktion Detect() in ad/computers/other/pre-windows-2000.go:43 gleicht nicht leere OperatingSystem-Werte ohne Beachtung der Groß- und Kleinschreibung mit Windows 95|Windows 98 ab. Sie untersucht weder Mitglieder noch Berechtigungen dieser Gruppe.

Schließen Sie die Prüfung mit den nachgewiesenen Fakten ab: aufgelöste Identitäten, untersuchte ACL-Pfade, geprüfte Protokollbeschränkungen, getestete Abhängigkeiten und überwachte ausgewählte Änderungen. Der Mitgliedschaftsdetektor hilft bei der Priorisierung dieser Arbeit; die Nachweise bestimmen, welcher Zugriff sicher entfernt werden kann.