attachment
0001-don-t-check-for-PWEXPIRE_SHADOW-with-ldap-auth.patch

You probably misunderstood the original ticket. That was a specific request to update the shadowLastChange attribute in case LDAP password policy is used. There was no reference to shadow password policy. Note that in common case of LDAP password policy being used, this attribute should be updated on server side. The functionality in SSSD only covers cases when server is misconfigured and it doesn't update the attribute.

By doing what you suggest in the patch, you would basically rely that LDAP password policy module is configured on the server side which in many cases won't be. That's why we need shadow password policy in the first place.

One debug message in the patch says "Changing shadow password attributes not implemented", I believe this is still the case, the support is not there. I don't see a reason why not to implement it but you need to use standard LDAP operations, not the extended operation, that should be only used for LDAP password policy.

Replying to [comment:1 jzeleny]:

You probably misunderstood the original ticket. That was a specific request to update the shadowLastChange attribute in case LDAP password policy is used. There was no reference to shadow password policy. Note that in common case of LDAP password policy being used, this attribute should be updated on server side. The functionality in SSSD only covers cases when server is misconfigured and it doesn't update the attribute.

Oh, I wasn't aware of any openldap overlay that updates shadowLastChange with the extended operation. AFAIK pam_ldap and pam_ldapd both update the attribute "by hand".

By doing what you suggest in the patch, you would basically rely that LDAP password policy module is configured on the server side which in many cases won't be. That's why we need shadow password policy in the first place.

One debug message in the patch says "Changing shadow password attributes not implemented", I believe this is still the case, the support is not there. I don't see a reason why not to implement it but you need to use standard LDAP operations, not the extended operation, that should be only used for LDAP password policy.

It looks to me like the shadowLastChange attribute is updated by sssd (in sdap_pam_chpass_done) if ldap_chpass_update_last_change is true (this doesn't seem to be documented though).

Replying to [comment:2 lotheac]:

Replying to [comment:1 jzeleny]:

You probably misunderstood the original ticket. That was a specific request to update the shadowLastChange attribute in case LDAP password policy is used. There was no reference to shadow password policy. Note that in common case of LDAP password policy being used, this attribute should be updated on server side. The functionality in SSSD only covers cases when server is misconfigured and it doesn't update the attribute.

Oh, I wasn't aware of any openldap overlay that updates shadowLastChange with the extended operation. AFAIK pam_ldap and pam_ldapd both update the attribute "by hand".

Yes, my understanding was that pam_ldap updates the attribute using user's credentials and that the attribute must be writable by the user. That's also why this feature is broken, any user can trivially reset the value with ldapmodify.

By doing what you suggest in the patch, you would basically rely that LDAP password policy module is configured on the server side which in many cases won't be. That's why we need shadow password policy in the first place.

One debug message in the patch says "Changing shadow password attributes not implemented", I believe this is still the case, the support is not there. I don't see a reason why not to implement it but you need to use standard LDAP operations, not the extended operation, that should be only used for LDAP password policy.

It looks to me like the shadowLastChange attribute is updated by sssd (in sdap_pam_chpass_done) if ldap_chpass_update_last_change is true (this doesn't seem to be documented though).

Correct, we forgot to include the option in the man page. I'll change the summary accordingly.

Fields changed

summary: LDAP password changes fail with ldap_pwd_policy = shadow => ldap_chpass_update_last_change is not included in the manual page

Replying to [comment:3 jhrozek]:

Yes, my understanding was that pam_ldap updates the attribute using user's credentials and that the attribute must be writable by the user. That's also why this feature is broken, any user can trivially reset the value with ldapmodify.

Fair point, but sssd does exactly that as well with the option in question. The shadow policy depends on shadowLastChange being up to date (as far as I can tell, there's no reason a server-side policy would have to use shadowAccount attributes anyway) so it would make sense to be able to both use the attributes for policy and update shadowLastChange client-side.

Correct, we forgot to include the option in the man page. I'll change the summary accordingly.

Umm, shouldn't a new issue be created instead? jzeleny already mentioned that this could be implemented (though not using the exop).

Replying to [comment:5 lotheac]:

Replying to [comment:3 jhrozek]:

Yes, my understanding was that pam_ldap updates the attribute using user's credentials and that the attribute must be writable by the user. That's also why this feature is broken, any user can trivially reset the value with ldapmodify.

Fair point, but sssd does exactly that as well with the option in question. The shadow policy depends on shadowLastChange being up to date (as far as I can tell, there's no reason a server-side policy would have to use shadowAccount attributes anyway) so it would make sense to be able to both use the attributes for policy and update shadowLastChange client-side.

The whole shadow support in SSSD was sort of shoved into our throats a bit. We think it is an outdated technology and there are much better ways to deal with identity management nowadays. You are trying to fix/enhance something that is not that good any more (and broken in its nature as mentioned above). Is there any specific reason why you absolutely need to use shadow in your environment in the first place? May be we are missing some important use case that we need to know about.

Replying to [comment:6 dpal]:

Is there any specific reason why you absolutely need to use shadow in your environment in the first place? May be we are missing some important use case that we need to know about.

It's the path of least resistance in our current environment since it is already working on all our client machines (Linux, OSX, Solaris). Migrating to some other scheme would require extra work.

In any case, if you don't think shadow support should be enhanced, why support it at all?

In this ticket we are just fixing the man page. The other part of the ticket is tracked in #1314.

milestone: NEEDS_TRIAGE => SSSD 1.9.1

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=852948

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=852948 852948]

Fields changed

owner: somebody => jhrozek
patch: 0 => 1
status: new => assigned

master: e9cbbaf

resolution: => fixed
status: assigned => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2536

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.