it-doom
Goto Top

Fine Grained Password Policy funktioniert nicht richtig

Hallo zusammen,

um sicherzustellen, dass unsere User sichere Passwörter in unserer Windows Domäne (WS2019) verwenden, habe ich mich dazu entschieden, eine Fine Grained Password Policy zu erstellen. Leider ist die Umsetzung ziemlich in die Hose gegangen.

Die FGPP habe ich nur auf eine Sicherheitsgruppe angewendet, in der alle User drin sind.

Folgende Dinge sind nach der Aktivierung der Policy passiert, die ich mir nicht erklären kann:

1. Bei manchen Usern erschien sofort eine Aufforderung, das Passwort zu ändern. Meines Wissens nach sollte die FGPP nicht triggern, sondern erst wenn man den Haken beim User im AD setzt? Die Passwortänderung war dann aber einwandfrei möglich.
2. Manche User konnten ihr Passwort nicht ändern, egal wie lang oder komplex das Passwort war, das sie eingegeben haben. Ich musste dann manuell über das AD nachhelfen.
3. Ein User wurde scheinbar grundlos deaktiviert und musste manuell wieder aktiviert werden. Ich habe in der FGPP einen Lockout konfiguriert, der aber erst nach 5 aufeinanderfolgenden fehlgeschlagenen Anmeldungen, und nicht einfach so passiert.

Hat hierbei jemand ähnliche Erfahrungen gemacht und hat Ideen, weshalb dieses Verhalten Zustande kommt?
screenshot 2024-09-23 154615

Content-ID: 668320

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

Printed on: November 6, 2024 at 11:11 o'clock

pcpanik
Solution pcpanik Sep 23, 2024 updated at 14:26:37 (UTC)
Goto Top
Zitat von @IT-DOOM:
1. Bei manchen Usern erschien sofort eine Aufforderung, das Passwort zu ändern.

Ggf. hat es zum einen bereits mit dem Passwortalter zu tun. Du hast 120 Tage konfiguriert. Wurden eure User vorher schon mit Zeitrahmen dazu gegängelt die Passwörter zu ändern?

An der Stelle möchte ich dazu übrigens abraten, die User damit zu nerven.
Diese Strategie ohne ersichtlichen Grund alle paar Monate das Windows Passwört zu ändern ist auch für das BSI inzw. überholt.
Ein einmal sicheres Passwort ist besser, als eines, an das der User #1,2,3,4, etc anhängt, weil er es ändern muss.> Bei manchen Usern erschien sofort eine Aufforderung, das Passwort zu ändern.
IT-DOOM
IT-DOOM Sep 23, 2024 at 14:25:20 (UTC)
Goto Top
Wahrscheinlich wird es mit dem Zeitrahmen zu tun haben, es gab vorher so eine Richtlinie nicht. Allerdings weiß ich auch von einem User, der sein Passwort erst kürzlich selbst geändert hat und dennoch nach der Aktivierung der FGPP aufgefordert wurde, das PW zu ändern. Er war dann übrigens auch von dem Problem betroffen, dass er das Passwort nicht ändern konnte, egal wie komplex es war...
Ich werde es mir generell mit dem Zeitrahmen nochmal überlegen.
DerWoWusste
Solution DerWoWusste Sep 23, 2024 at 14:28:12 (UTC)
Goto Top
1 normal, wenn Kennwort älter als 120d
2 normal, wenn Nutzer sich ständig vertippen
3 normal, wenn das alte Kennwort irgendwo eingespeichert ist, und Prozesse sich dort bedienen. Da wird auch gerne mehr als 5x probiert.

Noch zwei Anmerkungen:
Die klassische Kennwortpolicy kann das Selbe und wirkt zudem noch auf lokale Konten der Rechner. Eine Fine grained... zu erstellen ergibt nur dann Sinn, wenn es mehrere davon geben soll.

Und du solltest dir das freie Produkt von Lithnet einmal ansehen, was wirklich viel mehr kann als die eingebaute FGPP.
kpunkt
kpunkt Sep 23, 2024 at 14:31:32 (UTC)
Goto Top
Naja, wenn das Passwort jünger als 10 Tage ist, kann es auch nicht geändert werden. Standard ist bei Windows IMHO 24 Stunden. Die Aufforderung zum Ändern hat mit der Möglichkeit das Passwort zu ändern nix zu tun.

Du kannst das generell schon machen. Aber ich würde da vorher alle User das Passwort an einem Zeitpunkt ändern lassen. Und tatsächlich vorher mindestens einen Tag lang, das Ändern verbieten.

