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
> 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
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
Freeipa-devel mailing list