ldm 3.4.8-1

A domain password that must be changed can now be changed at the login screen.

ldm could say a password had expired and nothing else. On a thin client that is the worse half of the message: the client is not a domain member, there is no local tool to change a domain password with, and the session server only repeats the refusal. The user was told to do something the machine gave them no way to do.

Two situations arrive here and the protocol does not tell them apart. One is a password that ran out. The other is an account that never had one of the user's own — an administrator set an initial password and marked it to be replaced at first sign-in, which is pwdLastSet=0 in Active Directory and the REQUIRES_PWCHANGE attribute on an MIT KDC. Measured on the latter: such an account reports Password expiration date: [never] and the KDC still answers KDC_ERR_KEY_EXPIRED. That is why the wording says a password must be changed rather than that it expired — for somebody who has just been handed one, "expired" is not true.

How it works. A KDC still issues a ticket for kadmin/changepw when the password has to be changed. That ticket is good for nothing else, and it is exactly what a login screen needs. ldm asks for the new password twice, sets it with that ticket over the protocol from RFC 3244 — which is what Active Directory speaks — and then signs in with the new password, so the session starts without a second login. The domain clears the expiry or the attribute as part of the change; the next sign-in asks nothing.

The greeter needed no new commands: its protocol already sets a prompt and takes an answer with the entry hidden, so the two extra questions work with every existing theme.

What is deliberately not done here. No rule is enforced on this side. Length, complexity, history and minimum age belong to the domain controller, and when it refuses, its own wording is what the user is shown — it describes the rule that actually applies, which nothing invented here could. Changing needs the controller holding the PDC emulator role, so a site with a second controller can sign in while the first is down but not change passwords; the message says that rather than blaming the password. Failures are told apart for the same reason: a controller that cannot be reached, a password service that does not answer, and a change the domain refused each say their own thing, or whoever reads the message goes looking at the wrong machine.

The new password goes to the KDC and nowhere else. It reaches the session server afterwards as the account's actual password, and both it and the old one are wiped rather than freed.

A KDC that does not answer still stops the login, and that is a decision. The credentials were never checked by anyone, and a session started with them lands in the xrdp dialog this whole check exists to avoid. The message says the authentication server cannot be reached and that the password is not the problem; the krb5 detail goes to the log.

Settings: RDP_PREAUTH_CHANGE_PASSWORD=False turns the offer off. LDM_NEWPASSWORD_PROMPT, LDM_NEWPASSWORD_AGAIN_PROMPT and LDM_NEWPASSWORD_MESSAGE carry a site's own wording. See ldm(1), section PASSWORDS THAT MUST BE CHANGED, and lts.conf(5).

Also in this release: the Kerberos code moved out of the xfreerdp plugin into src/ldmkrb5.c. The plugin had grown to 1383 lines doing three jobs, and the name of the file described the least of them. ldm links -lkrb5 now; the plugin no longer does and resolves ldm_krb5_* from the program that loads it, the way it already resolves ldm_lockout_*.

Tested against a local MIT KDC across ten scenarios: correct and wrong passwords, an expired password changed and used, mismatched entries, a cancelled change, the offer switched off, a policy rejection showing the server's own words, an unreachable KDC, a realm that is not configured, and a password service that does not answer. Not yet exercised against a real Active Directory.