mechii
Goto Top

Ü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.

Content-Key: 4880808317

Url: https://administrator.de/contentid/4880808317

Printed on: April 27, 2024 at 12:04 o'clock

Mitglied: 3063370895
3063370895 Dec 07, 2022 updated at 08:23:39 (UTC)
Goto Top
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  
Mitglied: 3063370895
3063370895 Dec 07, 2022 at 08:06:03 (UTC)
Goto Top
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."  
    }
   
}
Member: Cloudrakete
Cloudrakete Dec 07, 2022 at 09:13:54 (UTC)
Goto Top
Für deinen genannten Use-Case würde ich ebenfalls so vorgehen, wie chaot in seinem ersten Kommentar ausgeführt hat.
Member: DerWoWusste
DerWoWusste Dec 07, 2022 updated at 10:46:07 (UTC)
Goto Top
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!
Mitglied: 3063370895
3063370895 Dec 07, 2022 at 11:39:52 (UTC)
Goto Top
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.
Member: DerWoWusste
DerWoWusste Dec 07, 2022 at 12:24:59 (UTC)
Goto Top
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.
Mitglied: 3063370895
3063370895 Dec 07, 2022 updated at 12:35:32 (UTC)
Goto Top
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
Mitglied: 4863114660
4863114660 Dec 07, 2022 updated at 12:44:02 (UTC)
Goto Top
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.
Member: DerWoWusste
DerWoWusste Dec 07, 2022 at 12:51:30 (UTC)
Goto Top
das sollte auf jeden Fall bei richtigem User und PW "true" rauskommen.
Nee, es kommt False raus.
Member: DerWoWusste
DerWoWusste Dec 07, 2022 updated at 13:00:35 (UTC)
Goto Top
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  
Mitglied: 4863114660
4863114660 Dec 07, 2022 updated at 13:05:49 (UTC)
Goto Top
Klappt hier problemlos Server 2016 als auch Server 2022. Werden bei euch LDAPs Negotiate Abfragen geblockt?
Member: DerWoWusste
DerWoWusste Dec 07, 2022 at 13:18:37 (UTC)
Goto Top
Wie gesagt: am DC selbst ausgeführt, da ich die AD-cmdlets hier an den Clients mangels internet nicht zur Verfügung stelle.
Member: mechii
mechii Dec 07, 2022 at 14:42:10 (UTC)
Goto Top
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.
Mitglied: 4863114660
4863114660 Dec 07, 2022 updated at 15:01:10 (UTC)
Goto Top
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 😜.
Member: DerWoWusste
DerWoWusste Dec 07, 2022 updated at 19:25:08 (UTC)
Goto Top
Keiner sagt, dass das Skript nicht geht. Es scheint bloß bei ihm und mir nicht zu klappen, wenn direkt am DC ausgeführt!
Mitglied: 4863114660
4863114660 Dec 07, 2022 updated at 19:30:20 (UTC)
Goto Top
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.
Member: DerWoWusste
DerWoWusste Dec 07, 2022 at 20:56:24 (UTC)
Goto Top
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.
Mitglied: 4863114660
4863114660 Dec 07, 2022 updated at 22:45:42 (UTC)
Goto Top
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.
Mitglied: 3063370895
3063370895 Dec 08, 2022 at 07:00:49 (UTC)
Goto Top
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.
Member: DerWoWusste
DerWoWusste Dec 08, 2022 at 08:25:04 (UTC)
Goto Top
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.
Member: erikro
erikro Dec 08, 2022 at 14:31:24 (UTC)
Goto Top
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. face-wink

Liebe Grüße

Erik
Mitglied: 3063370895
3063370895 Dec 08, 2022 at 15:31:22 (UTC)
Goto Top
Wir machen Zufallspasswort + Passwort muss beim ersten Anmelden geändert werden..