none
Kennwortrichtlinie ... RRS feed

  • Frage

  • Hallo zusammen,

    nachdem ich auf einem DC in einer Subdomain eine eigene Password GPO erstellt hatte, diese aber nicht anwendet wurde hatte ich mich hilfesuchend an dieses Forum gewandt (http://social.technet.microsoft.com/Forums/de/gruppenrichtliniende/thread/3220a6a5-a630-45b3-aa3c-3a8355e59167). Mit Hilfe der Beiträge dort und den Artikeln hier (http://www.faq-o-matic.net/2010/06/24/besonderheiten-der-ad-kennwortrichtlinie/) und hier (http://www.gruppenrichtlinien.de/index.html?/HowTo/Kennwortrichtlinien.htm) habe ich mich dann entschieden, keine eigene GPO zu erstellen, sondern die Einstellung für die Password GPO in der Default Domain Policy in der betreffenden Subdomain zu machen.

    Tja, was soll ich sagen ... die Passwordeinstellungen dort werden nicht angewandt. Es sieht so aus, als ob die "standard"-Einstellungen (z. B. Passwortänderung nach 42 Tagen, statt nach den konfigurierten 90 Tagen) angewandt werden.

    Also ... an der DDP haben wir (außer den Passwordeinstellungen) nichts geändert. Diese ist auch auf Domänenebene verlinkt.

    Auch auf dem Client ausgeführten rsop.msc und gpresult /z zeigen an, dass für die Passwortrichtlinie die konfigurierten 90 Tage, max Länge und min Länge usw. angewandt werden ... auch die Kontensperrungsschwelle von 3 ungültigen Versuchen steht dort. Doch auch nach 4, 5 oder mehr Versuchen wird der Useraccount nicht gesperrt ...

    Ich bin über jeden Input, was noch falsch sein könnte dankbar ...

     

    Viele Grüße


    • Bearbeitet LarsB_from_GER Dienstag, 4. Oktober 2011 14:44 zusätzliche Informationen
    Dienstag, 4. Oktober 2011 14:39

Antworten

Alle Antworten

  • Hallo,

    nach dem du per rsop.msc geprüft hast, welche Einstellungen gezogen wird, hast du gebootet?

    Hast du Fehler im Eventlog des Clients bezüglich GPO?

    Bezüglich "Fine-Grained Password Policies" wurde noch nichts an der Domäne verbogen?

    Dienstag, 4. Oktober 2011 15:11
    Beantworter
  • Servus,

    > Doch auch nach 4, 5 oder mehr Versuchen wird der Useraccount nicht gesperrt ...

    der Benutzer soll Mal das Kennwort ändern. Versuche es anschließend erneut.


    Viele Grüße aus Mainz
    Yusuf Dikmenoglu
    Blog: LDAP://Yusufs.Directory.Blog/
    Jetzt anmelden an der: AD Mailingliste
    Dienstag, 4. Oktober 2011 19:16
  • Handelt es sich um einen selbst angelegten Account oder um den Builtin
    Admin? Den kann man nicht sperren...
     
    Wie viele Domain Controller hat die Domäne? Wenn es überschaubar ist:
    Prüf mal die Security Eventlogs, da sollten Einträge zu falschen
    Kennwörtern und Account Lockout auftauchen. Ggf. EventcombMT verwenden.
     
    Und dann solltest Du auch auf den DCs mal ein RSOP erstellen und
    schauen, welche PW-Richtlinien DORT ankommen.
     
    BTW: Sind auf Domänenebene noch weitere GPOs verlinkt?
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV...
    Mittwoch, 5. Oktober 2011 06:54
    Beantworter
  • Hallo,

    nach dem du per rsop.msc geprüft hast, welche Einstellungen gezogen wird, hast du gebootet?

    Hast du Fehler im Eventlog des Clients bezüglich GPO?

    Bezüglich "Fine-Grained Password Policies" wurde noch nichts an der Domäne verbogen?

    Yep, geboot ... nochmal geprüft. Wieder gebootet und versucht durch Falscheingabe des PW den Account zu sperren -> Fehlanzeige. Nein, es wurden auch keine Einstellungen zu "Fine-Grained Password Policies" gemacht.

    > Doch auch nach 4, 5 oder mehr Versuchen wird der Useraccount nicht gesperrt ...

    der Benutzer soll Mal das Kennwort ändern. Versuche es anschließend erneut.

    Auch dies hab ich gemacht ... leider keinen Erfolg ...
    Handelt es sich um einen selbst angelegten Account oder um den Builtin
    Admin? Den kann man nicht sperren...
    Wie viele Domain Controller hat die Domäne? Wenn es überschaubar ist:
    Und dann solltest Du auch auf den DCs mal ein RSOP erstellen und
    schauen, welche PW-Richtlinien DORT ankommen.
    BTW: Sind auf Domänenebene noch weitere GPOs verlinkt?
    Nein, kein Builtin Account. Habe für sowas einen ganz normalen Useraccount in der Domäne, mit dem ich testen kann. In dieser SubDomäne gibt es nur einen DC. Wir betreiben hier einen Forest aber in jeder Subdomäne gibt es nur einen DC (mit Ausnahme einer, die aber hiervon nicht betroffen ist). Was mich etwas wundert ist, dass wir in einer SubDomain eine _eigenständige_ Passwort GPO haben (nicht in der DDP) die problemlos angewandt wird. Dies hatte ich auch in der Subdomain vor, die jetzt Probleme macht. Ich hatte die Passwort GPO exakt so angelegt, wie in der Domain, in der diese funktioniert, aber leider kein Erfolg.
    Mittwoch, 5. Oktober 2011 07:48
  • >Handelt es sich um einen selbst angelegten Account oder um den Builtin
    >Admin? Den kann man nicht sperren...
    Kleine Anmerkung noch, ja stimmt, allerdings wird er zumindest als "locked" angezeigt.

    Wenn also nur in der Anmeldemaske geprüft wird, ob der Account gelockt ist,
    ist dies keine Referenz für eine Einstellung der Kontensperrungsschwelle.
    Mittwoch, 5. Oktober 2011 07:59
    Beantworter
  • >Dies hatte ich auch in der Subdomain vor, die jetzt Probleme macht. Ich hatte die Passwort GPO exakt so angelegt, wie in der Domain, in der diese >funktioniert, aber leider kein Erfolg.

    Welche Domänenfunktionsebene wird denn in Deiner SubDomain ausgeführt?

    Gruß
    Thomas


    Thomas Köck
    Mittwoch, 5. Oktober 2011 19:44
  • Am 04.10.2011 16:39, schrieb LarsB_from_GER:

    Es sieht so aus, als ob die "standard"-Einstellungen (z. B.
    Passwortänderung nach 42 Tagen, statt nach den konfigurierten 90
    Tagen) angewandt werden.

    - welche Einstellungn hat der PDC in seiner lokale Richtlinie?
    - die DDP ist auf Domänen ebene "ganz oben" verlinkt?
    - der Link ist aktiviert?
    - der Computeranteil ist nicht deaktiviert?
    - dene Replikation funktioniert?

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Donnerstag, 6. Oktober 2011 07:33
  • Howdie!
     
    On 06.10.2011 09:33, Mark Heitbrink [MVP] wrote:
    >     Es sieht so aus, als ob die "standard"-Einstellungen (z. B.
    >     Passwortänderung nach 42 Tagen, statt nach den konfigurierten 90
    >     Tagen) angewandt werden.
    >
    > - welche Einstellungn hat der PDC in seiner lokale Richtlinie?
    > - die DDP ist auf Domänen ebene "ganz oben" verlinkt?
    > - der Link ist aktiviert?
    > - der Computeranteil ist nicht deaktiviert?
    > - dene Replikation funktioniert?
     
    plus:
     
    - Auf der "Domain Controllers" OU ist nicht "Block Inheritance" aktiviert?
    - der PDC-E DC ist erreichbar?
     
    Florian
     

    The views and opinions expressed in my postings do NOT necessarily correlate with the ones of my friends, family or my employer. If anyone should be allowed to mark a response as an "answer", it should be the thread creator. No one else.
    Dienstag, 11. Oktober 2011 12:49
  • Sorry für die späte Antwort, aber ich wollte noch auf eine Rückmeldung des eines Mitarbeiters in der entsprechenden Domäne warten, wann das Passwort wieder zu ändern wäre. Tja, heute war es wieder soweit und es wären wieder nur 42 Tage gewesen *heul*

     

    >     Es sieht so aus, als ob die "standard"-Einstellungen (z. B.
    >     Passwortänderung nach 42 Tagen, statt nach den konfigurierten 90
    >     Tagen) angewandt werden.
    >
    > - welche Einstellungn hat der PDC in seiner lokale Richtlinie?
          bin mir jetzt nicht ganz sicher, was Du meinst, aber falls es sich um die Default Domain Controller Policy handelt, diese
          wurde nicht geändert ... also "standard"
    > - die DDP ist auf Domänen ebene "ganz oben" verlinkt?
          yep, hab ich überprüft.
    > - der Link ist aktiviert?
          yep, auch der Fall
    > - der Computeranteil ist nicht deaktiviert?
          nope, Haken bei "Computer Configuration Settings Disabled" ist nicht da
    > - dene Replikation funktioniert?
          yep, auch gut
     
    plus:
     
    > - Auf der "Domain Controllers" OU ist nicht "Block Inheritance" aktiviert?
         doch, ist aktiviert!!!! Welche Auswirkungen hat dies? Und was kann ich damit bewirken, bzw Abschalten??? Bitte um Erleuchtung ;-)
    > - der PDC-E DC ist erreichbar?
          yep, auch geprüft
     
    Florian
    Donnerstag, 3. November 2011 08:16
  • >doch, ist aktiviert!!!! Welche Auswirkungen hat dies? Und was kann ich damit bewirken, bzw

    Sollte allerdings nicht sein.

    Bei DCs gibt es hier einen Sonderfall.

    http://support.microsoft.com/kb/269236/en-us

     


    MVP - Group Policy http://matthiaswolf.blogspot.com/
    Donnerstag, 3. November 2011 09:29
    Beantworter