[Freeipa-devel] Handling of krbPrincpalExpiration in default ACI

[Martin Kosek]

On 01/08/2014 03:54 PM, Tomas Babej wrote:
> 
> On 01/08/2014 03:46 PM, Rob Crittenden wrote:
>> Simo Sorce wrote:
>>> On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote:
>>>> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote:
>>>>> Hi,
>>>>>
>>>>> I'm working on exposing the krbPrincipalExpiration attribute in the
>>>>> CLI
>>>>> (https://fedorahosted.org/freeipa/ticket/3306). However, this
>>>>> attribute
>>>>> is exempted from the default ACL "Admin can manage any entry"
>>>>> (install/share/default-aci.ldif +8).
>>>>>
>>>>> Now, we have several options:
>>>>> 1.) remove it from blacklisted options in "Admin can manage any
>>>>> entry" ACL
>>>>
>>>> Nope, it was excluded on purpose, to prevent admins from playing with
>>>> it.
>>>
>>> OOOk and maybe If I stop reading "Password" when I see "Principal" I
>>> would make more sense :-(
>>>
>>>>> 2.) create a new permission that allows writing to this attribute
>>>>> (i.e.
>>>>> Modify Kerberos principal expiration)
>>>>
>>>> Yep, this sounds right.
>>>>
>>>>> 3.) add this attribute to a existing permission (Modify users seems
>>>>> like
>>>>> the best candidate, however, the attribute does not really fit even
>>>>> there)
>>>>
>>>> Nope, needs to be explicit for auditing purposes that admins are
>>>> able to
>>>> violate the password policies of users by changing their expiration
>>>> date.
>>>>
>>>>> I see that the the approach 1.) was taken with the krbTicketFlags
>>>>> attribute in the past (install/updates/60-trusts.update +38).
>>>>
>>>> Yes, however I think this too should be probably explicit and have its
>>>> own permission with the new permission framework.
>>>>
>>>>> What would be the best approach here?
>>>>
>>>> I say 2.
>>>
>>> Given this is "Principal"'s expiration, I amend my suggestion.
>>>
>>> I say you can choose either 2 or 3. The *Account Expiration* (which is
>>> what really this attribute controls) is clearly a user attribute and it
>>> is not strictly necessary to have a separate permission.
>>> However it is not a bad idea either. I think there may be cases when
>>> some administrative process wants to allow admins to modify users, but
>>> not let them extend a user account lifetime. The account lifetime may be
>>> something that is controlled by an HR department and should not be
>>> modifiable by all admins.
>>>
>>> Simo.
>>>
>>
>> I was wondering about your initial logic but you came to the same
>> conclusion I did so I didn't say anything :-)
>>
>> I think I prefer #2 so that there is explicit permission to modify
>> this policy-related attribute.
>>
>> rob
> 
> Yes, I wouldn't personally go with #3 since the rest of the attributes
> in the permission seem more benign.
> 
> What puzzles me though: going with #2 and not with #1 will create the
> situation where we have an attribute that is exposed by Web UI / CLI,
> but members of the admins group do not have this permission to edit this
> attribute.
> 
> Or should we make assign this permission to admins group by default?
> They still can, in default configuration, change the
> roles/privileges/permissions anyway.

admins have no default permission so far, I would not start with it now. You
would need to add special privilege, roles...

Doing just #1 is IMO much easier for us to do. I also did not see the main
concern why the super admins cannot modify it.

Martin