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

Re: Using Replication Slave For Authentication

On Apr 20, 2010, at 1:50 PM, Sergiy Stepanenko wrote:

> On 04/20/2010 10:49 AM, Ariel wrote:
>> On Apr 20, 2010, at 12:20 PM, Sergiy Stepanenko wrote:
>> 
>>> On 04/20/2010 06:12 AM, Ariel wrote:
>>>> I have inherited an openldap server (2.4.9) and have set about to making it a bit more fault tolerant.  So I have added a syncrepl slave and everything seems to work fine.  It pulls down the whole ldap tree and stays in sync in real time with type=refreshAndPersist.  I can use command line tools to very that it has all the information from the original master server using a command like this:
>>>> 
>>>> ldapsearch -xLL -H ldaps://ldap2.domain.com/ -b "dc=domain,dc=com" -D "cn=admin,dc=domain,dc=com" -W
>>>> 
>>>> My problem however is that when I try to authenticate users against the slave server, it does not work.  All attempts fail.  Also when I use ApacheDS (graphical LDAP browser) to view its contents, it only shows the Root DSE and none of the child objects like cn=config or any of the users or any of that.  I can use ApacheDS fine to view and modify everything on the master server though.
>>>> 
>>>> The slapd.conf config files between the two are exactly the same (except one is declared as sync master and one as slave), the password hashes are successfully replicated to the slave as I can see with ldapsearch, but I have no idea how to debug why it won't authenticate users.  For reference, here is my syncrepl config section (in slapd.conf) on the slave:
>>>> 
>>>> syncrepl rid=123
>>>>          provider=ldaps://ldap1.domain.com:636
>>>>          type=refreshAndPersist
>>>>          searchbase="dc=domain,dc=com"
>>>>          filter="(objectClass=*)"
>>>>          scope=sub
>>>>          schemachecking=off
>>>>          bindmethod=simple
>>>>          binddn="uid=syncuser,ou=People,dc=domain,dc=com"
>>>>          credentials=syncpassword
>>>> 
>>>> and on the master server:
>>>> 
>>>> moduleload  syncprov.la
>>>> overlay syncprov
>>>> syncprov-checkpoint 100 10
>>>> syncprov-sessionlog 100
>>>> 
>>>> As a failover/backup server seems extremely prudent especially on the ancient hardware we have running these things, I really want to get this to work properly.  Perhaps even later doing a round-robin style load balancing between the two or what have you.
>>>> 
>>>> I have no idea how to debug this, any help would be greatly appreciated!
>>>> 
>>>> -a
>>>> 
>>> 
>>> Hi
>>> 
>>> If you can show ACL on master and slave it will help to understand why you cannot auth users against slave. From what you described, it looks like slave has either access restriction to userPassword and base DN for users or access fails. I also never noticed any TLS certificates configuration mentioned.
>>> 
>>> --
>>> Sergiy Stepanenko
>>> Systems Administrator
>>> Information Technology Services
>>> University of Saskatchewan
>>> -----------------------------------
>>> phone:    (306) 966-2762
>>> email:sergiy.stepanenko@usask.ca
>> 
>> 
>> Hey, thanks for the reply!  I can only see the ACL on the slave using ldapsearch from CLI (every user I have tested has seen exactly only the information they are allowed), and all privileges seem to be in working order.
>> 
>> When I use ApacheDS (or any other graphical client) using the same users, I only get the Root DSE which describes what Schema are loaded.  Also, we do not use TLS, just ldaps protocol with simple authentication.  All clients have `TLS_REQCERT     allow` in their /etc/ldap/ldap.conf so a self signed ssl certificate on the server will work.
>> 
> Make sure to use port 663 for SSL connection in ApacheDS, also check what bas DN is set up in Apache (Browser Options)
>> Connecting and authenticating from ldapsearch works, but no other mechanisms will work.
>> 
>> I'm probably missing something so simple it would make me cry.  Perhaps I should set the loglevel to something ridiculously high and see what it says?
> Try loglevel acl conns for starters and look at Apache search log. If it has been an error it would be there.
>> 
>> -a
> 
> Read log ldap or syslog where ever you point slapd output. I suspect that ldap appliances connect->bind->authenticate->access as self, but GUI clients fail to authenticate and resort in anonymous access level which normally looks like access to DSE entry only.
> 
> -- 
> Sergiy Stepanenko
> Systems Administrator
> Information Technology Services
> University of Saskatchewan
> -----------------------------------
> phone:    (306) 966-2762
> email:sergiy.stepanenko@usask.ca

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