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. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel