[Samba] Samba AD DC: users cannot change expired passwords

Fri Oct 27 08:44:51 UTC 2023

Hi Andrew,

Op 27-10-2023 om 02:22 schreef Andrew Bartlett:
> I'm sorry to say that from here you really need to work closely with a 
> Samba developer (eg via a commercial support provider) or do a deep 
> dive into debugging yourself.
>
> Ideally if you have time, do a git bisect between the last known 
> working version and the first failing one.  That may find the 
> problematic commit, which will make a fix and adding a regression test 
> much faster.
If the statement (below) is that it should not work, then I don't see 
why it is worth an investigation. Can you clarify that?
>
> I would note that we should never allow access over LDAP as a user who 
> has an expired password, even with the intention to change the 
> password.  Some other protocols (like kpasswd) should allow access 
> only to the password change service, and password changes over SAMR 
> can be done as one user (eg a service user) to change the password of 
> another.
I am not sure that it does not work on MS-AD  because the 
self-service-password application has some options for this:

# Active Directory mode
# true: use unicodePwd as password field
# false: LDAPv3 standard behavior
$ad_mode = true;
# Force account unlock when password is changed
$ad_options['force_unlock'] = true;
# Force user change password at next login
$ad_options['force_pwd_change'] = false;
# Allow user with expired password to change password
$ad_options['change_expired_password'] = true;

Why would there be an option 'change_expired_password' when this is not 
a supported feature in AD?

Since I have no MS-AD so cannot check it.

- Kees.