Generell halte ich Passwörter nach gewissen Zeiten ändern zu müssen für Grütze. Oftmals muss man es aber so machen, weil es z.B. eine Aufsichtsbehörde noch vorschreibt.
IT-DOOM
IT-DOOM Sep 23, 2024 at 14:40:58 (UTC)
Goto Top
Hi, deine Erklärungen für Punkt 1 und 3 klingen sehr schlüssig, danke erstmal dafür.
Zu Punkt 2: Bei ca. 15 Mitarbeitern und dann fünf Mal dem selben Problem finde ich es dann doch sehr unwahrscheinlich, dass sich alle die ganze Zeit vertippt hätten. Vor allem, wenn einer von denen ITler ist 😅
Mir kam das eher wie ein Windows-Bug vor.
eggired
Solution eggired Sep 24, 2024 at 04:35:01 (UTC)
Goto Top
Zitat von @IT-DOOM:

Zu Punkt 2: Bei ca. 15 Mitarbeitern und dann fünf Mal dem selben Problem finde ich es dann doch sehr unwahrscheinlich, dass sich alle die ganze Zeit vertippt hätten. Vor allem, wenn einer von denen ITler ist 😅
Mir kam das eher wie ein Windows-Bug vor.

Das kann schnell gehen:
WLAN mit RADIUS-Authenifizierung über die Windows-Credentials -> Altes Passwort ist noch in den gespeicherte. Netzwerkverbindungen -> Client versucht sich zu authentifizieren – gesperrt

Outlook versucht sich zu authentifizieren nach dem Start – gesperrt, wenn das alte Passwort noch in der Anmeldeinformationsverwaltubg hinterlegt ist (oder Vertipper eines geänderten Passworts gespeichert wurde)

Diensthandy versucht Mails abzurufen, alte Credentials sind hinterlegt – gesperrt

Das waren so „Klassiker“, die wir seinerzeit so hatten, als wir Kennwort-mäßig „die Zügel angezogen“ haben.

Grundsätzlich hilft im Troubleshooting weiter:

  • auf dem DC im Ereignis Protokoll prüfen:
Was steht für ein Rechnername bei den Events mit der ID 4740?
Hier taucht z. B. der Mailserver oder der Client auf.

  • Im Fall vom Client: Das Firmen-WLAN aus den gespeicherten Netzwerken entfernen und anschließend mit dem policy-konformen Passwort neu verbinden

  • Auf dem Client in der Anmeldeinformationsverwaltung nach gespeicherten Windows-Anmeldedaten gucken, eventuelle Alt-Einträge entfernen

Das hat dann immer gut geholfen. face-smile

Viele Grüße
eggired
Dirmhirn
Dirmhirn Sep 24, 2024 at 06:07:19 (UTC)
Goto Top
Lithnet
Kann man das wie fgpp nur auf Teile der Domain anwenden?
DerWoWusste
DerWoWusste Sep 24, 2024 updated at 07:39:44 (UTC)
Goto Top
Kann man das wie fgpp nur auf Teile der Domain anwenden?
Nein. Bislang noch nicht. Ich habe es hier genannt, da es sein Anwendungsfall zu sein scheint, eine Policy für alle zu haben. Lithnet's FAQ sagt dazu klar, dass es aber geplant ist:
Can I apply the password filtering to only a specified group of users?
Unfortunately not. The password filter applies to all users in the domain. A future version of Lithnet Password Protection is planned which will implement fine-grained password policies.

Da aber die eingebauten Policies (klassisch und FGPP) weiterhin wirken, könnte man FGPP zusätzlich nutzen, um weitere Restriktionen auf schützenswertere Konten aufzuerlegen - sprich: eine Bereicherung sollte es in jedem Fall sein.
Dirmhirn
Dirmhirn Sep 24, 2024 at 08:44:36 (UTC)
Goto Top
Da aber die eingebauten Policies (klassisch und FGPP) weiterhin wirken, könnte man FGPP zusätzlich nutzen, um weitere Restriktionen auf schützenswertere Konten aufzuerlegen

Danke, das werde ich mal vorschlagen.
WoenK0
WoenK0 Sep 24, 2024 at 17:08:11 (UTC)
Goto Top
Zitat von @IT-DOOM:

Hi, deine Erklärungen für Punkt 1 und 3 klingen sehr schlüssig, danke erstmal dafür.
Zu Punkt 2: Bei ca. 15 Mitarbeitern und dann fünf Mal dem selben Problem finde ich es dann doch sehr unwahrscheinlich, dass sich alle die ganze Zeit vertippt hätten. Vor allem, wenn einer von denen ITler ist 😅
Mir kam das eher wie ein Windows-Bug vor.

Caps Lock ?
Kann sein das man das bei den Usern als zweites erfrägt, aber bei sich selbst nicht ?
Und der Windows Bug kann dann auch ein falsches Keyboard Layout sein...weiss gar nicht wie oft mir so etwas passiert ist, vor allem über Konsolen...

Hab noch keinen Windows Bug gesehen, der die Passwort Eingabe stört.

Gerade wenn jemand ITler ist sollte man schauen ob er aus Überheblichkeit genau die Userfehler begeht über die er sich beschwert.