Hello to the list,
I'm trying to configure the slapd-meta OpenLDAP backend on an online cn=config configuration with no luck. Slapd version is 2.4.39 (the maximum I can achieve on the target machines building from vanilla source). The documentation is clear but too concise for me so I will try to explain what I'm trying to do to see if there is anybody that can help me.
Currently I have 3 slapd servers that share a common root for the DIT, i.e.:
dc=loc1,dc=root dc=loc2,dc=root dc=loc3,dc=root
What I would like to achieve is to obtain a fourth server that contains the previous trees, along with its own tree, i.e. a server that contains:
dc=loc0,dc=root (locally hosted data) dc=loc1,dc=root (coming from the first server, chasing referrals) dc=loc2,dc=root (coming from the second server, chasing referrals) dc=loc3,dc=root (coming from the third server, chasing referrals)
this way, all the clients connecting to this server will be able to retrieve data also from the other three remote servers.
As far as I understood, I only need to configure the "loc0" server to access the other three servers and get the data to serve to clients.
I have already configured the fourth server with its local DIT and this is the configuration:
# cat 'cn=config.ldif'
dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid structuralObjectClass: olcGlobal creatorsName: cn=config olcServerID: 1 olcThreads: 32 olcToolThreads: 8 olcRequires: LDAPv3 olcConnMaxPendingAuth: 100 olcTLSCACertificateFile: /etc/ssl/certs/my_ca_cert.pem olcTLSCertificateFile: /etc/ssl/certs/this-host_x509_cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/this-host_x509_key.key olcTLSVerifyClient: try olcTimeLimit: 600 olcLogLevel: stats2 sync [...]
# cat 'cn=module{0}.ldif'
dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}accesslog structuralObjectClass: olcModuleList [...]
Schema files are the following:
cn={0}core.ldif cn={1}cosine.ldif cn={2}nis.ldif cn={3}inetorgperson.ldif cn={4}dyngroup.ldif cn={5}kerberos.ldif
# cat 'olcDatabase={1}hdb.ldif'
dn: olcDatabase={1}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=loc0,dc=root olcAccess: {0}to attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn =admin,dc=loc0,dc=root" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=admin,dc=loc0,dc=root" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=loc0,dc=root olcRootPW:: xxxxxxxxxxxxxxxxxxxx olcDbCacheSize: 10000 olcDbCheckpoint: 512 10 olcDbConfig: {0}set_cachesize 0 524288000 1 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE olcDbIDLcacheSize: 30000 olcDbIndex: default pres,eq [...] structuralObjectClass: olcHdbConfig olcSyncrepl: {0}rid=0 provider=ldap://second-host.loc0.root bindmethod=s imple binddn="cn=admin,dc=loc0,dc=root" credentials=xxxxxx searchbase="dc=loc0,dc=root" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObj ect)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syn cdata=accesslog starttls=yes olcMirrorMode: TRUE [...]
On top of this DB I have the "syncprov" and the "accesslog" overlays configured (these are two servers in "MirrorMode", configured following the OpenLDAP admin documentation). I believe this DB is the ones containing the actual "loc0" DIT data...
Then I have the accesslog DB for the replica (with the syncprov overlay on top):
# cat 'olcDatabase={2}hdb.ldif'
dn: olcDatabase={2}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=loc0,dc=root olcDbConfig: {0}set_cachesize 0 524288000 1 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart [...]
On top of this environment I start loading the needed modules with this LDIF file:
version: 1
dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: back_ldap - add: olcModuleLoad olcModuleLoad: back_meta - add: olcModuleLoad olcModuleLoad: rwm
and it seems I'm able to load the new modules without errors into the configuration, thus I obtain:
# cat 'cn=module{0}.ldif'
dn: cn=module{0} structuralObjectClass: olcModuleList objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}accesslog olcModuleLoad: {3}back_ldap olcModuleLoad: {4}back_meta olcModuleLoad: {5}rwm [...]
Now I try to load the slapd-meta directives into a new database using this LDIF:
version: 1
dn: olcDatabase={3}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {3}meta olcSuffix: dc=root olcDbURI: "ldap://server-loc1.loc1.root/dc=loc1,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand olcDbURI: "ldap://server-loc2.loc2.root/dc=loc2,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand olcDbURI: "ldap://server-loc3.loc3.root/dc=loc3,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc3,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand
but I obtain an error that sticks me trying various combinations without success:
# ldapadd -Y EXTERNAL -H ldapi:/// -f slapd-META-DB-CREATION.ldif
SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase={3}meta,cn=config" ldap_add: Object class violation (65) additional info: attribute 'olcDbURI' not allowed
and:
# tail /var/log/openldap/slapd.log
Nov 9 19:47:17 server01 slapd[32392]: conn=1025 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:47:29 server01 slapd[32392]: conn=1052 op=2 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 Nov 9 19:49:47 server01 slapd[32392]: conn=1327 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:52:17 server01 slapd[32392]: conn=1628 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:54:46 server01 slapd[32392]: conn=1929 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:57:07 server01 slapd[32392]: Entry (olcDatabase={3}meta,cn=config), attribute 'olcDbURI' not allowed
Into the slapd-meta documentation the "URI" directive is mentioned but the "DbURI" seems to raise a "better error", in fact if I try to modify the above LDIF file using "URI" I obtain:
SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase={3}meta,cn=config" ldap_add: Undefined attribute type (17) additional info: olcUri: attribute type undefined
Moreover, it is not stated into the slapd-meta docs that the slapd-ldap backend is needed by slapd-meta but, anyway, I think its needed because if I try to load the slapd-meta alone it raises an error (I don't remember exactly which one).
At this point I'm stuck to this error and I wasn't able to find any hint on the web to solve this :( The examples I was able to find were related with the static slapd.conf configuration, I counldn't find any "full" configuration example using the cn=config. I'm wondering if I should create a "cn=root" actual DB first and then link the sub-DITs to it, or, maybe, add some other overlay... I really can't understand how it should work :(
Can please anybody help me? Thank you very much
--On Tuesday, November 17, 2015 7:57 PM +0200 Fr3ddie fr3ddie@fr3ddie.it wrote:
Il 10/11/2015 13:06, Fr3ddie ha scritto:
Hello to the list,
Nobody has any hint?
I suggest reading the code, because the answer is actually fairly obvious if you look at slapd-meta/config.c:
"NAME 'olcMetaTargetConfig' " "MUST ( olcMetaSub $ olcDbURI ) "
Yet you aren't using the olcMetaTargetConfig objectClass in your entry.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Il 18/11/2015 02:32, Quanah Gibson-Mount ha scritto:
--On Tuesday, November 17, 2015 7:57 PM +0200 Fr3ddie fr3ddie@fr3ddie.it wrote:
Il 10/11/2015 13:06, Fr3ddie ha scritto:
Hello to the list,
Nobody has any hint?
I suggest reading the code, because the answer is actually fairly obvious if you look at slapd-meta/config.c:
"NAME 'olcMetaTargetConfig' " "MUST ( olcMetaSub $ olcDbURI ) "Yet you aren't using the olcMetaTargetConfig objectClass in your entry.
Thank you very much for your help Quanah. Please excuse the delay, I have not been able to access the servers to perform other tests during this period...
I tried your suggestion and read the code, as much as I could have been able to.
Then I modified the ldif file in order to create the meta-DB and its sub-DBs containing the URIs of the target servers (if I correctly understood):
version: 1
dn: olcDatabase={3}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {3}meta olcSuffix: dc=loc1,dc=root olcSuffix: dc=loc2,dc=root olcSuffix: dc=loc3,dc=root olcDbConnTtl: 240 olcDbRebindAsUser: FALSE
dn: olcMetaSub={0}uri,olcDatabase={3}meta,cn=config objectClass: olcConfig objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbUri: "ldap://server-loc1.loc1.root/dc=loc1,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxxxxx starttls=yes tls_reqcert=demand
dn: olcMetaSub={1}uri,olcDatabase={3}meta,cn=config objectClass: olcConfig objectClass: olcMetaTargetConfig olcMetaSub: {1}uri olcDbUri: "ldap://server-loc2.loc2.root/dc=loc2,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxxxxx starttls=yes tls_reqcert=demand
[...]
Modifying the ldif file as such I'm able to load it into the DB with no complains by slapd. The problem is that I'm still unable to see the remote DITs using, e.g., Apache Directory Studio; the log on the server reports this:
Mar 1 12:40:08 server-loc0 slapd[1210]: conn=149188 op=9 meta_search_dobind_init[0] mc=0xa119b38: non-empty dn with empty cred; binding anonymously
On the target server the log reports nothing. It seems slapd is ignoring my configuration for authentication to remote targets (olcDbIdAssertBind): what can I try now? Is it possible that this is a bug or, instead, it's still my misconfiguration?
Thank you again for your help
--On Tuesday, March 01, 2016 7:23 PM +0100 Fr3ddie fr3ddie@fr3ddie.it wrote:
Il 18/11/2015 02:32, Quanah Gibson-Mount ha scritto:
--On Tuesday, November 17, 2015 7:57 PM +0200 Fr3ddie fr3ddie@fr3ddie.it wrote:
Il 10/11/2015 13:06, Fr3ddie ha scritto:
Hello to the list,
Nobody has any hint?
I suggest reading the code, because the answer is actually fairly obvious if you look at slapd-meta/config.c:
"NAME 'olcMetaTargetConfig' " "MUST ( olcMetaSub $ olcDbURI ) "Yet you aren't using the olcMetaTargetConfig objectClass in your entry.
Thank you very much for your help Quanah. Please excuse the delay, I have not been able to access the servers to perform other tests during this period...
I tried your suggestion and read the code, as much as I could have been able to.
Then I modified the ldif file in order to create the meta-DB and its sub-DBs containing the URIs of the target servers (if I correctly understood):
version: 1 dn: olcDatabase={3}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {3}meta olcSuffix: dc=loc1,dc=root olcSuffix: dc=loc2,dc=root olcSuffix: dc=loc3,dc=root
I've never used meta backend, but the above doesn't look valid to me (multiple suffixes). The man page shows a single suffix, with URI directives for additional representations of the DB.
dn: olcMetaSub={0}uri,olcDatabase={3}meta,cn=config objectClass: olcConfig objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbUri: "ldap://server-loc1.loc1.root/dc=loc1,dc=root" olcDbIdAssertBind: bindmethod=simplebinddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxxxxx starttls=yes tls_reqcert=demand
dn: olcMetaSub={1}uri,olcDatabase={3}meta,cn=config objectClass: olcConfig objectClass: olcMetaTargetConfig olcMetaSub: {1}uri olcDbUri: "ldap://server-loc2.loc2.root/dc=loc2,dc=root" olcDbIdAssertBind: bindmethod=simplebinddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxxxxx starttls=yes tls_reqcert=demand
The slapd-meta test suit shows an additional parameter, mode=self, being set. That may or may not help. ;)
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
On 04/03/2016 20:33, Quanah Gibson-Mount wrote:
Then I modified the ldif file in order to create the meta-DB and its sub-DBs containing the URIs of the target servers (if I correctly understood):
version: 1 dn: olcDatabase={3}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {3}meta olcSuffix: dc=loc1,dc=root olcSuffix: dc=loc2,dc=root olcSuffix: dc=loc3,dc=rootI've never used meta backend, but the above doesn't look valid to me (multiple suffixes). The man page shows a single suffix, with URI directives for additional representations of the DB.
[OMISSIS] The slapd-meta test suit shows an additional parameter, mode=self, being set. That may or may not help. ;)
Hello,
I performed further testing but I have no good news :(
about the multiple "olcSuffix" I'm inserting into the "olcDatabase={3}meta" (I don't know where I'm supposed to put multiple entries of the olcSuffix except the olcDatabase since it is an attribute of olcDatabaseConfig objectclass), I configured the meta backend with just one DB suffix and just one target, in order to keep it easy and avoid, as much as possible, my configuration mistakes. I believe this is the configuration I would have been supposed to do in order to properly configure the slapd-/ldap/ backend (?).
Moreover, although I tried both "mode=self", "mode=none" and "authzID="dn:cn=admin,dc=loc1,dc=root"" (and "flags=non-prescriptive" too, while without the "authzID" of course), the result is the same.
Logs from the slapd-meta equipped server report (I'm simply trying to directly access the admin dn):
Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11 SRCH base="cn=admin,dc=loc1,dc=root" scope=0 deref=0 filter="(objectClass=*)" Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11 SRCH attr=hasSubordinates objectClass Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11 meta_search_dobind_init[0] mc=0x7175f3e8: non-empty dn with empty cred; binding anonymously Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11 SEARCH RESULT tag=101 err=0 nentries=0 text=
and from the target server:
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 fd=59 ACCEPT from IP=10.0.x.55:51909 (IP=10.0.y.85:389) Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 op=0 BIND dn="cn=admin,dc=loc1,dc=root" method=128 Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 op=0 RESULT tag=97 err=53 text=unauthenticated bind (DN with no password) disallowed Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 op=1 UNBIND Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 fd=59 closed Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 fd=59 closed
thus the target server refuses unauthenticated bind and closes the connection (as it is configured to do so).
Moreover, if I try to put double quotes around the "binddn" directive it seems that slapd-meta doesn't recognize at all the dn I'm trying to use to bind to the target, and the target server's log reports:
Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 fd=58 ACCEPT from IP=10.0.x.55:49353 (IP=10.0.y.85:389) Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=0 BIND dn="" method=128 Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=0 RESULT tag=97 err=0 text= Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=1 SEARCH RESULT tag=101 err=123 nentries=0 text=anonymous proxied authorization not allowed Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=1 do_search: get_ctrls failed
Just to be complete, this is (one of) the configurations I'm trying:
dn: olcMetaSub={0}uri objectClass: olcConfig objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbURI: "ldap://server01.loc1.root/dc=loc1,dc=root" olcDbIDAssertBind: mode=self bindmethod=simple binddn=cn=admin,dc=loc1,dc=root credentials=xxxxxxx starttls=no authzID="dn:cn=admin,dc=loc1,dc=root"
while the rest of the configuration stayed the same as the one from my first mail.
At this point I'm really stuck and the only thing I can think of it is the presence of a bug somewhere into slapd-meta, since the behaviour doesn't reflect the configuration on, somehow simple, parameters.
Is there anybody having the same issues? Is it still my fault on configuration?
I really don't know where to put my hands on...
Thanks for support
Hi,
dn: olcDatabase={3}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {3}meta olcSuffix: dc=loc1,dc=root olcSuffix: dc=loc2,dc=root olcSuffix: dc=loc3,dc=rootI've never used meta backend, but the above doesn't look valid to me (multiple suffixes). The man page shows a single suffix, with URI directives for additional representations of the DB.
Indeed, you can only have one olcSuffix. This is the suffix under which your source URIs will be presented. I'm running a meta backend with the following configuration:
I have two source servers, first and second. Both have a subtree ou=people,ou=mydomain. The trees are combined on the meta server under the new suffix ou=newsuffix,dc=mydomain as ou=apeople and ou=bpeople.
dn: olcDatabase={1}meta, cn=config olcDatabase: {1}meta olcSuffix: ou=newsuffix,dc=mydomain objectClass: olcDatabaseConfig objectClass: olcMetaConfig
dn: olcMetaSub={0}uri, olcDatabase={1}meta, cn=config olcDbURI: "ldap://first.source.server/ou=apeople,ou=newsuffix,dc=mydomain" objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbRewrite: {0}suffixmassage "ou=apeople,ou=newsuffix,dc=mydomain" "ou=people,dc=mydomain" olcDbIDAssertBind: mode=none flags=override,prescriptive,proxy-authz-critical bindmethod=simple binddn="cn=myadmin" credentials="secret" starttls=yes tls_cert="/etc/openldap/certs/mycert.pem" tls_key="/etc/openldap/certs/mycert.key" tls_cacert="/etc/openldap/cacerts/cacerts.pem" tls_cacertdir="/etc/openldap/cacerts" tls_reqcert=demand
dn: olcMetaSub={1}uri, olcDatabase={1}meta, cn=config olcDbURI: "ldap://second.source.server/ou=bpeople,ou=newsuffix,dc=mydomain" objectClass: olcMetaTargetConfig olcMetaSub: {1}uri olcDbRewrite: {0}suffixmassage "ou=bpeople,ou=newsuffix,dc=mydomain" "ou=people,dc=mydomain" olcDbIDAssertBind: mode=none flags=override,prescriptive,proxy-authz-critical bindmethod=simple binddn="cn=myadmin" credentials="secret" starttls=yes tls_cert="/etc/openldap/certs/mycert.pem" tls_key="/etc/openldap/certs/mycert.key" tls_cacert="/etc/openldap/cacerts/cacerts.pem" tls_cacertdir="/etc/openldap/cacerts" tls_reqcert=demand
Hope this helps. Dirk
Il 10/03/2016 14:45, Dirk Kastens ha scritto:
dn: olcDatabase={3}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {3}meta olcSuffix: dc=loc1,dc=root olcSuffix: dc=loc2,dc=root olcSuffix: dc=loc3,dc=rootI've never used meta backend, but the above doesn't look valid to me (multiple suffixes). The man page shows a single suffix, with URI directives for additional representations of the DB.
Indeed, you can only have one olcSuffix. This is the suffix under which your source URIs will be presented. I'm running a meta backend with the following configuration:
I have two source servers, first and second. Both have a subtree ou=people,ou=mydomain. The trees are combined on the meta server under the new suffix ou=newsuffix,dc=mydomain as ou=apeople and ou=bpeople.
[OMISSIS]
Hope this helps.
Thank you very much Dirk.
I tried *several* configurations and OpenLDAP versions (i.e. 2.4.44-ltb) without success. I will try to explain all of them but, at this point, I can only think to a bug in the slapd-meta module. I kindly ask to the list where I am supposed to file the bug report.
First step has been the removal of the whole OpenLDAP installation/configuration/DB and setup of the 2.4.44-ltb version. This has been done in order to avoid any mistake I could have performed while manually compiling OpenLDAP. Following that, I configured a minimal slapd with the meta database only and a single target, in order to exclude any possible configuration error deriving from the other HDB DIT previously contained.
I tested everything using "ldapsearch" and sniffing the communication between the servers with Wireshark. The result is pretty bizarre. Now, when I directly interrogate the target server with ldapsearch I correctly obtain the answers to the performed queries, e.g.:
ldapsearch -D "cn=admin,dc=server1,dc=xxxx" -w XXXXXXX -p 389 -h ldap.server1.xxxx -b "ou=users,dc=server1,dc=xxxx" -s sub "(uid=john)"
# extended LDIF # # LDAPv3 # base <ou=users,dc=server1,dc=xxxx> with scope subtree # filter: (uid=john) # requesting: ALL #
dn: uid=john,ou=users,dc=server1,dc=xxxx objectClass: inetOrgPerson objectClass: posixAccount uid: john sn: Doe givenName: John cn: John Doe displayName: John Doe uidNumber: 1000 gidNumber: 10000 gecos: John Doe loginShell: /bin/bash homeDirectory: /home/john mail: john.doe@example.com postalCode: 31000 l: aaaaa o: ddddd mobile: +33 (0)6 xx xx xx xx homePhone: +33 (0)5 xx xx xx xx title: System Administrator postalAddress: initials: JD
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
If I try to interrogate the meta-enabled server, instead, it correctly connects to the target server, it performs the query, *the target server answers correctly to the slapd-meta server* with the same data set of the first ldapsearch (sniffed with Wireshark) but I obtain *no answer*, i.e.:
ldapsearch -D "cn=admin,dc=server1,dc=xxxx" -w XXXXXXX -p 389 -h ldap.server0.xxxx -b "ou=users,dc=server1,dc=xxxx" -s sub "(uid=john)"
# extended LDIF # # LDAPv3 # base <ou=users,dc=server1,dc=xxxx> with scope subtree # filter: (uid=john) # requesting: ALL #
# search result search: 2 result: 0 Success
# numResponses: 1
so the proxy server is not forwarding to the "ldapsearch" client the obtained data.
Following are the performed configurations. First slapd-meta configuration tried is this:
dn: olcDatabase={1}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {1}meta olcSuffix: dc=xxxx
dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config olcDbURI: "ldap://10.0.x.55/dc=server1,dc=xxxx" objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbIdAssertBind: bindmethod=simple binddn=cn=admin,dc=server1,dc=xxxx credentials=XXXXXXX starttls=no
so, as suggested by Dirk and as clearly stated in the manual, using as "olcSuffix" a "common" naming context and "attaching" the target tree as subtree, without any suffix massaging.
After this test I tried enabling the RWM overlay over the meta database and configuring suffix massaging, i.e.:
dn: olcOverlay={0}rwm,olcDatabase={1}meta,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: rwm-rewriteEngine "on"
dn: olcDatabase={1}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {1}meta olcSuffix: dc=xxxx
dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config olcDbURI: "ldap://10.0.x.55/dc=server1,dc=xxxx" olcDbRewrite: {0}suffixmassage "dc=server1,dc=xxxx" "dc=server1,dc=xxxx" objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbIdAssertBind: bindmethod=simple binddn=cn=admin,dc=server1,dc=xxxx credentials=XXXXXXX starttls=no
Last battery of tests, I tried to use the same "olcSuffix" I was trying to get from the target server, i.e. "dc=server1,dc=xxxx", with and without RWM massaging.
Results for all of the tests stayed the same, if I directly query the target server I obtain the correct answer; as soon as I query the meta server it is unable to forward to the client the data received from the target......
Il 14/07/2016 14:57, Dirk Kastens ha scritto:
Hi,
does the admin account exist on the meta directory server and does it have the correct access rights?
ldapsearch -D "cn=admin,dc=server1,dc=xxxx" -w XXXXXXX -p 389 -h ldap.server0.xxxx -b "ou=users,dc=server1,dc=xxxx" -s sub "(uid=john)"
Hello,
first of all I'm sorry for the delay but I'm following this activity for a non-profit org in my spare time, so I need a lot of time to make all the tests and report the results without breaking their systems.
Your suggestion was correct, I needed to insert a valid RootDN/RootPW in the meta-DB to make it work. Surprisingly, the server did not give me an authentication error (this is why I could not understand where my mistake was residing), but after that it worked.
Now the problem has moved toward a different issue... As I said in my previous posts, my idea was to put a meta-DB next to the actual hdb DB on the "dc=loc0,dc=root" slapd but, as far as I can understand, this is not possible or, at least, I was not able to find a working configuration.
I tried to create a meta DB at the root of the DIT ("dc=root") and then to "mount" the local hdb subtree (simply creating the "dc=local0,dc=root" physical hdb) and the remote sub-trees under that; then I tried to do the opposite, creating an actual "(dc=local0,)dc=root" hdb and then "mount" the remote sub-trees using slapd-meta. None of them worked, I have always got an error stating that the "dc=root" base-DN already exists (I don't remember the exact error) when going to "step 2".
Thus, from what I can understand, it is not possible to perform what I need. A possible solution could be to create a couple more servers just for the purpose to run the slapd-meta DB, "mounting" all of the four actual hdbs exposed by the other servers, and exposing these meta-servers to the clients.
Are my discoveries correct? Is the last approach feasible/correct? Am I missing something?
Thank you again for your and the rest of the mailing list people availability.
openldap-technical@openldap.org
-
Dirk Kastens -
Fr3ddie -
Quanah Gibson-Mount