AD logonCount pro DC pruefen: Summen vor Kontostilllegung einordnen

AD logonCount pro DC pruefen: Was die Prüfung feststellt

Wer AD logonCount pro DC pruefen möchte, muss zunächst klären, woher ein Verzeichniszähler stammt, bevor er ihn zur Stilllegung eines Administrationskontos heranzieht. Ein kleiner Wert auf einem Domänencontroller kann eine Prüfung anstoßen. Er belegt weder die domänenweite Aktivität des Kontos noch seine aktuellen Berechtigungen oder ob der verantwortliche Kontoinhaber es weiterhin benötigt.

Das nützliche Ergebnis ist eine Prüfakte: die Kontoidentität, alle DCs im Prüfungsumfang, jeder zurückgegebene Wert, ungeklärte Lesevorgänge, der aktuelle Zugriff und die Entscheidung des Kontoinhabers. Halten Sie diese Beobachtungen zusammen, damit ein Administrator erklären kann, warum ein Konto beibehalten, weiter untersucht oder in einen genehmigten Stilllegungsprozess aufgenommen wurde.

Dieser Leitfaden schlägt einen Ablauf zur ausschließlich lesenden Erfassung und Entscheidungsfindung vor. Die PowerShell-Beispiele passen dokumentierte Microsoft-Learn-Parameter an beispielhafte Identitäten und Server an; sie wurden nicht in einer Kundendomäne ausgeführt. Ersetzen Sie die Platzhalter durch verifizierte Werte und verwenden Sie das ActiveDirectory-Modul mit einer Identität, die zum Lesen des Verzeichnisses berechtigt ist.

Wie der Zähler funktioniert

Microsofts Referenz zum Attribut Logon-Count beschreibt einen Zähler erfolgreicher Anmeldungen, der auf jedem DC unabhängig und ohne Replikation geführt wird. Sie empfiehlt, jeden DC abzufragen und seine Werte zu summieren. Null bedeutet unbekannt. Stillgelegte DCs können Lücken in der Historie hinterlassen, und die dokumentierte Obergrenze von 65535 macht einen gesättigten Zähler ungeeignet, um die Aktivität auf diesem DC nachzuverfolgen.

Behandeln Sie das Attribut als kumulative Anzahl mit Grenzen bei Abdeckung und Historie, nicht als Zeitstempel. Eine Anzahl von 1–4 enthält kein Datum, aus dem sich eine kürzlich eingetretene Inaktivität berechnen ließe. Selbst ein vollständiger Satz aktueller Abfragen kann Beiträge stillgelegter Controller nicht rekonstruieren. Dokumentieren Sie diese Einschränkungen neben jeder Teilsumme, statt sie als die gesamte Lebenszeithistorie des Kontos zu beschreiben.

Ersetzen Sie logonCount nicht durch badPwdCount, wenn es nicht verfügbar ist. Der verwandte Ablauf zur badPwdCount-Analyse prüft Fehlerzähler vor einem Angriffsurteil. Seine konsequente Dokumentation von Server, Zeitpunkt und Erfassungsqualität gilt auch hier, doch ein Fehlerzähler beantwortet nicht die Frage nach erfolgreichen Anmeldungen.

Erkennung: Eine Nachweismatrix für Konto und DC aufbauen

Schritt 1 — Identität und Umfang festlegen

Gehen Sie vom ursprünglichen Befund aus und bewahren Sie seine Kontokennung, den Collector-Endpunkt, den Erfassungszeitpunkt, die Collector-Revision und Fehler auf. Bestätigen Sie die Domäne des Kontos und das DC-Inventar mit dem Team für den Verzeichnisbetrieb. Die beiden folgenden Hostnamen veranschaulichen getrennte Abfragen; sie sind keine vollständige DC-Liste einer tatsächlichen Domäne.

Wählen Sie eine stabile Kontokennung und gleichen Sie sie vor der erneuten Abfrage mit dem Befund ab. Bewahren Sie den DN oder die GUID zusammen mit dem angezeigten Namen in der Prüfakte auf. Wenn das Konto auf einem Server nicht aufgelöst werden kann, erhalten Sie den Suchfehler und untersuchen Sie Identität, Umfang oder Verzeichnisverfügbarkeit. Erstellen Sie keinen numerischen Eintrag für ein Objekt, das nicht zurückgegeben wurde.

