Working with a S4 installation that was initially provisioned on 12-Jan-2008.
When attempting to log in today, received the "Your password has expired and must be changed." message from Windows. The password change dialog was displayed, but upon attempting the change, Windows displayed the error "The system cannot change your password because the domain SMB4 is not available."
Will attach debug logs.
Created attachment 3146 [details]
Debug output during the initial login attempt
Created attachment 3147 [details]
Debug output while attempting to change password
So, we refuse to give a kerberos ticket, because the password has expired.
I think what we need to do is match Microsoft's KDC error return behavior, so we return the NTSTATUS code, which it will then use internally.
We need to figure out how this works on windows - it might use that error return to try a different password change codepath.
Looking into this a little more, I see "Kerberos: Server's key has expired at -- 2008-02-24T07:18:50" in the debug output from the initial login attempt (first attachment). It seems that this isn't an issue of user password expiration, but expiration of a kerberos principal (a "machine account" if I understand things correctly).
I have looked at the code and see how the pwdLastSet and maxPwdAge attributes are used to set the pw_end in hdb-ldb.c, which ultimately causes the "Server's key has expired..." message.
If I do understand things correctly, and the message was caused by a machine account expiring, I don't think that machine accounts should expire. Windows clients that are domain members by default change their machine account passwords on a regular basis, but that can be disabled. It appears that either S4 doesn't handle machine account password changes, or if it does it is not updating the pwdLastSet attribute when it does. Additionally, it appears that the pwdLastSet attribute for the S4 DC itself hadn't been updated since the provisioning, which would cause it to expire as well.
Yep, I was coming to a very similar conclusion, when I booted my Win2000 instance (which is similarly old).
I'll arrange machine accounts not to expire for the timebeing.
Current GIT should not expire machine accounts any more.
Can you try it out?
Still having problems with current Git.
Manually changed maxPwdAge to 12 hours to test (on my domain that was provisioned over 12 hours prior).
Still get the "Server's key expired..." message during the initial login attempt.
During the password change attempt, instead of:
sam_account_ok: Account for user 'xp-pro$@SMB4.INTERNAL.ID10TS.NET' password expired!.
sam_account_ok: Password expired at 'Sun Feb 24 07:18:50 2008 CST' unix time.
logon_hours_ok: No hours restrictions for user xp-pro$@SMB4.INTERNAL.ID10TS.NET
Kerberos: Client's key has expired at 2008-02-26T11:25:43 -- xp-pro$@SMB4.INTERNAL.ID10TS.NET
Closer with the changes made today, but not quite there.
Manually changed maxPwdAge to 10 minutes.
Machine accounts no longer expire.
User accounts that are not supposed to expire (Administrator by default, and any user created with "Password never expires") do not expire.
However, when trying to login with a user whose password has expired or a user created with "User must change password at next logon" checked, Windows displays the message "Unable to log you on because of an account restriction." There is no opportunity to change/update the password. The login process is simply denied.
The smbd logs indicate:
"sam_account_ok: Account for user 'test_account_2@SMB4.INTERNAL.ID10TS.NET' password expired!."
"sam_account_ok: Account for user 'test_account_3@SMB4.INTERNAL.ID10TS.NET' password must change!."
It appears there was a change in behavior as part of today's change that is passing different flags back to Windows, causing the "account restriction" message.
I have pushed patches to git://git.id10ts.net/samba.git that fix all but one issue related to the logon process.
The patches send the proper responses to allow the client to process user password changes when the user's password has expired or they are forced to change at next logon.
The flags passed back to the client allow the client to determine (at a coarse level) whether a password needs to be changed or an account is locked/otherwise restricted. The only remaining issue is to send the NTSTATUS error code back to the client to allow it to display the appropriate message in the user dialog.
Sorry for missing this in my previous reply.
The patches are in the v4-0-logon branch on git://git.id10ts.net/samba.git.
patches have been applied.
This bug seems to be fixed. Please close it!