[Freeipa-devel] User life-cycle: nsAccountLock

[thierry bordaz]

On 06/19/2014 09:06 AM, 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.
Setting a Staging password policy would keep userPassword in clear. This 
is needed because generation of krb keys is done by ipa-pwd on an 
unhashed password.

For kerberos authentication, to limit ipa-pwd to generate  the keys only 
in Active container, we need to provide a scope to that plugin. I did 
not find such scope and needs to be implemented.
When deleting an Active user, krb keys are removed. That means that only 
Active entries have krb keys.

For simple bind, we can do simple bind on Active entry. we can not bind 
with Delete user as userPassword has been removed.
Stage users may contain userPassword (in clear), we can rely on a cos to 
lock the entry or reject a bind in pre-op plugin.

thierry

>
> Martin