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:
> 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
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.
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 understand it gives operators a higher privilege, but I think we'll
have to think harder how to properly handle the issue.
Perhaps the best way is to create a new "proxy-API" to "promote" users
from a staging area. This service will have the privilege to create
users using its own credentials instead of those of the operator.
This can be done later, meanwhile we will have to accept operators need
the privilege to create users.
Freeipa-devel mailing list