07.12.2022

4269

Überprüfung von Benutzer Anmeldedaten in AD via Script

Gibt es eine Möglichkeit z.B. via

Test-ADCredentials -Username <Username> -Password "Kennwort" -Domain "<Fqdn>"

in der Powershell zu testen, ob sich ein Benutzer mit dem Kennwort "Beispiel123" anmelden lässt?

Hintergrund:
Wir haben das AD komplett neu aufgebaut, jeder Benutzer hat zur Erstanmeldung das Kennwort "Beispiel123" bekommen.
Aus bestimmten Gründen konnten wir nicht die Option setzen "Kennwort muss bei der ersten Anmeldung geändert werden"
Nun möchte ich via Script überprüfen, ob alle User ihr Kennwort geändert haben, oder einige noch das default Kennwort nutzen. Einzeln für jeden Benutzer ist das kein Thema, würde dies aber gerne für alle Mitglieder in der Domäne in einem Rutsch vis Script prüfen.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 4880808317

Url: https://administrator.de/forum/ueberpruefung-von-benutzer-anmeldedaten-in-ad-via-script-4880808317.html

Ausgedruckt am: 22.12.2024 um 01:12 Uhr

22 Kommentare

Neuester Kommentar

Prüfe doch wann das Passwort zuletzt geändert wurde mit

Get-ADUser username -Properties PasswordLastSet | Select-Object samaccountname,PasswordLastSet

Wenn ihr den Reset z.b. am 22.11.2022 um 07:00 morgens gemacht habt, zeigt dieser Befehl alle Nutzer an deren Passwort nicht nach 08:00 22.11.2022 geändert wurde:

 Get-AdUser -Filter{PasswordLastSet -lt "22.11.2022 08:00"} -Properties PasswordLastSet | Select-Object SamAccountName,PasswordLastSet  

Wenn du jedoch darauf bestehst es durchzutesten sollte es so funktionieren:

$usernames = (Get-ADUser -Filter * ).SamAccountName
$password = "Beispiel123"  

foreach ($username in $usernames) {

    if((New-Object DirectoryServices.DirectoryEntry "",$username,$password).psbase.name -ne $null){  
        Write-Host "$username hat sein Passwort nicht geändert."  
    }
   
}

Für deinen genannten Use-Case würde ich ebenfalls so vorgehen, wie chaot in seinem ersten Kommentar ausgeführt hat.

Moin.

Erster Gedanke ist leider: "was für ein Himmelfahrtskommando!"
Wer tut so etwas? Das AD von Minute eins der Kompromittierung hingeben.

Kennwörter nie bei allen auf den gleichen Wert setzen, zu keinem Zeitpunkt!

Du kannst, falls Du bei der Umsetzung des Powershellscriptes nicht klarkommst, auch mit net use arbeiten für deinen Test, wenn Du dir zuvor eine Userliste erzeugst:

for /f %a in (userlist.txt) do net use \\dc\sysvol /user:deinedom\%a Beispiel1234 && md \\server\share\poesePurchen\%a

Edit2: bei mir läuft das zweite Skript von @chaot1coz übrigens nicht (nennt mir den Testnutzer nicht, welcher sein PW nicht geändert hat). Und bei dem ersten Skript hätte ich Bedenken, da ja pwlastset und pwlastsettimestamp unterschiedlich sein können!

Edit2: bei mir läuft das zweite Skript von @chaot1coz übrigens nicht (nennt mir den Testnutzer nicht, welcher sein PW nicht geändert hat)

Das (ungeänderte) Skript prüft mit jedem AD-Nutzer, ob er sich mit dem Passwort "Beispiel123" anmelden kann, nicht ob / wann jemand sein Passwort geändert hat. Funktioniert in meinen Tests (Passwort eines Testnutzers auf Beispiel123 gesetzt) zu 100%

Und bei dem ersten Skript hätte ich Bedenken, da ja pwlastset und pwlastsettimestamp unterschiedlich sein können!

Erläutere bitte. In meinen Tests ist PasswordLastSet akkurat.

Funktioniert in meinen Tests (Passwort eines Testnutzers auf Beispiel123 gesetzt) zu 100%

Hier eben nicht. Keine Ahnung, warum. Selbst wenn ich das Skript manuell durchgehe, ist für diesen Nutzer
(New-Object DirectoryServices.DirectoryEntry "",$username,$password).psbase.name
leer.

Bei pwlastset habe ich mich vertan, sorry - ich habe das verwechselt mit lastlogon und lastlogontimestamp, zweit Attribute, von denen letzteres nur alle 14 Tage repliziert wird und somit oft in simplen Skripten falsche Ergebnisse liefert.

Zitat von @DerWoWusste:

Funktioniert in meinen Tests (Passwort eines Testnutzers auf Beispiel123 gesetzt) zu 100%

Hier eben nicht. Keine Ahnung, warum. Selbst wenn ich das Skript manuell durchgehe, ist für diesen Nutzer
(New-Object DirectoryServices.DirectoryEntry "",$username,$password).psbase.name
leer.

Was kommt raus wenn du diese Zeile ausführst:

