Password change process in Winbind

[Ivan Korytov]

Hello!

I've received a request for improving interaction with user when changing password in Winbind (pam_winbind).

Two problems were identified:
- user doesn't receive a reason why new password was declined
- displayed password policy didn't account for any PSO applied to this user

Samba reports password reject reason in Kerberos because it provides a field for custom messages and they didn't remove it (yet or never will).
That makes clients using Winbind unaware if displayed password policy is correct and why password was rejected. Clients using SSSD can at least know the reject reason.

Functions used to change a password through RPC in Winbind:
- ChangePasswordUser4 (current)
- ChangePasswordUser3 (previously used by default)
- ChangePasswordUser2

Only ChangePasswordUser3 reports back a reject reason for user.

pam_winbind still has support for displaying a reason, but with ChangePasswordUser4 it no longer can do that and shows only domain password policy without accounting for PSOs.

Some ways of solving this that I can see:
- rewrite pam_winbind to display password policy and reason only when ChangePasswordUser3 is used; no reason or policy description otherwise like in Windows to conform to their behavior
- provide ability to change password through Kerberos in pam_winbind
- create additional RPC pipe with Samba-only calls that will provide ChangePasswordUser4 with reject reason and policy (so not to interfere with any reserved pipes/names from Microsoft); fallback to other variants to maintain compatibility

I'm not sure if adding non-compatible but useful features is a preferred way or if there any security reasons behind hiding this information from user.

I've looked at other ways of at least providing correct password policy description. There is no RPC call that would send that information, AFAIK.
LDAP query from winbindd could have been sufficient but the user password is already expired when password change happens at login time, so user cannot request TGT to obtain service ticket. Computer account can send an LDAP query but cannot access PSO attributes without modifying ACL on it (only visible to creator and whom applied to by default).

Will be glad to get suggestions and opinions on this topic.
Thank you!

—
Ivan Korytov
korytovip at basealt.ru