Hello,
We have two Openldap server in master-slave replication. I just found that a replication issue on the slave and I think it is ACL related.
Few weeks ago I added ACL on the master (ldap-01) to allow user change their own password:
dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: loginShell eq olcDbIndex: uid eq,pres,sub olcDbIndex: memberUid eq,pres,sub olcDbIndex: uniqueMember eq,pres olcDbIndex: sambaSID eq olcDbIndex: sambaPrimaryGroupSID eq olcDbIndex: sambaGroupType eq olcDbIndex: sambaSIDList eq olcDbIndex: sambaDomainName eq olcDbIndex: default sub structuralObjectClass: olcHdbConfig entryUUID: 3b7e5722-d26f-1035-7735-91213c5bb357 creatorsName: cn=config createTimestamp: 20160629180122Z olcSuffix: dc=van,dc=company,dc=com olcRootDN: cn=Manager,dc=van,dc=company,dc=com olcRootPW:: e1NTSEF9cEpWbEIzOEh4UXJpcjnvSUl2enZzWTF1akt4Nnd6OTk= olcAccess: {0}to attrs=userPassword by self write by anonymous auth by dn.ba se="cn=Manager,dc=van,dc=company,dc=com" write by * none olcAccess: {1}to * by self write by dn="cn=Manager,dc=van,dc=company,dc= com" write by * read entryCSN: 20200504150528.806636Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20200504150528Z
Now I found on the slave(ldap-03) all userPassword attributes is disappeared. So I think the ACL may blocked the replication. I think I need add the replication user (rpuser) to the ACL on the master and allow the rpuser read(or RW?) access.
Could someone check my ACL and see if my guess is correct? If so then how do I add (or append?) the ACL to allow replication of the userPassword?
Thank you in advance.
Gao
olcRootDN: cn=Manager,dc=van,dc=company,dc=com olcRootPW:: e1NTSEF9cEpWbEIzOEh4UXJpcjnvSUl2enZzWTF1akt4Nnd6OTk=
You should change that password now, since you just shared its SSHA hash to the world ;)
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by dn.ba se="cn=Manager,dc=van,dc=company,dc=com" write by * none olcAccess: {1}to * by self write by dn="cn=Manager,dc=van,dc=company,dc= com" write by * read
It depends how your replica is connecting as. The above means that only cn=Manager and the user itself can read userPassword. Also note that since cn=Manager is also the rootdn, you don't need to add an ACL for it.
The second ACL also means that a user can change any of his/her own attributes (to * by self write), I'm not sure that is wise as I haven't seen what's in those entries. But if you are using RFC2307 and have attributes like uidNumber and gidNumber, it means the user can change the uidNumber and gidNumber to 0, for example, and become root on the machine that is using this directory as an NSS source for passwd and shadow.
entryCSN: 20200504150528.806636Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20200504150528Z
Now I found on the slave(ldap-03) all userPassword attributes is disappeared. So I think the ACL may blocked the replication. I think I need add the replication user (rpuser) to the ACL on the master and allow the rpuser read(or RW?) access.
Ah, now I saw this bit. Yes, you need to add the replication user to the acls to allow reading all attributes you want replicated, and also change the limits for that user so that it is not hampered by time and size limits.
--On Tuesday, May 19, 2020 3:13 PM -0700 Gao gao@pztop.com wrote:
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by dn.ba se="cn=Manager,dc=van,dc=company,dc=com" write by * none
You need to use ldapmodify to update the ACL. Thankfully this can be done rather easily:
ldapmodify ... dn: olcDatabase={2}hdb,cn=config changetype: modify delete: olcAccess olcAccess: {0} - add: olcAccess olcAccess: {0}to attrs=userPassword by self write by anonymous auth by dn.base="cn=Manager,dc=van,dc=company,dc=com" write by <rep user dn> read
I left off the by * none as it's implicit, as described in the slapd.access(5) man page
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 2020-05-20 06:04, Andreas Hasenack wrote:
olcRootDN: cn=Manager,dc=van,dc=company,dc=com olcRootPW:: e1NTSEF9cEpWbEIzOEh4UXJpcjnvSUl2enZzWTF1akt4Nnd6OTk=
You should change that password now, since you just shared its SSHA hash to the world ;)
It's my mistake. I reset a new password for this rootDN.
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by dn.ba se="cn=Manager,dc=van,dc=company,dc=com" write by * none olcAccess: {1}to * by self write by dn="cn=Manager,dc=van,dc=company,dc= com" write by * read
It depends how your replica is connecting as. The above means that only cn=Manager and the user itself can read userPassword. Also note that since cn=Manager is also the rootdn, you don't need to add an ACL for it.
The second ACL also means that a user can change any of his/her own attributes (to * by self write), I'm not sure that is wise as I haven't seen what's in those entries. But if you are using RFC2307 and have attributes like uidNumber and gidNumber, it means the user can change the uidNumber and gidNumber to 0, for example, and become root on the machine that is using this directory as an NSS source for passwd and shadow.
entryCSN: 20200504150528.806636Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20200504150528Z
Now I found on the slave(ldap-03) all userPassword attributes is disappeared. So I think the ACL may blocked the replication. I think I need add the replication user (rpuser) to the ACL on the master and allow the rpuser read(or RW?) access.
Ah, now I saw this bit. Yes, you need to add the replication user to the acls to allow reading all attributes you want replicated, and also change the limits for that user so that it is not hampered by time and size limits.
Thank you for the advises. I made a ldif like this:
dn: olcDatabase={2}hdb,cn=config changetype: modify add: olcAccess olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to by dn="uid=rpuser,dc=van,dc=company,dc=com" read by * read
{0} will allow user to change their own password, others can auth against the LDAP. (1) will allow replication user (rpuser) to read everything. others (*) will read as well.
Does the above ldif looks right?
I see in my old ACL {1} it already has "by * read", but why the replication user got blocked for replication? Is the rpuser not belong to *?
Gao
On Wed, May 20, 2020 at 3:48 PM Gao gao@pztop.com wrote:
I see in my old ACL {1} it already has "by * read", but why the replication user got blocked for replication? Is the rpuser not belong to *?
Because the more specific "{0}to attrs=userPassword" acl came first
--On Wednesday, May 20, 2020 12:48 PM -0700 Gao gao@pztop.com wrote:
Thank you for the advises. I made a ldif like this:
dn: olcDatabase={2}hdb,cn=config changetype: modify add: olcAccess olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to by dn="uid=rpuser,dc=van,dc=company,dc=com" read by * read
This will insert 2 new acls, and leave the existing ACLs. You don't want to do this. I already sent you a response on the correct way to fix the ACL statement.
Also, the above ACL set would not solve the problem. As clearly documented in slapd.access(5), ACL evaluation STOPS on the first matching access clause. The "by * none" would then block access to the RPuser to userPassword.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Andreas Hasenack -
Gao -
Quanah Gibson-Mount