[Freeipa-devel] User life-cycle: nsAccountLock

[thierry bordaz]

On 06/18/2014 03:40 PM, Simo Sorce wrote:
> On Wed, 2014-06-18 at 15:22 +0200, thierry bordaz wrote:
>> On 06/18/2014 12:47 PM, 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?
>> That is correct, provisioning system can create entries in Staging area
>> without nsAccountLock or with nsAccountLock: False.
>> With stageuser-add we have this ability but as you described below it
>> can be done with different ways.
>>
>> We may create a new DS plugin to enforce added stage entries (or
>> modifications) have the expected values. But I think the idea was to
>> make Stage container free to receive any kind of entries. This was the
>> activation job to make the control.
>>
>> activation (stageuser-activate) is setting 'nsAccountLock: False' so
>> currently at least this method is manipulating nsAccountLock.
> Shouldn't it just remove the attribute if present ?

Yes as we decide to not use this attribute to allow/disallow . I will 
remove it from CLIs
>
>>> 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?
>> Sure this solution would also have the advantages to prevent
>> authentication from Staging/Delete container and allow authentication
>> only from 'Active' container.
>> For LDAP BIND pre-bind which plugin are you thinking of ? a new one ?
>>
>> About Kerberos update, my understanding is that if we restrict (in sasl
>> mapping) the baseDN template (nsSaslMapBaseDNTemplate) to
>> cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication
>> only to Active user. Is that correct ?
> No, we have many other principals that can bind to DS in
> cn=computers,cn=users cn=services,cn=users and cn=kerberos at least, you
> cannot exclude those. Besides there are also simple binds.
Ok.
We want to exclude 'Stage' and 'Delete' containers. A possibility is to 
create a new multivalued attribute (like 'nsSaslMapExcludeSubtree') for 
nsSaslMapping entry.

thanks
thierry
>
> Simo.
>
>