openldap-technical September 2018

openldap-technical@openldap.org

30 participants
24 discussions

multiple syncrepl statements for partial DIT replication
by Manuela Mandache 11 Sep '18

11 Sep '18

Hi, I just subscribed to ask this question, I found no answer in the archives - sorry if I haven't looked well enough. There are three branches in the DIT on the provider and only two of them must be replicated to the consumers. Can this be done by defining two syncrepl statements on the consumers, one for each branch to be replicated and each one having a different rid? I run OpenLDAP 2.4.40 on CentOS 7. I know this result can be obtained by defining the right ACLs for the replication account on the provider and giving the parent of the three branches in the syncrepl statement, I was wondering if there are other ways of achieving it. Thank you, Manuela Mandache

2 1

Replication issue? Data is different between master and consumer with same entryCSNs
by Dave Steiner 09 Sep '18

09 Sep '18

I've been noticing various data discrepancies between our LDAP master and LDAP consumers. We are running OpenLDAP v2.4.44. We have two masters running "mirromode TRUE" and all updates go through a VIP that points to the first one unless it's not available (doesn't happen very often except for during patches and restarts). We have 13 consumers that replicate through that same VIP. Here's an example of our syncrepl for a client: syncrepl rid=221 type=refreshAndPersist schemachecking=on provider="ldap://ldapmastervip.rutgers.edu/" bindmethod=sasl saslmech=EXTERNAL starttls=yes tls_reqcert=demand tls_protocol_min="3.1" searchbase="dc=rutgers,dc=edu" attrs="*,+" retry="10 10 20 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog network-timeout=30 keepalive=180:3:60 I check the contextCSN attributes on all the instances every day and they are all in sync (except during any major changes, of course). But I occasionally notice discrepancies in the data.... even though the contextCSNs and entryCSNs are the same. For example (note hostnames have been changed): $ ldapsearch ... -H ldap://ldapmaster.rutgers.edu uid=XXXX postalAddress createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20121220100700Z postalAddress: Business And Science Bldg$227 Penn Street$Camden, NJ 081021656 entryCSN: 20180505002024.083133Z#000000#001#000000 modifyTimestamp: 20180505002024Z $ ldapsearch ... -H ldap://ldapconsumer3.rutgers.edu uid=XXXX postalAddress createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20121220100700Z postalAddress: BUSINESS AND SCIENCE BLDG$227 PENN STREET$CAMDEN, NJ 081021656 entryCSN: 20180505002024.083133Z#000000#001#000000 modifyTimestamp: 20180505002024Z So I'm trying to figure out why this happens (config issue, bug, ???) and second, if I can't use the contextCSN to report that everything is fine, what else can I do besides trying to compare ldif dumps. thanks, ds -- Dave Steiner steiner(a)rutgers.edu IdM, Enterprise Application Services ASB101; 848.445.5433 Rutgers University, Office of Information Technology

4 6

olcSecurity: tls=1 and olcLocalSSF= : what value should I use?
by Jean-Francois Malouin 06 Sep '18

06 Sep '18

Sorry if this is long and naive, I'm making my way with OpenLDAP. I have this annoying problem of local access over ldapi:/// of a configured mdb database using its rootDN. Some details: (I typically use ldapvi to access/modify/edit config as I'm an old wolf with vi hard-wired in my brain!) (Same could be done using native OpenLDAP utilities ldapadd/search/delete/etc: just replace the ldapvi '-h' option with '-H' to specify the protocol/host/port). Binding using EXTERNAL mech over local ldapi:/// works correctly for 'cn=config'. For example, here I made a mod to olcLogLevel for 'cn=config': ~# ldapvi -Y EXTERNAL -h ldapi:/// -b 'cn=config' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 24 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Done. Server logs for slapd show the binding with ssf=71: Sep 6 11:40:52 slapd[677]: conn=48667 fd=17 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND dn="" method=163 Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 However for the configured mdb database 'olcDatabase={1}mdb,cn=config' I have set olcSecurity: tls=1 to force binding with StartTLS. Here the relevant config piece for it: ('--out' makes ldapvi behave like ldapsearch). ~# ldapvi --out -Y EXTERNAL -h ldapi:/// -b 'olcDatabase={1}mdb,cn=config' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: cn=admin,dc=example,dc=com olcRootPW: {SSHA}XXXXXXXXXXXXXXXXXXXX olcSecurity: tls=1 ... However this setting prohibits me from binding to it using ldapi:/// with EXTERNAL mech with its rootDN 'cn=admin,dc=example,dc=com' as I then get the message: ~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 Confidentiality required (13) Additional information: TLS confidentiality required I can however do a simple bind over StartTLS with the rootDN of the database either over localhost or a remote client: ~# ldapsearch -LLL -Z -x -w xxxxxxxx -H ldap://localhost -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' slapd logs show: Sep 6 11:54:40 slapd[677]: conn=48699 fd=17 ACCEPT from IP=127.0.0.1:53542 (IP=0.0.0.0:389) Sep 6 11:54:40 slapd[677]: conn=48699 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 6 11:54:40 slapd[677]: conn=48699 op=0 STARTTLS Sep 6 11:54:40 slapd[677]: conn=48699 op=0 RESULT oid= err=0 text= Sep 6 11:54:40 slapd[677]: conn=48699 fd=17 TLS established tls_ssf=256 ssf=256 Sep 6 11:54:40 slapd[677]: conn=48699 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 Sep 6 11:54:40 slapd[677]: conn=48699 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 So ssf=265... I guess I need to modify either 'olcSecurity: tls=1' in the database config or add/insert the proper value for 'olcLocalSSF=' in the cn=config. What value should I use in order to still force StartTLS over simple binding and allow read/write/modify local access on the ldapi:/// listener. Regards! jf

2 2

duplicated naming context when using syncrepl proxy
by Jochen Keutel 05 Sep '18

05 Sep '18

Hallo, I'm using OpenLDAP on Debian 9 (2.4.44) and started to configure replication: szenario syncrepl proxy (push based replication, see 18.3.5 in OpenLDAP Admin Guide - "primary directory also contains back-ldap databases"). Configuring the LDAP backend leads unfortunately to a root DSE showing the same name context twice: namingContexts: dc=keutel,dc=de namingContexts: dc=keutel,dc=de Is this a known problem? Esp. this stops PHPLDAPAdmin from working: It prints a lot of PHP arrays in this case. I've set "hidden on" for this backend but the problem remains. My configuration: 1. slapd.conf on server1 (master): database ldap hidden on suffix "dc=keutel,dc=de" rootdn "cn=admin,dc=keutel,dc=de" uri ldaps://server2/ lastmod on restrict all acl-bind bindmethod=simple binddn="cn=replication,dc=keutel,dc=de" credentials=secret syncrepl rid=001 provider=ldaps://server1/ binddn="cn=replication,dc=keutel,dc=de" bindmethod=simple credentials=secret searchbase="dc=keutel,dc=de" type=refreshAndPersist retry="5 5 300 5" 2. converting this to dynamic config using slaptest gives the following entry: dn: olcDatabase={2}ldap objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcHidden: TRUE olcSuffix: dc=keutel,dc=de ... 3. starting slapd with this dynamic configuration 4. reading rootDSE: attribute namingContexts occurs twice with the same value. How can this be solved? Regards Jochen.

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2018