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

RE: Slave not able to update master pwdFailureTime via chain.

Hi,

On Mon, 31 Mar 2014, serpent6877 wrote:

Anyone else have an answer for this?


did you try to give your chaining user manage privileges on the target server:

  olcAccess: to attrs=userPassword by dn.base="cn=replication,dc=test,dc=net" manage
  olcAccess: to * by dn.base="cn=replication,dc=test,dc=net" manage

I have not gone through all you other settings again but I think this was the piece missing in your setup.

Try above for starters and then update us on the errors you are getting and your exact configuration.

Greetings
Christian





Thanks,
Brad

-------- Original message --------
From: Brad dameron <serpent6877@hotmail.com>
Date:03/24/2014  8:36 AM  (GMT-08:00)
To: Esteban Pereira <esteban.pereira@gepsit.fr>,openldap-technical@openldap.org
Subject: RE: Slave not able to update master pwdFailureTime via chain.


From what I read I need to setup authzTo. But having problems understanding what I need to set in the slaps.conf and on the allowed user.

-------- Original message --------
From: Esteban Pereira <esteban.pereira@gepsit.fr>
Date:03/20/2014  10:55 AM  (GMT-08:00)
To: Brad dameron <serpent6877@hotmail.com>,openldap-technical@openldap.org
Subject: Re: Slave not able to update master pwdFailureTime via chain.

I've never configured this kind of architecture, but as far as I know the
ppolicy, I think my first thought configuring this would have been to not
rebind as user because the attribute modified is an operational one which
need the manage right (not sure about that)

So I should have configured this with the replication user with manage
right and without rebinding as a user when chaining to the master.

Hope this help


On Thu, Mar 20, 2014 at 6:14 PM, Brad dameron <serpent6877@hotmail.com>wrote:


I understand what you are saying. But this is what the
ppolicy_forward_updates says:

 ppolicy_forward_updates
              Specify that policy state changes that result from Bind operations (such as recording
              failures, lockout, etc.) on a consumer should be forwarded to  a  master  instead  of
              being  written directly into the consumer?s local database. This setting is only use?
              ful on a replication consumer, and also requires  the  updateref  setting  and  chain
              overlay to be appropriately configured.

So when a password failure occurs "pwdFailureTime" it relays it to the master as the user doing a MOD
from what I have seen in my logs. And thus the user doesn't have access to modify this attribute.

Brad



------------------------------
Date: Thu, 20 Mar 2014 12:13:02 +0100
Subject: Re: Slave not able to update master pwdFailureTime via chain.
From: esteban.pereira@gepsit.fr
To: serpent6877@hotmail.com
CC: openldap-technical@openldap.org


Hi Brad,

pwdFailureTime is an operational attribute, I don't think any user can
modify it on any instance. May be you should try to modify it on the master
to see if it comes from this assumption.

Esteban


On Thu, Mar 20, 2014 at 11:33 AM, Brad dameron <serpent6877@hotmail.com>wrote:

OpenLDAP 2.4.23-26 on CentOS 5. I am trying to get the pwdFailureTime
updated on the master when the slave recieves a password failure. Here is
my config. It's pretty simple and basic. No TLS.

Master:

access to attrs=userPassword
        by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write
        by dn.exact="cn=replication,dc=test,dc=net" read
        by self         write
        by anonymous    auth
        by *            none
access to *
        by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write
        by dn.exact="cn=replication,dc=test,dc=net" write
        by self         write
        by users        read
        by anonymous    read
        by *            none



Slave:

overlay chain
chain-uri               ldap://172.16.0.84:389
chain-rebind-as-user    TRUE
chain-idassert-bind     bindmethod=simple
                        binddn="cn=replication,dc=test,dc=net"
                        credentials="MyPasswd"
                        mode="self"
chain-return-error      TRUE

# Password Policy
overlay ppolicy
ppolicy_default "cn=default,ou=Policies,dc=test,dc=net
ppolicy_use_lockout
ppolicy_forward_updates


# Slave Replication
syncrepl rid=101
        provider=ldap://172.16.0.84:389
        type=refreshAndPersist
        interval=00:00:01:00
        retry="60 10 300 +"
        searchbase="dc=test,dc=net"
        schemachecking=off
        bindmethod=simple
        binddn="cn=replication,dc=test,dc=net"
        credentials="MyPasswd"
updateref               "ldap://172.16.0.84:389";



I see the connection on the master but it gives a permission error:


Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD
dn="cn=testuser,ou=People,dc=test,dc=net"
Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD
attr=pwdFailureTime
Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 RESULT tag=103
err=50 text=


I read that you maybe need authzTo added to the binddn for the chain? Or
is this only for TLS?

I tried adding this ldif:

dn: cn=replication,dc=test,dc=net
changetype: modify
add: authzTo
authzTo: *

And even set the:

chain-idassert-authzFrom "*"

in the chain. But it always gives me the error code 50 not enough
permissions. I believe it is supposed to give access to the user to MOD the
pwdFailureTime tribute knowing it is coming from a relay. But I can't find
very specific docs on this or see what is wrong. Any help apreciated.

Thanks,
Brad







--
Christian Kratzer                   CK Software GmbH
Email:   ck@cksoft.de               Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0       D-71126 Gaeufelden
Fax:     +49 7032 893 997 - 9       HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843           Geschaeftsfuehrer: Christian Kratzer
Web:     http://www.cksoft.de/