Ok, since I should be updating this system to using the slapd.d/ configuration method eventually anyway, I did a `slaptest -f slapd.conf -F slapd.d` and got it to where I believe it works fine from the cn=config. This time, after running your command, this is the output I get:
version: 1
dn: cn=config structuralObjectClass: olcGlobal entryUUID: 2226bfc8-e1a6-102e-80d2-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#000000#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: cn=config subschemaSubentry: cn=Subschema
dn: cn=module{0},cn=config structuralObjectClass: olcModuleList entryUUID: 2226bfc8-e1a6-102e-80d3-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#000001#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: cn=module{0},cn=config subschemaSubentry: cn=Subschema
dn: cn=schema,cn=config structuralObjectClass: olcSchemaConfig entryUUID: 2226bfc8-e1a6-102e-80d4-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#000002#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: cn=schema,cn=config subschemaSubentry: cn=Subschema
dn: cn={0}core,cn=schema,cn=config structuralObjectClass: olcSchemaConfig entryUUID: 2226bfc8-e1a6-102e-80d5-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#000003#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: cn={0}core,cn=schema,cn=config subschemaSubentry: cn=Subschema
dn: cn={1}cosine,cn=schema,cn=config structuralObjectClass: olcSchemaConfig entryUUID: 2226bfc8-e1a6-102e-80d6-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#000004#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: cn={1}cosine,cn=schema,cn=config subschemaSubentry: cn=Subschema
dn: cn={2}nis,cn=schema,cn=config structuralObjectClass: olcSchemaConfig entryUUID: 2226bfc8-e1a6-102e-80d7-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#000005#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: cn={2}nis,cn=schema,cn=config subschemaSubentry: cn=Subschema
dn: cn={3}inetorgperson,cn=schema,cn=config structuralObjectClass: olcSchemaConfig entryUUID: 2226bfc8-e1a6-102e-80d8-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#000006#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: cn={3}inetorgperson,cn=schema,cn=config subschemaSubentry: cn=Subschema
dn: cn={4}ppolicy,cn=schema,cn=config structuralObjectClass: olcSchemaConfig entryUUID: 2226bfc8-e1a6-102e-80d9-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#000007#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: cn={4}ppolicy,cn=schema,cn=config subschemaSubentry: cn=Subschema
dn: olcDatabase={-1}frontend,cn=config structuralObjectClass: olcDatabaseConfig entryUUID: 2226bfc8-e1a6-102e-80da-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#000008#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: olcDatabase={-1}frontend,cn=config subschemaSubentry: cn=Subschema
dn: olcDatabase={0}config,cn=config structuralObjectClass: olcDatabaseConfig entryUUID: 2226bfc8-e1a6-102e-80db-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#000009#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: olcDatabase={0}config,cn=config subschemaSubentry: cn=Subschema
dn: olcDatabase={1}hdb,cn=config structuralObjectClass: olcHdbConfig entryUUID: 2226bfc8-e1a6-102e-80dc-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#00000a#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: olcDatabase={1}hdb,cn=config subschemaSubentry: cn=Subschema
dn: olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config structuralObjectClass: olcPPolicyConfig entryUUID: 2226bfc8-e1a6-102e-80dd-ab1f64ee6c67 creatorsName: createTimestamp: 20100421152725Z entryCSN: 20100421152725.747572Z#00000b#000#000000 modifiersName: modifyTimestamp: 20100421152725Z entryDN: olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config subschemaSubentry: cn=Subschema
I hope this is what you were looking for and helps. -a
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