[Freeipa-devel] Status/Question about User life cycle

[thierry bordaz]

On 05/23/2014 10:55 AM, Martin Kosek wrote:
> On 05/23/2014 10:22 AM, thierry bordaz wrote:
>> On 05/23/2014 10:04 AM, Martin Kosek wrote:
>>> On 05/23/2014 09:34 AM, thierry bordaz wrote:
> ...
>>>>>>       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
>>>>> Why is having ipaUniqueID attribute a problem for a staged user?
>>>> My understanding is that an account moves from 'staging' to 'active' when we
>>>> receive a formal approval.
>>> Right.
>> 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...
> 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.
>
>>>> Before the approval, the ipaUniqueID is 'generate'
>>>> and after it is a valid account.
>>> Right.
>>>
>>>> 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
>>> 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.
>> 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.
> 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
ok thanks for the clarifications :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140523/11650978/attachment.htm>