Issue 6518 - Slapd-ldap proxy between replica and mirror
Summary: Slapd-ldap proxy between replica and mirror
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: backends (show other issues)
Version: 2.4.21
Hardware: All All
: --- normal
Target Milestone: 2.5.1
Assignee: Ondřej Kuzník
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-13 08:06 UTC by udorta@iac.es
Modified: 2021-02-08 17:51 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description udorta@iac.es 2010-04-13 08:06:21 UTC
Full_Name: Ubay Dorta
Version: 2.4.21
OS: Suse Linux Enterprise Server 10 SP2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (161.72.9.46)


We have problems when we introduce a back-ldap proxy server between a
delta-syncrepl server and a mirror configuration of two servers.

The modifications through the replica server (with chaining configuration) over
the first mirror server are made without problems. The problem appears when we
introduce a back-ldap proxy between replica and the two servers in mirror mode.

First Scenario:
---------------------

A delta syncrepl server replicating from the first server of a mirror.

IPs: delta syncrepl (192.168.1.5), mirror server 1 (192.168.1.10), mirror server
2 (192.168.1.20)


replica slapd.conf

#####################
#  Chaining configuration #
#####################
overlay chain
chain-uri               "ldap://mirror1:389"

chain-idassert-bind     bindmethod="simple"
                        binddn="cn=replicator,dc=example,dc=com"
                        credentials="secret"
                        mode="self"
chain-return-error      TRUE

##########
#  Replica  #
##########
database bdb
suffix "dc=example,dc=com"
rootdn "cn=Administrator,dc=example,dc=com"
rootpw "secret"
checkpoint 1024 5
cachesize 10000
index objectClass,uidNumber,gidNumber eq
index member,mail eq,pres
index cn,displayname,uid,sn,givenname sub,eq,pres
overlay ppolicy
ppolicy_default "cn=Default Password Policy,dc=example,dc=com"
ppolicy_forward_updates
ppolicy_hash_cleartext
overlay memberof




##################
# Syncrepl directives #
##################
syncrepl  rid=001
          provider=ldap://mirror1:389

          type=refreshAndPersist
          retry="60 +"
          searchbase="dc=example,dc=com"
          filter="(objectclass=*)"
          scope=sub
          attrs="*"
          schemachecking=on
          binddn="cn=replicator,dc=example,dc=com"
          bindmethod=simple
          credentials=secret
          sizelimit=unlimited
          logbase="cn=accesslog"
          logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
          syncdata=accesslog

# Refer updates to the master
updateref               ldap://mirror1:389

-------------------------
-------------------------


slapd.conf  of mirror server #1
-------------------------------------------
# Global section                                                                
                                            
serverID 1                                                                      
                                            

moduleload memberof                    

access to dn.base=""                                    
        by * read                                       

access to dn.base="cn=Subschema"
        by * read              

access to attrs=userPassword,userPKCS12
        by self write                 
        by dn.base="cn=replicator,dc=example,dc=com" read
        by * auth                                  

access to attrs=shadowLastChange
        by self write          
        by * read              

# Give the replica DN unlimited read access.  This ACL needs to be
# merged with other ACL statements, and/or moved within the scope
# of a database.  The "by * break" portion causes evaluation of  
# subsequent rules.  See slapd.access(5) for details.            

access to *                                                      
        by dn.base="cn=replicator,dc=example,dc=com" read             
        by * break                                               

access to *
        by * read

# Load the accesslog overlay
moduleload accesslog.la    

#Load the syncprov overlay
moduleload syncprov.la   


# Accesslog database definitions
database bdb                   

monitoring off

suffix cn=accesslog
rootdn cn=accesslog                                                   
index default eq                                                      
index entryCSN,objectClass,reqEnd,reqResult,reqStart                  

overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE

# Let the replica DN have limitless searches
limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited


#######################################################################
# BDB database definitions                                            
#######################################################################

database bdb

monitoring off


suffix "dc=example,dc=com"
rootdn "cn=Administrator,dc=example,dc=com"
rootpw "secret"                      
checkpoint 1024 5                                            
cachesize 10000                                              
index objectClass,uidNumber,gidNumber eq                     
index member,mail eq,pres                                    
index cn,displayname,uid,sn,givenname sub,eq,pres            
overlay ppolicy
ppolicy_default "cn=Default Password Policy,dc=example,dc=com"
ppolicy_hash_cleartext
overlay memberof

# Habilitar authz-policiy
authz-policy to

index entryCSN eq
index entryUUID eq

# syncrepl Provider for primary db
overlay syncprov
syncprov-checkpoint 1000 60

# accesslog overlay definitions for primary db
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
logpurge 07+00:00 01+00:00

# Let the replica DN have limitless searches
limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
####################################################

