Martin Kosek wrote:
On Mon, 2011-08-22 at 18:26 -0400, Rob Crittenden wrote:
We used to calculate has_keytab based on whether krblastpwdchange was
set. We did this because you can't see whether a krbPrincipalKey is set.

We had a need to see whether a password was set on hosts. What I did was
create a new ACI that allows search on krbPrincpalKey and userPassword.
This means you can search for attribute existence and gives us a better
picture of what entries have.

This adds a new fake attribute, has_password. I've added has_password
and has_keytab to user objects as well so you can see whether a password
is set on a user (and may be useful during migration).


This all seems to work fine for hosts. With user object, I just wonder
if it is possible to detect if user has a keytab, but I guess not. I
generated a keytab for user but I have not seen some valuable difference
in user LDAP data.

This way, has_keytab seems to always have the same value as has_password
even though no keytab has been generated. Wouldn't has_keytab=True
confuse users?


If you search as Directory Manager you can see the attributes.

The typical case is if the user has a password they have a keytab, our password plugin enforces that.

If you are migrating users though you can have the case where you have a password but not a keytab.

For users we can suppress these if --all isn't requested if you'd like.


Freeipa-devel mailing list

Reply via email to