[Freeipa-devel] User life Cycle: referential integrity

[thierry bordaz]

On 06/04/2014 07:04 PM, Simo Sorce wrote:
> On Wed, 2014-06-04 at 18:46 +0200, thierry bordaz wrote:
>> On 06/04/2014 06:02 PM, Simo Sorce wrote:
>>> On Wed, 2014-06-04 at 17:46 +0200, thierry bordaz wrote:
>>>> Hello,
>>>>
>>>>           I am looking at the appropriate way to configure DS
>>>>           referential integrity and I am hitting some issues about its
>>>>           scoping and which attributes need to be preserved.
>>>>           
>>>>           
>>>>           User A  and B are both  Active. User A refers user B for
>>>>           example 'owner: <DN user B in Active container>'.
>>>>           If entry A is deleted (user-del), it keeps 'owner: <DN user B
>>>>           in Active container>'. Do we really want to preserve such
>>>>           attributes (owner, member, seeAlso...) in case the user is
>>>>           coming back (user-undel) ?
>>> No, when a user is deleted all references to it in the rest of the tree
>>> should be removed. the entries "it" references can stay I guess, the
>>> user is deleted so no harm should come from it having dangling DNs in
>>> its attributes.
>> Actually it was my concern. If users A then B are moved Active->Delete
>> (user-del), then the reference to B in the 'Active' container is not
>> removed by RI. If for any reason user A returns to Active (user-undel),
>> it contains dangling DN unless it is checked/removed.
>>>>           If it makes sense we may achieve this if we extends RI to both
>>>>           'Active' and 'Delete' container.
>>> Nope, makes no sense.
>>>
>>>>           If we prefer to remove such attributes, then 'user-del' is a
>>>>           MODRDN followed by some MODs or a ADD-DEL where the Delete
>>>>           entry is rebuilt from the 'Active' entry.
>>> Delete must be a modrdn, we cannot delete the entry and re-add it.
>> ok great :)
>>>>           This is a similar problem when using 'stageuser-add <id>
>>>>           --from-delete', the references may become invalid (unless RI
>>>>           also covers Staging).
>>> There should be no references in either staged or delete users, or they
>>> should be adjusted when the user is unstaged/undeleted.
>>>
>>>>           An option would be to accept to have invalid references in
>>>>           'staging' and 'delete', but when the entry is
>>>>           stageuser-activate/user-undel the reference are checked and
>>>>           removed if invalid. Here invalid means, the referred entry
>>>>           does not exist or is not 'Active'.
>>> Yup, this sounds right, when you "activate" the user references need to
>>> be checked and adjusted accordingly.
>> Which attributes need to be checked/adjusted ? those configured in RI ?
>> attributes with DN syntax ?
> Probably all the attrributes with DN syntax, I am partiocularly
> concerned with memberof and manager.
> but memberof should be removed automatically at delete time by the fact
> the user should be removed from any group (does RI do this when an entry
> moves out of scope ?)
Yes that is correct. If the user is removed from the group, memberof 
plugin update the memberof attribute in the user entry.
If the user is moved out of the scope then this is the RI that updates 
the 'member' attribute of the group and then memberof plugin updates  
'memberof'.
So a 'user-del' command removes all 'memberof' attribute.
>
> Manager if there should probably be adjusted, others should probably be
> just wiped and let automember or other plugin or an admin fix whatever
> need fixing ?
Ok to keep Manager and remove others DN syntax attributes.
>
> Seem like a rathole especially if the user has an objectclass in ti the
> has a DN containing attribute as MUST ...
A possibility would be to keep those attributes and replace their values 
with a specific value (empty value ?)

thierry
>
> We need to think of a sensible behavior when this happens as it could be
> an additional custom class/attribute the admin added...
>
> Simo.
>