4:46 p.m.
On 27 Nov 2019, at 14:33, Dharmalingam S
<cooldharma06(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs