2:13 p.m.
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
6:04 a.m.
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.
11:48 a.m.
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
12:06 p.m.
--On Wednesday, May 20, 2020 12:48 PM -0700 Gao <gao(a)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>
11:37 a.m.
--On Tuesday, May 19, 2020 3:13 PM -0700 Gao <gao(a)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>
1035
days inactive
1036
days old
openldap-technical@openldap.org
5 comments
3 participants
participants (3)
-
Andreas Hasenack -
Gao -
Quanah Gibson-Mount