authentication via LDAP has ceased functioning after we upgraded to SLES 11.4 via recommended method (boot from DVD). Unfortunately with SLES I cannot give you any meaningful log output since neither PAM nor the ldap client give you any and pam_debug is not available on SLES.
We suspect it boils down to requiring the userfilter inetOrgPerson. Of course we set this filter in the /etc/ldap.conf. It worked just fine in 10.4 but now all you get is "invalid password".
Using tcpdump I was able to determine that unlike in 10.4 the ldap client now first queries the server with the filter inetOrgPerson (which works and returns results) but then subsequently(!) queries the server with the filter posixAccount. Now this last one does not work because this attribute is not used by the LDAP server (IBM Tivoli Directory Server). Since the query for the password is now made with the incorrect user filter - no password is ever checked against LDAP (from what I can tell) and thus the login fails.
Is there a way to force the LDAP client to stick with the configured userfilter (inetOrgPerson) versus it switching to a (hard-coded?) incorrect one for queries about password and shell? Thing is, we do not use passwords to log into the system via ssh, so we only need this PAM+LDAP to be working so applications can check user passwords againts it (the app does not have its own LDAP support). As such we dont need entries in LDAP for a users shell and whatever else is normally assigned to posixAccount.
As far as I can tell - modifying the production LDAP server is not an option.
FWIW The method of testing this is ssh'ing into the box (with pubkey) and then try to su into our own user for a password prompt. /var/log/messages only says "failed su ..." without any further details
