none
Probleme mit Fine Grained Passwort Policy RRS feed

  • Frage

  • Guten Morgen,

    wir haben eine Fine Grained Passwort Policy im Einsatz um die Passwortpolicy gesteuert umzusetzen, über Gruppen, satt per GPO.

    In der Default Domain Policy (DDP) ist somit nichts hinterlegt zum Thema Passwort. Soweit so gut, das Problem haben wir mit Client/Usern die von Remote arbeiten.

    In der Passwortpolicy ist momentan als Maximales Alter des Kennwortes 9999 Tage hinterlegt.

    Eine Kollegin arbeitet per VPN Client mit Ihrem Geschäftslaptop von zu Hause. (bei Ihrem User ist im AD das Attribut "Kennwort läuft nie ab" aktiv.) Sie meldet sich alle 4-6 Wochen das ihr User gesperrt ist, und sie aufgefordert wurde das Kennwort zu ändern. (ohne aktive VPN Verbindung)

    Verbindet sie sich dann per VPN stimmen natürlich das AD Kennwort und ihr geändertes nicht mehr überein.

    Ich denke das hier die lokalen Sicherheitseinstellungen greifen (Secpol), der Standardwert hier ist 42. Ich verstehe aber nicht wieso diese überhaupt aktiv werden.

    Nun die Frage: Liege ich mit der Vermutung richtig? Wenn ja, wie kann ich die lokalen Sicherheitseinstellungen ändern, nicht manuell sondern per GPO?
    Ist dies eine Folge da die Passworteinstellungen nicht in der DDP eingestellt sind und daher irgendwann die lokalen Sicherheitseinstellungen aktiv werden, wenn der Client X-Tage nicht mehr in der Domain war/ist.

    Das Problem tritt aktuell bei 4 Mitarbeitern auf, die alle auf diesem Weg arbeiten: Geschäftslaptop zu Hause, per VPN in die Firma.

    Danke und Gruß

    Sven

    Dienstag, 3. Juli 2018 06:22

Alle Antworten

  • Sie meldet sich alle 4-6 Wochen das ihr User gesperrt ist, und sie aufgefordert wurde das Kennwort zu ändern. (ohne aktive VPN Verbindung)

    Was jetzt - gesperrt oder Kennwortänderung? Wortlaut der Meldung(en) und Screenshot wäre hilfreich.

    Verbindet sie sich dann per VPN stimmen natürlich das AD Kennwort und ihr geändertes nicht mehr überein.

    Arbeitet sie mit einem lokalen Benutzer, und Ihr habt nur "zufällig" einen gleichnamigen Domänenbenutzer mit dem gleichen Kennwort?

    Ich denke das hier die lokalen Sicherheitseinstellungen greifen (Secpol), der Standardwert hier ist 42. Ich verstehe aber nicht wieso diese überhaupt aktiv werden.

    secpol greift für lokale User, nicht für Domänenbenutzer.

    Dienstag, 3. Juli 2018 08:32
  • Der User arbeitet mit dem Domänen-User von zu Hause, kein lokaler User. Der PC hat nur einen lokalen Installationsuser.

    Der/die User/in wird aufgefordert das Kennwort zu ändern (obwohl die Einstellung im User "Kennwort läuft nie ab" gesetzt wurde), dabei befindet sich der PC nicht in der Domäne.

    Die Dame ändert das Kennwort, meldet sich an und verbindet sich dann via VPN (Weblogin). Hierbei greift sie auf verschiedenste Ressourcen zu. (Citrix, Netzlaufwerke, etc.)
    Irgendwann ist dann ihr User gesperrt, mitten im arbeiten. Weil natürlich das geänderte Kennwort (ohne Domänen Verbindung) nicht mit dem im AD übereinstimmt.

    Die Passwort-ändern Aufforderung sollte eigentlich gar nicht kommen, verstehe nicht woher.

    Was soll ich hier für Screenshots liefern? Ich glaube das es hier keine weiterführenden Screenshots gibt.(Passwort-ändern Dialog ist der bekannte von Windows, und User gesperrt sehe ich im AD) 

    Dienstag, 24. Juli 2018 07:17
  • Hallo,

    Mal eine Frage zum Verständnis: Wie soll denn eine GPO mit einer Passwort Policy greifen wenn der Rechner nicht in der Domäne ist?

    Auch verstehe ich nicht wie sie mit einem Domänen Benutzer an einem nicht Domänen Rechner arbeiten soll? 

    Die Richtlinien werden ja nur an Domänen Rechner verteilt wenn diese auch eine Verbindung zu einem DC haben.

    Entweder muss das VPN schon beim Rechnerstart greifen damit die Einstellungen übertragen werden oder man muss mit einem lokalen Account arbeiten um sich am Rechner anzumelden. Ein Mischbetrieb zwischen einem lokal gespeicherten Domänen Account und einem aktiven Domänen Account über VPN gibt Probleme.


    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Dienstag, 24. Juli 2018 08:19
  • > Auch verstehe ich nicht wie sie mit einem Domänen Benutzer an einem nicht Domänen Rechner arbeiten soll?

    Der Thread ist mir irgendwie durchgerutscht :-)

    Also noch mal zusammengefaßt, was der TO so schreibt:

    Der PC ist Mitglied der Domäne und hat keine relevanten lokalen User, die Dame arbeitet mit einem Domänenaccount. Sie meldet sich zuhause offline an und stellt dann eine VPN-Verbindung her. Richtig soweit?

    Frage:

    Wann genau kommt die Aufforderung zur Kennwortänderung? Direkt bei der Windows-Anmeldung? Beim Herstellen der VPN-Verbindung? Irgendwann anders? (Bei Anmeldung mit cached credentials ist KEINE Kennwortänderung möglich! Das geht bei Domänenaccounts nur, wenn die Domäne auch erreichbar ist.)
     -- Greetings/Grüße, Martin

    Dienstag, 24. Juli 2018 08:47