[Freeipa-devel] User life-cycle: nsAccountLock

[Simo Sorce]

On Thu, 2014-06-19 at 14:47 +0200, Martin Kosek wrote:
> On 06/19/2014 02:33 PM, Simo Sorce wrote:
> > On Thu, 2014-06-19 at 09:06 +0200, Martin Kosek wrote:
> >> On 06/18/2014 06:09 PM, Simo Sorce wrote:
> >>> On Wed, 2014-06-18 at 17:49 +0200, thierry bordaz wrote:
> >>>> On 06/18/2014 04:45 PM, Simo Sorce wrote:
> >>>>> On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote:
> >>>>>> On 06/18/2014 03:31 PM, Simo Sorce wrote:
> >>>>>>> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote:
> >>>>>>>> On 06/17/2014 05:59 PM, thierry bordaz wrote:
> >>>>>>>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote:
> >> ...
> >>>>> Right, if we allow setting userPassword this would happen, but then if
> >>>>> we allow setting userPassword do we also generate Kerberos Keys ?
> >>>
> >>>> Currently setting of the userPassword (add entry or mod entry) triggers 
> >>>> generation of krb keys (I guess in ipa-kdb).
> >>>
> >>> No it happen in ipa-pwd-extop
> >>>
> >>>>> If this is the case then we probably need to change the pre-bind plugin
> >>>>> (and ipa-kdb ?) to explicitly exclude staging (and deleted ?).
> >>>
> >>>> Do you mean to prevent ipa-kdb to generate krb keys when the this is 
> >>>> Delete/Staging
> >>>
> >>> No I mean to prevent the ipa-kdb driver (it's the KDC driver) from
> >>> returning any key even if present for entries in those suffixes.
> >>
> >> IMO we should definitely allow provisioning system to set userPassword, looks
> >> like a valid use case to me.
> >>
> >>>>> I was actually planning to use staging to allow kadmin to create
> >>>>> entries, so we need to be careful how ipa-kdb limits access to staging,
> >>>>> I would guess it should pretend KrbKerberosKey is not present for those
> >>>>> entries.
> >>
> >> When someone creates user with plain text userPassword, we normally hash it and
> >> also generate krbPrincipalKey, right? Should we then simply avoid both
> >> operations in the staging area, let the password be stored in plain text and
> >> let the Kerberos keys and attributes be generated during user activation? It
> >> will happen via recreating the entry anyway, so the right operations should be
> >> triggered.
> > 
> > No, we do not store plain text passwords.
> > 
> > Simo.
> 
> Ok, but then we need to allow generation krbPrincipalKey for staged users, when
> a new user is filed and userPassword is set. Otherwise you would not be able to
> generate the krpPrincipalKey during user activation.

This is ok, this is actually what happens today if you do it.
The only thing we need to do is to change the code to not allow use of
keys for staged/deleted entries, which we have to do anyway if we allow
to write userPassword.

One issue is what to do with expiration times.
When you store a password we do create keys and hash it, but we also
mark it as expired by default.

I guess we want to maintain that ?

Simo.