Hi again, Important precision... The proposed approach allows to solve easily the pb caused by the user_id_attribute change. But it has a MAJOR DRAWBACK: the public id for the affected users no longer matches the one that would generated by OpenStack which uses a deterministic algorithm to be able to do a mapping purge/populate sequenceas explained in https://docs.openstack.org/keystone/ussuri/admin/configuration.html. So if doing what we did you SHOULD NOT use anymore keystone-manage mapping_populate for those users (that mens you should not do a pureg for tese entries, populate does nothing forexisting entries) or you will have to revert the public_id change for these entries. Michel Le 01/02/2024 à 09:37, Michel Jouvin a écrit :
Hi,
For the record, it turned out to be a pretty easy and smooth operation. What we did was:
- Save the existing ID for the domain users who used the cloud at least once: MariaDB [keystone]> select user.id, user.extra, id_mapping.local_id from user inner join id_mapping on id_mapping.public_id=user.id where user.domain_id = "actual_domain_id"; - Update user_id_attribute in the Keysone domain configuration - Wait for entries withe new user_id_attribute to appear in table id_mapping (column local_id) - In id_mapping, for each user, swap the public_id value between the previous user entry and the new one (use a select on local_id to find them)
After these changes users should retrieve access to everything as they are still map to the same OpenStack user.
Best regards,
Michel
Le 24/01/2024 à 10:29, Michel Jouvin a écrit :
Hi,
For historical (and bad) resons, we decided 10 years ago when we created our cloud that the Keystone LDAP backend will use the CN as the user_id_attribute rather than the usual SAMAccountName. Since then it has been a source of various problems with CN changes, accented characters in CN... We'd like to change it to SAMAccountName but there is clearly no easy/supported way of doing it and we are looking for some information on the best way to do it and the risks if somebody has some clues... It should impact ~30 users so not a huge number...
What we have in mind is basically:
- Change the backend attribute - Import new accounts - Assign the new accounts to the same projects as the ol accounts, with the same role
One of the foreseen problemsis that old and new accounts will share the same user_name_attribute, based on SAMAccountName. It is not allowed by openstack if I'm right so for the scenario to work we need to change the user_name_attribute of old accounts to something different (we don't care that the user cannot use the account during the transition peroid as long as it doesn't impact active resources). Is it enough to update it in the database? We'd prefer to keep the old accounts in OpenStack until the end of the transition...
Another minor issue is the reassignment of keypairs to the new account. It is poosble to ask the user to reload its public keys but we were wondering it there was a not too risky way of doing it for him/her by updating the DB (I guess there is no API for this).
Thanks in advance if you have any thought/information to share. Best regards.
Michel