[Freeipa-devel] Handling of krbPrincpalExpiration in default ACI

[Tomas Babej]

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.