lithnet/ad-password-protection

Password filter working correctly from AD but not from clients

krokeau opened this issue · 5 comments

Hi,
I've been trying out password filter, and i keep hitting one hurdle : passwords change don't work from windows clients.
Everything works neatly from the AD : password change or refusal gets registered in the event viewer. From windows clients, password change are always refused and don't get registered in the event viewer.
Obviously my config is wrong somewhere, but no matter what change i do and hit gpupdate, it won't work.

I have 2 win 2019 AD servers . I've setup a dfs replication group for the store and i got no issues trying out the password filter on the users from the AD console.
i feel like i've tried everything in the security filter of the gpo.
GPO is linked to the domain controllers as said in the wiki.

What could i be missing out ?
Best regards

Do you have a minimum password age policy in place? By default users can only change their password once every 24 hours. Admins can reset the password without this restriction.

If there are no logs from LPP saying why the password change or set operation was rejected, that means it's the windows password policy, which is always processed first, that is rejecting the password.

No, neither min or max age policy is defined.
But if i change a user password in AD, while checking the "user must change password at next boot", then somehow the policy is applied when the password mod screen appears, as it enforces the password complexity rules. Low complexity passwords will be denied.

But only IDs 4/5 in the event viewer will be logged, the bad tries from computer won't be logged, contrary to the bad tries when setting passwords directly from AD

Just to clarify, there's no client side config. Only the DCs process password changes, therefore LPP only needs to be installed and the policy applied only to the DCs themselves.

There are different policy settings for password "set" (done by an admin without knowing old password) versus password "change" (performed by the user by using their old password). One thing to check is to make sure these are set as expected.

But otherwise if it's working for password set operations, then the filter is installed and configured correctly. There's no other policy or config to set.

LPP must be installed on every DC as well. Any of them could process a password change request from a client.

If your not seeing event logs for rejection from LPP then it must be windows rejecting the password. Or another filter.

If your not seeing event logs for rejection from LPP then it must be windows rejecting the password. Or another filter.

Oh my god finally thank you so much.... All along it was my test workstation. Just asked 3 different domain users to change their password and everything was logged in either DC event viewer.
Going through gpedit in the test workstation i don't find a specific setting that differs from my workstation though...

It's a old win7 install from 2016 that has been upgraded to win 10

stale commented

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.