On 05/28/2014 02:55 PM, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:
On 05/28/2014 08:22 AM, Martin Kosek wrote:
On 05/27/2014 08:18 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:
On Tue, 27 May 2014, Simo Sorce wrote:
On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:
On 05/27/2014 06:56 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:
On 05/27/2014 06:06 PM, Simo Sorce wrote:
We just need to care about the 'uid' attribute in the staged entry, and
pick that to generate the RDN of the user in the active tree. If there
are conflicts the 'unstage' will fail cleanly, as the 'add' operation
will just fail (due to non unique RDN) and the admin will have to take
care of the situation.
In that case the provisioning system created a staging entry
ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE
It could be an issue for the provisioning system to retrieve the entry
it created.
Too bad for the provisioning system, we are not going to allow users to
have a form that does not use uid in the RDN in IPA.
Sounds like a lot of complexity for a problem we do not really have, all
we need is to not enforce uniqueness in staging.
This proposal was also to limit the operator privilege to do MODRDN from
'pre-active' to 'active', instead ADD on 'active'.
It is not useful, the operator still needs to be able to create in
pre-active ... so it can still create what it wants.
yes that is correct.
Does it address the security concern, if the operator that is allowed to
add in 'staging'/'pre-active' is different from the one allowed to move
the entry in 'active' ?
Well it really depends on 'who' the operator is.
We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.
The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give priority
to getting the workflow right in terms of the way it works.
I think re-creating the user object gives us better chances at handling
the overall workflow and fixing up entries accordingly to the management
framework view of what a user needs to look like, so in the end I prefer
that route.
I agree. It also opens us a way to handle import of any foreign schema
person if staged object uses extensibleObject object class where we are
in control of what exactly will get into the actual tree.
Right it allows us to do things like filter out objectclass or
attributes the provisioning system adds but that the admin does not want
in the final entry. This is not something we may want to build into the
solution from day zero, but it gives us the option to build it more
easily, as a framework filter on the 'unstage' operation.
(We so need to be able to copy additional objectclasses and their
attributes from day 0 though).
Simo.
Ok, thanks guys, I see an agreement. Thierry, we should now update all the
information here:
http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP
(you can even link this thread in the archives)
Martin
Yes I will do that.
Regarding workflow, it looks a priority that active entries are valid
(regarding FreeIPA).
Currently CLI offers:
* ipa user-add (in active)
* ipa user-add --stage (in stage).
In order to prevent admin to add a corrupted entry in active and force
any entry to go through the filter of objectclass/attribute, we could
make 'ipa user-add' to create entry in staging and 'ipa user-add
--active' to create entry in active. Even more, should we support to add
entry directly in 'active' or rather only support 'user-add' to go only
in staging ?
I do not see why this would ever be necessary, ipa user-add cannot
create a "corrupt entry" by definition.
I am actually not very happy with the "ipa user-add --stage" idea, the
staging area is necessary for when you do not create a full 'ipa' user
entry, but rather for when a provisioning system creates an "incomplete"
entry.
I'm not sure what the use case for this is either, other than
simplifying testing. If you have access to the IPA API then why bother
staging a user?
rob
I agree, FreeIPA CLI or API will create valid entry.
Now a staging area can be used for storing entries waiting for an
approval. For an example, a cron job scanning the stage container may
send request to an approver. The approver having the ability to read the
'stage' entry will issue 'ipa user-unstage' or not.
thanks
thierry
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