>
> Andrew Bartlett
>
> On Thu, 2023-10-26 at 21:31 +0200, Kees van Vloten via samba wrote:
>> Hi Tobias and Rowland,
>> Is there any progress on topic?
>> Not here at least, I am still unable to change expired passwords, at
>> least  over LDAP, whereas that worked fine before 4.18.6.  In the
>> meantime I moved to 4.19.2 (and to Bookworm) but nothing changed.
>> I have enabled LDAP password change in enabled dsheuristics (value:
>> 000000001) in order to accommodate the self-service-password webui (from
>> ltb-project.org), which is a handy tool for users without desktop access
>> to change their password when it is that time again.
>> As such the tool still works fine, except that it is no longer possible
>> to change expired passwords. I looked back in git history if something
>> changed on the configuration of self-service-password but recently there
>> were no changes (last was in Feb. 22).
>> The audit_auth.log on the DC just shows an expired message and that's it:
>> {"timestamp": "2023-10-26T20:21:10.245303+0200", "type":
>> "Authentication", "Authentication": {"version": {"major": 1, "minor":
>> 3}, "eventId": 4625, "logonId": "0", "logonType": 8, "status":
>> "NT_STATUS_PASSWORD_EXPIRED", "localAddress": "ipv4:192.168.1.13:389",
>> "remoteAddress": "ipv4:192.168.1.17:36386", "serviceDescription":
>> "LDAP", "authDescription": "simple bind/TLS", "clientDomain": "SAMDOM",
>> "clientAccount": "CN=test 1 user,OU=User Accounts,DC=samdom,DC=com",
>> "workstation": "DC1", "becameAccount": null, "becameDomain": null,
>> "becameSid": null, "mappedAccount": "test1", "mappedDomain": "SAMDOM",
>> "netlogonComputer": null, "netlogonTrustAccount": null,
>> "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0,
>> "netlogonTrustAccountSid": null, "passwordType": "Plaintext",
>> "clientPolicyAccessCheck": null, "serverPolicyAccessCheck": null,
>> "duration": 5351}}
>> log.samba has as litte info (at loglevel 3):
>> [2023/10/26 20:21:10.240175,  3]
>> ../../source4/auth/ntlm/auth.c:206(auth_check_password_send)
>>     auth_check_password_send: Checking password for unmapped user
>> [SAMDOM]\[test1]@[DC1]
>>     auth_check_password_send: user is: [SAMDOM]\[test1]@[DC1]
>> [2023/10/26 20:21:10.245239,  2]
>> ../../source4/auth/sam.c:259(authsam_account_ok)
>>     sam_account_ok: Account for user 'test1' password expired!.
>> [2023/10/26 20:21:10.245253,  2]
>> ../../source4/auth/sam.c:261(authsam_account_ok)
>>     sam_account_ok: Password expired at 'Mon Aug 14 11:54:53 2023 CEST'
>> unix time.
>> [2023/10/26 20:21:10.245274,  2]
>> ../../source4/auth/ntlm/auth.c:399(auth_check_password_recv)
>>     auth_check_password_recv: sam authentication for user [SAMDOM\test1]
>> FAILED with error NT_STATUS_PASSWORD_EXPIRED, authoritative=1
>> [2023/10/26 20:21:10.245284,  2]
>> ../../auth/auth_log.c:858(log_authentication_event_human_readable)
>>     Auth: [LDAP,simple bind/TLS] user [SAMDOM]\[CN=test 1 user,OU=User
>> Accounts,DC=samdom,DC=com] at [Thu, 26 Oct 2023 20:21:10.245280 CEST]
>> with [Plaintext] status [NT_STATUS_PASSWORD_EXPIRED] workstation [DC1]
>> remote host [ipv4:192.168.1.17:36386] mapped to [SAMDOM]\[test1]. local
>> host [ipv4:192.168.1.13:389]
>> - Kees.
>> Op 26-09-2023 om 09:05 schreef Pluess, Tobias via samba:
>>> Hi Rowland
>>> I went to my DC and set the samba log level to 10.
>>> Then I rebooted the DC.
>>> Afterwards, I went to the windows 10 machine and first logged in as a
>>> "normal" user that has no expired password. That worked of course well.
>>> Then I logged out and tried to log in as a new user, that has never logged
>>> in before, and whose account was configured as "user needs to change the
>>> password on first login". Then I was stuck in the "password expired" loop
>>> as described before.
>>> I uploaded the log.samba file to my Nextcloud
>>> https://hb9fsx.ch/nextcloud/s/bW8zx52TaTsJ44j
>>> <https://hb9fsx.ch/nextcloud/s/bW8zx52TaTsJ44j>
>>> as it is quite large. I marked the positions in the log where i logged in
>>> as "######## existing user login #######" and "######## new user with
>>> expired password login #######" so they can be found easily.
>>> But I believe the log is, unfortunately, not very helpful, as I cannot see
>>> any messages about the expired passwords, I cannot even find the user names
>>> of users who logged in, so therefore this log file is probably either not
>>> the right one or it will be difficult to impossible to learn something
>>> about this problem from that log. Nevertheless I wanted to share it  with
>>> you as you still may find something in there, hopefully.
>>> Let me know if I can help with providing further log files or doing other
>>> experiments.
>>> Thanks,
>>> best
>>> Tobias
>>> On Mon, Sep 25, 2023 at 5:16 PM Rowland Penny via samba <
>>> samba at lists.samba.org
>>> <mailto:samba at lists.samba.org>
>>> > wrote:
>>>> On Mon, 25 Sep 2023 16:47:57 +0200
>>>> "Pluess, Tobias via samba" <
>>>> samba at lists.samba.org
>>>> <mailto:samba at lists.samba.org>
>>>> > wrote:
>>>>> Hi Rowland,
>>>>> yes I also got this message that was from Kees but signed by me. I
>>>>> did not send it. But I did send the very first message, though.
>>>> It confused me no end, can I suggest that if anyone replies to a samba
>>>> mailing list post, they just reply to the list, do not 'CC' anyone else
>>>> and do not reply to anyone else. That way, anyone who is subscribed to
>>>> the list will get the reply.
>>>>> I just checked the logs on the DC. There is nothing relevant in
>>>>> there. I cannot see any errors whatsoever.
>>>>> The strange thing is:
>>>>> When the password is expired, the user can, on the Windows 10 login
>>>>> page, literally enter ANY password, and gets the message "your
>>>>> password is expired" and when the user tries to change his password,
>>>>> no matter if the correct or a random password is entered as the old
>>>>> password, the message "password expired" appears again and the login
>>>>> is stuck in this forever loop unless "cancel" is clicked, which, of
>>>>> course, cancels the login.
>>>> I think that the password may or may not be changing, but either way,
>>>> the other relevant attributes do not seem to be being reset. Note,
>>>> this all guess work.
>>>>> So I checked every log file under /var/log/samba on my DCs (I have
>>>>> two off them, dc0 and dc1, which are rsync'ed).
>>>>> Let me know which config I shall change to increase the loglevel and
>>>>> I will do that and post the logs here.
>>>> Raising the loglevel on any Samba machine is fairly easy, you just add
>>>> the very aptly named parameter 'log level' to the global part of the
>>>> smb.conf , this should also point to a number, the higher the number,
>>>> the bigger the log. For instance, add 'log level = 3' will make Samba
>>>> log at level 3, you could try raising this number until something
>>>> possibly 'pops' out, The maximum level I would go to would be 10, but
>>>> beware, the logs at that level will be very large. You will also need
>>>> to restart your DC after adding the parameter or changing the log level.
>>>> Rowland
>>>> --
>>>> To unsubscribe from this list go to the following URL and read the
>>>> instructions:
>>>> https://lists.samba.org/mailman/options/samba
>>>> <https://lists.samba.org/mailman/options/samba>
> -- 
> Andrew Bartlett (he/him) https://samba.org/~abartlet/
> Samba Team Member (since 2001) https://samba.org
> Samba Team Lead https://catalyst.net.nz/services/samba
> Catalyst.Net Ltd
>
> Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group 
> company
>
> Samba Development and Support: https://catalyst.net.nz/services/samba
>
> Catalyst IT - Expert Open Source Solutions
>
>