Replication issue? Data is different between master and consumer with same entryCSNs
by Dave Steiner
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
5 years
- 4
- 6
olcSecurity: tls=1 and olcLocalSSF= : what value should I use?
by Jean-Francois Malouin
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
5 years
- 2
- 2
duplicated naming context when using syncrepl proxy
by Jochen Keutel
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.
5 years
- 3
- 4