best practices for configuring client-side NSS/PAM over LDAP+SSL ?

[Nathan Stratton Treadway]

As we start to upgrade up to or install Lucid on our servers, we're
running into the issue discussed in LP: #423252, "NSS using LDAP+SSL
breaks setuid applications like su, sudo, apache2 suexec, and atd".

In my research I noticed that that bug has been open for more than a
year, and that there doesn't seem to be any real sign of progress toward
fixing it in either that bug's discussion nor among the various related
Debian bugs.  

I saw that the Lucid and Maverick release notes both include the same
paragraph on the topic, recommending the use of nscd or switching to
using "libnss-ldapd" instead of "libnss-ldap" ... but as far as I could
tell from the files found in the lp:ubuntu-docs/maverick Bazaar branch,
the upcoming Maverick version of the Server Guide is still going to
mention only the "libnss-ldap" package -- and of course the
"libnss-ldap" package is in main while the "libnss-ldapd" is in
universe.

On the other hand, as mentioned in the discussion for LP: #423252, the
"nscd" approach doesn't appear to be a complete fix: it allows "sudo" to
work, but the "su" and "at" commands still fail for certain types of
users.


So, I'm wondering what other sites have ended up doing about this, and
if anyone can give us some advice on which appoach would be considered
"best practice" for setting up Lucid machines at this point.  

Are sites just giving up and switching back to non-SSL ldap://
connections to avoid this problem?  Running "nscd" and living without
"su" and "at"?  Or have people switched to using "libnss-ldapd" in spite
of the main-v.s.-universe situation?

Any chance that "libnss-ldapd" will be moving into main (and presumably
thus replacing "libnss-ldap") in the Natty (or even Natty+1) timeframe?   

Thanks.

						Nathan