[Freeipa-devel] [PATCH] 851 add password indicator

[Martin Kosek]

On Wed, 2011-08-24 at 07:40 -0400, Rob Crittenden wrote:
> 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).
> >>
> >> rob
> >
> > 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?
> >
> > Martin
> >
> 
> If you search as Directory Manager you can see the attributes.

I am.  That was an misunderstanding, I saw the key attributes I just
didn't know that our password plugin enforces the keytab.

> 
> 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.

OK, this justifies the usefulness of has_keytab :-)

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

Not necessary, lets keep it consistent with the host plugin.

ACK & Pushed to master, ipa-2-1.

Martin