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

[Rob Crittenden]

Simo Sorce wrote:
> 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.
>

Yes, this looks like it will work and eliminating a deny rule is a 
definite plus.

rob