On 03/27/2015 10:20 AM, Martin Kosek wrote:
On 03/26/2015 10:32 PM, Dmitri Pal wrote:
On 03/26/2015 04:24 PM, thierry bordaz wrote:
On 03/26/2015 08:53 PM, Dmitri Pal wrote:
On 03/26/2015 02:33 PM, thierry bordaz wrote:
On 03/26/2015 04:21 PM, Martin Kosek wrote:
First, I think *this* thread should better be on freeipa-devel since it is
only
upstream feature specific, no planning inside.
On 03/26/2015 02:02 PM, thierry bordaz wrote:
On 03/26/2015 01:02 PM, David Kupka wrote:
Hi Thierry!
On 03/26/2015 11:45 AM, thierry bordaz wrote:
Hello,
In user life cycle, when a stage entry is activated it is moved from
a stage container to an active container.
Then when an active entry is deleted it is moved to a delete
container.
The move stage->active is done by creating a new entry (ADD active,
DEL stage).
The move active->delete can be done with a MODRDN of the entry or
also ADD delete_entry + DEL active_entry.
I was wondering what is the best approach: MODRDN vs ADD-DEL.
Why did we choose ADD-DEL over MODRDN in stage->active procedure? Could we
use the same reasoning to repeat the choice?
ADD-DEL was preferred (for activate) mainly because there are provisioning
systems. So the stage entry can contain invalid values or missing some
attributes/values. We need to rebuild a very clean entry, picking some
values
from the stage entry, if the values are valid.
The original proposal was MODRDN to also allow us control the operation with
the MODRDN ACIs you added to DS. You cannot really control DEL and ADD
operation together, so you would have to allow the person who activates the
entries to delete any staged user and add a new active user.
I agree, MODRDN was the original proposal but finally ADD-DEL was choosen
because entries added by provisioning system should be validated (in
particular structural objectclass
https://www.redhat.com/archives/freeipa-devel/2014-May/msg00471.html).
That means that the helpdesk person that has rights to ADD on active
container need DEL rights on staging.
In fact MODRDN ACI brings an additional control, where the helpdesk person
does not need that rights.
This is original section I added for this reasoning:
http://www.freeipa.org/index.php?title=V4/User_Life-Cycle_Management#MODRDN_vs._ADD-DEL
Why cannot the activate command be multistep? I.e. move the entry to active
users, generate missing fields and enable the entry? It could also trigger
automember for that user, we have commands for it.
I think it is also feasible.
Just a remark if the stage entry has a userpassword/krbPrincipalKey, at the
time it is modrdn to active container we can authenticate with it.
This even if all the initialization steps are not completed.
In this case, I see the benefits for ADD-DEL. It would have to be done anyway,
if structural objectclasses are added to the entry, right?
Please just make sure to include the end result and reasoning to the cleaned
wiki design.
Sure. I am doing this right now.
For user-del, the active entry is valid, we just want to clear some
attributes.
Actually digging into the archive it was already discussed
https://www.redhat.com/archives/freeipa-devel/2014-June/msg00080.html
leading
to MODRDN !
I would really prefer custom LDAP plugin that would do the processing of
delete
entry (re-add it or convert DEL to MODRDN, if possible). The reason is that
with this approach, people/software would be still able to use standard
ldapdelete operation to delete users instead of figuring out they need to
MODRDN it to some location to keep the company policies.
The ticket 3911 says: [RFE] Allow managing users add/modify/*delete* via LDAP
client. With MODRDN DEL approach, you are breaking the delete part.
That is right, using DS plugin it hides some complexity at the application
level.
If we introduce user-del options '--preserve|--permanent', we would need to
give this option to the DEL (control ?).
Hm. I do not see it that way.
I see that command has two options do a MODRDN (--preserve) or DEL
(--permanent) depending on flags. This is the decision made in framework
before it hits DS. So I am not sure anything should be given to the control.
It would be invoked only in case of MOD. In case of DEL everything would
work as now. No?
(adding freeipa-devel)
If this is the application or CLI that decides what to do, I agree that
--preserve will issue a MODRDN and --permanent a DEL.
My understanding of Martin point, is that the application/CLI should not
decide but just issue a DEL.
This would be the job of a DS plugin to convert the DEL into a MODRDN (or
ADD-DEL) to move the entry from active to delete container.
In that case, DS plugin needs to decide if the DEL intend to preserve the
entry (move to delete container) or permanently delete the entry (true ldap
delete).
I was wondering how to give to DS plugin the way to decide: configuration
parameter, DEL control..
I see but this seem more complicated than what I propose and I do not see a
reason for the complexity.
My main concern was that there may be software doing direct LDAP additions and
modifications for the users. This is the reason why this ticket was opened. The
software may ADD staging users, helpdesk would activate them and the software
would DELete them at the end of the life cycle.
In my proposal, to enable deleted users container, one just needs to switch a
button and activate the DS plugin which would make DEL into a MODRDN.
With your proposal, the application would need to be learned to do MODRDN
instead of LDAP DEL - is that really feasible?
Applications that use to DEL active entries at the end of the life cycle
would act as 'user-del --permanent'.
If they need to be ULC aware they will need to learn to do MODRDN to do
a 'user-del --preserve'.
Now if the default mode is '--preserve' a DEL on active container should
be rejected or be translated.
Simo, do you have any preference here since your name was called out based on
your note to do modrdn in
https://www.redhat.com/archives/freeipa-devel/2014-June/msg00083.html
?
Thanks,
Martin
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