Microsoft dokumentiert die Auswahl der Identität, die explizite Serverauswahl und zusätzliche Attribute in Get-ADUser. Diese Anpassungen fordern logonCount ausdrücklich von einem benannten DC an, statt sich auf die standardmäßige Serverauswahl zu verlassen:

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc01.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc02.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Führen Sie dieselbe dokumentierte Abfrage gegen jeden verifizierten DC im Prüfungsumfang einzeln aus. Speichern Sie das zurückgegebene Objekt und jeden Fehler mit dem gewählten Endpunkt und dem Abfragezeitpunkt. Eine erfolgreiche Verbindung allein belegt nicht, dass das angeforderte Attribut zurückgegeben wurde. Prüfen Sie die Eigenschaft, statt zuzulassen, dass eine spätere numerische Konvertierung einen leeren Wert in Null umwandelt.

Schritt 2 — Die Rohbeobachtungen bewahren

Verwenden Sie eine Zeile pro Konto und DC. Die folgende Matrix ist eine empfohlene Nachweisstruktur, keine Beispielausgabe aus einer Kundenumgebung und keine vom Detektor automatisch gelieferten Felder.

Bewahren Sie bei einer zurückgegebenen Null die wörtliche Null auf und kennzeichnen Sie den Aktivitätswert als unbekannt. Bewahren Sie bei einem fehlenden Attribut dessen Fehlen auf. Bei einem ungültigen Wert erhalten Sie seine ursprüngliche Darstellung und stufen die Interpretation als ungeklärt ein. Bei einer fehlgeschlagenen Abfrage erhalten Sie den Fehler und lassen die Anzahl ungesetzt. Diese Zustände können unterschiedliche Folgemaßnahmen erfordern, obwohl keiner eine bekannte Aktivitätsanzahl liefert.

Ist ein Server nicht verfügbar, behalten Sie seine Zeile im erklärten Umfang bei. Weisen Sie den erneuten Versuch oder die Untersuchung einem Verantwortlichen zu. Ein erfolgreicher Wiederholungsversuch wird zu einer neuen Beobachtung mit eigenem Zeitpunkt; er sollte den ursprünglichen Erfassungsfehler nicht überschreiben. Bewahren Sie ebenso unterschiedliche Beobachtungen bei wiederholter Erfassung auf, statt den Wert auszuwählen, der die Prüfung vollständig erscheinen lässt.

Schritt 3 — Zusammenfassen, ohne Unsicherheit zu beseitigen

Summieren Sie die bekannten positiven Werte und erhalten Sie dabei die vollständige Matrix. Geben Sie das Ergebnis als bekannte Teilsumme an, sobald ein DC einen unbekannten Wert hat oder nicht erfolgreich abgefragt wurde. Listen Sie daneben auf, welche DCs beigetragen haben und welche nicht, das Erfassungsintervall sowie jeden gesättigten Zähler oder fehlenden historischen Beitrag.

Entfernen Sie nicht stillschweigend nicht verfügbare Server aus dem Umfang und füllen Sie deren Zellen nicht mit Null. Eine Tabelle mit einem numerischen Wert in jeder Zeile kann weiterhin ungeklärte Nachweise enthalten. Die Zusammenfassung sollte dies für die Person sichtbar machen, die über weiteren Erfassungsbedarf entscheidet.

Wenden Sie dieselbe Regel beim Vergleich von Prüfungen an. Halten Sie Kontoidentität und DC-Abdeckung konsistent, beschreiben Sie Änderungen am Inventar und bewahren Sie die frühere Matrix auf. Eine veränderte Teilsumme kann eine veränderte Abdeckung widerspiegeln; sie liefert nicht automatisch ein Intervall kürzlich erfolgter Aktivität. Wenn die Entscheidung eine Zeitleiste erfordert, beschaffen Sie separat eingeordnete Aktivitätsnachweise für einen angegebenen Zeitraum und dokumentieren Sie deren Abdeckung.

Zugriff und Kontoverantwortung vor der Stilllegung prüfen (Remediation)

Schritt 4 — Das administrative Kennzeichen klären

Der Detektor verwendet adminCount=1, um Kandidaten auszuwählen. Stellen Sie den aktuellen Zugriff fest, bevor Sie das Konto als Administratorkonto bezeichnen. Der Ablauf zur Bereinigung eines veralteten adminCount erklärt, warum das Kennzeichen eine frühere privilegierte Mitgliedschaft überdauern kann. Folgen Sie seiner Prüfung von Mitgliedschaften und Berechtigungen, statt anzunehmen, dass das Flag ein Inventar aktueller Rechte ist.

Fordern Sie für die Stilllegungsentscheidung eine Prüfung direkter und verschachtelter Gruppen, der primären Gruppe, relevanter delegierter Berechtigungen und der Ressourcen an, die das Konto administrieren kann. Halten Sie Prüfer, Umfang und ungeklärte Pfade in der Akte fest. Eine unauffällige Liste direkter Gruppen beantwortet die umfassendere Zugriffsfrage nicht abschließend.

