Re: Insufficient acces in some cases

[Clément OUDOT <clement.oudot@worteks.com>]

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

-- 
Clément Oudot | Identity Solutions Manager

clement.oudot@worteks.com


Worteks | https://www.worteks.com