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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
