> On 27 Nov 2019, at 14:33, Dharmalingam S <cooldharm...@gmail.com> 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 -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > 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/389-users@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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/389-users@lists.fedoraproject.org
