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.
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 ?
This would allow us to be sure that nobody can bind/authenticate to these users
without having to manipulate nsAccountLock attribute.
The only downside is that this would not be effective in older FreeIPA
versions, but AFAIR, we specified that if User Life Cycle is enabled, all
server should have at least 4.1 - otherwise for example deleted users would be
put to the special container or old servers would not have the appropriate DS
plugins updates.
Martin
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
