When I want to change or set the flags "Password never expires, Account disabled ..." in the user properties/add dialog, this often has no effect. (Derived from bug 4815)
Can I have some more details on this? I can set and unset these flags on my test setup, and at least the account disabled flag seems to do the right thing in terms of denying logon.
- First option "User Must Change Password at Next Logon" seems not work. When I click on "OK", the checkmark is gone. - Second option "User Cannot Change Password" - the same thing
One time I managed also to set the "User Must Change Password at Next Logon" option in ADUC, but now I am unable to reset it (ADUC shows the option unchecked, User Manager checked). Now I am also unable to login with this user (errormessage: account restriction).
Is there any progress on this bug?
This should be a bit similar to 4824. I think the two flags are controlled by the attributes "pwdAllowSet" and "pwdLastSet". I couldn't write there a simple patch, because the appropriate set functions in samldb.c (I think) are missing. The get functions exist.
I can't set the password_last_change value against AD using SAMR, and the pwdAllowSet attribute doesn't exist. I'll need to see how AD and usrmgr interact here, as I think this just isn't expected to work.
This problem seems to persist also with the new "acct_flags" changes in the code done by you Andrew.
The flags - "User Must Change Password at Next Logon" - "User Cannot Change Password" aren't fully working yet.
The two flags "User Must Change Password at Next Logon" and "User Cannot Change Password" don't work in the sense that any check/uncheck operation after a "OK" is definitely lost. I investigated this now a bit through wireshark. The involved RPC calls are LSA "QueryUserInfo" and "SetUserInfo" with the the attribute "acctFlags". Especially, the "User Manager" seems to send back the unchanged attribute. More and more I've the opinion that this is also a "User Manager" bug and not a SAMBA 4 one (can you reproduce it on Windows Server?).
My opinion is that it is a bug in the NT User Manager for Domains itself and so I close it with "INVALID".