10
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?
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?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668320
Url: https://administrator.de/contentid/668320
Ausgedruckt am: 21.11.2024 um 18:11 Uhr
10 Kommentare
Neuester Kommentar
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.
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.
Ich werde es mir generell mit dem Zeitrahmen nochmal überlegen.
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.
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.
2
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.
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.
1
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.
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.
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.
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:
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.
Viele Grüße
eggired
1
Lithnet
Kann man das wie fgpp nur auf Teile der Domain anwenden?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.
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.
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.
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.
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.
1
