Bug#1109448: unblock: samba/2:4.22.3+dfsg-4
22.07.2025 13:17, Ivo De Decker wrote:
Control: tags -1 moreinfo
Hi,
On Fri, Jul 18, 2025 at 11:05:54AM +0300, Michael Tokarev wrote:
[ Reason ]
There are several changes in this debian release,
a few minor packaging fixes, a bugfix from upstream for
#1109005, and a long-forgotten fix for another issue,
which I wasn't aware of until very recently (when it
hit our setup), - #907318.
While I've no single doubt about the other changes, -
these should go in for trixie, I'm a bit uncertain about
the #907318 fix - it changes pam config for winbind (for
domain logons) to - finally - include pam-winbind in the
account section. While it works fine in our setup (where
accounting was missing for years), and while exactly the
same setup is done in sssd package (an alternative login
mechanism for active directory users), there might be some
yet unknown surprize still, which is not a good thing to
have this late in the release cycle.
Yet I think this change is worth the effort to have in
trixie (finally!).
We are very late in the cycle, and this bug has been around for a long time.
Given the risk that this might break user logins, I would prever if this
change was reverted and kept for forky.
It doesn't actually break logins, it finally makes logins to
work the way they were intended to work.
What the account function in pam_winbind does is to verify
if the user password has been expired or the user has to
change their password at first login. This is what has been
broken here for us: I reset user password in the Active
Directory to a simple one, and added a flag for the user for
it to change the password at first login. They logged in,
but weren't prompted for a new password, and, being lazy,
ended up with that simple password.. Thankfully I asked
the user if they changed the passwd okay, and finally found
this issue.
The account procedure in pam_winbind and the way it is being
used here (after the change) makes everything work correctly.
The change does not break login for local users (or other
users outside of the AD), because it has [user_unknown=ignore]
in the pam configuration, and the module correctly return
PAM_USER_UNKNOWN if it's not AD/winbind user.
For the AD users, it only checks for PAM_WINBIND_NEW_AUTHTOK_REQD
data being set in the pam context (which is set in the same file,
in pam_sm_authenticate() method, if the user should change their
password). If it is not set, the account method just return ok.
And only for AD users, and only if PAM_WINBIND_NEW_AUTHTOK_REQD is
set, the module will ask for the new password.
I verified multiple scenarios of using this module with the
changed pam configuration, - everything works correctly.
There's no risk to break logins for users with active accounts.
There's a "risk" to enable processing of "user must change their
password at first login" case, -- for these, it finally works
the way how it is intended to work.
Arguable, one might say that finally and suddenly requiring to
change user passwords which had to be changed many years ago
is a breaking change. But it's difficult to argue it this way,
it's fixing a bug instead.
Hopefully this clears things up and makes the change to look
much less problematic.
The pam_winbind account function:
https://salsa.debian.org/samba-team/samba/-/blob/master/nsswitch/pam_winbind.c?ref_type=heads#L2962
Thanks,
/mjt
Reply to: