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 _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
