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, 3 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
14 years, 5 months
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, 2 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.
5 years, 6 months
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, 1 month
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, 2 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
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.
14 years, 9 months
slurpd replication problem.
by Choi, Justin
I am seeing invalid credential error logs a lot.
Could you guys let me know how to solve this issue?
Thanks.
Server Log(slurpd -d 2)
Replicated Log (/usr/sbin/slapd -u ldap -d 2 -h ldap:///)
Slapd.conf
database bdb
suffix "dc=ijji,dc=com"
rootdn "cn=Manager,dc=ijji,dc=com"
rootpw {SSHA}EpkPadkANDlpX7yfcsa2WbA+bSssh0S4
# 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/ldap/ijji.com
# 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
#updatedn cn=Replication Manager,dc=ijji,dc=com
#updateref ldap://ca1xc115.ijji.com
access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=Manager,dc=ijji,dc=com" write
by * none
access to *
by self write
by dn.base="cn=Manager,dc=ijji,dc=com" write
by * read
access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=Replication Manager,dc=ijji,dc=com" write
by * none
access to *
by self write
by dn.base="cn=Replication Manager,dc=ijji,dc=com" write
by * read
# Replicas of this database
replogfile /var/lib/ldap/openldap-master-replog
replica host=ca1xc115.ijji.com:389
binddn="cn=Replication Manager,dc=ijji,dc=com"
bindmethod=simple credentials=skdltmwkq
loglevel -1
database bdb
suffix "dc=ijji,dc=com"
rootdn "cn=Manager,dc=ijji,dc=com"
rootpw {SSHA}EpkPadkANDlpX7yfcsa2WbA+bSssh0S4
# 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/ldap/ijji.com
# 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
updatedn "cn=Replication Manager,dc=ijji,dc=com"
updateref ldap://ca1xc124.ijji.com
access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=Manager,dc=ijji,dc=com" write
by * none
access to *
by self write
by dn.base="cn=Manager,dc=ijji,dc=com" write
by * read
access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=Replication Manager,dc=ijji,dc=com" write
by * none
access to *
by self write
by dn.base="cn=Replication Manager,dc=ijji,dc=com" write
by * read
# 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
loglevel -1
Justin Choi
Sr. Security Engineer
NHN USA, Inc.
3353 Michelson Suite 250
Irvine, CA 92612
Mobile (408) 329-8554
MSN iD: counterhacker(a)live.com <mailto:amyoh79@hotmail.com>
Office (949) 863-1292 ext 256
Fax (949) 863-9418
16 years
n-way multi master setup
by Joshua Miller
Good morning,
I am attempting to follow the admin guide in setting up n-way
multi-master replication.
re:
http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
I'm running OpenLDAP 2.4.7, from Buchan Milne's RPMs, DB 4.6 on CentOS 5.1.
I have setup a working directory on both nodes, then removed all data to
start fresh, converting my slapd.conf to a slapd.d with slaptest.
ie,
# /etc/init.d/ldap stop
# rm -rf /var/lib/ldap/*
# slaptest -f slapd.conf -F slapd.d
# /etc/init.d/ldap start
Since I already had cn=config setup from my slapd.conf file, I skipped
that part of the admin guide's instructions. I then modified the
directory with the following LDIF, replacing the URI and credential
values with my environment specific ones:
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://ldapserver1
olcServerID: 2 ldap://ldapserver2
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://ldapserver2
binddn="cn=config" bindmethod=simple
credentials=secret searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
olcSyncRepl: rid=002 provider=ldap://ldapserver1
binddn="cn=config" bindmethod=simple
credentials=secret searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE
I received no errors on running the modify command to add the changes
from this LDIF.
I then attempted to make a change and have it replicated, very simple to
start with, using the following LDIF:
dn: cn=config
changetype: modify
replace: olcSecurity
olcSecurity: ssf=256
Once I successfully made this change on ldapserver1, I received the
following errors in the logs of ldapserver2 (continuously repeating):
ldapserver2 slapd2.4[12172]: conn=15 op=0 EXT oid=1.3.6.1.4.1.1466.20037
ldapserver2 slapd2.4[12172]: conn=15 op=0 STARTTLS
ldapserver2 slapd2.4[12172]: conn=15 op=0 RESULT oid= err=0 text=
ldapserver2 slapd2.4[12172]: conn=15 fd=17 ACCEPT from
IP=10.12.2.25:4174 (IP=0.0.0.0:389)
ldapserver2 slapd2.4[12172]: conn=15 fd=17 TLS established tls_ssf=256
ssf=256
ldapserver2 slapd2.4[12172]: conn=15 op=1 BIND dn="cn=config" method=128
ldapserver2 slapd2.4[12172]: conn=15 op=1 BIND dn="cn=config"
mech=SIMPLE ssf=0
ldapserver2 slapd2.4[12172]: conn=15 op=1 RESULT tag=97 err=0 text=
ldapserver2 slapd2.4[12172]: conn=15 op=2 SRCH base="cn=config" scope=2
deref=0 filter="(cn=config)"
ldapserver2 slapd2.4[12172]: conn=15 op=2 SEARCH RESULT tag=101 err=0
nentries=1 text=
ldapserver2 slapd2.4[12172]: conn=15 op=3 UNBIND
ldapserver2 slapd2.4[12172]: conn=15 fd=17 closed
ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID>
unknown factor <80>A<C2>
ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID>
unknown factor <D0>A<C2>
ldapserver2 slapd2.4[12172]: null_callback : error code 0x50
ldapserver2 slapd2.4[12172]: syncrepl_entry: rid=002 be_modify failed (80)
ldapserver2 slapd2.4[12172]: do_syncrepl: rid=002 retrying (4 retries left)
ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID>
unknown factor
ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID>
unknown factor
ldapserver2 slapd2.4[12172]: null_callback : error code 0x50
Any idea what I may have done wrong here?
Thanks!
Josh Miller, RHCE
16 years, 5 months