9:13 a.m.
Hi,
I have set up a replication master/slave between 2 openldap 2.4.44 on rhel 7.x.
On the slave server, the userPassword attribute is not replicated by syncrepl, all other
attributes are replicated OK
The replication has been set up as follow:
On master server (provider), I have set up :
# replication
moduleload syncprov
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
On slave server (consumer), I've set up in the /etc/openldap/slapd.conf:
# replication
syncrepl rid=100
provider=ldaps://fr-te-ldap-x1.intra.commercial-union.fr
type=refreshAndPersist
searchbase="dc=aviva,dc=fr"
scope=sub
schemachecking=on
bindmethod=simple
filter="(objectClass=*)"
binddn="cn=admin,dc=aviva,dc=fr"
credentials=redhat
retry="15 +"
index entryUUID,entryCSN eq
sizelimit 100000
On both server ( master, slave) , the ACL has been set up as follow :
access to attrs=userPassword
by self write
by anonymous auth
by * read
access to *
by self read
by users read
by anonymous read
Please help me !
What is wrong in this configuration and why the userPassword attribute is not replicated
on slave side ?
Please advice me,
Thank,
Razvan
3:35 p.m.
Is cn=admin,dc=aviva,dc=fr the root user? If not he doesn't have write
access to userPassword.
Nick
On Sun, May 31, 2020 at 6:29 PM <razvanpopescu(a)hotmail.com> wrote:
Hi,
I have set up a replication master/slave between 2 openldap 2.4.44 on
rhel 7.x.
On the slave server, the userPassword attribute is not replicated by
syncrepl, all other attributes are replicated OK
The replication has been set up as follow:
On master server (provider), I have set up :
# replication
moduleload syncprov
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
On slave server (consumer), I've set up in the /etc/openldap/slapd.conf:
# replication
syncrepl rid=100
provider=ldaps://fr-te-ldap-x1.intra.commercial-union.fr
type=refreshAndPersist
searchbase="dc=aviva,dc=fr"
scope=sub
schemachecking=on
bindmethod=simple
filter="(objectClass=*)"
binddn="cn=admin,dc=aviva,dc=fr"
credentials=redhat
retry="15 +"
index entryUUID,entryCSN eq
sizelimit 100000
On both server ( master, slave) , the ACL has been set up as follow :
access to attrs=userPassword
by self write
by anonymous auth
by * read
access to *
by self read
by users read
by anonymous read
Please help me !
What is wrong in this configuration and why the userPassword attribute is
not replicated on slave side ?
Please advice me,
Thank,
Razvan
3:40 p.m.
--On Sunday, May 31, 2020 7:35 PM -0400 Nick Folino <nick(a)folino.us> wrote:
Is cn=admin,dc=aviva,dc=fr the root user? If not he doesn't have write
access to userPassword.
Replication does not require write access to the attribute, only read.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
8:01 a.m.
What do you suggest ?
to re try a replication from master to a empty slave database ?
Or is a bug here in Openldap 2.4.44 and userPassword is not replicated ?
Please advice me,
Razvan
8:07 a.m.
--On Monday, June 1, 2020 4:01 PM +0000 razvanpopescu(a)hotmail.com wrote:
What do you suggest ?
to re try a replication from master to a empty slave database ?
Or is a bug here in Openldap 2.4.44 and userPassword is not replicated ?
There is no bug here with OpenLDAP. The problem is with your
configuration. There are definitely fixes since 2.4.44 that are important
to have, but they are not related to the problem you're having.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
10:55 a.m.
On 6/1/20 5:01 PM, razvanpopescu(a)hotmail.com wrote:
What do you suggest ?
to re try a replication from master to a empty slave database ?
Or is a bug here in Openldap 2.4.44 and userPassword is not replicated ?
There is no bug in OpenLDAP regarding replication of userPassword. Most
likely you're authentication and authorization (ACLs) is wrong.
Ciao, Michael.
9 a.m.
What should I change in my configuration master/slave in terms of ACL prior to replicate
the userPassword attribute from provider to consumer ?
Please help me,
Razvan
9:09 a.m.
--On Tuesday, June 2, 2020 5:00 PM +0000 razvanpopescu(a)hotmail.com wrote:
What should I change in my configuration master/slave in terms of
ACL
prior to replicate the userPassword attribute from provider to consumer ?
You've not provided your full configuration (minus passwords) so there's
little help that can be offered. You may wish to review my email from 5/31
in which I gave you the first steps you should be taking.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
7:18 a.m.
Hi,
My configuration is very simple.
On master, the slapd.conf file contains:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/rfc2307aix.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
TLSCACertificatePath /etc/openldap/certs
TLSCertificateFile "fr-te-ldap-x1.intra.commercial-union.fr"
TLSCertificateKeyFile /etc/openldap/certs/password
TLSCipherSuite ECDHE+AESGCM:DHE+AESGCM
TLSDHParamFile /etc/openldap/dh2048.pem
TLSProtocolMin 3.3
TLSECName prime256v1
password-hash {CRYPT}
#password-crypt-salt-format "$6$%.16s"
access to attrs=userPassword
by self write
by anonymous auth
by * read
access to *
by self read
by users read
by anonymous read
database bdb
suffix "dc=aviva,dc=fr"
rootdn "cn=admin,dc=aviva,dc=fr"
rootpw xxxxx
directory /var/lib/ldap
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
# replication LDAP
moduleload syncprov
index entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
sizelimit unlimited
And on slave server, the slapd conf contains:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/rfc2307aix.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
TLSCACertificatePath /etc/openldap/certs
TLSCertificateFile "fr-te-ldap-x2.intra.commercial-union.fr"
TLSCertificateKeyFile /etc/openldap/certs/password
TLSCipherSuite ECDHE+AESGCM:DHE+AESGCM
TLSDHParamFile /etc/openldap/dh2048.pem
TLSProtocolMin 3.3
TLSECName prime256v1
password-hash {CRYPT}
access to attrs=userPassword
by self write
by anonymous auth
by * read
access to *
by self read
by users read
by anonymous read
database bdb
suffix "dc=aviva,dc=fr"
rootdn "cn=admin,dc=aviva,dc=fr"
rootpw xxxx
directory /var/lib/ldap
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
# replication
syncrepl rid=100
provider=ldaps://fr-te-ldap-x1.intra.commercial-union.fr
type=refreshAndPersist
searchbase="dc=aviva,dc=fr"
scope=sub
schemachecking=on
bindmethod=simple
filter="(objectClass=*)"
binddn="cn=admin,dc=aviva,dc=fr"
credentials=redhat
retry="15 +"
index entryUUID,entryCSN eq
sizelimit 100000
Could you please tell me what is wrong here ?
Please advice me,
Razvan
10:52 a.m.
--On Thursday, June 4, 2020 3:18 PM +0000 razvanpopescu(a)hotmail.com wrote:
Hi,
My configuration is very simple.
binddn="cn=admin,dc=aviva,dc=fr"
Since you're using the rootdn, ACLs are not in effect at all.
What release of OpenLDAP are you running?
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
9:16 a.m.
hello
not sure it's the best practice , but here's the ACL I set on my provider to allow
replication on consumer with cn=repuser,ou=dsa,dc=mydomain,dc=fr as the replication user
DN
# cat olcRepConfigAccess.ldif
dn: olcDatabase={3}mdb,cn=config #Database number (3) and type (mdb) might be different
on your instance .
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage by * break
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to dn.base="dc=mydomain,dc=fr" by * read
olcAccess: {3}to dn.subtree="dc=mydomain,dc=fr" by
dn.exact="cn=repuser,ou=dsa,dc=mydomain,dc=fr" read by * break
olcAccess: {4}to attrs=userPassword,shadowLastChange by self write by anonymous auth by
dn.exact="cn=repuser,ou=dsa,dc=mydomain,dc=fr" read by * none
olcAccess: {5}to * by self read by * none
Then I set it this way
ldapmodify -Y EXTERNAL -H ldapi:/// -f ./olcRepConfigAccess.ldif
hope it helps .
----- Mail original -----
De: razvanpopescu(a)hotmail.com
À: "openldap-technical" <openldap-technical(a)openldap.org>
Envoyé: Mardi 2 Juin 2020 18:00:46
Objet: Re: userPassword is not replicated
What should I change in my configuration master/slave in terms of ACL prior to replicate
the userPassword attribute from provider to consumer ?
Please help me,
Razvan
9:38 a.m.
--On Tuesday, June 2, 2020 7:16 PM +0200 Jehan PROCACCIA
<jehan.procaccia(a)imtbs-tsp.eu> wrote:
not sure it's the best practice , but here's the ACL I set on
my provider
There are numerous issues with the ACL set you just provided. I definitely
would not use it as a guide on how to do things.
olcAccess: {1}to dn.base="" by * read
This is an ACL that is meant to go into the frontend DB, not the primary DB.
olcAccess: {3}to dn.subtree="dc=mydomain,dc=fr" by
dn.exact="cn=repuser,ou=dsa,dc=mydomain,dc=fr" read by * break
This ACL will never be used, since ACL{2} already covers your entire tree.
olcAccess: {4}to attrs=userPassword,shadowLastChange by self write by
anonymous auth by dn.exact="cn=repuser,ou=dsa,dc=mydomain,dc=fr" read by *
none
Same as #3.
olcAccess: {5}to * by self read by * none
Same as #3.
In practice, you only have two functioning ACLs with what you provided:
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by
* break
olcAccess: {2}to dn.base="dc=mydomain,dc=fr" by * read
Probably most critical, you've given everyone, including anonymous, read
access to the userPassword attribute of every account in your tree.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
10:03 a.m.
From: "Quanah Gibson-Mount" <quanah(a)symas.com>
olcAccess: {1}to dn.base="" by * read
This is an ACL that is meant to go into the frontend DB, not the primary DB.
I remembered set that one so that ApacheDirectoryStudio (or other GUI) could read the
RootDSE, but now you make me wonder ...?
olcAccess: {3}to dn.subtree="dc=mydomain,dc=fr" by
dn.exact="cn=repuser,ou=dsa,dc=mydomain,dc=fr" read by * break
This ACL will never be used, since ACL{2} already covers your entire tree.
ACL{2} is dn.base not subtree :
olcAccess: {2}to dn.base="dc=mydomain,dc=fr" by * read
for me it not a subtree acces, but just a "one level" => dn.base , the object
dc=mydomain,dc=fr itself (again for GUIs)
but If I am wrong on that interpretation, you are right, then it allow access to
everything to everyone :-( ! .
please confirm
olcAccess: {4}to attrs=userPassword,shadowLastChange by self write by
anonymous auth by dn.exact="cn=repuser,ou=dsa,dc=mydomain,dc=fr" read by *
none
you are right I should move UP {4} above {3} , but {3} is just a line for
dn.exact="cn=repuser,ou=dsa,dc=mydomain,dc=fr" read , then by * there is a break
!
Same as #3.
olcAccess: {5}to * by self read by * none
Same as #3.
In practice, you only have two functioning ACLs with what you provided:
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by
* break
olcAccess: {2}to dn.base="dc=mydomain,dc=fr" by * read
Probably most critical, you've given everyone, including anonymous, read
access to the userPassword attribute of every account in your tree.
If you confirm how wrong is {2} , I must change it , indeed .
Thanks .
PS: to clarify the discussion , here's my initial post
# cat olcRepConfigAccess.ldif
dn: olcDatabase={3}mdb,cn=config #Database number (3) and type (mdb) might be different
on your instance .
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage by * break
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to dn.base="dc=mydomain,dc=fr" by * read
olcAccess: {3}to dn.subtree="dc=mydomain,dc=fr" by
dn.exact="cn=repuser,ou=dsa,dc=mydomain,dc=fr" read by * break
olcAccess: {4}to attrs=userPassword,shadowLastChange by self write by anonymous auth by
dn.exact="cn=repuser,ou=dsa,dc=mydomain,dc=fr" read by * none
olcAccess: {5}to * by self read by * none
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
10:08 a.m.
--On Tuesday, June 2, 2020 8:03 PM +0200 Jehan PROCACCIA
<jehan.procaccia(a)imtbs-tsp.eu> wrote:
> From: "Quanah Gibson-Mount" <quanah(a)symas.com>
> olcAccess: {1}to dn.base="" by * read
> This is an ACL that is meant to go into the frontend DB, not the primary
> DB.
I remembered set that one so that ApacheDirectoryStudio (or other GUI)
could read the RootDSE, but now you make me wonder ...?
It's not a bad ACL, it's just in the wrong place, which is why I mentioned
the frontend DB.
ACL{2} is dn.base not subtree :
olcAccess: {2}to dn.base="dc=mydomain,dc=fr" by * read
Yeah, I misread that one, sorry. :) So the rest of the ACLs look fine.
Generally for the frontend DB, you see something like:
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.subtree="cn=Subschema" by * read
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
9:20 a.m.
Should I use a specifique user for replication ?
Or should I use rootdn as user for replication ?
9:39 a.m.
--On Tuesday, June 2, 2020 5:20 PM +0000 razvanpopescu(a)hotmail.com wrote:
Should I use a specifique user for replication ?
Yes.
Or should I use rootdn as user for replication ?
No.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
3:40 p.m.
--On Sunday, May 31, 2020 5:13 PM +0000 razvanpopescu(a)hotmail.com wrote:
binddn="cn=admin,dc=aviva,dc=fr"
access to attrs=userPassword
by self write
by anonymous auth
by * read
Giving everyone read access to the userPassword attribute is an extremely
poor idea.
I would suggest testing with the "cn=admin,dc=aviva,dc=fr" identity to see
if it specfically has read access to userPassword on the provider, because
it seems that it does not.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
1207
days inactive
1211
days old
openldap-technical@openldap.org
16 comments
5 participants
participants (5)
-
Jehan PROCACCIA -
Michael Ströder -
Nick Folino -
Quanah Gibson-Mount -
razvanpopescu＠hotmail.com