[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Solaris 9 LDAP client issues

Igor Brezac wrote:

On Tue, 20 Aug 2002, Scott Moorhouse wrote:

This is still definitely not working.  OpenLDAP considers the LDAP
client to be binding as an anonymous user.  Whether that means it
botched the authentication or never tried it in the first place is
something I'm not familiar enough with the debug output of slapd to
determine yet.  I can't even get it to bind as my RootDN.

I have been testing my binding capabilities and access controls with the
GQ LDAP client, and everything works as expected there, so why doesn't
the Solaris client work?

You do not hove something configured properly.

Or the client's broken. :) Or, there's some incompatibility between in and 2.0.23, which is the OpenLDAP version I'm using, I guess.

Here's the ldif of the entry I've tried to bind to using Solaris 9's
LDAP client.   Perhaps I'm missing some objectclass or attribute it expects?

dn: cn=NamingClient,dc=mydomain,dc=com
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: NamingClient
userPassword: {crypt}[DEScryptstring]

This is all you need for the binding purposes.

What are the contents of /var/ldap/ldap_client_* and /etc/defaultdomain?

NS_LDAP_BINDDN= cn=NamingClient,dc=mydomain,dc=com
NS_LDAP_BINDPASSWD= {NS1}[hex string]

NS_LDAP_SERVERS= my.ldap.server.ip
NS_LDAP_SEARCH_BASEDN= dc=mydomain,dc=com
NS_LDAP_SERVICE_SEARCH_DESC= automount:ou=AutomountMaps,dc=mydomain,dc=com


Is /etc/defaultdomain supposed to be a dn if you are using LDAP as a naming service? My guess is no, but with Sun, nothing surprises me.

My GQ client binds to that fine and gets the special permissions I have
laid out for it in slapd.conf...

I've also tried binding as the RootDN with the RootDN password with the
same results.  Unless I allow anonymous read to the userPassword
attribute, no one can log in.

I am not familiar with GQ LDAP client. I suggest that you try ldapsearch and use -b -D -W params (eg ldapsearch -x -b 'dc=mydomain,dc=com' -D cn=NamingClient,dc=mydomain,dc=com -W 'cn=NamingClient'). If this works and if the result shows userPassword you should be good to go.

I was able to reproduce favorable results using ldapsearch on both the Linux LDAP server and the Solaris client.
I was able to bind as cn=NamingClient,dc=mydomain,dc=com using the password I set up on its userPassword attribute and I could see the userPassword attributes in ou=People that I am attempting UNIX logins with. I rebound without supplying credentials and could not see the userPassword attribute, as expected.

I think from my experimentation with slapd's access rules and looking at the slapd debug output it's clear that the Solaris naming services client simply is not binding properly and only gets anonymous level privileges. For the life of me I can't understand what I'm doing wrong at this point. Maybe someone will notice something in the /var/ldap/ldap_client_* files above that will help.