[Freeipa-devel] User life-cycle: nsAccountLock

[Simo Sorce]

On Wed, 2014-06-18 at 15:55 +0200, thierry bordaz wrote:
> 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.

I fail to see the need for this.
In order to be able to to GSSAPI authentication you need to be able to
acquire a ticket for the principal, but the KrbKerberosKey should be
removed when deleting a user and the provisioning system has no way to
create it in the staged entries. So there should be no way for a
principal to make an AS request to start with nor a TGS request, so it
should never be able to have a ticket that would map to one of those
entries.

Also just changing the Sasl mapping will not preclude simple binds ?
But can we simply delete userPassword from deleted and prevent it to be
set in staging (or alternatively force accountlock) ?
Third alternative is to change the ipa pre-bind plugin to preclude any
binding for entries in deleted/staged

Simo.