Rich, do you know if these controls need any special treatment or behave the same as the OpenLDAP password controls?

(In reply to comment #2)
> Rich, do you know if these controls need any special treatment or behave the
> same as the OpenLDAP password controls?

I don't know.  They are pretty simple, so they might work exactly the same way as the OpenLDAP controls.

Upstream ticket:
https://fedorahosted.org/sssd/ticket/984

Created attachment 583569 [details]
simple implementation of Netscape password warning expiration control

What do you think about this simple implementation?  It doesn't compare the value to any other password control warning value to see, for instance, which is smaller.  Also, if the bv_val happened to not be a null-terminated string, it would return who knows what.  But a quick test against our 389-ds setup has it correctly parsing the Netscape control (as well as the server-side password controls that are returned).  I'll add the .4 control for expired passwords if this is the right direction.

(In reply to comment #7)
> Created attachment 583569 [details]
> simple implementation of Netscape password warning expiration control
> 
> What do you think about this simple implementation?  It doesn't compare the
> value to any other password control warning value to see, for instance, which
> is smaller.  Also, if the bv_val happened to not be a null-terminated string,
> it would return who knows what.  But a quick test against our 389-ds setup has
> it correctly parsing the Netscape control (as well as the server-side password
> controls that are returned).  I'll add the .4 control for expired passwords if
> this is the right direction.

Thanks for the patch! Yes, I think this is probably headed in the right direction. I think you identified the same issues I would have: we need to do a better job of validating the return values, but otherwise this looks pretty good. Please feel free to add the expired passwords.

Created attachment 584357 [details]
simple implementation of Netscape password warning expiration control

This round adds a strndup/memcpy/atoi/free (along with an initial check of bv_len for suspiciously long values) to carefully get the number of seconds until password expiration out of the control.  Other alternatives might be a custom atoi-like function that took a maximum length parameter like snprintf or a libldap function that I don't know of (I didn't look too hard, to be honest).  The .3.4.4 oid for password expiration is now also handled.
Tests against our 389 server show proper return of the two controls and their handling (although I can't disable the ldap server-side password policy controls on our production servers, so those were also returned with the Netscape ones).
What do you think?  How can the patch be improved?

Created attachment 584385 [details]
simple implementation of Netscape password warning expiration control

(In reply to comment #10)
> Created attachment 584357 [details]
> simple implementation of Netscape password warning expiration control
> 
> This round adds a strndup/memcpy/atoi/free (along with an initial check of
> bv_len for suspiciously long values) to carefully get the number of seconds
> until password expiration out of the control.  Other alternatives might be a
> custom atoi-like function that took a maximum length parameter like snprintf or
> a libldap function that I don't know of (I didn't look too hard, to be honest).
>  The .3.4.4 oid for password expiration is now also handled.
> Tests against our 389 server show proper return of the two controls and their
> handling (although I can't disable the ldap server-side password policy
> controls on our production servers, so those were also returned with the
> Netscape ones).
> What do you think?  How can the patch be improved?

I've made a few changes. Notably: I updated all of the DEBUG messages in that function to use the new macros to be more consistent. I switched your nval conversion to use our custom strtouint32() function instead of atoi(), which is deprecated. (Please let me know if uint32_t is unacceptable here). I switched the creation of nval to use talloc_strndup() which always guarantees NULL-termination (also to stick with our convention of always using TALLOC for memory management in SSSD). I made #defines for the OIDs in a common header.

I've also submitted this revised patch for further upstream review at https://fedorahosted.org/pipermail/sssd-devel/2012-May/009794.html as per our upstream review process (https://fedorahosted.org/sssd/wiki/BugLifecycle)

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

*** This bug has been marked as a duplicate of bug 771412 ***

Comment on attachment 584385 [details]
simple implementation of Netscape password warning expiration control

Giving this old bug attachment a "+" since a recent bugzilla upgrade has started spamming me weekly about it.