--On Sunday, May 31, 2020 7:35 PM -0400 Nick Folino nick@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

--On Monday, June 1, 2020 4:01 PM +0000 razvanpopescu@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

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

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

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@hotmail.com À: "openldap-technical" openldap-technical@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

From: "Quanah Gibson-Mount" quanah@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

Should I use a specifique user for replication ? Or should I use rootdn as user for replication ?