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