[Freeipa-devel] Handling of krbPrincpalExpiration in default ACI

[Simo Sorce]

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.

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