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…
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...?
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?
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.
For the record, here is a summary on how we handled this migration. After discussing with @ThiefMaster, we identified that our use case was matching the situation described in the documentation at Authentication — Indico 3.0-dev documentation, unfrotunately not with a lot of details on how to do it!
The basic idea is that in a situation like ours where Shibboleth is used to authenticated all users, local and remote, and where all the identity information for the user can be retrieved from the Shibboleth auth information, there is no real need for specific actions from the identity provider at login time and that its roles is mainly to check group membership (another responsibility of an identity provider). To achive this, as group membership is checked by identifying users known by the identity provider who match the logged user email, it should be enough to have the Shibboleth auth provider associated with the LDAP identity provider to resolve groups from AD, as long as the email returned as part of the Shibboleth auth is matching the user email in AD.
Unfortunately, it does not work of the shelf as the user Indico identifier built by the LDAP identity provider is based on the LDAP username which is not returned by the Shibboleth auth provider. There are 2 options to fix this:
Associate the standard Shibboleth Identity provider with the auth provider and configure an additional LDAP identity provider mapped to AD but not associated with an auth provider. It will then be used to resolve groups.
Use a modified version of the LDAP identity provider that handles properly the auth information returned by the Shibboleth auth provider. I opened a PR along this line that will probably not be merged in the short term, if it ever happens… at least it gives the idea. It is what we use at IJCLab now.
Another aspect of the migration is upding the identity provider name associated with users and/or groups. It can be easily done with indico shell (with some help from @ThiefMaster)
)