So in your case the ldap users (everyone?) *expect* to have to enter two passwords. I was assuming that the ldap and kerberos users were disjoint.
I think it's the use_first_pass, rather than the binding that's killing you. If the optional doesn't turn off the warning then there's no pam workaround to the bug that I see. s/use_/try_/ on pam_ldap might fix the error, but you'd be getting two Kerberos failed warnings instead of just one. *bleah* On Jun 30, 2006, at 2:36 PM, Erich Weiler wrote: > Hi Henry, > > Alas, it doesn't work. I think what the "binding" line does is > choke the chain, because it doesn't accept my krb5 password. LDAP > works though, but still gives the "Kerberos Authentication Failed" > message. > > I do need the kerberos module 2nd in the chain, because some folks > have kerberos passwords and some have LDAP passwords, but all use > their LDAP accounts. And if they have a kerberos password, it > needs to check and authenticate them that way first so they can get > a krb5 ticket (for sec=krb5 reasons with NFSv4). > > Thanks for trying though. > > ciao, erich > > Henry B. Hotz wrote: >> On Jun 30, 2006, at 8:46 AM, Erich Weiler wrote: >>> # Default definitions for Authentication management >>> # Used when service name is not explicitly mentioned for >>> authentication >>> # >>> other auth requisite pam_authtok_get.so.1 >>> other auth required pam_unix_cred.so.1 >>> other auth sufficient pam_unix_auth.so.1 >>> other auth sufficient pam_krb5.so.1 nowarn >>> other auth sufficient pam_ldap.so.1 >> As a workaround, maybe: >> other auth requisite pam_authtok_get.so.1 >> other auth required pam_unix_cred.so.1 >> other auth sufficient pam_unix_auth.so.1 >> other auth optional pam_krb5.so.1 nowarn try_first_pass >> other auth binding pam_ldap.so.1 use_first_pass >> other auth required pam_krb5.so.1 nowarn use_first_pass >> ?? >> A bit redundant with the Kerberos exchanges, but might do what you >> want *if* the "optional" avoids the messages. I'm assuming you >> have a reason for putting krb5 ahead of ldap in the chain. ------------------------------------------------------------------------ ---- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
