[Freeipa-devel] [DRAFT2] Per-domain DNS update permissions

Simo Sorce simo at redhat.com
Fri Jun 22 12:59:58 UTC 2012


On Fri, 2012-06-22 at 14:25 +0200, Martin Kosek wrote:
> 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";)

Oh right!
I like it even more then :-)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-devel mailing list