Re: Solaris 9 LDAP client issues

[Scott Moorhouse <smoorhouse@ae-solutions.com>]

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?
>  
/var/ldap/ldap_client_cred
NS_LDAP_BINDDN= cn=NamingClient,dc=mydomain,dc=com
NS_LDAP_BINDPASSWD= {NS1}[hex string]

/var/ldap/ldap_client_file
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= my.ldap.server.ip
NS_LDAP_SEARCH_BASEDN= dc=mydomain,dc=com
NS_LDAP_SEARCH_SCOPE= sub
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= automount:ou=AutomountMaps,dc=mydomain,dc=com

/etc/defaultdomain
mydomain.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.

Thanks...