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

Re: Using Replication Slave For Authentication

My backend is hdb.  Also, I'm very sure the rootdn and rootpw are correct, as I have been using it for most of my testing.  As for being denied read for cn=config, I'm pretty sure that is because it doesn't exist.  

After running your command this is the result:

No such object (32)

It does not exist on either the master or slave server.  I am using the slapd.conf configuration method, is there anything else I could show you?


On Apr 20, 2010, at 4:29 PM, Sergiy Stepanenko wrote:

> I guess your backend is bdb or hdb.
> Run
> ldapsearch -LL -H <your_ldap_host> -x -D <rootdn> -w <rootpw> -b "cn=config" * +
> and see what it produces. But before you do that open slapd.conf if you use flat file configuration and check what exactly configured for rootdn and rootpw because if "backend default search access denied to "cn=admin,dc=domain,dc=com" then you have a problem in config.
> It is much easier to talk if I know what is configured actually, because snippets of log and config file dont tell whole story.
> Cheers
>> Putting loglevel to -1 (everything) and logging in with ApacheDS as cn=admin,dc=domain,dc=com (which is supposed to supersede any ACL rules and have read/write to everything I believe) I find a whole lot of "access granted" lines and then towards the end":
>> =>  access_allowed: search access to "cn=config" "entry" requested
>> =>  slap_access_allowed: backend default search access denied to "cn=admin,dc=domain,dc=com"
>> =>  access_allowed: no more rules
>> send_ldap_result: conn=0 op=8 p=3
>> send_ldap_result: err=32 matched="" text=""
>> Error 32 means object doesn't exist (I think).  Which would be true, our LDAP tree has no cn=config.  We get the same error on the primary server, so I suppose it is ApacheDS trying to look for what would be in the Apache LDAP implementation.  But that's the only error I can find, everything else is miles and miles of "search access granted".
>> I tried to get it to list DN="dc=domain,dc=com" by hand from ApacheDS, and it would not return anything (it says "No base DN returned from server.") although in the logs it shows:
>> conn=6 op=3 SRCH base="dc=domain,dc=com" scope=0 deref=3 filter="(objectClass=*)"
>> conn=6 op=3 SRCH attr=hasSubordinates objectClass
>> =>  hdb_search
>> bdb_dn2entry("dc=domain,dc=com")
>> =>  access_allowed: search access to "dc=domain,dc=com" "entry" requested
>> <= root access granted
>> access_allowed: search access granted by manage(=mwrscxd)
>> base_candidates: base: "dc=domains,dc=com" (0x00000001)
>> send_ldap_result: conn=6 op=3 p=3
>> send_ldap_result: err=0 matched="" text=""
>> send_ldap_response: msgid=4 tag=101 err=0
>> But when I run the ldapsearch command (as any user) from other computers on the network it returns the DN's information... So I am thoroughly confused...  I am pretty sure it is not logging in as anonymous, but I have no idea why only the ldapsearch command is the only thing that can authenticate and retrieve information.  It is the same version of openldap as the primary server, it has the same exact config, it has all the same schema loaded, it has the exact full ldap tree.  I'm going to explode!@$#@
>> -a
> -- 
> Sergiy Stepanenko
> Systems Administrator
> Information Technology Services
> University of Saskatchewan
> -----------------------------------
> phone:    (306) 966-2762
> email:sergiy.stepanenko@usask.ca