Active Directory ist ein Verzeichnisdienst, der Informationen über Benutzer, Computer und zugehörige Objekte verwaltet. Hier erfahren Sie, wie Sie inaktive Benutzerkonten finden können.
Es handelt sich um eine Datenbank mit relationalen Informationen, die im Laufe der Zeit gepflegt werden muss, um nützlich und relevant zu sein. Ein Verzeichnis enthält Konten, die nicht mehr verwendet werden. Diese Konten in Active Directory zu finden, ist nicht so einfach, wie es auf den ersten Blick scheint. Lassen Sie uns die Suche nach inaktiven Benutzerkonten und deren automatisierte Entfernung erläutern.
Lassen Sie uns definieren, was für diesen Prozess benötigt wird. Unser Ziel ist es, Mitarbeiterkonten zu finden, die sich über einen längeren Zeitraum nicht im Netzwerk angemeldet haben. Ich habe immer 90 oder 120 Tage als ein gutes Maß für die Abfrage der Inaktivität verwendet, aber diese Zahl kann auch nur 14 Tage betragen. Sie müssen entscheiden, was für Ihr Unternehmen richtig ist. 90 Tage sind ein ausreichender Puffer, um die Abwesenheit von Mitarbeitern aufgrund von Urlaub, familiären Notfällen oder längeren krankheitsbedingten Fehlzeiten zu berücksichtigen. Sobald die Konten 90 Tage Inaktivität erreicht haben, wollen wir diese Konten deaktivieren und in eine separate OU verschieben.
Wenn wir definieren, wonach wir zuerst suchen, können wir einen einfachen Regelsatz erstellen, dem wir folgen können. Unser Regelwerk sieht folgendermaßen aus:
Jedes Benutzerkonto hat mehrere Attribute, die Anmeldeinformationen enthalten. Wir möchten die Attribute finden, die die letzte Anmeldezeit anzeigen. Wenn wir diese Attribute finden können, können wir sie verwenden, um nach Konten zu suchen, die seit einem bestimmten Datum nicht mehr angemeldet waren. Wir können PowerShell verwenden, um den gesamten Regelsatz anzuzeigen und ein Attribut auszuwählen, mit dem wir arbeiten möchten.
Get-ADUser ist das am häufigsten verwendete Cmdlet zum Anzeigen von Benutzerinformationen. Sie können Get-ADObject und Search-ADAccount verwenden, aber Get-ADUser ist das beste Cmdlet für unsere Aufgabe. Um alle Benutzereigenschaften anzuzeigen, müssen wir der Cmdlet-Syntax -properties * hinzufügen. Wenn wir diese Syntax weglassen, sehen wir nur die Standardeigenschaften, nämlich nur 10 Eigenschaften.
Get-ADUser Michael_Kanakos -Properties *
Wir geben eine lange Liste von Feldern aus unserer Abfrage zurück (über 150!). Wir können nach Attributen suchen, die bestimmte Wörter enthalten, indem wir Platzhalter verwenden. Dies hilft uns, Attribute zu finden, die für unsere Aufgabe nützlich sein können. Wir möchten Anmeldeinformationen finden, also suchen wir nach Attributen, die das Wort Logon enthalten.
Sobald wir PowerShell angewiesen haben, alle Eigenschaften abzurufen, wäre es hilfreich, wenn wir die Liste der Eigenschaften einschränken könnten, um nur Eigenschaften anzuzeigen, die mit dem Wort Anmelden übereinstimmen. Select-Object bietet die Möglichkeit, ein Wildcard-Match durchzuführen und unsere Ergebnisse zu begrenzen. Die | -Zeichen (genannt "the pipe") nimmt die Ergebnisse auf der linken Seite und übergibt sie an Select-Object. Select-Object führt dann den Wildcard-Abgleich durch und begrenzt dann die Ergebnisse basierend auf unseren Wildcard-Kriterien.
Get-ADUser Benutzername -Eigenschaften * | Select-Object *Anmelden*
BadLogonCount : 0
lastLogon : 132181280348543735
LastLogonDate : 11/11/2019 9:08:45 PM
lastLogonTimestamp : 132179981259860013
AnmeldenAnzahl : 328
AnmeldungArbeitsstationen :
MNSLogonAccount : Falsch
SmartcardLogonRequired : False
Die Ergebnisse variieren ein wenig je nach Domänenfunktionsebene des Active Directory. Meine Suche gibt acht Attribute zurück. Drei sehen vielversprechend aus: LastLogon, LastLogonDate und LastLogonTimeStamp. Einige der Werte können etwas seltsam aussehen, wenn Sie nicht wissen, wie Active Directory Datums-/Uhrzeitinformationen in bestimmten Attributen speichert. Einige Datumsinformationen sind herkömmliche Datums-/Uhrzeitinformationen, und andere werden als "Ticks" gespeichert.
PowerShell- und .NET Framework-Datumszeitwerte stellen Datumsangaben als die Anzahl der Ticks seit 12:00 Uhr am 1. Januar 0001 dar. Ticks entsprechen einem Zehnmillionstel einer Sekunde, was bedeutet, dass es 10.000 Ticks pro Millisekunde gibt. Es gibt mathematische Cmdlets, die Ticks in ein Standard-Datumsformat konvertieren können.
PowerShell zeigt den tatsächlichen Tick an, der das Datum/die Uhrzeit darstellt. Wenn Sie mit der Konvertierung von Ticks in das Datumsformat vertraut sind, können Sie diese Felder in Active Directory-Benutzer und -Computer oder Active Directory-Verwaltungszentrum betrachten. In beiden Anwendungen werden die Häkchen als Zeit-/Datumsformat dargestellt.
ADUser-Logon-Eigenschaften
Bei unserer Suche wurden mehrere Eigenschaften gefunden, die Datum/Uhrzeit-Anmeldeinformationen anzeigen. Zwei Eigenschaften haben das gleiche Datum und die gleiche Uhrzeit, eine nicht. Was ist hier los?
Die Abweichung in den Datums-/Uhrzeitinformationen ist beabsichtigt und dient dazu, DCs davor zu schützen, dass sie durch Replikationsdatenverkehr, der versucht, alle Anmeldeinformationen synchron zu halten, zerstört werden. Die LastLogon-Eigenschaft wird jedes Mal aktualisiert, wenn Sie sich authentifizieren, aber die Daten werden auf dem Domänencontroller gespeichert, gegen den Sie sich authentifiziert haben, und nicht auf den anderen Domänencontrollern repliziert. Die Eigenschaften LastLogonTimeStamp und LastLogonDate werden auf alle Domänencontroller repliziert, die Replikation erfolgt jedoch nur selten.
Wenn wir uns die Daten ansehen, können wir sehen, wie sich die verzögerte Replikation auf unsere Abfrage auswirken könnte. Beachten Sie, dass LastLogonTimeStamp in diesem Beispiel tatsächlich zwei Tage zurückliegt. Jedes Mal, wenn sich ein Benutzer interaktiv anmeldet, eine Netzwerkdateifreigabe berührt oder andere Aktivitäten ausführt, für die das Netzwerk die Authentifizierung des Kontos erfordert, werden Anmeldeinformationen in Active Directory gespeichert. Wenn die DCs diese Daten JEDES MAL replizieren würden, wenn jemand etwas im Netzwerk berührt, könnten die DCs in einer großen Umgebung überwältigt werden. Das Ergebnis ist, dass einige Anmeldeinformationen korrekt sind, aber nicht repliziert werden, und einige Anmeldeinformationen replizieren sich, jedoch nur gelegentlich.
Für unsere Anforderungen benötigen wir nicht den EXAKTEN Anmeldezeitstempel. Wir müssen nur Konten finden, die sich seit längerer Zeit (mehr als 90 Tage) nicht mehr angemeldet haben. Jeder Wert kann nützlich sein, auch wenn das Datum um ein paar Tage abweicht. Wenn wir meine Anmeldedaten als Beispiel nehmen, könnte die abgefragte Zeit der 11.11. oder 13.11. sein, je nachdem, welchen Wert wir verwenden. Spulen Sie drei Monate vor und nehmen Sie an, ich hätte mich nie wieder angemeldet. Ein Datum würde als inaktiv markiert werden, weil es mehr als 90 Tage alt ist, und ein Feld würde nicht als inaktiv markiert werden. Wenn ich diesen Prozess jedoch so einrichte, dass er monatlich abläuft, würde ich das Konto bei der nächsten Überprüfung erkennen. Das ist der entscheidende Teil. Wenn wir dies regelmäßig tun, können wir jedes Feld verwenden, solange wir konsequent prüfen.
Ich habe die LastLogonDate-Eigenschaft aus zwei Gründen verwendet. Erstens ist es bereits ein Datumswert, so dass ich mich nicht mit der Konvertierung des Werts befassen muss. Zweitens ist es ein replizierter Wert, und das macht mein Leben einfacher. Wenn ich LastLogon verwenden würde, hätte ich Daten, die für Personen, die sich bei anderen Domänencontrollern in meinem Netzwerk authentifizieren, nicht auf dem neuesten Stand sind. Ich müsste den lokalen DC für jeden Benutzer abfragen, um den neuesten Zeitstempel zu erhalten, und das ist eine Menge Arbeit und nicht sehr effizient.
Um die Informationen zu einem einzelnen Konto zu erhalten, ist der Code einfach.
get-aduser Michael_Kanakos -properties LastLogonDate | Select-Object Name, LastLogonDate
Name LastLogonDate
---- -------------
mkanakos 11.11.2019 21:08:45
Um dies für alle meine Benutzer zu tun, ist nur ein bisschen mehr Code erforderlich. Wir müssen einen Filter verwenden, um alle Benutzerkonten abzufragen.
Get-ADUser -filter * -properties LastLogonDate | Select-Object Name, LastLogonDate
Jetzt finden wir nur die Konten mit einem Anmeldedatum, das älter als 90 Tage ist. Wir benötigen das aktuelle gespeicherte Datum, um es als Vergleichsoperator zu verwenden.
$date = (get-date). AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Select-Object Name, LastLogonDate
Dieser Code ruft alle Benutzer ab, die sich über 90 Tage nicht angemeldet haben. Wir speichern das Datum vor 90 Tagen auf eine Variable. Wir können einen AD-Filter erstellen, um Anmeldungen zu finden, die kleiner als dieses Datum sind. Als Nächstes müssen wir die Anforderung hinzufügen, nur aktive Konten abzufragen. In diesem Beispiel verwende ich Splatting, um den Code lesbarer zu machen, da die Syntax sehr lang ist. Das Splatting von AD-Cmdlets kann schwierig sein, daher habe ich auch die Langversion der Syntax unter dem Splatting-Beispiel gezeigt.
$date = (get-date). AddDays(-90)Select-Object-$SelectProps
$paramhash = @{
Filter = "LastLogonDate -lt $date -und Enabled -eq $true"
Eigenschaften = 'LastLogonDate'
}
$SelectProps = 'Name','LastLogonDate','Enabled','DistinguishedName'
Dies gibt uns unsere inaktiven Benutzer, die aktiviert sind. Wir speichern die Ergebnisse zur Wiederverwendung in einer Variablen. Die DistinguishedName-Eigenschaft wird später benötigt. Sobald wir die Benutzer gefunden haben, können wir an unserem nächsten Schritt arbeiten: dem Deaktivieren der Konten. Wir verwenden das Cmdlet Set-ADUser , um Änderungen am AD-Benutzerkonto vorzunehmen.
$Today = Get-Date
$DisabledUsers = (
$InactiveUsers | Foreach-Objekt {
Set-User $_. DistinguishedName -Enabled $false -Description "Acct deaktiviert auf $Today über Inactive Users Script"}
)
Wir haben unsere Benutzerkonten deaktiviert. Es ist an der Zeit, sie in eine neue Organisationseinheit zu verschieben. In unserem Beispiel verwenden wir die Organisationseinheit mit dem Namen Disabled-Users. Der Distinguished Name für diese Organisationseinheit lautet "OU=Disabled-Users,DC=Contoso,DC=Com" Wir verwenden das Cmdlet Move-ADObject , um Benutzer in die Zielorganisationseinheit zu verschieben.
$DisabledUsers | ForEach-Objekt {
Verschieben-ADObject $_. DistinguishedName -TargetPath "OU=Disabled-Users,DC=Contoso,DC=Com"}
In unserem letzten Schritt haben wir das Move-ADObject verwendet, um Benutzer in eine neue Organisationseinheit zu verschieben. Wir haben jetzt den Kerncode, der benötigt wird, um eine zuverlässige, wiederholbare automatisierte Aufgabe zu erstellen. Was kommt als nächstes? Das hängt von Ihren individuellen Anforderungen ab. Dieser Code kann und sollte so eingerichtet werden, dass er jeden Monat automatisch zur gleichen Zeit ausgeführt wird. Eine einfache Möglichkeit, dies zu tun, besteht darin, einen geplanten Auftrag zu erstellen, um den Code monatlich auszuführen.
Es gibt noch mehr, was wir diesem Code hinzufügen könnten, um ihn zu verbessern. Code für die Fehlerprüfung und zusätzliche Felder für Benutzerinformationen wären zwei nützliche Ergänzungen. Die meisten Teams, die diese Art von Aufgaben ausführen, erstellen einen Bericht darüber, was deaktiviert wurde, so dass die zusätzlichen Felder variieren. Sie könnten weitere Felder aus Active Directory einbeziehen, um einen Bericht nützlicher zu machen. Wir könnten diese Aufgabe noch einen Schritt weiterführen, indem wir eine weitere Aufgabe erstellen, um diese deaktivierten Benutzer nach 6 Monaten zu löschen.
Die Lösung anspruchsvoller Automatisierungsanforderungen ist viel einfacher, wenn die Aufgaben in überschaubare Teile aufgeteilt werden. Wir begannen mit den Anforderungen und bauten unsere Syntax in kleinen Schritten auf; wir bestätigten, dass jeder Schritt funktioniert, bevor wir versuchten, eine weitere Variable hinzuzufügen. Auf diese Weise haben wir diese Aufgabe leicht verständlich gemacht und hoffentlich zu einer großartigen Lernerfahrung.
Lassen Sie sich von unseren Experten beibringen, wie Sie die erstklassigen Funktionen von Sitefinity nutzen können, um überzeugende digitale Erlebnisse zu bieten.
Weitere InformationenAbonnieren Sie, um alle Neuigkeiten, Informationen und Tutorials zu erhalten, die Sie benötigen, um bessere Business-Apps und -Websites zu erstellen