[Freeipa-devel] Handling of krbPrincpalExpiration in default ACI

[Petr Viktorin]

On 01/08/2014 03:43 PM, 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.

How rare would this case be? We'll have manageable permissions, it 
should be easy to exclude the attribute and add a separate permission 
for it.


-- 
Petr³