On 06/18/2014 03:31 PM, Simo Sorce wrote:
On Wed, 2014-06-18 at 12:47 +0200, 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?
No, thinking hard about it I think nsAccountLock should be completely
ignored in the staged area. It is an operational attribute that is
responsibility of IPA admins, provisioning systems have nothing to do
with it. If they do not want a user to be available they simply do not
provision it. If they do then it is on the admin to decide if/when to
unstage the user and make it available.
A Stage user is waiting for an approval before being Active. And an
approver may have a look at its properties to decide.
During the time it remains in Staging, admin do not want someone to bind
with that entry even if the provisioning system set the password.
pre-bind plugin or cos are possibilites to prevent binding with that entry.
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?
The staged user should have it's userPassword anmd KrbKerberosKey
removed, so no binding should be possible.
That means a Delete user being staged (ipa stageuser-add <login>
--from-delete) will loose its password/keys.
I believe it is an acceptable limitation else the admin would prefere to
do 'ipa user-undelete <login>'.
This would allow us to be sure that nobody can bind/authenticate to these users
without having to manipulate nsAccountLock attribute.
We should just make sure no credentials are set ?
Is there any valid reson for the provisioning system to be allowed to
set userPassword ? (It can't set KrbKerberosKey anyway)
Does that mean stageuser-add/mod should not support options around
password setting ?
Alternatively/optionally just set a CoS that enforces nsAccountLock to
be set on all staged entries without having to explicitly set it ?
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.
Yeah I do not see an issue with older servers, esp if we do not allow
credentials on the entry anyway.
Simo.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
