Converting OpenLdap ACL policies to 389-ds aci policies.

[Dharmalingam S]

Hi,

Thanks for quick response in both IRC and forums.

Please find the following test ACL policies which am trying to convert.

olcAccess: to dn.subtree="dc=test,dc=com" attrs=userPassword
  by dn.exact="cn=repl,dc=test,dc=com" write
  by group.exact="cn=DirectoryAdmins,ou=Groups,dc=test,dc=com" write
  by dn.children="ou=DirectoryAdmins,dc=test,dc=com" write
  by self write
  by anonymous auth  (( need to find))
  by * none

I.   
 aci: (target = "ldap:///dc=test,dc=com")(targetattr = "userPassword")(version 3.0; acl "ACI for userPassword attribute";
  allow(write) (userdn = "ldap:///cn=repl,dc=test,dc=com") OR
               (groupdn = "ldap:///cn=DirectoryAdmins,ou=Groups,dc=test,dc=com") OR
               (groupdn = "ldap:///ou=DirectoryAdmins,dc=test,dc=com") OR
               (userdn = "ldap:///self");)
## TODO: 
##  read and search opeartions are there need to verify with auth
# aci: (targetattr = "userPassword")(version 3.0; acl "Enable only auth for anonymous";
#  allow(read, search) userdn= "ldap://anyone") 
 aci: (targetattr = "userPassword")(version 3.0; acl "Disable for all other users";
  deny(all) (userdn= "ldap:///all");)

II. With multiple allow in one rule:
 aci: (target = "ldap:///dc=test,dc=com")(targetattr = "userPassword")(version 3.0; acl "ACI for userPassword attribute";
  allow(write) (userdn = "ldap:///cn=repl,dc=test,dc=com"); allow(write)(groupdn = "ldap:///cn=DirectoryAdmins,ou=Groups,dc=test,dc=com"); allow(write)(groupdn = "ldap:///ou=DirectoryAdmins,dc=test,dc=com"); allow(write)(userdn = "ldap:///self");)

Kindly can you review and let me know if i am wrong.

Thanks & Regards
Cooldharma06

[William Brown]

> On 27 Nov 2019, at 14:33, Dharmalingam S  wrote:
>
> Hi,
>
> Thanks for quick response in both IRC and forums.
>
> Please find the following test ACL policies which am trying to convert.
>
> olcAccess: to dn.subtree="dc=test,dc=com" attrs=userPassword
>  by dn.exact="cn=repl,dc=test,dc=com" write
>  by group.exact="cn=DirectoryAdmins,ou=Groups,dc=test,dc=com" write
>  by dn.children="ou=DirectoryAdmins,dc=test,dc=com" write
>  by self write
>  by anonymous auth  (( need to find))
>  by * none

OpenLDAP's aci's are more like "here is an attribute, and all the different ways an object could interact with it".

Where as 389-ds is more about "Here is a subtree of attributes that can be manipulated by these objects"

You'll probably end up with multiple ACI's to handle this scenario as a result.

Expanding your openldap rules roughly gives:

allow cn=repl write to userPassword on dc=...

allow cn=Directory Admins write userPassword on dc=...
allow all entries below ou=Directory Admins write on userPassword on dc=....
allow self write to userPassword for all entries under dc=....
allow anonymous to bind
deny all to read.
> I.   
> aci: (target = "ldap:///dc=test,dc=com")(targetattr = "userPassword")(version 3.0; acl "ACI for userPassword attribute";
>  allow(write) (userdn = "ldap:///cn=repl,dc=test,dc=com") OR
>               (groupdn = "ldap:///cn=DirectoryAdmins,ou=Groups,dc=test,dc=com") OR
>               (groupdn = "ldap:///ou=DirectoryAdmins,dc=test,dc=com") OR
>               (userdn = "ldap:///self");)
> ## TODO: 
> ##  read and search opeartions are there need to verify with auth
> # aci: (targetattr = "userPassword")(version 3.0; acl "Enable only auth for anonymous";
> #  allow(read, search) userdn= "ldap://anyone") 
> aci: (targetattr = "userPassword")(version 3.0; acl "Disable for all other users";
>  deny(all) (userdn= "ldap:///all");)
>
> II. With multiple allow in one rule:
> aci: (target = "ldap:///dc=test,dc=com")(targetattr = "userPassword")(version 3.0; acl "ACI for userPassword attribute";
>  allow(write) (userdn = "ldap:///cn=repl,dc=test,dc=com"); allow(write)(groupdn = "ldap:///cn=DirectoryAdmins,ou=Groups,dc=test,dc=com"); allow(write)(groupdn = "ldap:///ou=DirectoryAdmins,dc=test,dc=com"); allow(write)(userdn = "ldap:///self");)

So taking those above:

cn=repl isn't needed because in 389-ds a replication dn is internally granted full read-write. So that rule can go.

Similar, internal to the server, we can read userPassword so there is no need for "anonymous" auth.

And finally, the "lack of allow" becomes a deny, so we don't need the * none.

That leaves:

allow cn=Directory Admins write userPassword on dc=...
allow all entries below ou=Directory Admins write on userPassword on dc=....
allow self write to userPassword for all entries under dc=....

These three as the only rules you need to emulate.

To further improve this, you *should* consider making entries below ou=Directory Admins a member of cn=Directory Admins, because that's going to be easier to audit and apply rules to. Generally it should ALWAYS be groups that grant a permission rather than location of storage in the directory. The primary reason is flexibility. If yfou have ou=Directory Admins and ou=Server Admins, you can only be in one ou, but not both. Groups allow you to express permissions far more dynamically, and you can keep all user accounts
under ou=people instead.

Anyway, if you do that then you only need two rules:

(targetattr="userPassword")(version 3.0; acl "Enable self partial modify"; allow (write)(userdn="ldap:///self");)
(targetattr="userPassword")(version 3.0; acl "Enable diradmins to reset user passwords"; allow (write)(groupdn="ldap:///cn=Directory Admins,dc=test,dc=com");)

You put both of these aci's as an ldap modify on to your root entry, the domain object:

ldapmodify -f change.ldif ...

and change.ldif would contain:

dn: dc=test,dc=com
changetype: modify
add: aci
aci: (targetattr="userPassword")(version 3.0; acl "Enable self partial modify"; allow (write)(userdn="ldap:///self");)
aci: (targetattr="userPassword")(version 3.0; acl "Enable diradmins to reset user passwords"; allow (write)(groupdn="ldap:///cn=Directory Admins,dc=test,dc=com");)
-

Now, I haven't tested that modify, but it's probably going to work. I highly recommend having a "staging" or "dev" instance with production, or production-like data to test on to see if changes like this perform as you expect.

Hope that helps,
> Kindly can you review and let me know if i am wrong.

All good, we're happy to review and help out :)

PS:

You can see all aci's that are already in place with:

ldapsearch -D 'cn=directory manager' -w -b dc=test,dc=com -s sub '(aci=*)' aci

Hope that helps!
> Thanks & Regards
> Cooldharma06
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs