spsman
Goto Top

GPO Passwortrichtlinie finden

Hi,

wir haben einen WS 2022 als DC. dort sin ca. 15 GPO eingerichtet (meist für Netzlaufwerke entsprechender Gruppen).
Jetzt werden die User alle Nase Lang aufgefordert neue Passörter zu vergeben. Leider ist das nicht ganz konsistent.
Sprich einige müssen all 42 Tage, einige all 3 Monate, Einige 1x pro Jahr, und einige nie...

Jetzt wollte ich da mal ein wenig forschen. Leider sind bei der Immigration von WS2012 scheinbar die Delegierungseinträge verloren gegangen. (Auch wenn Sie noch funktionieren)-> Sprich dort steht nur noch "Autorisierte Benutzer" aber nicht mehr auf welche Gruppen die GPO angewendet werden.

Sprich wir haben eine Sicherheitsgruppe "VPN", durch die die Passwörter min. 8 Zeichen 3 von 4 Komplexitätsmerkmalen haben müssen und 1x im Jahr geändert werden sollen.

Wie kann ich herausfinden welche Bedingungen die Passwortrichtlinie des entsprechend User definieren?

Danke im voraus.

Content-ID: 5159027459

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

Ausgedruckt am: 18.11.2024 um 23:11 Uhr

Nils02
Nils02 22.08.2024 um 11:55:52 Uhr
Goto Top
Hallo,

ich vermute, es steckt die Fine-grained Password Policy dahinter:
https://www.msxfaq.de/windows/sicherheit/finegrained_password_policy.htm

LG
SPSman
SPSman 22.08.2024 um 13:26:33 Uhr
Goto Top
Hi,

leider nein. Zumindest bekomme ich mit
Get-ADFineGrainedPasswordPolicy -Filter "name -like '*'"  
nix zurück.

Ich denke eher es gibt
User die sind schon länger da = Nie Kennwort zurücksetzen
User die VPN nutzen = Kennwort alle 3/12 Monate zurücksetzen
Neue User = 42 Tage
Admins (ich) = 1 Jahre

Die frage ist halt, wie bekomme ich die entsprechende Richtline ausgelesen?
erikro
erikro 22.08.2024 um 13:33:26 Uhr
Goto Top
Moin,

Zitat von @SPSman:
leider nein. Zumindest bekomme ich mit
Get-ADFineGrainedPasswordPolicy -Filter "name -like '*'"  
nix zurück.

Ich denke eher es gibt
User die sind schon länger da = Nie Kennwort zurücksetzen
User die VPN nutzen = Kennwort alle 3/12 Monate zurücksetzen
Neue User = 42 Tage
Admins (ich) = 1 Jahre

Es gibt genau zwei Möglichkeiten:

1. Standard
Die Passwortrichtlinien sind in der Default Domain Policy festgelegt und es gelten die gleichen Richtlinien für alle User.

2. Grained Password Policies
Dann können verschiedene Richtlinien auf verschiedene Organisationseinheiten wirken.

Wenn Du keine Grained Policies findest, dann gilt 1.

Setze ich beim User selbst den Haken "Passwort läuft nie ab", dann werden die Richtlinien außer Kraft gesetzt.

Liebe Grüße

Erik
DerWoWusste
DerWoWusste 22.08.2024 um 13:52:54 Uhr
Goto Top
Führe den Befehl bitte auf allen Domänencontrollern aus, mit großer Sicherheit habt ihr Replikationsprobleme. Ohne Fine grained password policies ist es wie gesagt nicht möglich, unterschiedliche Richtlinien zu haben, zumindest nicht bei Domänenkonten - geht es um lokale Nutzer, wäre das hingegen möglich.
erikro
erikro 22.08.2024 um 13:55:47 Uhr
Goto Top
Zitat von @DerWoWusste:

Führe den Befehl bitte auf allen Domänencontrollern aus, mit großer Sicherheit habt ihr Replikationsprobleme.

Das wäre natürlich eine mögliche Ursache dafür, dass der TO keine grained policies findet.
Nils02
Nils02 22.08.2024 um 14:40:46 Uhr
Goto Top
Hast du mal ein Gpresult /h gemacht und dir den HTML report angeschaut?
Dort solltest du finden, woher das kommt.

Mit der Default Policy kannst du nur eine Richtlinie für alle machen.

Ansonsten ist das Kennwort-Ablaufdatum im Benutzer gesetzt, bzw. Kennwort läuft nicht ab.
SPSman
SPSman 27.08.2024 um 07:56:00 Uhr
Goto Top
Hallo,

ich habe jetzt mal das GP-Result angeschaut:
-> Bei USER 1 (Admin - haken Kennwort läuft nie ab):
admin_result


-> Bei USER 2 (Normalo User Kennwort alle 3 Monate neu):
admin_result


Man Sieht erstmal nichts mit Sicherheitseinstellung wie beim Admin, übrigens trotz das beide in der selben Sicherheitsgruppe sind, die beim Admin die Kennwortrichtlinie definiert.

Wo kommts her \\o//
has_result
SPSman
SPSman 27.08.2024 um 07:56:37 Uhr
Goto Top
Wie habe nur einen DC face-smile
DerWoWusste
DerWoWusste 27.08.2024 um 11:36:20 Uhr
Goto Top
Gibt es ggf. unbekannte Software, die das managet? Dazu würde sich dann meist auf jedem Client ein Agent finden. Diese Software könnte die allgemeine Kennwortrichtlinie für einige überstimmen.

