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.



_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to