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
>