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

Re: Using Replication Slave For Authentication

To: openldap-technical@openldap.org
Subject: Re: Using Replication Slave For Authentication
From: Ariel <ariel@bidcactus.com>
Date: Wed, 21 Apr 2010 11:31:52 -0400
In-reply-to: <4BCE0E8E.4070502@mail.usask.ca>
References: <29DBDF7B-FC68-4022-A013-84EF445303F7@bidcactus.com> <4BCDD467.5020708@mail.usask.ca> <9F6F4B4C-4E7A-4DA4-A2AA-7E71DA762D4A@bidcactus.com> <4BCDE97C.6050004@mail.usask.ca> <3A9DAB1F-864B-4587-B2C3-78A883E80C94@bidcactus.com> <4BCE0E8E.4070502@mail.usask.ca>

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

Follow-Ups:
- Re: Using Replication Slave For Authentication
  - From: Sergiy Stepanenko <ses863@mail.usask.ca>

References:
- Using Replication Slave For Authentication
  - From: Ariel <ariel@bidcactus.com>
- Re: Using Replication Slave For Authentication
  - From: Sergiy Stepanenko <ses863@mail.usask.ca>
- Re: Using Replication Slave For Authentication
  - From: Ariel <ariel@bidcactus.com>
- Re: Using Replication Slave For Authentication
  - From: Sergiy Stepanenko <ses863@mail.usask.ca>

Prev by Date: Re: RPM spec file
Next by Date: Re: RPM spec file
Index(es):
- Chronological
- Thread