[Freeipa-devel] User life-cycle: nsAccountLock

[thierry bordaz]

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:
>>>> ...
>>>>>      Thanks for your precise feedback and sorry for my late answer.
>>>>>      So if I try to consolidate my understandings, the workflow would be:
>>>>>
>>>>>       1. Staging (container: cn=staged
>>>>>          users,cn=accounts,cn=provisioning,SUFFIX)
>>>>>            * ipa stageuser-add <login>
>>>>>              It creates a stage entry with
>>>>>
>>>>>                  uidNumber: -1
>>>>>                  gidNumber: -1
>>>>>                  ipaUniqueID: autogenerate
>>>>>                  description: __no_upg__
>>>>>                  manager: checks that the DN is an active user
>>>>>                  nsAccountLock: True
>>>> I was thinking about the nsAccountLock part again. Should we really force
>>>> provisioning systems to set it to True for staged users? Should we even
>>>> manipulate it in stageduser plugin?
>>> No, thinking hard about it I think nsAccountLock should be completely
>>> ignored in the staged area. It is an operational attribute that is
>>> responsibility of IPA admins, provisioning systems have nothing to do
>>> with it. If they do not want a user to be available they simply do not
>>> provision it. If they do then it is on the admin to decide if/when to
>>> unstage the user and make it available.
>> A Stage user is waiting for an approval before being Active. And an
>> approver may have a look at its properties to decide.
>> During the time it remains in Staging, admin do not want someone to bind
>> with that entry even if the provisioning system set the password.
>> pre-bind plugin or cos are possibilites to prevent binding with that entry.
> 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).
>
> 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
>
> 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.
>
>>>> The original reason why I proposed it in
>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management
>>>> is to prevent LDAP BINDs on such user or Kerberos authentication on such user.
>>>> Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND
>>>> pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX?
>>> The staged user should have it's userPassword anmd KrbKerberosKey
>>> removed, so no binding should be possible.
>> That means a Delete user being staged (ipa stageuser-add <login>
>> --from-delete) will loose its password/keys.
>> I believe it is an acceptable limitation else the admin would prefere to
>> do 'ipa user-undelete <login>'.
> What I meant here is the ipa-del would drop the passwords and keys, so
> there is no undelete that will restore them. But if we think we should
> preserve them then the above option (change in ipa-kdb plugin) is the
> best way to go to mask out these entries.
I do not know what are the consequences of dropping password and keys.
A use case would be someone that returns back to an organization and get 
his account undelete. This person will likely remember his previous 
password and would expect to be authenticate with kerberos using that 
password.
Now if password and keys have been removed, he should reset his password 
before being authenticate. I think it is an acceptable limitation.

>
>>>> This would allow us to be sure that nobody can bind/authenticate to these users
>>>> without having to manipulate nsAccountLock attribute.
>>> We should just make sure no credentials are set ?
>>> Is there any valid reson for the provisioning system to be allowed to
>>> set userPassword ? (It can't set KrbKerberosKey anyway)
>> Does that mean stageuser-add/mod should not support options around
>> password setting ?
> Well the problem is that is you allow setting userPassword then you need
> it in the clear and have to also generate Kerberos Keys, and then we
> need to prevent them from being used (ipa-kdb change).
>
> Allowing to set a pre-hashed userPassword won't work because then the
> user cannot authenticate with Kerberos and the server need to be
> permanently set in migration mode or the user must be forced to go
> somewhere to change the password so setting a pre-shared password in the
> first place is basically useless.
>
> Otherwise we can simply forbid them being set by provisioning and the
> only thing we need to do is to remove userPassword/KrbPrincipalKey when
> the user is moved to the deleted tree.
>
> Simo.
>
>
>