From the data I see that you mirror cn=config, but what about the rest?
Mark Monaghan CLmjmonaghan@glowmail.org.uk schrieb am 12.03.2018 um 13:58 in
Nachricht DB5PR02MB133699C3DB28BF67BC49A33D81D30@DB5PR02MB1336.eurprd02.prod.outlook.com
Hi All,
I'm looking for a bit of advice on my LDAP setup to see where I'mgoing wrong with this. I have searched high and low all over the internet for an answer, and I can't see to find anyone having the exact same issue. If anyone could shed any light on this, it would be great.
I've built two LDAP servers on Centos 7.4/OpenLDAP 2.4.44 running in mirror mode, and they are working successfully. I can create, delete, and edit entries on either server using the manager account, and the changes will be instantly mirrored over to the other server.
However, my problems started when I wanted to introduce two users to have full control over an OU each within the structure. I have put the ACLs for these users in place, and they work, but as soon as I do anything, even just an edit on an existing item in that OU, the change isn't mirrored over to the other server, and the server being mirrored to no longer replicates as it says the database is not a shadow.
The users in question are corpadmin and eduadmin, managing the Corporate and Education OUs respectively.
The ACLs in my databaseconfig file for the two users being place are as follows:
dn: olcDatabase={2}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=wireless,dc=org structuralObjectClass: olcHdbConfig creatorsName: cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,dc=wireless,dc=org" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.subtree="ou=Corporate,dc=wireless,dc=org" by dn="uid=corpadmin,ou=Admins,dc=wireless,dc=org" write by * read olcAccess: {3}to dn.subtree="ou=Education,dc=wireless,dc=org" by dn="uid=eduadmin,ou=Admins,dc=wireless,dc=org" write by * read olcAccess: {4}to * by dn="cn=Manager,dc=wireless,dc=org" write by * read olcRootDN: cn=manager,dc=wireless,dc=org
The original databaseconfig file, minus the ACLs is like so:
dn: olcDatabase={2}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=wireless,dc=org structuralObjectClass: olcHdbConfig creatorsName: cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,dc=wireless,dc=org" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=Manager,dc=wireless,dc=org" write by * read olcRootDN: cn=manager,dc=wireless,dc=org
These ACLs have been added to the same file on the other server, so both ACLs match.
Is there anywhere else I should be making these ACL changes, such as the olcDatabase={0}config file (Pasted here for ref)?
dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none olcRootPW:: 213jh287ycshasdkujqy7w483i1234jh123er7qwedfasdf olcMirrorMode: TRUE structuralObjectClass: olcDatabaseConfig entryUUID: 507c5e6e-b24a-1037-9c97-89a2062470b8 creatorsName: cn=config createTimestamp: 20180302094624Z olcSyncrepl: {0}rid=001 provider=ldap://ldapauth1.fqdn.org binddn="cn=config" bindmethod=simple credentials=password searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=002 provider=ldap://ldapauth2.fqdn.org binddn="cn=config" bindmethod=simple credentials=password searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 entryCSN: 20180302133047.428537Z#000000#002#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20180302133047Z
Finally, barring a restore of both servers, is there any way of bringing the two servers back into sync if I get a database is not a shadow error? Again, I've had a good look for information, but most posts mentioned that it was a bug with an earlier version of OpenLDAP and to upgrade to resolve this, rather than any info on how to resync the databases.
Thanks in advance.
Cheers,
Mark