On 06/22/2012 02:23 PM, Simo Sorce wrote: > On Fri, 2012-06-22 at 12:20 +0200, Martin Kosek wrote: >> On 06/18/2012 05:37 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On Fri, 2012-06-15 at 10:15 -0400, Simo Sorce wrote: >>>>> On Fri, 2012-06-15 at 15:22 +0200, Martin Kosek wrote: >>>>>> Hello all, >>>>>> >>>>>> In a scope of ticket 2511 I would like to implement an ability to >>>>>> delegate a DNS update permissions to chosen user (or host) without >>>>>> having to give the user full "Update DNS Entries" privileges, i.e. >>>>>> allow >>>>>> him to modify any DNS zone or record. >>>>>> >>>>>> So far, this is what I would like to do (comments welcome): >>>>>> >>>>>> 1) Create new objectclass "idnsManagedZone" with "managedBy" attribute >>>>>> in MAY list >>>>>> 2) Create new DNS commands: >>>>>> a] dnszone-add-managedby [--users=USERS] [--hosts=HOSTS] >>>>>> b] dnszone-remove-managedby [--users=USERS] [--hosts=HOSTS] >>>>>> - these commands would add/remove chosen user/host DN to managedBy >>>>>> attribute in chosen DNS zone >>>>>> 3) Add new generic ACIs to cn=dns,$SUFFIX: >>>>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>>>> "Users and hosts can add DNS entries";allow (add) userattr = >>>>>> "parent[1].managedby#USERDN";) >>>>>> ... add similar ACIs for UPDATE, REMOVE access >>>>>> >>>>>> With these steps done, all that an administrator would need to do to >>>>>> delegate a management of a DNS zone "example.com" is to run this >>>>>> command: >>>>>> $ ipa dnszone-add-managedby example.com --users=fbar >>>>>> >>>>>> The only downside I found so far is that the user would already need to >>>>>> have "Read DNS Entries" permission assigned, otherwise he would not be >>>>>> able to actually read DNS entries (allow rules can't take precedence >>>>>> over deny rule we implemented to deny public access to DNS tree). >>>>>> >>>>>> An admin could of course create a special privilege and role with just >>>>>> "Read DNS Entries" permission and then assign it to relevant >>>>>> users/groups, but this looks awkward. Any idea to make this simpler? >>>>>> Maybe creating a group "dns readers" by default which would allow such >>>>>> access? >>>>> >>>>> Change the deny rule to deny to everyone except the user in >>>>> "parent[1].managedby#USERDN" ? >>>>> >>>>> Simo. >>>>> >>>> >>>> Good idea, I will do that. I will just use >>>> "parent[0,1].managedby#USERDN" so that user can also read the zone >>>> record. This way, a selected user will have read/write access to the >>>> chosen zone only, which is exactly what we want to achieve. >>> >>> Yes, this sounds workable to me too. >>> >>> rob >>> >> >> There were some second thoughts about the proposed design, which I would >> like to discuss so that we can eventually accept another (better) >> solution for this feature. >> >> The main concern here was that proposed solution (based on user list in >> managedBy attribute in DNS zone) is not in line with the rest of >> permission&privilege architecture in IPA. >> >> Here is another idea how to address the feature (I tested it and it >> would work): >> 1) Get rid of the deny rule on cn=dns,$SUFFIX by modifying global access >> rule (a working patch attached) to avoid current and future issues with >> extending ACIs (deny rules are evil). >> >> 2) Add new Managed Entry Definition and Template to automatically add >> "Manage DNS zone $idsname" permission. These could be used with standard >> IPA privileges, roles and thus could be assigned to users, groups, >> hosts, hostgroups... >> >> 3) New DNS zone managedBy attribute won't be manageable by user, but it >> will hold a DN of the managed Permission entry >> >> 4) Add the following ACIs to cn=dns,$SUFFIX: >> aci: (targetattr = "*") >> (version 3.0; acl "Read DNS entries"; allow (read,search,compare) >> userattr = "parent[0,1].managedby#GROUPDN";) >> >> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX") >> (version 3.0;acl "Add dns entries";allow (add) >> userattr = "parent[1].managedby#GROUPDN";) >> >> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX") >> (version 3.0;acl "Remove DNS entries";allow (delete) >> userattr = "parent[1].managedby#GROUPDN";) >> >> aci: (targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || >> dnsclass || arecord || aaaarecord || a6record || nsrecord || cnamerecord >> || ptrrecord || srvrecord || txtrecord || mxrecord || mdrecord || >> hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord || >> locrecord || nxtrecord || naptrrecord || kxrecord || certrecord || >> dnamerecord || dsrecord || sshfprecord || rrsigrecord || nsecrecord || >> idnsname || idnszoneactive || idnssoamname || idnssoarname || >> idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || >> idnssoaminimum || idnsupdatepolicy || idnsallowquery || >> idnsallowtransfer || idnsallowsyncptr || idnsforwardpolicy || >> idnsforwarders") >> (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "Update >> DNS Entries";allow (write) userattr = "parent[0,1].managedby#GROUPDN";) >> >> I needed to add permission DN to the managedBy attribute so that I could >> create just one set of generic ACIs without having to create a set of >> ACIs for every new zone and thus let users with "Update DNS entries" >> permission have a write access to the "aci" attribute. >> >> Would this design be better than the previous one? Comments welcome. > > Removing Deny ACIs would be great. > But don't we need a second set of ACIs to allow uber admins to still > control all zones ? or is that part of current ACIs not going to > change ? > > Simo. >
Thanks to the removal of the deny rule, this would be already allowed by this existing ACI: aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonicalName || krbUPEnabled || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || krbTicketFlags || ipaUniqueId || memberOf || serverHostName || enrolledBy")(version 3.0; acl "Admin can manage any entry"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel