On 05/27/2014 12:39 PM, thierry bordaz wrote:
On 05/27/2014 06:06 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 17:55 +0200, thierry bordaz wrote:
On 05/27/2014 04:35 PM, Martin Kosek wrote:
On 05/27/2014 04:27 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote:
This topic was already discussed in the past, see following part of
the design:
http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP
One of the biggest concern was that to allow operator unstage a
user,
he would
need to have a delete ACI in staging container AND add ACI in the
active users
area - which would also allow him to create any user he wishes in
the
users area.
This is the reason why we preferred to do and control it via MODRDN
and the
reason why Thierry implemented the new ACI for controlling MODRDN
operation:
https://fedorahosted.org/389/ticket/47553
I know that's why we did it, but I had a hard look since then, and I
believe we cannot really use that method.
The reason is simply that we do not control who adds the user
object and
our reason to do the staging is to make it simple for an external
provisioning system to create a basic user entry the way it knows how
to, with only the attributes the provisioning system cares about.
But this means we have no guarantee of what objectclasses are
available
on the object, so we have no guarantees all the necessary structureal
objectclasses have been added in the staging object.
We have to recreate the user object in order to be able to add all
the
right structural objectclasses as those can only be added at object
creation time in an LDAPv3 compliant LDAP server.
Both approach looks possible:
* adding required structural OC+AT in the existing entry
* creating a new entry with all structural OC+AT and update the AT
values with what exists in the stage entry
but I think the second one would be simpler to implement.
My assessment too.
Here again uid uniqueness is a difficulty: if 'uid' exists in stage
entry we need to delete the stage entry before adding the active one.
There is a risk to loose the entry if the add fails. Also it is
important to apply DEL/ADD on the same replica so that DEL csn < ADD
csn.
I think the solution is to not have the uid uniqueness plugin look into
the staging tree. I think it is fair to put the burden of not creatoing
conflicting uids in the provisioning system the drives creating the
staged entries.
If a staged entry has a conflicting uid then at unstaging time we will
throw an error and the admin will have to fix the staged entry (either
remove it and ask the provisioning people to re-provision, or modifying
it).
Ok great.
Recreating the object will also allow you to deal with the other case
you brought forward where the provisioning system used CN as the RDN,
but we want uid.
I am not sure: if some provisioning systems created the two entries
# entry 1
dn: ou=TestUser,cn=staged
users,cn=accounts,cn=provisioning,dc=example,dc=com
objectClass: top
objectClass: account
uid: xxx
ou: TestUser
# entry 2
dn: uid=TestUser,cn=staged
users,cn=accounts,cn=provisioning,dc=example,dc=com
objectClass: top
objectClass: posixAccount
cn: TestUser
uid: TestUser
ipaUniqueID: autogenerate
uidNumber: -1
gidNumber: -1
If we activate both entries. we will create a new entry with all the
required objectclass but at the end we will need to pick up a 'uid'
value.
Entry 2 will keep its 'uid'. Entry 1 we have two solutions, 'xxx'
but then it changes the RDN value or 'TestUser' (the former RDN
value) that is in collision with entry 2.
I think it would simplify the problem if we enforce that staged
entries have 'uid' RDN.
To be honest I do not see the problem.
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.
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.
I understand it gives operators a higher privilege, but I think we'll
have to think harder how to properly handle the issue.
A possibility is to create a "pre-active" status, between 'stage' and
'active'.
The 'stage' container contains raw provisioned entries. 'pre-active' a
copy of the 'stage' entry with all the structural objectclasses.
If 'pre-active' is out of the scope of uid uniqueness, we can add the
'pre-active' entry before removing the 'stage' entry (and rollback in
case of failure). Then do a MODRDN (with appropriate aci) 'pre-active'
-> 'active'.
Sounds like a lot of complexity for a problem we do not really have, all
we need is to not enforce uniqueness in staging.
This proposal was also to limit the operator privilege to do MODRDN
from 'pre-active' to 'active', instead ADD on 'active'.
Just a note:
The modrdn privilege is needed for moving users from normal to deleted
and from deleted to normal or to staging.
This was its primary intent of the RFE. It was not for staging to normal
as that use case can in fact be addressed by adding a normal entry and
then deleting the staged entry.
Simo.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
