Keystone LDAP backend: need to change user_id_attribute from CN to SAMAccountName
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
Any thought on this? Thanks in advance. 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
Hi Michel, My temptation would be to try having a look at the keystone dB and see what the unique identifier is for the LDAP user's for role assignment. It may be possible to update that so that as keystone is concerned nothing changes. Probably something to try in staging first Hope this helps Thanks Alex Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Michel Jouvin <michel.jouvin@ijclab.in2p3.fr> Sent: Thursday, January 25, 2024 8:52:17 AM To: openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: Re: Keystone LDAP backend: need to change user_id_attribute from CN to SAMAccountName Any thought on this? Thanks in advance. 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
Hi Michel, If you’re considering making a leap, it may be worth exploring federation with Keycloak, we’ve been doing this and it’s working really nicely and opens up all sorts of options (LDAP, switch to Azure AD/Okta, etc) without much complications. We’ve also enabled user-sync through https://github.com/vexxhost/keystone-keycloak-backend which will make all groups and users automatically appear inside Keystone instantly (as opposed to after one sign on), and then combining that with https://github.com/vexxhost/keystoneauth-websso which allows users to login using the CLI with their browser. This also helps enforce any MFA or anything like that across all OpenStack access. I understsand this isn’t the ask here, but just want to put it on your eyes in case you’re going through this big change anyways. Good luck! Mohammed From: Michel Jouvin <michel.jouvin@ijclab.in2p3.fr> Date: Thursday, January 25, 2024 at 3:56 AM To: openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: Re: Keystone LDAP backend: need to change user_id_attribute from CN to SAMAccountName [You don't often get email from michel.jouvin@ijclab.in2p3.fr. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Any thought on this? Thanks in advance. 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
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
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
participants (3)
-
Alexander Dibbo - STFC UKRI
-
Michel Jouvin
-
Mohammed Naser