# MirrorMode - Syncrepl directive
syncrepl        rid=001
                provider=ldap://mirror2:389
                bindmethod=simple
                binddn="cn=Administrator,dc=example,dc=com"
                credentials=secret

                searchbase="dc=example,dc=com"
                schemachecking=on
                type=refreshAndPersist
                retry="60 +"
mirrormode on

---------------
---------------

In the mirror servers we have set the attribute authzTo for the replicator dn:

ldapsearch -x -b 'cn=replicator,dc=example,dc=com' -H ldap://mirror1:389 -D
'cn=Administrator,dc=example,dc=com' -w secret authzTo

# replicator, example.com
dn: cn=replicator,dc=example,dc=com
authzTo: ldap:///dc=example,dc=com??sub?(objectClass=person)


When we launch the following modification through the replica:
ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D
'uid=user,ou=people,dc=example,dc=com' -W
Enter LDAP Password:
modifying entry "uid=user,ou=people,dc=example,dc=com"

In the mirror server we get:

ldap-mirror1[2649]: conn=1002 op=2 PROXYAUTHZ
dn="uid=user,ou=people,dc=example,dc=com"
ldap-mirror1[2649]: conn=1002 op=2 MOD
dn="uid=user,ou=people,dc=example,dc=com"
ldap-mirror1[2649]: conn=1002 op=2 MOD attr=userPassword
ldap-mirror1[2649]: conn=1002 op=2 RESULT tag=103 err=0 text=

Therefore modifying through the replica server is possible with the chaining
configuration.

Second sceneario
--------------------------
The problem appears when we introduce the back-ldap proxy server to set the high
availability feature that provides the mirror mode.

IPs:
-----
192.168.1.5 -> delta syncrepl

192.168.1.10 -> Back-ldap proxy
192.168.1.20 -> Mirror mode server 1  
192.168.1.30 -> Mirror mode server 2



back-ldap proxy slapd.conf:

database        ldap
suffix          "dc=example,dc=com"
uri             "ldap://mirror1:389 ldap://mirror2:389"
rootdn          "cn=Administrator,dc=example,dc=com"

overlay ppolicy


Launching the modification to the proxy, it works:

ldapmodify -x -H ldap://proxy:389 -f pass1_user.ldif -D
'uid=user,ou=people,dc=example,dc=com' -W
Enter LDAP Password:
modifying entry "uid=udg77530,ou=people,dc=example,dc=com"

The /var/log/messages of proxy and mirror shows the following:

ldap-proxy[4051]: conn=1000 fd=8 ACCEPT from IP=192.168.1.5:42921
(IP=192.168.1.10:389)
ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com"
method=128
ldap-mirror1[3438]: conn=1015 fd=19 ACCEPT from IP=192.168.1.10:18103
(IP=192.168.1.20:1389)
ldap-mirror1[3438]: conn=1015 op=0 BIND dn="" method=128
ldap-mirror1[3438]: conn=1015 op=0 RESULT tag=97 err=0 text=
ldap-mirror1[3438]: conn=1015 op=1 SRCH
base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0
filter="(objectClass=*)"
ldap-mirror1[3438]: conn=1015 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
ldap-mirror1[3438]: conn=1016 fd=20 ACCEPT from IP=192.168.1.10:18104
(IP=192.168.1.20:1389)
ldap-mirror1[3438]: conn=1016 op=0 BIND
dn="uid=user,ou=people,dc=example,dc=com" method=128
ldap-mirror1[3438]: conn=1016 op=0 BIND
dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0
ldap-mirror1[3438]: conn=1016 op=0 RESULT tag=97 err=0 text=
ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com"
mech=SIMPLE ssf=0
ldap-mirror1[3438]: conn=1015 op=2 SRCH
base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0
filter="(objectClass=*)"
ldap-mirror1[3438]: conn=1015 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
ldap-proxy[4051]: conn=1000 op=0 RESULT tag=97 err=0 text=
ldap-proxy[4051]: conn=1000 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com"
ldap-proxy[4051]: conn=1000 op=1 MOD attr=userPassword
ldap-mirror1[3438]: conn=1015 op=3 SRCH
base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0
filter="(objectClass=*)"
ldap-mirror1[3438]: conn=1015 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
ldap-mirror1[3438]: conn=1016 op=1 MOD
dn="uid=user,ou=people,dc=example,dc=com"
ldap-mirror1[3438]: conn=1016 op=1 MOD attr=userPassword
ldap-mirror1[3438]: conn=1016 op=1 RESULT tag=103 err=0 text=
ldap-proxy[4051]: conn=1000 op=1 RESULT tag=103 err=0 text=
ldap-proxy[4051]: conn=1000 op=2 UNBIND
ldap-mirror1[3438]: conn=1016 op=2 UNBIND
ldap-mirror1[3438]: conn=1016 fd=20 closed
ldap-proxy[4051]: conn=1000 fd=8 closed


But when the modification is made through the replica server we get the error:


ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D
'uid=user,ou=people,dc=example,dc=com' -W
Enter LDAP Password:
modifying entry "uid=user,ou=people,dc=rexample,dc=com"
ldap_modify: unknown result code (123)


