Migrating from sonar-auth-aad plugin to built-in SAML (Azure AD)

Hi everyone, we’re currently on SonarQube 8.9 LTS (Enterprise edition, single server) and will be upgrading to 9.8 soon.

We are currently authenticating users via SSO with our Azure AD with this plugin: GitHub - hkamel/sonar-auth-aad: Azure Active Directory Authentication for SonarQube. It works well. But I noticed that there is new, built-in SAML auth setup in the latest versions. How to setup Azure AD (sonarqube.org)

Is there a guide for, or does anyone have any experience with, migrating from the plugin to the built-in auth? Will users have two different accounts that need to be combined/migrated together, or will it do that seamlessly?

I found this guide: Migrating SonarQube Users Between Identity Providers (with a focus on LDAP → SAML) - SonarQube / Guides - Sonar Community (sonarsource.com) but it’s not clear to me whether it’s relevant since it mostly discusses a migration from LDAP.

Thanks in advance!


Welcome to the community!

If you look at your users’ current Identity Provider values, what do you see?


Thanks! Good to be here.

Currently the identity provider values are all aad.

Reading that guide through again, looks like it is relevant. I would need to set up the built-in SAML auth, then run a script to migrate each user from aad to saml. Does that sound correct?


Yes, that sounds right.

And as advised in the guide, I would double-check it in a test server because I think this question is still pertinent:

Specifically, you probably want to make sure you only need to migrate the provider & not also set a newExternalIdentity

newExternalIdentity is most relevant in cases where your users are known by their e-mail address with the new Identity Provider rather than an LDAP login (colin.mueller3@example.com vs. cmueller3 ).


1 Like


In our case I think we do want to set a new identity - we don’t need to I guess, but currently everyone’s logins have the format firstname-lastname<numbers> and I think I would prefer to just use the email address to make scripting admin actions easier in the future.

Just thinking out loud. I will report back here after we do the migration to help others who might be searching for this.

1 Like

We completed this, though we did run into a hiccup.

The provider change would not “take”, or complete in some way, unless we deactivated the user after changing their provider. I watched our test user click on both authentication providers after we changed their account over, and both providers gave them a “your account is associated to a different provider” type of error message, and the login would fail. After deactivating their account, they were able to log in with the new provider without problems.

Our script to change over all the users ended up being pretty similar to the one in the article linked above, just with the extra deactivate step, and done in a loop to change over all users with the old provider type in one go.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.