cn=config replication stops after adding olcAccess entries
by Jan Hugo Prins
Hello,
I'm trying to setup a new MMR cluster.
I started the installation using the documentation from:
https://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
OS: CentOS 7.7.
CentOS RPM packages OpenLDAP version 2.4.44-21
The base installation works fine, all schema's loaded etc.
At first I was thinking everything was fine, until I started testing
failure scenario's.
When I tried to rebuild a failed node I noticed that it wouldn't be
populated.
cn=config was empty except for the base config and only some data was
replicated.
After a lot of searching I found that adding any olcAccess rules would
destroy the replication.
With the olcAccess lines in the config below only the schemas are
replicated. When I remove all olcAccess lines all replication works.
The base config I use for a node looks like this:
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 1 ldap://ldap01.internal
olcServerID: 2 ldap://ldap02.internal
olcServerID: 3 ldap://ldap03.internal
olcPidFile: /var/run/openldap/slapd.pid
olcLogLevel: 16512
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=config
olcRootPW: eich4mieceeB6ma9ehah
olcSyncRepl: rid=001 provider=ldap://ldap01.internal binddn="cn=config"
bindmethod=simple
credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 +" timeout=1
olcSyncRepl: rid=002 provider=ldap://ldap02.internal binddn="cn=config"
bindmethod=simple
credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 +" timeout=1
olcSyncRepl: rid=003 provider=ldap://ldap03.internal binddn="cn=config"
bindmethod=simple
credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 +" timeout=1
olcMirrorMode: TRUE
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib64/openldap/
olcModuleLoad: syncprov.la
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
The complete config on a running node looks like this:
dn: cn=config
objectClass: olcGlobal
objectClass: olcConfig
objectClass: top
cn: config
olcLogLevel: 16512
olcPidFile: /var/run/openldap/slapd.pid
olcServerID: 1 ldap://ldap01.internal
olcServerID: 2 ldap://ldap02.internal
olcServerID: 3 ldap://ldap03.internal
dn: cn=module{0},cn=config
objectClass: olcModuleList
objectClass: olcConfig
objectClass: top
cn: module{0}
olcModuleLoad: {0}syncprov.la
olcModulePath: /usr/lib64/openldap/
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcConfig
objectClass: olcFrontendConfig
objectClass: top
olcAccess: {0}to dn.subtree="dc=domain,dc=com"
attrs=userPassword,shadowLastChange by self write by
dn.base="cn=bbsyncrepl, dc=domain,dc=com" read by anonymous auth
by * none
olcAccess: {1}to dn.subtree="dc=domain,dc=com" attrs=sambaNTPassword
by self write by dn.base="cn=bbsyncrepl, dc=domain,dc=com" read
by anonymous auth by * none
olcAccess: {2}to dn.subtree="dc=domain,dc=com" attrs=sambaLMPassword
by self write by dn.base="cn=bbsyncrepl, dc=domain,dc=com" read
by anonymous auth by * none
olcAccess: {3}to dn.subtree="dc=domain,dc=com" by
dn.base="cn=bbsyncrepl,dc=domain,dc=com" read by self write by * read
olcAddContentAcl: FALSE
olcDatabase: {-1}frontend
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcMonitoring: TRUE
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
objectClass: olcConfig
objectClass: top
olcDatabase: {0}config
olcMirrorMode: TRUE
olcMonitoring: TRUE
olcRootDN: cn=config
olcRootPW: XXXXXX
olcSyncrepl: {0}rid=001 provider=ldap://ldap01.internal
binddn="cn=config" bindmethod=simple credentials=XXXXXX
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1
olcSyncrepl: {1}rid=002 provider=ldap://ldap02.internal
binddn="cn=config" bindmethod=simple credentials=XXXXXX
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1
olcSyncrepl: {2}rid=003 provider=ldap://ldap03.internal
binddn="cn=config" bindmethod=simple credentials=XXXXXX
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcSyncProvConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}syncprov
dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config
objectClass: olcSyncProvConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {1}syncprov
dn: olcDatabase={1}bdb,cn=config
objectClass: olcBdbConfig
objectClass: olcDatabaseConfig
objectClass: olcConfig
objectClass: top
olcAddContentAcl: FALSE
olcDatabase: {1}bdb
olcDbCacheFree: 1
olcDbCacheSize: 1000000
olcDbCheckpoint: 512 5
olcDbDirectory: /var/lib/ldap
olcDbDirtyRead: FALSE
olcDbDNcacheSize: 0
olcDbIDLcacheSize: 0
olcDbIndex: default sub
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,subinitial
olcDbIndex: uid pres,eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: mailLocalAddress pres,eq
olcDbIndex: memberUid eq
olcDbIndex: mail eq,subinitial
olcDbIndex: mailRoutingAddress pres,eq
olcDbIndex: sambaSID eq
olcDbIndex: sn eq,subinitial
olcDbIndex: sambaPrimaryGroupSID eq
olcDbIndex: givenName eq,subinitial
olcDbIndex: sendmailMTAHost pres,eq,sub
olcDbIndex: sambaDomainName eq
olcDbIndex: sendmailMTAKey pres,eq,sub
olcDbIndex: sendmailMTAMapName pres,eq
olcDbIndex: sendmailMTAAliasValue pres,eq
olcDbIndex: sendmailMTAMapValue pres,eq
olcDbIndex: sendmailMTAAliasGrouping pres,eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbNoSync: FALSE
olcDbSearchStack: 16
olcDbShmKey: 0
olcLastMod: TRUE
olcLimits: {0}dn.exact="cn=Manager,dc=domain,dc=com" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcLimits: {1}dn.exact="cn=bbsyncrepl,dc=domain,dc=com"
size.soft=unlimited size.hard=unlimited time.soft=unlimited
time.hard=unlimited
olcLimits: {2}dn.exact="cn=incontrol,dc=domain,dc=com"
size.soft=unlimited size.hard=unlimited time.soft=unlimited
time.hard=unlimited
olcMaxDerefDepth: 15
olcMirrorMode: TRUE
olcMonitoring: TRUE
olcReadOnly: FALSE
olcRootDN: cn=Manager,dc=domain,dc=com
olcRootPW: XXXXXX
olcSuffix: dc=domain,dc=com
olcSyncrepl: {0}rid=004 provider=ldap://ldap01.internal
binddn="cn=Manager,dc=domain,dc=com" bindmethod=simple
credentials=XXXXXX searchbase="dc=domain,dc=com" type=refreshAndPersist
interval=00:00:00:10 retry="5 5 300 5" timeout=1 network-timeout=0
starttls=no filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off
olcSyncrepl: {1}rid=005 provider=ldap://ldap02.internal
binddn="cn=Manager,dc=domain,dc=com" bindmethod=simple
credentials=XXXXXX searchbase="dc=domain,dc=com" type=refreshAndPersist
interval=00:00:00:10 retry="5 5 300 5" timeout=1 network-timeout=0
starttls=no filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off
olcSyncrepl: {2}rid=006 provider=ldap://ldap03.internal
binddn="cn=Manager,dc=domain,dc=com" bindmethod=simple
credentials=XXXXXX searchbase="dc=domain,dc=com" type=refreshAndPersist
interval=00:00:00:10 retry="5 5 300 5" timeout=1 network-timeout=0
starttls=no filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
objectClass: olcSyncProvConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}syncprov
In the logging I see the following:
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "entry" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "objectClass" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "entry" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "objectClass" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "entry" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "objectClass" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: read access to "cn=config" "entry" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
But also:
Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrep2:
rid=003 LDAP_RES_SEARCH_RESULT
Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrep2:
rid=003 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrep2:
rid=003 (53) Server is unwilling to perform
Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrepl:
rid=003 rc -2 retrying
Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrep2:
rid=002 LDAP_RES_SEARCH_RESULT
Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrep2:
rid=002 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrep2:
rid=002 (53) Server is unwilling to perform
Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrepl:
rid=002 rc -2 retrying
Something else I see, when I use jxplorer to look at the content of a
server using the cn=config credentials I would expect to see all values
including the empty values. On a server without olcAccess lines I see
this, but when there are olcAccess lines I only see the configured
values. All unset values are not visible.
Any help is appreciated.
Thank you very much.
Jan Hugo Prins
5 years, 4 months
Re: Authenticate to ldap using Kerberos
by Howard Chu
Dan White wrote:
> On 09/09/10 20:05 -0700, Russ Allbery wrote:
>> Wouter van Marle<wouter(a)squirrel-systems.com> writes:
>>> At this moment, I can connect to my ldap server from Evolution,
>>> authenticated. I have to enter a username and a password in my evo
>>> settings, which one way or another is communicated to openldap, which
>>> then checks this un/pw combo and considers it valid to give the
>>> information.
>>
>> If you are using Kerberos, you should never have to enter your username
>> and password into anything that isn't kinit or your initial authentication
>> to your system. If you do, that something is broken and is not using
>> Kerberos properly. Period.
>
> So if the poster had stated that he wanted to perform PAM authentication
> for his simple binds, I don't think he'd be confronted with such a violent
> reaction. However, from the standpoint of slapd, that's exactly what he's
> wanting to do.
>
> Performing simple binds have precisely the same negative security footprint
> regardless of where his passwords may be stored. I'm assuming Evolution
No, it makes a difference, and the fact that you're not aware of the
difference demonstrates that you haven't thought it through enough to be
qualified to render an opinion on it.
Kerberos is secure precisely because client passwords are never transmitted
across the network. Period. When you break that guarantee, everything else
about the Kerberos system is jeopardized, and typically, when Kerberos is in
use at a site, there's a large ecosystem of apps dependent on it and all of
their security goes down the drain at the same time.
> supports ldaps or STARTTLS, which would go a long way in mitigating that
> risk. If it didn't support TLS, I'd think that'd be a much more urgent
ldaps or TLS might be ok, assuming you're not using a broken SSL
implementation. Abusing Kerberos in the requested way and relying on other
security systems to take up the slack is opening yourself up to a whole world
of unintended consequences, and we need only look at Debian last year to see
how real those problems may be.
> focus (GSSAPI only provides 56 bits of encryption).
The strength of GSSAPI's encryption layer is irrelevant in this discussion
since, when used properly, it NEVER exposes the client's secret key to anybody
else.
>> SASL is what you do when you implement Kerberos properly. Evolution is
>> not doing this. It's either implementing a broken version of SASL where
>> it only implements a single mechanism (PLAIN), or it's actually not doing
>> SASL at all (most likely). The problem is exactly that Evolution is not
>> properly implementing Kerberos SASL mechanisms.
>
> Would you agree that any application which does not support the full range
> of SASL mechanisms is broken? What about simple binds? Would you suggest
> that OpenLDAP remove all support for simple binds? If not, why not?
RFC4513 pretty much deprecates Simple Binds. Certainly it discourages using
them on an unprotected session, and the OP has already stated that he has yet
to get TLS working. And applications don't have to implement specific SASL
mechanisms, that's all hidden inside libldap and libsasl2. All they have to do
is use the right libldap calls and they automatically get support for all
mechanisms, currently known as well as future mechs.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 9 months
ppolicy issues
by r0m5
Hello !
I have two issues regarding ppolicy. I use debian jessie backports
(slapd 2.4.44).
1) I use "olcPPolicyHashCleartext: TRUE" so the clients send cleartext
passwords and slapd hashes it before writing in database for security
reasons (and slapd can perform password quality checks). But I need
exceptions for that. Indeed for some reason I have to use EAP-MD5 and
EAP-MD5 makes it mandatory to store cleartext passwords in LDAP. So I
would like to find a way to use "olcPPolicyHashCleartext: TRUE" on some
OUs, but not on others. Any way to do that ?
Maybe setting up a second mdb database with a different ppolicy overlay
configuration ("olcPPolicyHashCleartext: FALSE") and the same olcSuffix
than the existing database ? A search on the base DN would then need to
cover the two databases.
2) syncrepl of (for example) pwdChangedTime. This attribute is not
synced to my consumers, even though the schema is imported on the
consumer, the module is configured and the overlay is also configured.
Syncrepl for attributes non related to ppolicy works fine. Somehow
ppolicy is working on the consumers though, since after a failed bindind
on the consumer I can see pwdFailureTime on this consumer. Any idea ? (I
tried slapd -d -1 but didn't find something relevant, I can paste the
resuslts here if needed)
Regards,
********* provider
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 fb6dde8c
dn: olcOverlay={1}ppolicy
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=ppolicies,dc=acme,dc=fr
olcPPolicyHashCleartext: TRUE
structuralObjectClass: olcPPolicyConfig
entryUUID: 3528350a-0f9a-1037-89da-e5a4ba1189f6
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20170807085738Z
entryCSN: 20170807085738.529346Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170807085738Z
********* provider
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 295fad94
dn: cn=module{2}
objectClass: olcModuleList
cn: module{2}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}ppolicy.la
structuralObjectClass: olcModuleList
entryUUID: 6e4da4de-0a3e-1037-9174-b1e488f02d8a
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20170731131804Z
entryCSN: 20170731131804.891811Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170731131804Z
********* consumer
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 4758a296
dn: olcOverlay={0}ppolicy
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=ppolicies,dc=acme,dc=fr
olcPPolicyHashCleartext: TRUE
structuralObjectClass: olcPPolicyConfig
entryUUID: e5a3785a-0d8c-1037-908e-d903a2095e18
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20170804181719Z
entryCSN: 20170804181719.336420Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170804181719Z
********* consumer
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 d0060305
dn: cn=module{1}
objectClass: olcModuleList
cn: module{1}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}ppolicy.la
structuralObjectClass: olcModuleList
entryUUID: e560e800-0d8c-1037-908d-d903a2095e18
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20170804181718Z
entryCSN: 20170804181718.900179Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170804181718Z
********* consumer
olcSyncrepl: {0}rid=2 provider=ldap://ldap-provider-dev.acme
starttls=critical
tls_reqcert=demand bindmethod=simple
binddn="cn=replication,ou=Applications
,dc=acme,dc=fr" credentials=xxx searchbase="dc=acme,dc=fr" schemache
cking=off type=refreshAndPersist filter="(objectClass=*)" attrs="*"
scope=s
ub retry="60 +"
7 years, 10 months
Delta-syncrepl and delay in replication
by MIKI Soichiro
Hi All,
I am testing delta-syncrepl using OpenLDAP 2.3.43.7(actually
as ZimbraLDAP on ZCS 5.0.16).
It spends a lot of time to complete replication when adding
20,000 or 200,000 objects(accounts) to the master at a time.
[Time for replication]
User time(updates to master) replica1 replica2
-------------------------------------------
20,000 0:19:03 0:58:51 1:19:29
200,000 2:38:03 4:33:39 13:33:38
[Setting value in LDAP]
*checkpoint = 10240
*Thread numbers = 8
*Security = 0(zimbra_require_interprocess_security)
*The following operation is actually executed by each user in a loop.
1.Add account
2.Add settings(filters,contacts,signatures) for an account
3.Update the setting of the created account
There seems no performance problem with writing accesslog to the
database, thus, updates to the master server was finished
successfully in reasonable time.
Also, it seems that there is no bottleneck such as resource of
the servers, and we still have extra spaces on CPU, memory and
network. I've attached the servers spec.
I assume there will be a problem with the process of pushing
data from LDAP master to multiple replicas, but is this process
serialized ?
How can we reduce the replication time on replica servers?
I think updates could not be delayed on the replicas themselves
because only the secondary replica took a lot of time
to update data.
And we don't have plan to execute export/import method.
Here are the settings of the provider and the replicas:
########################################################
# BDB database definitions for provider
# excluding Zimbra settings
########################################################
database bdb
suffix ""
rootdn "cn=config"
# number of entries to keep in memory
cachesize 10000
# number of search results to keep in memory
idlcachesize 10000
# check point whenever 64k data bytes written or
# 5 minutes has elapsed whichever occurs first
checkpoint 64 5
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory "/opt/zimbra/openldap-data"
# recommended for replication
index entryUUID eq
index entryCSN eq
sizelimit unlimited
timelimit unlimited
overlay syncprov
syncprov-checkpoint 20 10
syncprov-sessionlog 500
include /opt/zimbra/conf/master-accesslog-overlay.conf
##################################################
# BDB database definitions for consumer
##################################################
database bdb
suffix ""
rootdn "cn=config"
# number of entries to keep in memory
cachesize 10000
# number of search results to keep in memory
idlcachesize 10000
# check point whenever 64k data bytes written or
# 5 minutes has elapsed whichever occurs first
checkpoint 64 5
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory "/opt/zimbra/openldap-data"
index uid pres,eq
# white pages
index mail pres,eq,sub
index cn pres,eq,sub
index displayName pres,eq,sub
index sn pres,eq,sub
index gn pres,eq,sub
# recommended for replication
index entryUUID eq
index entryCSN eq
sizelimit unlimited
timelimit unlimited
###include /opt/zimbra/conf/master-accesslog-overlay.conf
syncrepl rid=100
provider=ldap://ldapm.XXX1.XXX-test.ne.jp:389
retry="60 +"
type=refreshAndPersist
schemachecking=off
searchbase=""
bindmethod=simple
binddn=uid=zmreplica,cn=admins,cn=zimbra
credentials=@@ldap_replication_password@@
starttls=critical
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata="accesslog"
updateref ldap://ldapm.ngm1.XXX-test.ne.jp:389
overlay syncprov
Please let us know if you need more information.
Best Regards,
Soichiro Miki
=====
Soichiro Miki
Hitachi Software Engineering Co,Ltd.
s-miki(a)hitachisoft.jp
15 years
RE: N-way multi master configuration issue
by Naga Chaitanya Palle
Hi,
I was able to get the syncronization working between 2 providers.
I had to remove data on both the servers and start from beginning.
It worked.
Now i am facing another issue.
In case of single provider-client configuration, fot tls, i used to generate certificate on server and copy the same certificate to client for encrypted communication between provider and client.
Now in case of N-way multimaster, i created server1 certificate and copied that certificate to server2 and vice versa. but there is no communication happening between the servers now.
Can you please let me know how to use tls with N-way multimaster for N=2 and N>2.
Thanks and Regards,
Naga Chaitanya
________________________________________
From: Naga Chaitanya Palle
Sent: Monday, August 29, 2011 1:37 PM
To: Buchan Milne
Cc: openldap-technical(a)openldap.org
Subject: RE: N-way multi master configuration issue
Hi Buchan,
After making the changes are per your suggestions, I am still not able to read data between the servers.
Also, I deleted DI data on server 2 and restarted to import data from server1 , but no use.
Can you please check the slapd.conf files and suggest.
Server 1 slapd.conf file
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/share/openldap2.4/schema/sudo.schema
include /usr/share/openldap2.4/schema/core.schema
include /usr/share/openldap2.4/schema/cosine.schema
include /usr/share/openldap2.4/schema/inetorgperson.schema
include /usr/share/openldap2.4/schema/nis.schema
include /usr/share/openldap2.4/schema/misc.schema
include /usr/share/openldap2.4/schema/openldap.schema
include /usr/share/openldap2.4/schema/ppolicy.schema
include /usr/share/openldap2.4/schema/corba.schema
loglevel 296
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/ldap2.4/slapd.pid
argsfile /var/run/ldap2.4/slapd.args
access to attrs=userPassword
by self write
by users read
by anonymous auth
#access to attrs=shadowLastChange
# by self write
# by * auth
access to *
by * read
access to *
by dn.base="cn=Manager,dc=comverse-in,dc=com" read
by * break
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
#TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem
#TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem
#TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
serverId 001
database bdb
suffix "dc=comverse-in,dc=com"
rootdn "cn=Manager,dc=comverse-in,dc=com"
rootpw {SSHA}9tKeVZfgKFCfgIFQxXt5esH0HhQk1dIS
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap2.4
# Indices to maintain for this database
#index objectClass eq,pres
#index ou,cn,mail,surname,givenname eq,pres,sub
#index uidNumber,gidNumber,loginShell eq,pres
#index uid,memberUid eq,pres,sub
#index nisMapName,nisMapEntry eq,pres,sub
#index sudoUser eq
index sudoUser eq
index member eq
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
#index objectclass,entryCSN,entryUUID eq
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
modulepath /usr/lib/openldap2.4
# modules available in openldap-servers-overlays RPM package:
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
syncrepl rid=123
provider=ldap://devonly144.comverse-in.com
type=refreshAndPersist
interval=00:00:01:00
searchbase="dc=comverse-in,dc=com"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=Manager,dc=comverse-in,dc=com"
credentials=sonora
index objectClass,entryCSN,entryUUID eq
mirrormode true
overlay syncprov
syncprov-checkpoint 100 10
overlay ppolicy
ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com"
ppolicy_hash_cleartext
ppolicy_use_lockout
#SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
#replogfile /var/lib/ldap/openldap-master-replog
#replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical
Server2 slapd.conf file
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/share/openldap2.4/schema/sudo.schema
include /usr/share/openldap2.4/schema/core.schema
include /usr/share/openldap2.4/schema/cosine.schema
include /usr/share/openldap2.4/schema/inetorgperson.schema
include /usr/share/openldap2.4/schema/nis.schema
include /usr/share/openldap2.4/schema/misc.schema
include /usr/share/openldap2.4/schema/openldap.schema
include /usr/share/openldap2.4/schema/ppolicy.schema
include /usr/share/openldap2.4/schema/corba.schema
loglevel 296
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/ldap2.4/slapd.pid
argsfile /var/run/ldap2.4/slapd.args
access to attrs=userPassword
by self write
by users read
by anonymous auth
#access to attrs=shadowLastChange
# by self write
# by * auth
access to *
by * read
access to *
by dn.base="cn=Manager,dc=comverse-in,dc=com" read
by * break
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
#TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem
#TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem
#TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
serverId 002
#database bdb
database bdb
#suffix "dc=comverse-in,dc=com"
suffix "dc=comverse-in,dc=com"
#rootdn "cn=Manager,dc=comverse-in,dc=com"
rootdn "cn=Manager,dc=comverse-in,dc=com"
rootpw {SSHA}4qLml3DcOyfwiKlN/garIms4a8fmsNkx
#rootpw sonora
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap2.4
# Indices to maintain for this database
#index objectClass eq,pres
#index ou,cn,mail,surname,givenname eq,pres,sub
#index uidNumber,gidNumber,loginShell eq,pres
#index uid,memberUid eq,pres,sub
#index nisMapName,nisMapEntry eq,pres,sub
#index sudoUser eq
index sudoUser eq
index member eq
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
#index objectclass,entryCSN,entryUUID eq
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
modulepath /usr/lib/openldap2.4
# modules available in openldap-servers-overlays RPM package:
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
overlay ppolicy
ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com"
ppolicy_hash_cleartext
ppolicy_use_lockout
#SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
#replogfile /var/lib/ldap/openldap-master-replog
#replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical binddn="cn=Manager,dc=comverse-in,dc=com" bindmethod=simple credentials=sonora
#serverId 2
syncrepl rid=124
provider=ldap://uplite98.comverse-in.com
type=refreshAndPersist
interval=00:00:01:00
searchbase="dc=comverse-in,dc=com"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=Manager,dc=comverse-in,dc=com"
credentials=sonora
#updateref ldap://uplite98.comverse-in.com
index objectClass,entryCSN,entryUUID eq
mirrormode true
overlay syncprov
syncprov-checkpoint 100 10
Thanks and Regards,
Naga Chaitanya
-----Original Message-----
From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
Sent: Friday, August 26, 2011 7:15 PM
To: Naga Chaitanya Palle
Cc: openldap-technical(a)openldap.org
Subject: Re: N-way multi master configuration issue
On Friday, 26 August 2011 15:28:13 Naga Chaitanya Palle wrote:
> Hi buchan,
>
> My server 1 is uplite98.comverse-in.com. In its slapd.conf, I have syncrepl
> pointing to server 2 devonly144.comverse-in.com and vice versa for
> server2.
Then your serverid (and, it should actually be serverId) is wrong:
> > serverid 124 ldap://devonly144.comverse-in.com
> > syncrepl rid=124
> >
> > provider=ldap://devonly144.comverse-in.com:389
The URI form of serverId is useful if you have the same configuration on all
your masters, in which case the listening address of your server must match
one of the URIs. You may want to use this form for now:
serverId 1
If your serverId's weren't correct (check the contextCSNs), you should
probably re-import an export of one server on the other one.
> I did not exactly understand what you indicated.
> Can you please be more specific about what changes needs to be done in the
> slapd.conf file?
In a multi-master setup, each server should be replicating off *all* servers,
including itself.
> Thanks and Regards,
> Naga Chaitanya
>
> -----Original Message-----
> From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
> Sent: Friday, August 26, 2011 6:56 PM
> To: openldap-technical(a)openldap.org
> Cc: Naga Chaitanya Palle
> Subject: Re: N-way multi master configuration issue
>
> On Friday, 26 August 2011 12:56:38 Naga Chaitanya Palle wrote:
> > Hi,
> >
> > I am trying to set up N-way multimaster configuration using syncrepl on
> > openldap2.4 for RHEL 5.4
> >
> > Currently I am using two masters for testing.
> >
> > The slapd.conf on server1 is
> > moduleload syncprov.la
> > serverid 124 ldap://devonly144.comverse-in.com
> > syncrepl rid=124
> >
> > provider=ldap://devonly144.comverse-in.com:389
> > type=refreshAndPersist
> > interval=00:00:01:00
> > searchbase="dc=comverse-in,dc=com"
> > filter="(objectClass=*)"
> > scope=sub
> > attrs="*"
> > schemachecking=off
> > bindmethod=simple
> > binddn="cn=Manager,dc=comverse-in,dc=com"
> > credentials=sonora
> >
> > index objectClass,entryCSN,entryUUID eq
> > mirrormode true
> >
> > overlay syncprov
> > syncprov-checkpoint 100 10
> >
> >
> > The slapd.conf on server2 is
> > moduleload syncprov.la
> > serverid 123 ldap://uplite98.comverse-in.com
> > syncrepl rid=123
> >
> > provider=ldap://uplite98.comverse-in.com:389
> > type=refreshAndPersist
> > interval=00:00:01:00
> > searchbase="dc=comverse-in,dc=com"
> > filter="(objectClass=*)"
> > scope=sub
> > attrs="*"
> > schemachecking=off
> > bindmethod=simple
> > binddn="cn=Manager,dc=comverse-in,dc=com"
> > credentials=sonora
> >
> > index objectClass,entryCSN,entryUUID eq
> > mirrormode true
> >
> > overlay syncprov
> > syncprov-checkpoint 100 10
> >
> > But there is no data synchronization happening between the severs.
>
> Of course not, you have configured each server only to replicate from
> itself.
>
> > When I added test3 user on server1, it is not reflecting on server 2.
> > Same way when I added test4 user on server2 it is not reflecting on
> > server1.
> >
> > Please let me know what is missing in this configuration.
>
> syncrepl statements pointing to the other master.
>
> Regards,
> Buchan
>
>
>
>
> ===========================================================================
> ==== Please refer to http://www.aricent.com/legal/email_disclaimer.html for
> important disclosures regarding this electronic communication.
> ==========================================================================
> =====
===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
13 years, 9 months
Problem with N-Way multimaster replication after an node fail and restore
by David Tello
I have a problem with the N-Way replication multimaster. My enviroiment is
debian Stretch and slapd (2.4.47+dfsg-3~bpo9+1) from Stretch backports.
I have configured a cluster with 3 nodes. I have configured to replicate
the config database and a normal data mdb database. I followed the
documentation and the cluster sync work correctly when all nodes are
started.
If i made a change in any node, this change is replicated to the others. My
problem appears when i make a change whe one node is down. In this case,
the other two nodes repli correctly, and when the downed node start this
get all pending changes correctly. And in this point occurs the problem.
After the start of downed node, the changes mades in this node are not send
to the other two nodes. For other way, the changes mades in the other two
nodes (no shutdowned) are sended to all nodes correctly.
I tried this config with a two nodes cluster and the behavior was the same,
after reboot slapd do not send more updates.
I have checked the olcServerId because i know that a mistake here can
produce similar problems. I really think that it is correct.
The cmdlines of the proccess are:
/usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode1/ ldap://127.0.0.1/
ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
/usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode2/ ldap://127.0.0.1/
ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
/usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode3/ ldap://127.0.0.1/
ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
The config database configuración is below:
*DN: cn=config*
.....
olcServerID: 1 ldap://wbsvisionNode1/
olcServerID: 2 ldap://wbsvisionNode2/
olcServerID: 3 ldap://wbsvisionNode3/
*dn: olcDatabase={0}config,cn=config*
.......
olcMirrorMode: TRUE
olcSyncUseSubentry: FALSE
olcSyncrepl:
{0}rid=001
provider=ldap://wbsvisionNode1
bindmethod=simple
binddn="cn=admin,cn=config"
credentials="TuoDqAG7UbCJx8H8gfMO"
starttls=no
tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
tls_key=/etc/pki/private/wbsagnitio.local.es.key
tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
tls_reqcert=never
searchbase="cn=config"
scope=sub
type=refreshAndPersist
retry="5 5 300 +"
{1}rid=002
provider=ldap://wbsvisionNode2
bindmethod=simple
binddn="cn=admin,cn=config"
credentials="TuoDqAG7UbCJx8H8gfMO"
starttls=no
tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
tls_key=/etc/pki/private/wbsagnitio.local.es.key
tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
tls_reqcert=never
searchbase="cn=config"
scope=sub
type=refreshAndPersist
retry="5 5 300 +"
{2}rid=003
provider=ldap://wbsvisionNode3
bindmethod=simple
binddn="cn=admin,cn=config"
credentials="TuoDqAG7UbCJx8H8gfMO"
starttls=no
tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
tls_key=/etc/pki/private/wbsagnitio.local.es.key
tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
tls_reqcert=never
searchbase="cn=config"
scope=sub
type=refreshAndPersist
retry="5 5 300 +"
FALSE
------
*dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config*
objectClass: olcSyncProvConfig
objectClass: olcOverlayConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 1000 1
The data database configuración is below:
*dn: olcDatabase={1}mdb,cn=config*
objectClass: olcMdbConfig
objectClass: olcDatabaseConfig
olcDatabase: {1}mdb
...
olcDbIndex: objectClass eq
olcDbIndex: entryCSN eq
...
olcLastMod: TRUE
olcSuffix: dc=local,dc=es
.........
olcMirrorMode: TRUE
olcSyncrepl: {0}rid=004
provider=ldap://wbsvisionNode1
bindmethod=simple
binddn="cn=manager,dc=local,dc=es"
credentials="test"
starttls=no
searchbase="dc=local,dc=es"
scope=sub
type=refreshAndPersist
retry="5 5 300 +"
olcSyncrepl: {1}rid=005
provider=ldap://wbsvisionNode2
bindmethod=simple
binddn="cn=manager,dc=local,dc=es"
credentials="test"
starttls=no
searchbase="dc=local,dc=es"
scope=sub
type=refreshAndPersist
retry="5 5 300 +"
olcSyncrepl: {2}rid=006
provider=ldap://wbsvisionNode3
bindmethod=simple
binddn="cn=manager,dc=local,dc=es"
credentials="test"
starttls=no
searchbase="dc=local,dc=es"
scope=sub
type=refreshAndPersist
retry="5 5 300 +"
olcSyncUseSubentry: FALSE
dn: olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcDynamicList
objectClass: olcOverlayConfig
olcOverlay: {0}dynlist
olcDlAttrSet: {0}virtualGroup memberDnURL uniqueMember
olcDlAttrSet: {1}virtualGroup memberUidURL memberUid:uid
olcDlAttrSet: {2}virtualGroup memberSidURL sambaSIDList:sambaSID
dn: olcOverlay={1}lastbind,olcDatabase={1}mdb,cn=config
objectClass: olcLastBindConfig
objectClass: olcOverlayConfig
olcOverlay: {1}lastbind
olcLastBindPrecision: 30
dn: olcOverlay={2}unique,olcDatabase={1}mdb,cn=config
objectClass: olcUniqueConfig
objectClass: olcOverlayConfig
olcOverlay: {2}unique
olcUniqueAttribute: uid
olcUniqueAttribute: uidNumber
olcUniqueAttribute: employeeNumber
olcUniqueBase: dc=local,dc=es
dn: olcOverlay={3}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
olcOverlay: {3}memberof
olcMemberOfDangling: ignore
olcMemberOfGroupOC: groupOfUniqueNames
olcMemberOfMemberAD: uniqueMember
olcMemberOfMemberOfAD: memberOf
olcMemberOfRefInt: TRUE
dn: olcOverlay={4}accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcAccessLogConfig
objectClass: olcOverlayConfig
olcAccessLogDB: cn=accesslog
olcOverlay: {4}accesslog
olcAccessLogOld: (|(objectClass=wbsagnitioGroup)(objectClass=wbsagnitioAccou
nt))
olcAccessLogOldAttr: roles
olcAccessLogOldAttr: objectClass
olcAccessLogOps: writes
olcAccessLogOps: bind
olcAccessLogPurge: 7+00:00 1+00:00
dn: olcOverlay={5}ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcPPolicyConfig
objectClass: olcOverlayConfig
olcOverlay: {5}ppolicy
olcPPolicyDefault: cn=0-default,ou=passwordpolicies,ou=configuration,dc=loca
l,dc=es
olcPPolicyForwardUpdates: FALSE
olcPPolicyHashCleartext: FALSE
olcPPolicyUseLockout: FALSE
dn: olcOverlay={6}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcSyncProvConfig
objectClass: olcOverlayConfig
olcOverlay: {6}syncprov
olcSpCheckpoint: 1000 1
Below i show the sync log of some operations to show the behavior of my
cluster:
TEST 1: 3 Nodes up. Update in node 1 (correct):Log Node1:
May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
removing 0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002,
cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
removing 0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000
Log Node2:
May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=004
cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_message_to_entry:
rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
d6c282a0-00ff-1039-89ae-b1c1eec8fb13
May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid 23fff700
May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
be_search (0)
May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
cn=Usuarios,ou=grupos,dc=local,dc=es
May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
0x7f80081057c0 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping
original sid 001
May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
0x7f8008107700 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
removing 0x7f8008107700 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping
original sid 001
May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003,
cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
removing 0x7f80081057c0 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
0x7f8008105ea0 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
removing 0x7f8008105ea0 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006
cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006 CSN too
old, ignoring 20190507150322.383471Z#000000#001#000000
(cn=Usuarios,ou=grupos,dc=local,dc=es)
Log Node3:
May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
d6c282a0-00ff-1039-89ae-b1c1eec8fb13
May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid adbb2700
May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
be_search (0)
May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
cn=Usuarios,ou=grupos,dc=local,dc=es
May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
0x7f428c1045c0 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
original sid 001
May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
0x7f428c1069e0 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
removing 0x7f428c1069e0 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
original sid 001
May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
removing 0x7f428c1045c0 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002,
cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
0x7f428c104c90 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
removing 0x7f428c104c90 20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005
cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000
May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005 CSN too
old, ignoring 20190507150322.383471Z#000000#001#000000
(cn=Usuarios,ou=grupos,dc=local,dc=es)
TEST 2: 3 Nodes up. Update in node 2 (correct) (later this will be the down
node):Log Node1:
May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=005
cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_message_to_entry:
rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
d6c282a0-00ff-1039-89ae-b1c1eec8fb13
May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid eaffd700
May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
be_search (0)
May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
cn=Usuarios,ou=grupos,dc=local,dc=es
May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping
original sid 002
May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
removing 0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping
original sid 002
May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
removing 0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
0x7fc7d4121830 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
removing 0x7fc7d4121830 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006
cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006 CSN too
old, ignoring 20190507150531.748816Z#000000#002#000000
(cn=Usuarios,ou=grupos,dc=local,dc=es)
Log Node2:
May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
0x7f8008106ed0 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
0x7f80081050e0 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
removing 0x7f80081050e0 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003,
cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
removing 0x7f8008106ed0 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=001,
cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
Log Node3:
May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005
cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
d6c282a0-00ff-1039-89ae-b1c1eec8fb13
May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid acbb0700
May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
be_search (0)
May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
cn=Usuarios,ou=grupos,dc=local,dc=es
May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
0x7f4288107310 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
original sid 002
May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
0x7f4288109c60 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
removing 0x7f4288109c60 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
original sid 002
May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
removing 0x7f4288107310 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=001,
cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
0x7f42881079f0 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
removing 0x7f42881079f0 20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000
May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004 CSN too
old, ignoring 20190507150531.748816Z#000000#002#000000
(cn=Usuarios,ou=grupos,dc=local,dc=es)
TEST 3: 2 Nodes up. The node 2 is down. Update in node 1:Log Node1:
May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000
May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000
May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
removing 0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000
May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002,
cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
removing 0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000
May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
Log Node3:
May 7 17:10:15 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
d6c282a0-00ff-1039-89ae-b1c1eec8fb13
May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid a6ffd700
May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
be_search (0)
May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
cn=Usuarios,ou=grupos,dc=local,dc=es
May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
0x7f42a0124640 20190507151016.178467Z#000000#001#000000
May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
original sid 001
May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
0x7f42a01261a0 20190507151016.178467Z#000000#001#000000
May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
removing 0x7f42a01261a0 20190507151016.178467Z#000000#001#000000
May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
original sid 001
May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
removing 0x7f42a0124640 20190507151016.178467Z#000000#001#000000
May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002,
cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000
May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
0x7f42a0124810 20190507151016.178467Z#000000#001#000000
May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
removing 0x7f42a0124810 20190507151016.178467Z#000000#001#000000
TEST 4: 3 Nodes up. Logs of the sync produced by the Node2 start. The node2
resync correctly the change made in TEST3 (when this node was down).
Log Node1:
May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
0x7fc7dc122780 20190507151352.582436Z#000000#001#000000
May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
removing 0x7fc7dc122780 20190507151352.582436Z#000000#001#000000
May 7 17:13:52 wbsvisionNode1 slapd[14058]: syncprov_search_response:
cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
Log Node2:
May 7 17:13:52 wbsvisionNode2 slapd[591]: slapd starting
May 7 17:13:52 wbsvisionNode2 slapd[435]: Starting OpenLDAP: slapd.
May 7 17:13:52 wbsvisionNode2 systemd[1]: Started LSB: OpenLDAP standalone
server (Lightweight Directory Access Protocol).
May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=001
LDAP_RES_INTERMEDIATE - REFRESH_DELETE
May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=003
LDAP_RES_INTERMEDIATE - REFRESH_DELETE
May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
LDAP_RES_INTERMEDIATE - SYNC_ID_SET
May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
LDAP_RES_INTERMEDIATE - SYNC_ID_SET
May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry:
rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
d6c282a0-00ff-1039-89ae-b1c1eec8fb13
May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f6021700
May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
be_search (0)
May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
cn=Usuarios,ou=grupos,dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry:
rid=006 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
d6c282a0-00ff-1039-89ae-b1c1eec8fb13
May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f501f700
May 7 17:13:52 wbsvisionNode2 slapd[591]: dn_callback : entries have
identical CSN cn=Usuarios,ou=grupos,dc=local,dc=es
20190507151016.178467Z#000000#001#000000
May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
be_search (0)
May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
cn=Usuarios,ou=grupos,dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006 entry
unchanged, ignored (cn=Usuarios,ou=grupos,dc=local,dc=es)
May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn
ou=personas,dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn
ou=grupos,dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn
ou=dominios,dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn ou=dns,dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
present UUID d6b9eaaa-00ff-1039-8994-b1c1eec8fb13, dn
ou=forward,ou=dns,dc=local,dc=es
.................................
Similar lines with other entries.
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn
cn=Usuarios,ou=grupos,dc=local,dc=es
...............................
May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
0x7f63d0123740 20190507151016.178467Z#000000#001#000000
May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn
ou=personas,dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn
ou=grupos,dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn
ou=dominios,dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn ou=dns,dc=local,dc=es
May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn
cn=Usuarios,ou=grupos,dc=local,dc=es
.............................
Similar lines with other entries.
May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
0x7f63d0121400 20190507151016.178467Z#000000#001#000000
May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
removing 0x7f63d0121400 20190507151016.178467Z#000000#001#000000
May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
removing 0x7f63d0123740 20190507151016.178467Z#000000#001#000000
Log Node3:
May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
0x7f428c103b00 20190507151352.329505Z#000000#003#000000
May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
removing 0x7f428c103b00 20190507151352.329505Z#000000#003#000000
May 7 17:13:52 wbsvisionNode3 slapd[1100]: syncprov_search_response:
cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
TEST 5: 3 Nodes up. Change is made in Node2 after resync and this is not
sended to the other nodes in the cluster.Log Node1:
Empty.
Log Node2:
May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
0x7f63cc121370 20190507152835.873382Z#000000#002#000000
May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
0x7f63cc125120 20190507152835.873382Z#000000#002#000000
May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
removing 0x7f63cc125120 20190507152835.873382Z#000000#002#000000
May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
removing 0x7f63cc121370 20190507152835.873382Z#000000#002#000000
Log Node3:
Empty.
6 years, 1 month
RE: Issues with resetting user password
by CLARKE, ED C
Hello Quanah,
I appreciate your help, and I wanted to give you some insight on how IBM set up our LDAP server regarding password changes.
Below is an example what we have, essentially the .sh script performs an ldapmodify operation, using the ResetPW.ldif file.
ResetPW.sh ***** Reset password shell script ********
$ cat ResetPW.sh
#/bin/bash
ldapmodify -h 127.0.0.1 -D "cn=Manager,dc=att,dc=com" -w LinuxONE -x -f /root/ResetPW.ldif
----- root pdprfsl4.sldc.sbc.com /root -----
ResetPW.ldif:
$ cat ResetPW.ldif
#
dn: uid=foxdiv,ou=People,dc=att,dc=com
changetype: modify
replace: pwdReset
pwdReset: TRUE
-
replace: userPassword
userPassword: XXXXXXXXXX
-
----- root pdprfsl4.sldc.sbc.com /root -----
This process has been working, if this is not ideal, then I will make any changes that you recommend.
Below is the results of a search command & the commands that you gave me:
--- ec4397 Mon Sep 21 09:22:34 CDT 2020 pdprfsl4 /home/ec4397 ---
$ sudo ldapsearch -x -b "uid=ec4397,ou=People,dc=att,dc=com" -H ldapi:/// -D "cn=Manager,dc=att,dc=com" -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <uid=ec4397,ou=People,dc=att,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# ec4397, People, att.com
dn: uid=ec4397,ou=People,dc=att,dc=com
uid: ec4397
cn: ec4397
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 17780
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 2000
gidNumber: 1001
homeDirectory: /home/ec4397
userPassword:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= *** I commented this out ****
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
--- ec4397 Mon Sep 21 09:22:34 CDT 2020 pdprfsl4 /home/ec4397 ---
--- ec4397 Mon Sep 21 09:22:34 CDT 2020 pdprfsl4 /home/ec4397 ---
$ sudo ldapwhoami -x -H ldapi:/// -D uid=foxdiv,ou=People,dc=att,dc=com -W
[sudo] password for ec4397:
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
--- ec4397 Mon Sep 21 09:22:34 CDT 2020 pdprfsl4 /home/ec4397 ---
Any other tests that you would like me to run?
Thanks,
Ed
-----Original Message-----
From: Quanah Gibson-Mount <quanah(a)symas.com>
Sent: Friday, September 18, 2020 4:46 PM
To: CLARKE, ED C <ec4397(a)att.com>; openldap-technical(a)openldap.org
Subject: RE: Issues with resetting user password
--On Friday, September 18, 2020 2:42 PM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote:
> Nothing you've provided shows any attempt to connect to the ldap
> server using an SIMPLE BIND with the user DN
> "uid=foxdiv,ou=People,dc=att,dc=com" and a password.
As an example, the correct way to test the user password change went through would be something like:
ldapwhoami -x -H ldap://ldap.example.com:389/ -D uid=foxdiv,ou=People,dc=att,dc=com -W
If slapd is running on ldaps, adjust the URI accordingly. If it's on port
389 but requires startTLS, add the -ZZ option, etc.
You will be prompted for the password for the LDAP user. If the operation
succeeds, then the password was correctly updated in LDAP.
It sounds as though you may be attempting *nix <-> ldap integration, but
that hasn't been specified. Regardless, the above ldapwhoami command is
the next step in confirming whether or not the password was correctly
changed and accepted on the user side. If that works, and you're
attempting the *nix<->ldap integration and *that* is not working, it would
imply that the integration is not configured correctly.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.symas.com&d=DwICAg&… >
4 years, 8 months
Re: Authenticate to ldap using Kerberos
by Dan White
On 09/09/10 20:05 -0700, Russ Allbery wrote:
>Wouter van Marle <wouter(a)squirrel-systems.com> writes:
>> At this moment, I can connect to my ldap server from Evolution,
>> authenticated. I have to enter a username and a password in my evo
>> settings, which one way or another is communicated to openldap, which
>> then checks this un/pw combo and considers it valid to give the
>> information.
>
>If you are using Kerberos, you should never have to enter your username
>and password into anything that isn't kinit or your initial authentication
>to your system. If you do, that something is broken and is not using
>Kerberos properly. Period.
So if the poster had stated that he wanted to perform PAM authentication
for his simple binds, I don't think he'd be confronted with such a violent
reaction. However, from the standpoint of slapd, that's exactly what he's
wanting to do.
Performing simple binds have precisely the same negative security footprint
regardless of where his passwords may be stored. I'm assuming Evolution
supports ldaps or STARTTLS, which would go a long way in mitigating that
risk. If it didn't support TLS, I'd think that'd be a much more urgent
focus (GSSAPI only provides 56 bits of encryption).
>> Now basically the problem is that ldap is using the wrong authentication
>> type. Wrong as in not the one that I want it to use. It is using it's
>> own, internal authentication - this I want to change to an external
>> system. It seems I need something like you guys call 'pass-through
>> authentication'. And what I learnt over the last year or so when I
>> looked more into this and related matter, Linux provides sasl and pam as
>> general authentication libs, designed exactly for this purpose. Sasl and
>> pam even can talk to each other.
At this point, I'd agree with the above.
>No. This is not correct.
>SASL is what you do when you implement Kerberos properly. Evolution is
>not doing this. It's either implementing a broken version of SASL where
>it only implements a single mechanism (PLAIN), or it's actually not doing
>SASL at all (most likely). The problem is exactly that Evolution is not
>properly implementing Kerberos SASL mechanisms.
Would you agree that any application which does not support the full range
of SASL mechanisms is broken? What about simple binds? Would you suggest
that OpenLDAP remove all support for simple binds? If not, why not?
>PAM is indeed a way to verify passwords, but it has nothing to do with
>SASL except in the very limited special case that there is one SASL
>mechanism that communicates a password to the server, and once the
>password is on the server, you might want to use PAM to check it. PAM is
>not a network protocol; PAM is a way of plugging together password
>verification systems on a local system and was really designed for either
>console login or remote authentication that requires a password (such as
>ssh without any Kerberos support). If you have Kerbeors and yet you're
>resorting to using it with network services like LDAP, that means your
>client software (in this case Evolution) is crappy and broken.
Most protocols have support for legacy (pre-SASL) authentication. IMAP has
login, POP has user/pass, LDAP has simple binds. (SMTP being one exception
to this).
In an ideal world we could just do away with all software that only
has support for legacy authentication, but that'd break a good chunk of the
ISP services I help to maintain. I'm not really a big fan of that.
>Sadly, lots of client software is crappy and broken, so this is not an
>uncommon thing to have to do, but that doesn't make Evolution any less
>broken.
--
Dan White
14 years, 9 months
Re: Re: OpenLDAP 2.3.4 TLS negotiation failure
by Tian Zhiying
Hi Dieter：
Thanks for your quick reply.
I have changed 'TLS_REQCERT try' and check the commonName of the host certificate, the common name is LDAP Server hostname "auth.server.com", the following is the query results:
[root@auth cacerts]# openssl s_client -connect localhost:636 -showcerts -state -CAfile /etc/openldap/cacerts/cacert.pem
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddress=tianzy(a)server.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddress=tianzy(a)server.com
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server certificate request A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client certificate A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
Now, the /etc/openldap/ldap.conf file:
URI ldap://ldap.server.com/
BASE dc=server,dc=com
TLS_CACERT /etc/openldap/cacerts/cacert.pem
#SSL ON
TLS_REQCERT try
But, run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I also get the following error:
[root@client cacerts]# ldapsearch -x -H ldap://ldap.server.com -ZZ
ldap_start_tls: Connect error (-11)
Tian Zhiying
From: DieterKlünter
Date: 2013-10-23 17:35
To: openldap-technical
CC: tianzy1225
Subject: Re: OpenLDAP 2.3.4 TLS negotiation failure
Am Wed, 23 Oct 2013 16:47:25 +0800
schrieb "Tian Zhiying" <tianzy1225(a)thundersoft.com>:
> Hi
>
> On the LDAP Server , I run following command is ok:
> #ldapsearch -x -H ldap://ldap.server.com -ZZ
> #ldapsearch -x -H ldap://ldap.server.com
>
> But on my client , I run "#ldapsearch -x -H ldap://ldap.server.com",
> is ok; Run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I get the
> following error: [root@client cacerts]# ldapsearch -x -H
> ldap://ldap.server.com -ZZ ldap_start_tls: Connect error (-11)
>
> On LDAP Server log file, I get the following error messages:
> Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 ACCEPT from
> IP=192.168.9.9:45648 (IP=0.0.0.0:389) Oct 23 16:41:25 auth
> slapd[4213]: conn=206 op=0 STARTTLS Oct 23 16:41:25 auth slapd[4213]:
> conn=206 op=0 RESULT oid= err=0 text= Oct 23 16:41:25 auth
> slapd[4213]: conn=206 fd=24 closed (TLS negotiation failure)
>
> My client ldap configuration:
> /etc/openldap/ldap.conf file:
> URI ldap://ldap.server.com/
> BASE dc=server,dc=com
> TLS_CACERT /etc/openldap/cacerts/ca.crt
> SSL ON
> TLS_REQCERT demand
Set 'TLS_REQCERT try' and check the commonName of the host
certificate.
SSL ON is not an openldap configuration parameter.
The /etc/ldap.conf file is not a openldap client configuration file,
but of nss_ldap.
> /etc/ldap.conf file:
> BASE dc=server,dc=com
> URI ldap://ldap.server.com
> SSL ON
> TLS_CACERT /etc/openldap/cacert/ca.crt
> TLS_REQCERT demand
>
> Any suggestion what cause TLS negotiation failure?
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
11 years, 7 months
Re: Error 53 applying syncrepl LDIF
by Hung Luu
On Fri, Jan 29, 2010 at 2:16 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
> --On Friday, January 29, 2010 1:56 PM -0700 Hung Luu <hung.n.luu(a)gmail.com>
> wrote:
>
> Hello all,
>>
>> In a syncrepl setup, I understand that the syncrepl specification is
>> defined on the consumer server. I understand this to mean that I should
>> apply my LDIF (that adds the olcSyncrepl attribute to my config and hdb
>> backends) on the consumer server. However, ldapadd was only successful in
>> configuring my config backend for syncrepl, which is defined first in the
>> LDIF, and failed with LDAP error 53 when attempting to add the
>> olcSyncrepl attribute to my hdb backend; additional error info: "shadow
>> context; no update referral."
>>
>> Is this because the olcSyncrepl attribute added to my config backend
>> already established my consumer server as a replica and hence subsequent
>> writes to the consumer server will not be accepted?
>>
>> Ideally, I wanted to add the syncrepl configuration in my slapd.conf and
>> then convert it to cn=config; however, this doesn't appear to work with
>> 2.4.21 because the slaptest added a uri="" to the olcSyncrepl attribute
>> that running slapd complained of an invalid URL for olcSyncrepl. This is
>> not an issue in 2.4.20.
>>
>> Anyway, what's the right way for me to configure syncrepl on my 2.4.21
>> consumer server for both the config and hdb backends?
>>
>
> It works for me with 2.4.21:
>
> dn: olcDatabase={2}hdb,cn=config
> changetype: modify
> add: olcSyncrepl
> olcSyncrepl: rid=100 provider=${ldap_master_url} bindmethod=si
> mple timeout=0 network-timeout=0 binddn=uid=zmreplica,cn=admins,cn=zimbra c
> redentials=${ldap_replication_password} starttls=critical
> filter="(objectclass=*)" searchbase=""
> logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
> logbase=cn=access
> log scope=sub schemachecking=off type=refreshAndPersist retry="60 +"
> syncdat
> a=accesslog tls_cacertdir=/opt/zimbra/conf/ca
>
> is the LDIF I use to ldapmodify my entry.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
Are you able to get it to work with ldapadd as well? I'm getting a
segmentation fault using ldapmodify (installed as part of
openldap-clients.x86_64 rpm 2.3.43-3.el5).
Here's my LDIF file:
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: rid=000 provider="ldap://provider:389" type=refreshAndPersist
retry="5 5 300 +" searchbase="cn=config" attrs="*,+" bindmethod=simple
binddn="cn=ldap,ou=services,dc=example,dc=com" credentials=secret
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: rid=001 provider="ldap://provider:389" type=refreshAndPersist
retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+"
bindmethod=simple binddn="cn=ldap,ou=services,dc=example,dc=com"
credentials=secret
Something else that I tried that seems to get syncrepl working on 2.4.21 is
to use a slapd.d converted from a 2.4.20 slapd.conf, but I'm a little uneasy
about it.
Thanks,
Hung.
15 years, 4 months