ldap-proxy[3688]: daemon: activity on 1 descriptor
ldap-proxy[3688]: daemon: activity on:
ldap-proxy[3688]:  12r
ldap-proxy[3688]:
ldap-proxy[3688]: daemon: read active on 12
ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
ldap-proxy[3688]: connection_get(12)
ldap-proxy[3688]: connection_get(12): got connid=1001
ldap-proxy[3688]: connection_read(12): checking for input on id=1001
ldap-proxy[3688]: op tag 0x66, time 1271064513
ldap-proxy[3688]: conn=1001 op=2 do_modify
ldap-proxy[3688]: conn=1001 op=2 do_modify: dn
(uid=user,ou=people,dc=example,dc=com)
ldap-proxy[3688]: => get_ctrls
ldap-proxy[3688]: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (noncritical)
ldap-proxy[3688]: parseProxyAuthz: conn 1001
authzid="dn:uid=user,ou=people,dc=example,dc=com"
ldap-proxy[3688]: slap_sasl_getdn: conn 1001
id=dn:uid=user,ou=people,dc=example,dc=com [len=38]
ldap-proxy[3688]: >>> dnNormalize: <uid=user,ou=people,dc=example,dc=com>
ldap-proxy[3688]: <<< dnNormalize: <uid=user,ou=people,dc=example,dc=com>
ldap-proxy[3688]: ==>slap_sasl2dn: converting SASL name
uid=user,ou=people,dc=example,dc=com to a DN
ldap-proxy[3688]: <==slap_sasl2dn: Converted SASL name to <nothing>
ldap-proxy[3688]: parseProxyAuthz: conn=1001
"uid=user,ou=people,dc=example,dc=com"
ldap-proxy[3688]: ==>slap_sasl_authorized: can cn=replicator,dc=example,dc=com
become uid=user,ou=people,dc=example,dc=com?
ldap-proxy[3688]: <== slap_sasl_authorized: return 48
ldap-proxy[3688]: <= get_ctrls: n=1 rc=123 err="not authorized to assume
identity"
ldap-proxy[3688]: send_ldap_result: conn=1001 op=2 p=3
ldap-proxy[3688]: send_ldap_result: err=123 matched="" text="not authorized to
assume identity"
ldap-proxy[3688]: send_ldap_response: msgid=3 tag=103 err=123
ldap-proxy[3688]: conn=1001 op=2 RESULT tag=103 err=123 text=not authorized to
assume identity
ldap-proxy[3688]: conn=1001 op=2 do_modify: get_ctrls failed
ldap-proxy[3688]: daemon: activity on 1 descriptor
ldap-proxy[3688]: daemon: activity on:
ldap-proxy[3688]:
ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL


The file pass1_user.ldif has:


dn: uid=user,ou=people,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: ####CRYPT PASSWORD####

Thanks
Comment 1 ando@openldap.org 2010-04-14 12:39:28 UTC
changed notes
moved from Incoming to Software Enhancements
Comment 2 ando@openldap.org 2010-04-14 19:19:35 UTC
> We have problems when we introduce a back-ldap proxy server between a
> delta-syncrepl server and a mirror configuration of two servers.
>
> The modifications through the replica server (with chaining configuration)
> over
> the first mirror server are made without problems. The problem appears
> when we
> introduce a back-ldap proxy between replica and the two servers in mirror
> mode.

I've already fixed the bit of this issue related to not being able to
process ordered attributes in proxies (ITS#6516).  This is required to
retrieve attributes authzFrom and authzTo, used by the proxy authorization
process.

The rest of your issue is related to the fact that the slave uses
proxyAuthz to propagate the modify request to the updateref server.  When
this is a proxy, it needs to add proxyAuthz itself to correctly proxy the
operation to the master.  But two proxyAuthz controls are not allowed.

You'd need to use distributed procedures, which are not implemented in
OpenLDAP.  A distributed operation would then consist in an extended
operation that wraps the original one into a new request, with its own
controls.  At this point, proxyAuthz could apply incrementally at each
layer.

I'd treat your ITS as yet another request to implement distributed
procedures.

p.

Comment 3 OpenLDAP project 2014-08-01 21:04:54 UTC
needs distproc
Comment 4 Quanah Gibson-Mount 2021-01-14 18:09:54 UTC
Requires development of distributed procedures, feature request.
Comment 5 Quanah Gibson-Mount 2021-02-01 17:25:10 UTC
partial fix, more incoming:

Commits: 
  • ac70b01b 
by Ondřej Kuzník at 2021-02-01T16:43:06+00:00 
ITS#6518 When using proxyauthz, replace existing control - (async)meta


Commits: 
  • 1aecfe0b 
by Ondřej Kuzník at 2021-02-01T17:22:35+00:00 
ITS#6518 Only remove proxyauthz control if we generated one ourselves