Leap 15.2 Samba AD DC Password Expiration for Windows user, can't change password

Hi everybody,

I apologize if this topic has already been discussed; weeks of searching has turned up nothing.

I have a Leap 15.2 server built out with samba 4.11.14+git.202.344b137b75d, configured as a domain controller (samba-ad-dc), with MIT KRB5 1.16.3-lp152.5.13.1, nothing fancy, everything right from the Leap 15.2 repositories - no add-ons. Basic bare-bones build. The server works well with respect to joining Windows 10 20H2 workstations to it, creating, removing users, managing passwords via Windows Admin tools. I can change user passwords from workstations by executing CTRL+ALT+DEL and filling out the fields; all of that works well.

I am struggling with expired passwords and responding to them from the Windows 10 workstations. It keeps telling me the password has expired, offering only the OK button, which brings me back to the change password dialog. This happens with a brand new user flagged as “much change password” after creation or any existing user I decide to flag as “much change password” to trigger a password reset at next logon. This also occurs for regular users who do not have the “never expires” password attribute set on their user object; once their 45-day window comes due, and they try to logon, the workstation loops through the cycle, password expired, OK - password dialog box.

the smb.conf looks like this:


[global]
     workgroup = WRKGRP
     passdb backend = samba_dsdb
     map to guest = Never
     dns forwarder = <IP ADDRESS>
     netbios name = TEST
     realm = TESTING.LAB
     security = AUTO
     server role = domain controller
     log level = 3 passdb:5 auth:5

[netlogon]
     path = /path/to/scripts
     read only = No

[sysvol]
     path = /var/locks/sysvol
     read only = No

Here’s my krb5.conf


[libdefaults]
     default_realm = TESTING.LAB
     dns_lookup_realm = false
     dns_lookup_kdc = true

[logging]
     kdc = FILE:/var/log/krb5/krb5kdc.log
     admin_server = FILE:/var/log/krb5/kadmind.log
     default = SYSLOG:NOTICE:DAEMON

I can provide logs from Samba and Kerberos if you’d like to see them. Executing kinit from the server on the user tells me the password has expired, and allows me to change it successfully. smbclient tells me the password has also expired, but does not offer me a chance to change it, but that may have been my fault; I was doing that test on the quick, and I should go back and try again with more attention to detail. When running kinit, the “change password” flag was not turned off afterward, not that I expected it to do so, but the more info the better, right?

Yast2-samba-provision-ad-dc was used to set up the server. The smb and krb5 config files were removed prior to running the provision tool. Firewall has been disabled to avoid communications questions. samba-tool shows domain-level is 2008 R2. The resolv.conf i configured as expected.

I’m not familiar with managing AD DC environments, so I can only speculate a bit. I apologize in advance if I’m on the wrong track here. Not a group policy setting enforced on the clients?

Just in case this thread is of relevance…
https://www.tenforums.com/user-accounts-family-safety/150690-cannot-renew-password-expired.html

This may also be of value…
https://wiki.samba.org/index.php/Group_Policy

Thanks for the reply, Deano. Unfortunately, GPO’s don’t come into play here. There is something specific about changing expired passwords from the Windows interface…

For users who change passwords within the time frame that the password is current, there’s no problem. It’s as if the user is being denied access to change the password because the one-time authentication (initial provision of the valid password to AD) has been cleared, and the user is being treated as though a password has never been provided, or the workstation doesn’t have the right to complete the transaction, which I don’t know how that would come into play. I apologize, I’m not terribly familiar with AD Internals; I can only speculate here…

I can’t imagine that this is also a problem in regular AD environments, right? I’ll try to capture some network traces and share here.