<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 05/28/2014 02:55 PM, Rob Crittenden
wrote:<br>
</div>
<blockquote cite="mid:5385DCBA.4000608@redhat.com" type="cite">
<pre wrap="">Simo Sorce wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 05/28/2014 08:22 AM, Martin Kosek wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 05/27/2014 08:18 PM, Simo Sorce wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 27 May 2014, Simo Sorce wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 05/27/2014 06:56 PM, Simo Sorce wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 05/27/2014 06:06 PM, Simo Sorce wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Sounds like a lot of complexity for a problem we do not really have, all
we need is to not enforce uniqueness in staging.
</pre>
</blockquote>
<pre wrap="">This proposal was also to limit the operator privilege to do MODRDN from
'pre-active' to 'active', instead ADD on 'active'.
</pre>
</blockquote>
<pre wrap="">It is not useful, the operator still needs to be able to create in
pre-active ... so it can still create what it wants.
</pre>
</blockquote>
<pre wrap="">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' ?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Ok, thanks guys, I see an agreement. Thierry, we should now update all the
information here:
<a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP">http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP</a>
(you can even link this thread in the archives)
Martin
</pre>
</blockquote>
<pre wrap="">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 ?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
<font face="Times New Roman, Times, serif">I agree, FreeIPA CLI or
API will create valid entry.<br>
<br>
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.<br>
<br>
thanks <br>
thierry<br>
</font>
</body>
</html>