Daraus können verschiedene Ergebnisse entstehen: ein Konto mit gerechtfertigtem aktuellem Zugriff; ein früher privilegiertes Konto mit verbleibendem Zustand; ungerechtfertigte Berechtigungen, die eine gezielte Änderung erfordern; oder weiterhin nicht verifizierter Zugriff. Dokumentieren Sie die tatsächlichen Nachweise für die Einstufung. Setzen Sie adminCount nicht einfach zurück, um diesen Befund zu entfernen, und behandeln Sie die Bereinigung des Flags nicht als Kontostilllegung.

Schritt 5 — Die Entscheidung des Kontoinhabers einholen

Ermitteln Sie den verantwortlichen Kontoinhaber und fragen Sie, welche Arbeitsabläufe vom Konto abhängen. Prüfen Sie den angegebenen Zweck anhand verfügbarer betrieblicher Nachweise und Abhängigkeiten. Berücksichtigen Sie geplante, seltene, Wiederherstellungs- und Notfallnutzungen, soweit sie auf dieses Konto zutreffen; ihre Relevanz muss sich aus den Angaben des Kontoinhabers und der Umgebung ergeben, nicht aus einer angenommenen Erklärung für einen kleinen Zähler.

Der vorgeschlagene Prozess trennt die Zählerprüfung von der Genehmigung einer Zugriffsänderung. Wenn die Stilllegung genehmigt ist, verwenden Sie das Kontolebenszyklusverfahren der Organisation für die verifizierte Identität. Wählen Sie Änderungs- und Wiederherstellungsmethode aus diesem genehmigten Plan. Dieser Leitfaden schreibt keine massenhafte Deaktivierung oder Löschung auf Grundlage des Detektorschwellenwerts vor.

Schritt 6 — Das dokumentierte Ergebnis validieren

Lesen Sie nach einer genehmigten Änderung dasselbe Konto auf den dokumentierten Servern erneut aus und bewahren Sie die neuen Ergebnisse getrennt auf. Die oben dokumentierten Get-ADUser-Parameter für Identität, Server und Eigenschaften unterstützen auch diese wiederholbare Abfrage:

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc01.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Wiederholen Sie die für die Änderung relevante Zugriffsprüfung und lassen Sie den Kontoinhaber die betroffenen Arbeitsabläufe bestätigen. Dokumentieren Sie den tatsächlichen Kontozustand, Berechtigungen, verbleibende Abhängigkeiten, Fehler und Folgemaßnahmen. Allein das Verschwinden aus dem Befund belegt nicht, dass Berechtigungen oder geschäftliche Abhängigkeiten korrekt behandelt wurden.

Wie EtcSec dies erkennt

Die geprüfte etc-collector-Prüfung ist ADMIN_LOGON_COUNT_LOW, in Accounts, mit dem Schweregrad Info. Bei Collector-Revision afca1b9f7bba6f076d6a6493371486071001452b wählt admin-logon-count-low.go:36 aktivierte Benutzer mit AdminCount=true aus, schließt LogonCount=0 aus und behält eine von Null verschiedene Anzahl unter 5 bei. Sie wendet keinen Inaktivitätszeitraum an. Der Schwellenwert ist ein Produktprädikat, keine Regel zur Stilllegung von Konten.

Count ist die Anzahl übereinstimmender Benutzer, keine Summe von Anmeldungen. Der Detektor gibt den Befund auch dann zurück, wenn diese Anzahl Null ist; Details zu betroffenen Benutzern werden angehängt, wenn sie angefordert wurden und Treffer vorhanden sind. Ein Treffer ist ein Ermittlungsansatz aus der erfassten Sicht.

Der LDAP-Provider begrenzt diese Sicht. client.go:460 ruft Benutzer über die ausgewählte Verbindung ab, ohne DC-Zähler zu aggregieren. parser.go:41 fordert logonCount an; der Benutzerparser liest es über getIntAttr, dessen Behandlung fehlender Werte und ungültiger Ganzzahlen Null ergeben kann. Der Detektor kann daher nicht alle Erfassungszustände unterscheiden, die die unabhängige Matrix bewahrt. Der Ausschluss von Null verhindert, dass eine unbekannte Anzahl zu einem positiven Befund wird, verifiziert jedoch keine domänenweite Nutzung.

Die Prüfung berechnet keine Domänensumme und stellt weder effektive Rechte noch Kontoverantwortung, Abhängigkeiten oder eine Zeitleiste jüngster Aktivität fest. adminCount ist ihr Auswahlkennzeichen, kein Beleg aktueller Privilegien. Verwenden Sie ADMIN_LOGON_COUNT_LOW, um die Prüfung zu eröffnen, und ordnen Sie dann jede DC-Beobachtung und den Zugriff des Kontos ein, bevor Sie über seine Zukunft entscheiden.