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

ldap-back usage



I have a new requirement to proxy requests to a partner's LDAP (3rd
party), based on organization.  These request come into my slave
servers.  The slaves are chaining referrals to a single master (for my
company's users).  

I have set up the proxy using back-ldap, along with the rewrite/map
overlay (to massage the domain and map attrs).  All requests to the
partner's LDAP will be read-only.  

First question:  Is back-ldap the correct approach for this?  Is there a
better way? This set-up is fairly simple and it 'seems' to be working.  

Second question:  If this is the way, are there any rules that apply as
far as where the chain overlay (order) should appear in slapd.conf?


Here's a portion my slave slapd.conf (with openldap 2.3.43):

modulepath      /usr/lib/openldap
moduleload      ppolicy.la
moduleload      rwm.la

#===================================================================
# chain to master for updates
overlay		chain

chain-uri		ldap://172.1.1.1
chain-idassert-bind bindmethod="simple"
 
binddn="cn=ldapChain,o=myorg,dc=mycompany,dc=net"
                        credentials="chainsecret"
                        mode="self"

chain-max-depth         2
chain-return-error      TRUE
chain-rebind-as-user    TRUE

#===================================================================
# back-ldap (partner database)

database	ldap
uri		"ldap://172.2.2.2";
suffix	"o=partnerorg,dc=mycompany,dc=net"
lastmod off

#===================================================================
# Rewrite/map overlay
overlay         rwm

rwm-suffixmassage "o=partnerorg,dc=mycompany,dc=net"
"o=partnerorg,dc=partner,dc=net"
rwm-map objectclass top top
rwm-map objectclass person person
rwm-map objectclass posixAccount posixAccount
rwm-map attribute DiagAccessLevel gecos
rwm-map attribute DiagGroup description
<etc, snip>

#===================================================================
# Local database definitions

database        bdb
suffix          "dc=mycompany,dc=net"
rootdn          "cn=ldaproot,dc=mycompany,dc=net"
rootpw          bigsecret

lastmod         on
directory       /var/lib/ldap
mode            0660
checkpoint 100 30

# Indices to maintain for this database
index objectclass,entryCSN,entryUUID    eq,pres
<etc>

#-------------------------------------------------------------------
# ACLs for this database
access to attrs=userPassword
        by self write
        by group.exact="cn=administrators,o=myorg,dc=mycompany,dc=net"
write
        by dn.sub="o=partnerorg,dc=partner,dc=net" none
        by anonymous auth
        by * none

access to *
        by group.exact="cn=administrators,o=myorg,dc=mycompany,dc=net"
write
        by dn.sub="o=partnerorg,dc=partner,dc=net" none
        by anonymous none
        by * read

#===================================================================
syncrepl        rid=004
                type=refreshAndPersist
                provider=ldap://172.1.1.1
                retry="30 10 300 3"
                searchbase="dc=mycompany,dc=net"
                filter="(objectClass=*)"
                scope=sub
                schemachecking=off
                bindmethod=simple
                binddn="cn=syncRepl,o=myorg,dc=mycompany,dc=net"
                credentials="secretsync"

updateref       ldap://172.1.1.1


Thanks in advance,
John



This message is confidential to Prodea Systems, Inc unless otherwise indicated 
or apparent from its nature. This message is directed to the intended recipient 
only, who may be readily determined by the sender of this message and its 
contents. If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient:(a)any dissemination or copying of this message is strictly 
prohibited; and(b)immediately notify the sender by return message and destroy 
any copies of this message in any form(electronic, paper or otherwise) that you 
have.The delivery of this message and its information is neither intended to be 
nor constitutes a disclosure or waiver of any trade secrets, intellectual 
property, attorney work product, or attorney-client communications. The 
authority of the individual sending this message to legally bind Prodea Systems  
is neither apparent nor implied,and must be independently verified.