Sicherheitshalber teste bitte auch, ob es in eurem AD wirklich niemals PSOs gab:
Get-ADFineGrainedPasswordPolicy
Mal ohne weitere Argumente ausführen. Kommt da auch nichts?

Sollte es da nichts geben, dann muss das Problem eher in der Wahrnehmung gesucht werden: irgendjemand berichtet nicht korrekt, was passiert.
Nils02
Nils02 27.08.2024 um 12:37:29 Uhr
Goto Top
Richtig.
AD kann das ohne FGPP nicht.
Entweder das, oder eine andere Software ist im Einsatz.
Ein mMn. recht weitverbreitetes Tool ist https://github.com/lithnet/ad-password-protection
SPSman
SPSman 28.08.2024 um 06:42:52 Uhr
Goto Top
Zitat von @DerWoWusste:

Get-ADFineGrainedPasswordPolicy
Mal ohne weitere Argumente ausführen. Kommt da auch nichts?


PS C:\Users\admin> Get-ADFineGrainedPasswordPolicy
Cmdlet Get-ADFineGrainedPasswordPolicy an der Befehlspipelineposition 1
Geben Sie Werte für die folgenden Parameter an:
(Type !? for Help.)
Filter: !?
Ein Filter, beispielsweise "name -like "*"", mit dem das Verzeichnis nach übereinstimmenden differenzierten Kennwortrichtlinienobjekten durchsucht wir
d.
Filter: *

PS C:\Users\admin> Get-ADFineGrainedPasswordPolicy

Somit gehe ich davon aus das das nicht aktiv ist. Andere Software wird nicht eingesetzt, da ich der einzige bin der Software in umlaufbringt.

Was aber noch ein Option wäre ist eine Kennwortrichtlinie zu erstellen um im besten Falle alte einstellung zu überschreiben.(?)
SPSman
SPSman 28.08.2024 um 07:11:14 Uhr
Goto Top
Jetzt wirds richtig Spannend:

$adu = get-ADUser -Filter *  -Properties *

$adu|?{$_.PasswordLastSet -ne ""}|select sAMAccountName, passwordLastSet|Sort-Object passwordLastSet| ft  

führt zu 40benutzer ohne eintrag und:
ad_pw
erikro
erikro 28.08.2024 um 08:57:51 Uhr
Goto Top
Moin,

Zitat von @SPSman:
führt zu 40benutzer ohne eintrag und:

Suche mal so:

get-aduser -filter * -properties PasswordNeverExpires

Mal schauen, wie viele das PW nie ändern müssen.

Liebe Grüße

Erik
DerWoWusste
DerWoWusste 28.08.2024 um 09:02:21 Uhr
Goto Top
Nochmal die Basics: die Richtlinie, die auf den DC wirkt, zählt. Als Nutzer gpresult zu fahren, ist unsinnig, da diese Richtlinie nicht auf Nutzerkonten wirkt. Stattdessen am DC bitte
Gpresult /h %temp%\res.html & %temp%\res.html
auf einem elevated command prompt ausführen, die Kennwortrichtlinie im sich öffnenden HTML aufklappen und ansehen.
SPSman
SPSman 29.08.2024 um 12:45:50 Uhr
Goto Top
Zitat von @erikro:

get-aduser -filter * -properties PasswordNeverExpires

Damit kommt genau das gleich Ergebnis wie oben nur das dort jetzt False/True statt eines Datums steht, sprich 40x nix, 8x True/False...
SPSman
SPSman 29.08.2024 aktualisiert um 12:51:03 Uhr
Goto Top
Zitat von @DerWoWusste:
Gpresult /h %temp%\res.html & %temp%\res.html


screenshot 2024-08-29 124624

Wenn das real wäre würden mir die User aufm Kopp steigen. alle 42 Tage (1,5 Monate) neues Password... :o

Um Komplexität ist definitiv ein Akzeptanz Kriterium.

Wie gesagt das wurde 2018 bei der Einführung von damals noch RRAS VPN noch unter WS2012R2 definiert. (Mittelweile haben wir SSL VPN auf die Firewall).
DerWoWusste
DerWoWusste 29.08.2024 um 13:20:46 Uhr
Goto Top
Wenn das real wäre
Das ist real. Wenn Du Abweichungen hast ("3 Monate" / "1 Jahr"), dann können diese nur auf Finegrained Password Policies (="PSOs") stammen - die gibt es aber nicht bei Dir. Somit ist entweder der DC defekt (setzt um, was er nicht umsetzen soll bzw. was nicht einmal theoretisch ohne PSOs geht), oder deine Nutzer erzählen Dir Märchen, wenn es um die Dauern geht.

Gibt der Befehl "net accounts" am DC den die gleichen Werte aus?
erikro
erikro 29.08.2024 um 13:44:48 Uhr
Goto Top
Zitat von @SPSman:

Zitat von @erikro:

get-aduser -filter * -properties PasswordNeverExpires

Damit kommt genau das gleich Ergebnis wie oben nur das dort jetzt False/True statt eines Datums steht, sprich 40x nix, 8x True/False...

Das ist sehr seltsam, da dieses Attribut eigentlich nie leer sein kann. Langsam habe ich wie @DerWoWusste das Gefühl, dass da was am DC defekt ist.