[Freeipa-devel] Handling of krbPrincpalExpiration in default ACI

Martin Kosek mkosek at redhat.com
Wed Jan 8 15:33:27 UTC 2014


On 01/08/2014 04:19 PM, Simo Sorce wrote:
> On Wed, 2014-01-08 at 15:49 +0100, Petr Viktorin wrote:
>> 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.
> 
> Right which is why I say 2 or 3, I do not have a strong preference, if
> it is a hassle to create a new permission now, feel free to fold into
> the std modify users permission for now.
> 
> Simo.

I still do not understand why we should do #2 or #3 only. Then lower level
admins with the permission assigned could do the job, but the super admin still
couldn't. IMO doing #1 (and #2 or #3) would make more sense.

Martin




More information about the Freeipa-devel mailing list