[Freeipa-devel] Handling of krbPrincpalExpiration in default ACI

[Simo Sorce]

On Wed, 2014-01-08 at 16:41 +0100, Tomas Babej wrote:
> 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.
> >
> Maybe the approach we should take is both #1 and #2. Not taking the #1
> doesn't make sense for consistency's sake and reasons Martin mentioned
> (we do not prevent admin user for doing this anyway, just make it more
> complicated).
> 
> For fine-grained permission management, we can create new
> permission/privilege/role, and that's #2. This can be part of the
> current permission work, right?

Works for me, having 2 is important for when we rework the current
default ACI system and make admins also use permissions.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York