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



Freeipa-devel mailing list

Reply via email to