On 03/ 1/10 04:20 AM, Piotr Jasiukajtis wrote: > Hi Doug, > > The main reason I use nss-ldap from 3rd party is because with native > one I can't log in using kerberos/ldap account. > > At this moment I upgraded system to b133. I can log into the system's > console using 3rd party nss-ldap. > With the same configuration (just cp nss-ldap...) I'm not able to do > so with native nss-ldap: > login[918]: [ID 468494 daemon.crit] login account failure: No account > present for user > > I have ldapclient running with the following setting: > NS_LDAP_FILE_VERSION= 2.0 > NS_LDAP_AUTH= sasl/GSSAPI > NS_LDAP_SEARCH_SCOPE= sub > NS_LDAP_CACHETTL= 0 > NS_LDAP_CREDENTIAL_LEVEL= self > NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=posixAccount > > As a 'root' user I have already host/ principal ticket. Also I am able > to obtain TGT with 'kinit'. > > In logs I get: > login[499]: [ID 738555 daemon.warning] libsldap: Metaslot disabled for > self credential mode >
Yes, I've seen this before a long time ago, which may be related: 6786011 LDAP SASL bind operation should not disable metaslot globally is really being addressed by the following active CRs: 6884140 softtoken touches $HOME too soon 6443649 softtoken should honor $HOME, avoid getpwuid In any case, what I saw in the past was that the binding calls will fail in the following mech_krb5 call, krb5_c_random_make_octets(), which returns PKCS_ERR. Subsequently, looking at the metaslot I noticed that it was disabled. Shawn. -- > and > getent[543]: [ID 293258 daemon.warning] libsldap: Status: 7 Mesg: > Session error no available conn. > pfexec[546]: [ID 293258 daemon.warning] libsldap: Status: 7 Mesg: > openConnection: GSSAPI bind failed - 82 Local error > > Any idea how to solve that? > > On Fri, Feb 26, 2010 at 8:56 PM, Doug Leavitt<Doug.Leavitt at sun.com> wrote: > >> Hi Piotr, >> >> >>> I'm not sure it's a right alias, however it's related to the GSSAPI. >>> >>> I have a snv_129 kerberos+ldap client machine. Kerberos is already >>> configured. KDC is running on Linux. >>> >>> Original nss_ldap library is replaced with nss-ldap from >>> >>> http://freeipa.org/downloads/solaris/nss_ldap/10/RHATnss-ldap-253-12.i386.pkg >>> >> >> This is the root of your problem. The nss-ldap that you replaced >> the OpenSolaris nss-ldap with is not compatible with OpenSolaris >> components. Linux nss-ldap is a different source base with different >> characteristics and behaviors and is not compatible with OpenSolaris's >> current naming system. >> >> If you choose to install Linux nss-ldap you need to understand that >> none of the advanced facilities like nscd caching, per-user >> LDAP/Kerberos support or using any of the Solaris nss_ldap tools >> including ldapclient, ldap_cachemgr or ldaplist will function when >> you do this. >> >> All of these components including Solaris pam_ldap require the use >> of Solaris nss_ldap and other internal interfaces associated with each >> of these pieces. >> >> By replacing Solaris nss_ldap with Linux nss_ldap you have broken >> the LDAP naming services stack which is why you are getting all >> those error messages. >> >> The correct solution is to not replace nss_ldap with the incompatible >> components. >> >> Linux nss_ldap is not a substitute library for the current OpenSolaris >> nss_ldap naming libraries. >> >> I hope that answers your question. >> >> Doug. >> >> > > > -- Shawn.
