Hi, there is an interesting insufficient access problem...
There are 3 (in dev environment 2) multimaster ldap node.
There is a simple web frontend, written in PHP, where user can change its own password, or can get a link to set up a new pass if old one had lost.
In some cases (some users) the user can't change the own password through PHP. When I change it from webserver with ldapmodify and a simple ldif file, it works as well.
But when I try to modify the passwd through PHP, I got "Insufficient access" error, and these lines are in syslog:
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => access_allowed: search access to "uid=comp1_user1,ou=Users,ou=COMP1,dc=wificloud,dc=company,dc=hu" "objectClass" requested Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dn: [2] ou=djp,dc=wificloud,dc=company,dc=hu Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dnpat: [3] ou=(AH|Delta|Comp1|Comp2|Comp3),dc=wificloud,dc=company,dc=hu nsub: 1 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] matched Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] attr objectClass Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => match[dn0]: 26 60 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: m Sep 18 17:48:13 dev-ldap-01 slapd[12125]: p Sep 18 17:48:13 dev-ldap-01 slapd[12125]: 1 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: w Sep 18 17:48:13 dev-ldap-01 slapd[12125]: i Sep 18 17:48:13 dev-ldap-01 slapd[12125]: f Sep 18 17:48:13 dev-ldap-01 slapd[12125]: i Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: l Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: m Sep 18 17:48:13 dev-ldap-01 slapd[12125]: p Sep 18 17:48:13 dev-ldap-01 slapd[12125]: a Sep 18 17:48:13 dev-ldap-01 slapd[12125]: n Sep 18 17:48:13 dev-ldap-01 slapd[12125]: y Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: h Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]:
(I replaced names and chars, so the match[dn0] numbers are not correct).
Only few users can trigger this problem (don't know why), and only through PHP.
What's the problem here?
Thanks,
a.
Le 18/09/2018 à 18:11, Ervin Hegedüs a écrit :
Hi, there is an interesting insufficient access problem...
There are 3 (in dev environment 2) multimaster ldap node.
There is a simple web frontend, written in PHP, where user can change its own password, or can get a link to set up a new pass if old one had lost.
In some cases (some users) the user can't change the own password through PHP. When I change it from webserver with ldapmodify and a simple ldif file, it works as well.
But when I try to modify the passwd through PHP, I got "Insufficient access" error, and these lines are in syslog:
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => access_allowed: search access to "uid=comp1_user1,ou=Users,ou=COMP1,dc=wificloud,dc=company,dc=hu" "objectClass" requested Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dn: [2] ou=djp,dc=wificloud,dc=company,dc=hu Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dnpat: [3] ou=(AH|Delta|Comp1|Comp2|Comp3),dc=wificloud,dc=company,dc=hu nsub: 1 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] matched Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] attr objectClass Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => match[dn0]: 26 60 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: m Sep 18 17:48:13 dev-ldap-01 slapd[12125]: p Sep 18 17:48:13 dev-ldap-01 slapd[12125]: 1 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: w Sep 18 17:48:13 dev-ldap-01 slapd[12125]: i Sep 18 17:48:13 dev-ldap-01 slapd[12125]: f Sep 18 17:48:13 dev-ldap-01 slapd[12125]: i Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: l Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: m Sep 18 17:48:13 dev-ldap-01 slapd[12125]: p Sep 18 17:48:13 dev-ldap-01 slapd[12125]: a Sep 18 17:48:13 dev-ldap-01 slapd[12125]: n Sep 18 17:48:13 dev-ldap-01 slapd[12125]: y Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: h Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]:
(I replaced names and chars, so the match[dn0] numbers are not correct).
Only few users can trigger this problem (don't know why), and only through PHP.
What's the problem here?
Hello,
I would say that the PHP application is sending some garbage to the directory. What application are you using for password change, is it LTB Self Service Password ?
Hi,
thanks for reply,
On Tue, Sep 18, 2018 at 09:40:00PM +0200, Clément OUDOT wrote:
Le 18/09/2018 à 18:11, Ervin Hegedüs a écrit :
Hi, there is an interesting insufficient access problem...
There are 3 (in dev environment 2) multimaster ldap node.
There is a simple web frontend, written in PHP, where user can change its own password, or can get a link to set up a new pass if old one had lost.
In some cases (some users) the user can't change the own password through PHP. When I change it from webserver with ldapmodify and a simple ldif file, it works as well.
But when I try to modify the passwd through PHP, I got "Insufficient access" error, and these lines are in syslog:
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => access_allowed: search access to "uid=comp1_user1,ou=Users,ou=COMP1,dc=wificloud,dc=company,dc=hu" "objectClass" requested Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dn: [2] ou=djp,dc=wificloud,dc=company,dc=hu Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dnpat: [3] ou=(AH|Delta|Comp1|Comp2|Comp3),dc=wificloud,dc=company,dc=hu nsub: 1 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] matched Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] attr objectClass Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => match[dn0]: 26 60 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u
...
Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: h Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]:
I would say that the PHP application is sending some garbage to the directory. What application are you using for password change, is it LTB Self Service Password ?
no, that's a custom development, which will be extend with many other features - no matter now.
But then I don't understand, why comes this error only few users (total number of users is about 200 now, we know about 2-3 affected user).
Anyway, I thought it also what you wrote, and switched back to native LDAP (instead of LDAPS), and make a capture at LDAP side.
There aren't any garbage in packets, all request contains absolutely normal lines... If you interesting about it, I can send you a cap file - but that contains sensitive datas, of course.
I just can share some screenshots about the traffic, hope it seems that no other garbage:
https://www.dropbox.com/sh/x8ol6cfc39zj7cp/AADCo3CgcHPQnvOre4hjuULpa
Thanks again,
a.
Le 18/09/2018 à 22:23, Ervin Hegedüs a écrit :
But then I don't understand, why comes this error only few users (total number of users is about 200 now, we know about 2-3 affected user).
Anyway, I thought it also what you wrote, and switched back to native LDAP (instead of LDAPS), and make a capture at LDAP side.
There aren't any garbage in packets, all request contains absolutely normal lines... If you interesting about it, I can send you a cap file - but that contains sensitive datas, of course.
I just can share some screenshots about the traffic, hope it seems that no other garbage:
https://www.dropbox.com/sh/x8ol6cfc39zj7cp/AADCo3CgcHPQnvOre4hjuULpa
It would be be interesting to see how your OpenLDAP ACL are configured. Are you sure that a user can modify userPassword and sambaNT/LM password attributes?
Hi,
On Tue, Sep 18, 2018 at 10:34:55PM +0200, Clément OUDOT wrote:
Le 18/09/2018 à 22:23, Ervin Hegedüs a écrit :
But then I don't understand, why comes this error only few users (total number of users is about 200 now, we know about 2-3 affected user).
Anyway, I thought it also what you wrote, and switched back to native LDAP (instead of LDAPS), and make a capture at LDAP side.
There aren't any garbage in packets, all request contains absolutely normal lines... If you interesting about it, I can send you a cap file - but that contains sensitive datas, of course.
I just can share some screenshots about the traffic, hope it seems that no other garbage:
https://www.dropbox.com/sh/x8ol6cfc39zj7cp/AADCo3CgcHPQnvOre4hjuULpa
It would be be interesting to see how your OpenLDAP ACL are configured.
the ACL system a little bit complicated (I guess), but I think it works as well:
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by anonymous auth by * none olcAccess: {1}to dn.subtree="ou=OU1,dc=service1,dc=bigcompany,dc=hu" by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none olcAccess: {2}to dn.regex="ou=(comp1|comp2|comp3),dc=service1,dc=bigcompany,dc=hu" by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none olcAccess: {3}to dn.subtree="dc=bigcompany,dc=hu" by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none olcAccess: {4}to * by self write by anonymous auth by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none
Are you sure that a user can modify userPassword and sambaNT/LM password attributes?
yes, I'm sure.
The NT/LM password attribures aren't named any place, the userPassword is, but all user can modify its own - see ACL's above.
And as I wrote in first mail, the simple "ldapmodify" works as well.
And more important, the other users under the same OU can change their own userpassword/nt/lm password attributes through PHP.
The service user (_srvuser1) also can modify (through PHP), but I'ld like to use as the logged user modify its own passwd.
Thanks,
a.
Le 18/09/2018 à 23:10, Ervin Hegedüs a écrit :
Hi,
On Tue, Sep 18, 2018 at 10:34:55PM +0200, Clément OUDOT wrote:
Le 18/09/2018 à 22:23, Ervin Hegedüs a écrit :
But then I don't understand, why comes this error only few users (total number of users is about 200 now, we know about 2-3 affected user).
Anyway, I thought it also what you wrote, and switched back to native LDAP (instead of LDAPS), and make a capture at LDAP side.
There aren't any garbage in packets, all request contains absolutely normal lines... If you interesting about it, I can send you a cap file - but that contains sensitive datas, of course.
I just can share some screenshots about the traffic, hope it seems that no other garbage:
https://www.dropbox.com/sh/x8ol6cfc39zj7cp/AADCo3CgcHPQnvOre4hjuULpa
It would be be interesting to see how your OpenLDAP ACL are configured.
the ACL system a little bit complicated (I guess), but I think it works as well:
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by anonymous auth by * none olcAccess: {1}to dn.subtree="ou=OU1,dc=service1,dc=bigcompany,dc=hu" by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none olcAccess: {2}to dn.regex="ou=(comp1|comp2|comp3),dc=service1,dc=bigcompany,dc=hu" by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none olcAccess: {3}to dn.subtree="dc=bigcompany,dc=hu" by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none olcAccess: {4}to * by self write by anonymous auth by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none
Are you sure that a user can modify userPassword and sambaNT/LM password attributes?
yes, I'm sure.
The NT/LM password attribures aren't named any place, the userPassword is, but all user can modify its own - see ACL's above.
No, the olcAccess {3} deny all access inside dc=bigcompany,dc=hu, the rule {4} is never evaluated.
And as I wrote in first mail, the simple "ldapmodify" works as well.
Do you test to modify only userPassword attribute? Or your modification is also on Samba attributes?
And more important, the other users under the same OU can change their own userpassword/nt/lm password attributes through PHP.
I don't how, because your ACL allow only userPassword modification for 'self'.
The service user (_srvuser1) also can modify (through PHP), but I'ld like to use as the logged user modify its own passwd.
I think you should merge your ACL like this:
olcAccess: {3}to dn.subtree="dc=bigcompany,dc=hu" by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by self write by * none
Hi,
On Tue, Sep 18, 2018 at 11:21:07PM +0200, Clément OUDOT wrote:
Le 18/09/2018 à 23:10, Ervin Hegedüs a écrit :
Hi,
On Tue, Sep 18, 2018 at 10:34:55PM +0200, Clément OUDOT wrote:
Le 18/09/2018 à 22:23, Ervin Hegedüs a écrit :
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by anonymous auth by * none olcAccess: {1}to dn.subtree="ou=OU1,dc=service1,dc=bigcompany,dc=hu" by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none olcAccess: {2}to dn.regex="ou=(comp1|comp2|comp3),dc=service1,dc=bigcompany,dc=hu" by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none olcAccess: {3}to dn.subtree="dc=bigcompany,dc=hu" by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none olcAccess: {4}to * by self write by anonymous auth by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by * none
Are you sure that a user can modify userPassword and sambaNT/LM password attributes?
yes, I'm sure.
The NT/LM password attribures aren't named any place, the userPassword is, but all user can modify its own - see ACL's above.
No, the olcAccess {3} deny all access inside dc=bigcompany,dc=hu, the rule {4} is never evaluated.
well, you're right - but then how does it works for other users?
It's too late here (.hu), I'll check it again tomorrow.
And as I wrote in first mail, the simple "ldapmodify" works as well.
Do you test to modify only userPassword attribute? Or your modification is also on Samba attributes?
no, I just put the userPassword attribute,
And more important, the other users under the same OU can change their own userpassword/nt/lm password attributes through PHP.
I don't how, because your ACL allow only userPassword modification for 'self'.
yes, that's very interesting.
and one important thing: if this issue is a "simple" ACL problem, why logs slapd an interesting lines (one char in a line)? Why just deny the access...?
The service user (_srvuser1) also can modify (through PHP), but I'ld like to use as the logged user modify its own passwd.
I think you should merge your ACL like this:
olcAccess: {3}to dn.subtree="dc=bigcompany,dc=hu" by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write by self write by * none
thanks, as I wrote, it's too late here to focus the problem, I'll check it tomorrow with fresh brain :).
Thanks for all,
a.
Hi,
On Tue, Sep 18, 2018 at 11:21:07PM +0200, Clément OUDOT wrote:
No, the olcAccess {3} deny all access inside dc=bigcompany,dc=hu, the rule {4} is never evaluated.
yep,
And as I wrote in first mail, the simple "ldapmodify" works as well.
Do you test to modify only userPassword attribute? Or your modification is also on Samba attributes?
SMB attributes modification was denied when I tested today.
And more important, the other users under the same OU can change their own userpassword/nt/lm password attributes through PHP.
I don't how, because your ACL allow only userPassword modification for 'self'.
so, you're right, Clément, and thanks for the clarification.
Our end customers desinformed me - today become clear that nobody can modify their passwords (userPassword, NT/LM passwd) through the webservice.
I've modified ACL rules, now it works as well - thanks again.
Anyway, it's very interesting, how and why slapd logs that lines... they also misleaded me.
Thanks,
a.
openldap-technical@openldap.org
-
Clément OUDOT -
Ervin Hegedüs