Date: Fri, 27 Aug 2010 21:33:42 +1200 From: ian@ianshome.com To: stuart_cherrington@hotmail.co.uk Subject: Re: Getting Solaris to use Openldap
On 08/27/10 08:48 PM, Stuart Cherrington wrote:
Hi,
I Have an OpenLDAP 2.4.18 server on RHEL 5.3. I can get Linux clients to use the master by use of the /etc/ldap.conf file. I'm now trying to get a SOlaris 10 client to use the master by initialising with the default profileName. If I run:
ldapclient -v init -a proxypassword=xxxxx -a proxydn=cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -a domainname=ldn.sw.com 10.2.250.15
I also add a -a profileName=default
Shouldn't need to add this as ldapclient takes 'default' as the default profilename if not specified. I did try it with this anyway but got same error.
So the 2 errors are the *NOTFOUND nisDomainObject *which is there when I check on the master:
[root@msldap01 openldap2.4]# ldapsearch2.4 -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxx-b dc=ldn,dc=sw,dc=com -s base # extended LDIF # # LDAPv3 # base <dc=ldn,dc=sw,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: ALL #
# ldn.sw.com dn: dc=ldn,dc=sw,dc=com dc: ldn o: ldn associatedDomain: ldn.sw.com nisDomain: ldn.sw.com objectClass: dcObject objectClass: organization objectClass: domainRelatedObject *objectClass: nisDomainObject* objectClass: top
That looks OK.
The other error is 'Failed to find defaultSearchBase for domain ldn.sw.com'
[root@msldap01 openldap2.4]# ldapsearch2.4 -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w 5wap5proxy -b cn=default,ou=profile,dc=ldn,dc=sw,dc=com -s base # extended LDIF # # LDAPv3 # base <cn=default,ou=profile,dc=ldn,dc=sw,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: ALL #
Do you have a cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com entry?
Yeh
[root@msldap01 openldap2.4]# ldapsearch2.4 -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxx -b cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -s base # extended LDIF # # LDAPv3 # base <cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: ALL #
# proxyagent, profile, ldn.sw.com dn: cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com cn: proxyagent sn: proxyagent objectClass: top objectClass: person userPassword:: e0NSWVBUfXYuTWpqUDJEb3lpMXc=
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
# default, profile, ldn.sw.com dn: cn=default,ou=profile,dc=ldn,dc=sw,dc=com *defaultSearchBase: dc=ldn,dc=sw,dc=com* authenticationMethod: simple followReferrals: TRUE profileTTL: 43200 searchTimeLimit: 30 objectClass: DUAConfigProfile defaultServerList: 10.2.250.15 credentialLevel: proxy cn: default defaultSearchScope: one
You should add
serviceSearchDescriptor: passwd:<people base> serviceSearchDescriptor: group:<group base>
I initially had these (and one for shadow) but they didn't make any difference the error, but I expect I'll need them when its in operation.
-- Ian.
On 08/27/10 09:56 PM, Stuart Cherrington wrote:
Date: Fri, 27 Aug 2010 21:33:42 +1200
# default, profile, ldn.sw.com dn: cn=default,ou=profile,dc=ldn,dc=sw,dc=com *defaultSearchBase: dc=ldn,dc=sw,dc=com* authenticationMethod: simple followReferrals: TRUE profileTTL: 43200 searchTimeLimit: 30 objectClass: DUAConfigProfile defaultServerList: 10.2.250.15 credentialLevel: proxy cn: default defaultSearchScope: one
You should add
serviceSearchDescriptor: passwd:<people base> serviceSearchDescriptor: group:<group base>
I initially had these (and one for shadow) but they didn't make any difference the error, but I expect I'll need them when its in operation.
What are the searches being run (from your slapd.log)?
Do the work?
The first search '(&(objectClass=nisDomainObject)(nisDomain=your domain')) should return your nisDomain, the next the profile.
Date: Fri, 27 Aug 2010 22:33:15 +1200 From: ian@ianshome.com To: stuart_cherrington@hotmail.co.uk Subject: Re: Getting Solaris to use Openldap CC: openldap-technical@openldap.org
On 08/27/10 09:56 PM, Stuart Cherrington wrote:
Date: Fri, 27 Aug 2010 21:33:42 +1200
# default, profile, ldn.sw.com dn: cn=default,ou=profile,dc=ldn,dc=sw,dc=com *defaultSearchBase: dc=ldn,dc=sw,dc=com* authenticationMethod: simple followReferrals: TRUE profileTTL: 43200 searchTimeLimit: 30 objectClass: DUAConfigProfile defaultServerList: 10.2.250.15 credentialLevel: proxy cn: default defaultSearchScope: one
You should add
serviceSearchDescriptor: passwd:<people base> serviceSearchDescriptor: group:<group base>
I initially had these (and one for shadow) but they didn't make any difference the error, but I expect I'll need them when its in operation.
What are the searches being run (from your slapd.log)?
The ldap.log contains
Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21) Aug 27 12:36:24 msldap01 slapd2.4[22363]: SRCH "" 0 3 Aug 27 12:36:24 msldap01 slapd2.4[22363]: 0 30 0 Aug 27 12:36:24 msldap01 slapd2.4[22363]: filter: (objectClass=*) Aug 27 12:36:24 msldap01 slapd2.4[22363]: attrs: Aug 27 12:36:24 msldap01 slapd2.4[22363]: namingcontexts Aug 27 12:36:24 msldap01 slapd2.4[22363]: Aug 27 12:36:24 msldap01 slapd2.4[22363]: send_ldap_result: err=0 matched="" text="" Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21) Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21) Aug 27 12:36:24 msldap01 slapd2.4[22363]: SRCH "dc=ldn,dc=sw,dc=com" 2 3 Aug 27 12:36:24 msldap01 slapd2.4[22363]: 0 30 0 Aug 27 12:36:24 msldap01 slapd2.4[22363]: filter: (&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com)) Aug 27 12:36:24 msldap01 slapd2.4[22363]: attrs: Aug 27 12:36:24 msldap01 slapd2.4[22363]: Aug 27 12:36:24 msldap01 slapd2.4[22363]: send_ldap_result: err=32 matched="" text="" Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21)
Which balances out your next statement :-)
Do the work?
The first search '(&(objectClass=nisDomainObject)(nisDomain=your domain')) should return your nisDomain, the next the profile.
I think I got the query syntax correct on the query
[root@msldap01 ~]# ldapsearch2.4 -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxx-b dc=ldn,dc=sw,dc=com "(&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com))" # extended LDIF # # LDAPv3 # base <dc=ldn,dc=sw,dc=com> with scope subtree # filter: (&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com)) # requesting: ALL #
# ldn.sw.com dn: dc=ldn,dc=sw,dc=com dc: ldn o: ldn associatedDomain: ldn.sw.com nisDomain: ldn.sw.com objectClass: dcObject objectClass: organization objectClass: domainRelatedObject objectClass: nisDomainObject objectClass: top
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
-- Ian.
On 08/28/10 12:41 AM, Stuart Cherrington wrote:
Date: Fri, 27 Aug 2010 22:33:15 +1200 From: ian@ianshome.com
What are the searches being run (from your slapd.log)?
The ldap.log contains
Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21) Aug 27 12:36:24 msldap01 slapd2.4[22363]: SRCH "" 0 3 Aug 27 12:36:24 msldap01 slapd2.4[22363]: 0 30 0 Aug 27 12:36:24 msldap01 slapd2.4[22363]: filter: (objectClass=*) Aug 27 12:36:24 msldap01 slapd2.4[22363]: attrs: Aug 27 12:36:24 msldap01 slapd2.4[22363]: namingcontexts Aug 27 12:36:24 msldap01 slapd2.4[22363]: Aug 27 12:36:24 msldap01 slapd2.4[22363]: send_ldap_result: err=0 matched="" text="" Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21) Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21) Aug 27 12:36:24 msldap01 slapd2.4[22363]: SRCH "dc=ldn,dc=sw,dc=com" 2 3 Aug 27 12:36:24 msldap01 slapd2.4[22363]: 0 30 0 Aug 27 12:36:24 msldap01 slapd2.4[22363]: filter: (&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com)) Aug 27 12:36:24 msldap01 slapd2.4[22363]: attrs: Aug 27 12:36:24 msldap01 slapd2.4[22363]: Aug 27 12:36:24 msldap01 slapd2.4[22363]: send_ldap_result: err=32 matched="" text="" Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21)
So that one failed with LDAP_NO_SUCH_OBJECT (err=32).
Which balances out your next statement :-)
Do the work?
The first search '(&(objectClass=nisDomainObject)(nisDomain=your domain')) should return your nisDomain, the next the profile.
I think I got the query syntax correct on the query
[root@msldap01 ~]# ldapsearch2.4 -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxx-b dc=ldn,dc=sw,dc=com "(&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com))"
Just -h 10.2.250.15 -x -b 'dc=ldn,dc=sw,dc=com' "(&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com))" should match the scripted search.
# extended LDIF # # LDAPv3 # base <dc=ldn,dc=sw,dc=com> with scope subtree # filter: (&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com)) # requesting: ALL #
# ldn.sw.com dn: dc=ldn,dc=sw,dc=com
and that one worked. Compare the log entry for the manual search with the scripted one.
What are the searches being run (from your slapd.log)?
The ldap.log contains
Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21) Aug 27 12:36:24 msldap01 slapd2.4[22363]: SRCH "" 0 3 Aug 27 12:36:24 msldap01 slapd2.4[22363]: 0 30 0 Aug 27 12:36:24 msldap01 slapd2.4[22363]: filter: (objectClass=*) Aug 27 12:36:24 msldap01 slapd2.4[22363]: attrs: Aug 27 12:36:24 msldap01 slapd2.4[22363]: namingcontexts Aug 27 12:36:24 msldap01 slapd2.4[22363]: Aug 27 12:36:24 msldap01 slapd2.4[22363]: send_ldap_result: err=0 matched="" text="" Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21) Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21) Aug 27 12:36:24 msldap01 slapd2.4[22363]: SRCH "dc=ldn,dc=sw,dc=com" 2 3 Aug 27 12:36:24 msldap01 slapd2.4[22363]: 0 30 0 Aug 27 12:36:24 msldap01 slapd2.4[22363]: filter: (&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com)) Aug 27 12:36:24 msldap01 slapd2.4[22363]: attrs: Aug 27 12:36:24 msldap01 slapd2.4[22363]: Aug 27 12:36:24 msldap01 slapd2.4[22363]: send_ldap_result: err=32 matched="" text="" Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21)
So that one failed with LDAP_NO_SUCH_OBJECT (err=32).
OOI - How do you know err=32 means LDAP_NO_SUCH_OBJECT?
Which balances out your next statement :-)
Do the work?
The first search '(&(objectClass=nisDomainObject)(nisDomain=your domain')) should return your nisDomain, the next the profile.
I think I got the query syntax correct on the query
[root@msldap01 ~]# ldapsearch2.4 -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxx-b dc=ldn,dc=sw,dc=com "(&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com))"
Just -h 10.2.250.15 -x -b 'dc=ldn,dc=sw,dc=com' "(&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com))" should match the scripted search.
OK - I ran
ldapsearch2.4 -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxx -x -b 'dc=ldn,dc=sw,dc=com'
It showed me everything in the LDAP tree, Last few lines are
# search result search: 2 result: 0 Success
# numResponses: 310 # numEntries: 309
Which seems to work OK.
The log output says
Aug 31 09:38:00 msldap01 slapd2.4[22363]: connection_get(21) Aug 31 09:38:00 msldap01 slapd2.4[22363]: ==> bdb_bind: dn: cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com Aug 31 09:38:00 msldap01 slapd2.4[22363]: send_ldap_result: err=0 matched="" text="" Aug 31 09:38:00 msldap01 slapd2.4[22363]: connection_get(21) Aug 31 09:38:00 msldap01 slapd2.4[22363]: SRCH "dc=ldn,dc=sw,dc=com" 2 0 Aug 31 09:38:00 msldap01 slapd2.4[22363]: 0 0 0 Aug 31 09:38:00 msldap01 slapd2.4[22363]: filter: (objectClass=*) Aug 31 09:38:00 msldap01 slapd2.4[22363]: attrs: Aug 31 09:38:00 msldap01 slapd2.4[22363]: Aug 31 09:38:00 msldap01 slapd2.4[22363]: connection_get(21) Aug 31 09:38:00 msldap01 slapd2.4[22363]: send_ldap_result: err=0 matched="" text="" Aug 31 09:38:01 msldap01 slapd2.4[22363]: connection_get(21)
# extended LDIF # # LDAPv3 # base <dc=ldn,dc=sw,dc=com> with scope subtree # filter: (&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com)) # requesting: ALL #
# ldn.sw.com dn: dc=ldn,dc=sw,dc=com
and that one worked. Compare the log entry for the manual search with the scripted one.
-- Ian.
On 08/31/10 09:40 PM, Stuart Cherrington wrote:
Aug 27 12:36:24 msldap01 slapd2.4[22363]: Aug 27 12:36:24 msldap01 slapd2.4[22363]: send_ldap_result: err=32 matched="" text="" Aug 27 12:36:24 msldap01 slapd2.4[22363]: connection_get(21)
So that one failed with LDAP_NO_SUCH_OBJECT (err=32).
OOI - How do you know err=32 means LDAP_NO_SUCH_OBJECT?
RTFM!
Just -h 10.2.250.15 -x -b 'dc=ldn,dc=sw,dc=com' "(&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com))" should match the scripted search.
OK - I ran
ldapsearch2.4 -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxx -x -b 'dc=ldn,dc=sw,dc=com'
It showed me everything in the LDAP tree, Last few lines are
That's because it isn't the search I suggested you try...
Just -h 10.2.250.15 -x -b 'dc=ldn,dc=sw,dc=com' "(&(objectClass=nisDomainObject)(nisDomain=ldn.sw.com))" should match the scripted search.
OK - I ran
ldapsearch2.4 -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxx -x -b 'dc=ldn,dc=sw,dc=com'
It showed me everything in the LDAP tree, Last few lines are
That's because it isn't the search I suggested you try...
OK - so I tried
ldapsearch2.4 -h 10.2.250.15 -x -b 'dc=ldn,dc=sw,dc=com' # extended LDIF # # LDAPv3 # base <dc=ldn,dc=sw,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object
# numResponses: 1
What I don't understand is 'which' object is missing?
-- Ian.
Stuart Cherrington wrote:
OK - so I tried
ldapsearch2.4 -h 10.2.250.15 -x -b 'dc=ldn,dc=sw,dc=com' # extended LDIF # # LDAPv3 # base <dc=ldn,dc=sw,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object
# numResponses: 1
What I don't understand is 'which' object is missing?
Hi Stuart,
AIUI from reading above then the following LDAP search works:
ldapsearch2.4 -h 10.2.250.15 -x -b 'dc=ldn,dc=sw,dc=com' -D 'cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com'
whereas the following doesn't:
ldapsearch2.4 -h 10.2.250.15 -x -b 'dc=ldn,dc=sw,dc=com'
Since it appears to fail when not specifying a bind DN with -D, this suggests to me that you have an ACL on 'dc=ldn,dc=sw,dc=com' which does not allow access to that part of the tree for anonymous binds - hence the "No such object" message.
For security reasons, we tend to disable anonymous binds on all our installations; however it seems as if the Solaris libraries require anonymous access to the 'cn=default,ou=profile...' part of the tree before they will rebind using proxyDN.
HTH,
Mark.
openldap-technical@openldap.org
-
Ian Collins -
Mark Cave-Ayland -
Stuart Cherrington