(New-Object DirectoryServices.DirectoryEntry "","BekannterUserName","PasswortImKlartext").psbase.name -ne $null  

das sollte auf jeden Fall bei richtigem User und PW "true" rauskommen.

BEi falschem PW, deaktiviertem oder gesperrtem User kommt "false" raus

Moin.
Es gibt als Alternative auch noch eine explizite .NET Methode die rein das Validieren der Credentials macht.

$usernames = (Get-ADUser -Filter * ).SamAccountName
$password = 'Beispiel123'  
Add-Type -A System.DirectoryServices.AccountManagement
$ds = New-Object System.DirectoryServices.AccountManagement.PrincipalContext(1)
foreach ($username in $usernames) {
    if($ds.ValidateCredentials($username, $password,'Negotiate,Signing,Sealing')){  
        Write-Host "$username hat sein Passwort nicht geändert."  
    }
}

https://learn.microsoft.com/de-de/dotnet/api/system.directoryservices.ac ...

Gruß S.

das sollte auf jeden Fall bei richtigem User und PW "true" rauskommen.

Nee, es kommt False raus.

Auch bei @4863114660 's Skript wird der Nutzername hier nicht angezeigt.
Was ist wohl bei unseren ADs unterschiedlich? Hier 2016 Server 1607. Skript auf dem Dc ausgeführt.

Ich würde somit weiterhin dazu raten, es simpel zu halten mit dem obigen net use gegen eine Liste zu arbeiten.
Liste erstellen (Für TestOU):

(get-aduser -filter * -searchbase "OU=Test,DC=deinedom,DC=de").samaccountname | out-file d\temp\userlist.txt -Encoding ascii  

Klappt hier problemlos Server 2016 als auch Server 2022. Werden bei euch LDAPs Negotiate Abfragen geblockt?

Wie gesagt: am DC selbst ausgeführt, da ich die AD-cmdlets hier an den Clients mangels internet nicht zur Verfügung stelle.

Erstmal vielen Dank für die vielen Antworten.
Sowohl bei chaot1coz`s als auch bei schlepper`s script nimmt er das Script zwar an, aber nach ca. 1 Sekunde springt er in eine neue Zeile ohne jeglichen output.

Server 2019 Build1809 direkt am DC ausgeführt.

Zitat von @mechii:

Erstmal vielen Dank für die vielen Antworten.
Sowohl bei chaot1coz`s als auch bei schlepper`s script nimmt er das Script zwar an, aber nach ca. 1 Sekunde springt er in eine neue Zeile ohne jeglichen output.

Ist normal wenn es keine User mit dem Passwort mehr gibt, dann gibt's auch keinen Output 🙂.

Klappt hier in allen 5 Domains die mir ich hier im Zugriff habe problemlos!

Wozu sonst gibt es wohl die verlinkte .NET Methode, zum Spaß bestimmt nicht 😜.

Keiner sagt, dass das Skript nicht geht. Es scheint bloß bei ihm und mir nicht zu klappen, wenn direkt am DC ausgeführt!

Zitat von @DerWoWusste:

Keiner sagt, dass das Skript nicht geht. Es scheint bloß bei ihm und mir nicht zu klappen, wenn direkt am DC ausgeführt!

Hier auch ein DC, daran kann es auch nicht liegen.
Du kannst ja mal die Bedingungs Zeile aus der If Abfrage raus nehmen und mal so ausführen, was dann bei dir kommt.

Du kannst ja mal die Bedingungs Zeile aus der If Abfrage raus nehmen und mal so ausführen, was dann bei dir kommt.

False kommt da.
Und du führe es mal direkt am DC aus.

Zitat von @DerWoWusste:
Und du führe es mal direkt am DC aus.

Hab ich ja, läuft hier wie gesagt einwandfrei in allen 5 Domains auf den DCs direkt ausgeführt, macht aber keinen Unterschied, klappt genauso auch von einer WS.

Zitat von @DerWoWusste:

Du kannst ja mal die Bedingungs Zeile aus der If Abfrage raus nehmen und mal so ausführen, was dann bei dir kommt.

False kommt da.
Und du führe es mal direkt am DC aus.

Bei mir klappts auch auf den DCs.

Was kommt denn, wenn du nur das ausführst:

New-Object DirectoryServices.DirectoryEntry "","username","passwort"  

username/passwort ersetzen.
Dann sollte er zumindest eine aussagekräftige Fehlermeldung ausspucken.

Ah...
Es lag daran, dass mein Testkonto anmeldebeschränkt war.
Während ich mein Skript ja bei mir laufen lassen konnte (wo ich dem Testnutzer Anmelderechte gegeben hatte), hatte er diese nicht auf dem DC. Daran lag es.

Moin,

als Denkanstoß.

Ich habe das "Problem" in meiner alten Firma so gelöst: Die neuen User haben ein vierzehn Zeichen langes zufällig erzeugtes individuelles Passwort bekommen (sowas z. B.: QG3x(&:,P2g:_§). Nach dem Ausdruck wurde die Information vernichtet. Das ändern die User ganz schnell freiwillig. Und wenn nicht, war mir das auch egal.