Advice about handling of AD migration

Administrators
#1

Hi,

LAL and a few other labs merged one year ago to form IJCLab. As a result all LAL AD users are in the process of being migrated to a new AD domain (in the same forest), IJCLab. Adding the second AD in the Indico configuration is not a problem but I have a few questions:

  • Email associated with the user is not the same in the new AD as in the LAL AD. That means that Indico doesn’t detect that the new account should be merged with the existing ones having the same email. Is there a way to do this in the background, preferably by script. Something like select all the @ijclab.in2p3.fr users, look for existing accounts that may be a preexisting account for the same user, merge them.

  • Group handling: at some point we’d like to remove the old (LAL) AD from the Indico config, what will be consequence on groups that were provided by this provider. Is it enough to have a group with the same name in the new AD? I guess that no…

Thanks in advance for any hint/suggestion.

#2

Salut Michel,

  • If you are using UIDs and not complete emails for authentication, I would expect that the transition is almost transparent. Users may just want to update the data from the LDAP (AD) instance. (Or you can force the update.)
    But you seem to say that you want to connect to the old and new tree simultaneously during a transition period. Thus, you would have jouvin@lal and jouvin@ijclab (or uid=jouvin,dc=lal,dc=in2p3,dc=fr, but UID=jouvin in both cases) exposed by AD to Indico. I don’t know, how Indico will react on that. If you are lucky, it takes the first.
  • Group memberships are defined by the memberOf attribute of the user entries in AD mode, IIRC. (Whereas LDAP mode uses the members attribute of the group entries.) Thus you seem to be on the easy side with this. Group memberships should be recognised as expected after migration. However, the same question as before comes to my mind: How will Indico handle a group, if it exists in both trees simultaneously, e.g. cn=physiciens,ou=groups,dc=lal,dc=in2p3,dc=fr and cn=physiciens,ou=groups,dc=ijclab...?
#3

Hi Dirk,

Thanks for your answer. The problem of collisions is in fact simpler that it looks at first glance.

  • For users, they are migrated from one domain to the other one, so they should never exist in both domains (we have few exceptions of username collisions between former LAL and IJCLab that will be solved during the migration). And any way one domain is bound to one provider so there should be no ambiguity. Here my only concern is that the “automatic merge” (after confirmation) of accounts bu Indico will not work and I’d like to automatize in some way this work rather than going through the web interface after the complaint by each of the 800 users!

  • For groups, I think we should be lucky enough not to have collisions for the groups that are really used. My problem here is really the continuity of permissions set up on existing events created at LAL time. Imagine a category was restricted to group A (from LAL), we can/will migrate this group to IJCLab at some point. Can we expect that the group A will now be expanded using the information provided by IJCLab AD or for Indico is LAL:A different from IJCLab:A?

Michel

#4

You could have a look at the Identity objects associated with each user (e.g. via the identities relationship on every user), and in particular their identifier. This is what links an Indico User to the login information coming from SSO. So if you have the mappings between users from your two ADs, you could of course update them or even create new identities (so logging in via either one works).

For groups in ACLs we store the IDENTITY_PROVIDERS key and the group name. So if you move groups to a new provider but keep the same name, then it will just keep working. Otherwise, you can of course update the database to change the name for all those rows. Since there are quite a few tables containing ACLs I can send you a small snippet that can do it for all of them in one go if you want.

#5

Thanks for this input. I’ll have a look and ask you if I need more information!