We are running SCIM in Azure and are unable to create users where the primary email and userPrincipalName are not the same. In the documentation it says emailsoruserName but for users were the primary email and userPrincipalName are the same we have no issues.
Is the SCIM setup to not allow username and email to be different?
On a side note. While troubleshooting this I tried to do a GET to the /Users endpoint but no data was returned even though the request was 200 OK. Is that intended?
Same issue with us. Bitwarden supports keeps saying that UPN and email should be the same.
4 users within our organisation with a different e-mail domain but same SSO company domain weāve now manually added to the admin console; and linked the groups mannualy.
1 user got divorced, 1 user got married. UPN stayed the same, but primary e-mail adres was changed. same kind of issues.
We use SCIM provisioning from Azure where al fields are linked including Email linked to UPN field from Azure.
SSO from Azure all fields towards Bitwarden are linked to UPN.
But still Bitwarding onboarding retrieves the email address somehow from Azure during onboarding.
Bitwarden support keeps telling dat UPN and Email should be te same.
But this is not an option for my organization.
Iām now working with this workarround manual creation of user accounts.;
I donāt see a solution yet.
In Azure, you can change the attribute mappings on SCIM and SAML. For the āUsernameā SCIM attribute (and NameID SAML claim), you could send them the email instead of UPN.
That said, Bitwarden is wrong. There is no requirement that UPN and email match. Some companies intentionally make them different so that knowing someoneās email does not aid in compromising a login. And, if somebody does not have a company mailbox, it is perfectly legal to put their gmail account in the email field so it shows up in corporate/school address book.
Weāve intentionally mapped al e-mail related fields in SCIM and SAML to UPN field in Azure AD. But the behaviour of onboarding with SCIM provisioned accounts just got wearder and wearder.
In the onboarding proces Bitwarden managed still retrieves e-mail and UPN form what I think is the SAML / SSO application.
What weāve done now is set e-mail[āworkā] to user.mail (this is the default). And externalId to the Azure Ad objectID (Guid code). This was default set to āmailnicknameā
With a powershell script provided by Bitwarden support weāve set al external ID filed fo our other users to Azure Ad objectID.
The users with difference between UPN and E-Mail weāve created manual in Bitwarden. On the onboarding proces we see that Bitwarden then creates a second account in Bitwarden with status invited. I think that Bitwarden calls this JIT provisioning. This second account with status invite is then deleted.
I think there are background processes setup which are not visual to customer, but Bitwarden doesnāt want to redesign so that a UPN and e-mail address may differ.