Hey! I have been having some trouble with user accounts. What I'd like to do is pull users from Azure AD, and allow the users to login to their ingested account using OIDC. The ingestion and login work fine, but when logging in a new user is created, separate from the existing one. I think this happens because the ingester uses the text before the "@" in the mail address as the user id. but the OIDC authentication seems to use the full email address. When I configure the ingester to use the full email, the accounts still mismatch due to different casing. Is there a good way to avoid these kinds of issues? I have noticed that for example the metabase plugin also creates users, so I guess this problem is a bit broader than just these two plugins. If there currently is no way to do this, I would be happy to contribute a solution!

Hi @quaint-branch-37931, thanks for reporting and volunteering to contribute! @big-carpet-38439, are user ids case sensitive? Could you follow up with @quaint-branch-37931 to get this issue resolved?

Hello @quaint-branch-37931, checkout this link There is an environment variable for OIDC that can help you to extract the the email suffix before the @…

Thank you @incalculable-ocean-74010, very helpful video! While extracting the name before "@" would solve my issue for now, I don't think this solution would be ideal since not all users in our azure directory have an @mycompany.com address as principal name.

Hey iasoon, Urns are case sensitive so that would explain the lack of uniqueness. I think the question now is to understand how both options appeared in the system. OIDC would explain the former. Did you ingest user metadata from another system that has the company name in upper case?

Hey Pedro, I just found out the cause of this issue: the OIDC integration uses the

userPrincipalName

field from the Azure AD user directory for usernames, but the ingestion source defaults to the "mail" attribute. Apparently these don't always match in my org's user directory 🙂 It might make sense to ensure that the defaults for these two modules (Azure AD OIDC and Azure AD ingestion source) match up, to avoid these issues for other users. Is there a reason for using the

mail

attribute as default for the ingestion source?

Sounds like a good idea, could you open a feature request for it? About why ingestion sources defaults to the mail I’m not sure. Perhaps it is the most common atribute across OIDC implementations.

Alright, I'll open an issue!

@quaint-branch-37931 Are you thinking that lower-casing the emails is the right solution here?

In the ingestion source, you mean? I think it would be the easiest way around the problem from where we currently stand :) but definitely not the cleanest solution imo. I left a comment on the issue - I think either adding a datahub config option for case insensitivity of some urns, or allow for matching on a secondary case insensitive attribute (such as email) would be the preferred solution.

Hello @big-carpet-38439 🙂 We face in our organization a similar problem. Datahub uses our AD as the OIDC SSO provider and fetches the email addresses of the users from there. Now we ingested data from tableau. There we face the problem that the email addresses are not in the same format as in the AD. Some email addresses include capital letters, most emails are lowercased. Is there any update on this issue how to solve the email matching? Should I create a new issue in Github, is there any chance that this issue could be solved in the future? Thanks in advance!