Hello,
I’m having trouble understanding why I can’t get a service account to reset a userPassword attribute.
ACLs are:
{0}to attrs=userPassword by self write by anonymous auth by * none {1}to * by self write by users read by dn.base="uid=pwreset,dc=example,dc=com" write by * none
But when the password reset utility attempts to modify the password I see the following 50 error, indicating that the ACL is somehow preventing the pwreset account from modifying userPassword
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 ACCEPT from IP=192.168.1.104:52888 (IP=0.0.0.0:389) Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 STARTTLS Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 RESULT oid= err=0 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 TLS established tls_ssf=256 ssf=256 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 BIND dn="uid=pwreset,dc=example,dc=com" method=128 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 BIND dn="uid=pwreset,dc=example,dc=com" mech=SIMPLE ssf=0 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 RESULT tag=97 err=0 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=username))" Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 MOD dn="uid=username,ou=People,dc=example,dc=com" Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 MOD attr=userPassword Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 RESULT tag=103 err=50 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=4 UNBIND Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 closed
I’ve also tried with this ACL combination:
{0}to attrs=userPassword by self write by anonymous auth by dn.base="uid=pwreset,dc=example,dc=com" write by * none {1}to * by self write by users read by * none
Any advice would be greatly appreciated.
Scott
--On Thursday, October 1, 2020 4:22 PM -0700 Scott Classen sclassen@lbl.gov wrote:
Hello,
I'm having trouble understanding why I can't get a service account to reset a userPassword attribute.
ACLs are:
{0}to attrs=userPassword by self write by anonymous auth by * none {1}to * by self write by users read by dn.base="uid=pwreset,dc=example,dc=com" write by * none
But when the password reset utility attempts to modify the password I see the following 50 error, indicating that the ACL is somehow preventing the pwreset account from modifying userPassword
The above ACLs give no access to the userPassword attribute for the pwreset DN.
{0}to attrs=userPassword by self write by anonymous auth by dn.base="uid=pwreset,dc=example,dc=com" write by * none {1}to * by self write by users read by * none
The above ACLs give the pwreset DN write access to the userPassword attribute, but do not give any access to the psuedo "entry" attribute, which is mandatory as documented 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 Oct 1, 2020, at 3:27 PM, Quanah Gibson-Mount quanah@symas.com wrote:
--On Thursday, October 1, 2020 4:22 PM -0700 Scott Classen <sclassen@lbl.gov mailto:sclassen@lbl.gov> wrote:
Hello,
I'm having trouble understanding why I can't get a service account to reset a userPassword attribute.
ACLs are:
{0}to attrs=userPassword by self write by anonymous auth by * none {1}to * by self write by users read by dn.base="uid=pwreset,dc=example,dc=com" write by * none
But when the password reset utility attempts to modify the password I see the following 50 error, indicating that the ACL is somehow preventing the pwreset account from modifying userPassword
The above ACLs give no access to the userPassword attribute for the pwreset DN.
{0}to attrs=userPassword by self write by anonymous auth by dn.base="uid=pwreset,dc=example,dc=com" write by * none {1}to * by self write by users read by * none
The above ACLs give the pwreset DN write access to the userPassword attribute, but do not give any access to the psuedo "entry" attribute, which is mandatory as documented in the slapd.access(5) man page.
Regards, Quanah
I added this as the first ACL and now things are working:
{0}to dn.subtree="ou=People,dc=example,dc=com" attrs=entry,userPassword by dn.exact="uid=pwreset,dc=example,dc=com" write by * break
Scott Classen sclassen@lbl.gov schrieb am 02.10.2020 um 02:16 in
Nachricht 04E7C3A0-4B9E-4975-9B16-2381FE8D3B25@lbl.gov:
On Oct 1, 2020, at 3:27 PM, Quanah Gibson‑Mount quanah@symas.com wrote:
‑‑On Thursday, October 1, 2020 4:22 PM ‑0700 Scott Classen
<sclassen@lbl.gov
mailto:sclassen@lbl.gov> wrote:
Hello,
I'm having trouble understanding why I can't get a service account to reset a userPassword attribute.
ACLs are:
{0}to attrs=userPassword by self write by anonymous auth by * none {1}to * by self write by users read by dn.base="uid=pwreset,dc=example,dc=com" write by * none
But when the password reset utility attempts to modify the password I see the following 50 error, indicating that the ACL is somehow preventing the pwreset account from modifying userPassword
The above ACLs give no access to the userPassword attribute for the pwreset
DN.
{0}to attrs=userPassword by self write by anonymous auth by dn.base="uid=pwreset,dc=example,dc=com" write by * none {1}to * by self write by users read by * none
The above ACLs give the pwreset DN write access to the userPassword
attribute, but do not give any access to the psuedo "entry" attribute, which
is mandatory as documented in the slapd.access(5) man page.
Regards, Quanah
I added this as the first ACL and now things are working:
{0}to dn.subtree="ou=People,dc=example,dc=com" attrs=entry,userPassword by
dn.exact="uid=pwreset,dc=example,dc=com" write by * break
Hi!
Out of curiosity I had checked our ACLs finding that we do not have the "entry" part, but still everything is working for years. So I'd like to ask: In which version (if any) was that requirement added? Also I could not find the specific reference in my version of the manual page.
Regards, Ulrich
--On Friday, October 2, 2020 12:07 PM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Hi!
Out of curiosity I had checked our ACLs finding that we do not have the "entry" part, but still everything is working for years. So I'd like to ask: In which version (if any) was that requirement added? Also I could not find the specific reference in my version of the manual page.
It was introduced with OpenLDAP 2.4. It has been documented in the man pages since December 15, 2003.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 02.10.2020 um 17:00 in
Nachricht <7A16291DDB50B2241EA1677D@[192.168.1.156]>:
‑‑On Friday, October 2, 2020 12:07 PM +0200 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
Hi!
Out of curiosity I had checked our ACLs finding that we do not have the "entry" part, but still everything is working for years. So I'd like to ask: In which version (if any) was that requirement added? Also I could not find the specific reference in my version of the manual page.
It was introduced with OpenLDAP 2.4. It has been documented in the man pages since December 15, 2003.
Would you care to quote the part you are referring to?
Regards, Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Friday, October 2, 2020 6:11 PM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
It was introduced with OpenLDAP 2.4. It has been documented in the man pages since December 15, 2003.
Would you care to quote the part you are referring to?
OPERATION REQUIREMENTS ....
The add operation requires add (=a) privileges on the pseudo-attribute entry of the entry being added, and add (=a) privileges on the pseudo- attribute children of the entry's parent.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 02.10.2020 um 17:22 in
Nachricht <A3944FA90747F40502912333@[192.168.1.156]>:
‑‑On Friday, October 2, 2020 6:11 PM +0200 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
It was introduced with OpenLDAP 2.4. It has been documented in the man pages since December 15, 2003.
Would you care to quote the part you are referring to?
OPERATION REQUIREMENTS ....
The add operation requires add (=a) privileges on thepseudo‑attribute entry of the entry being added, and add (=a) privileges on the pseudo‑ attribute children of the entry's parent.
I understand that, but I failed to apply it to the case where the password is being changed: Is a modify equivenent to "delete, then add"? I thought: "no"...
‑‑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
-
Quanah Gibson-Mount -
Scott Classen -
Ulrich Windl