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