[Freeipa-devel] Handling of krbPrincpalExpiration in default ACI

[Martin Kosek]

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

I would personally do #1, for simplicity. krbPrincipalExpiration is not
something controlled by ipa-kdb or custom policy to warrant excluding it from
admin's permissions. It is basically just disabling an account in a future,
something that admin can already do with cron+"ipa user-disable $user" - i.e. I
did not see why this attribute needs to be protected from admins.

I am also not sure if the HR example is the right one. We are talking about
permission for admins group, i.e. the "ultimate admins group" that only few
members in the organization should have. Normal admins should be controlled via
RBAC which does not allow krbPrincipalExpiration (but can be added).

Martin