<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/23/2014 10:55 AM, Martin Kosek
wrote:<br>
</div>
<blockquote cite="mid:537F0D0B.6070804@redhat.com" type="cite">
<pre wrap="">On 05/23/2014 10:22 AM, thierry bordaz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 05/23/2014 10:04 AM, Martin Kosek wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 05/23/2014 09:34 AM, thierry bordaz wrote:
</pre>
</blockquote>
</blockquote>
<pre wrap="">...
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> 3) inactivate the user
(active to inactive) ipa user-inactivate# (after the command
ipaUniqueID=<final value>)
Here there is no possibility to move back an active entry to
staging, because in staging
the entries do not have ipaUniqueID set
</pre>
</blockquote>
<pre wrap="">Why is having ipaUniqueID attribute a problem for a staged user?
</pre>
</blockquote>
<pre wrap="">My understanding is that an account moves from 'staging' to 'active' when we
receive a formal approval.
</pre>
</blockquote>
<pre wrap="">Right.
</pre>
</blockquote>
<pre wrap="">
Here what is not clear to me is what is this approval.
Would it be a user granted the autorization to run 'ipa user-activate', or an
attribute set in the 'staging' entry (a task could them 'activate' all the
staging entries which receive the approval), or a kind of 'approved group' that
contains the DN of approved entries, or...
</pre>
</blockquote>
<pre wrap="">
We do not need to care about what approval is in a particular deployment, what
we need to care about is how to give privileges to someone to do the activation
(ipa user-activate). This should be solved via standard permission/ACI to
MODRDN from staging area to active users area (the MODRDN ACI you did) that can
be assigned to group of privileged operators.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Before the approval, the ipaUniqueID is 'generate'
and after it is a valid account.
</pre>
</blockquote>
<pre wrap="">Right.
</pre>
<blockquote type="cite">
<pre wrap="">For example, the user attribute should be:
Staging Active Disabled
ipaUniqueID: generate ipaUniqueID: abc-def-ghi-jkl ipaUniqueID:
abc-def-ghi-jkl
uidNumber: -1 uidNumber: 1234uidNumber: 1234
gidNumber: -1 gidNumber: 1234gidNumber: 1234
<no memberof> attribute memberof: * <no
memberof>:
nsaccountlock: true nsaccountlock: false
nsaccountlock: true
</pre>
</blockquote>
<pre wrap="">Nice overview, we may even add it to design. Looks correct to me, though I
still do not undestand practical reasons why a user moved from active to staged
container cannot have ipaUniqueID already generated.
</pre>
</blockquote>
<pre wrap="">I think an advantage of having 'active'->'staging' is that the customer has not
to understand some constraint of the state machine. Everything is allowed
staging<-->active<-->delete.
On the opposite I believe
* the entries in staging will not have the same "properties". Some may
have ipaUniqueID/uidNumber set, some others may not.
* What would be the real difference between 'staging' and 'delete'. It
looks like the same state.
</pre>
</blockquote>
<pre wrap="">
It is true that the entries will be similar from attributes and values POV.
However, they will be different in a meaning. Staging area may contain dozen
recently provisioned users *planned* to be activated after the approval is
made, while the deleted users container may contain hundreds or thousands of
users deleted long time ago.
But from LDAP behavior POV, the users will be similar - you cannot BIND to
them, you cannot kinit with them.
Martin
</pre>
</blockquote>
<font face="Times New Roman, Times, serif">ok thanks for the
clarifications <span class="moz-smiley-s1"><span> :-) </span></span></font><br>
</body>
</html>