Azure AD: Get correct email of user

Sushrut Paranjape 61 Reputation points
2021-02-02T13:10:21.913+00:00

Hello,

We are working on a custom application where we need to store user's email in our database. We use Azure AD for authentication.

We came across different client's Azure AD and found that for some users mail field is null. So we need to find a way to get user's correct email.

In one client's case, AD has alternate email field with correct email for user. However for other client, they have user's email same as user principal name.

So it seems there is no standard way to depend on these fields to get correct email address. Is this right or there is a field that we can depend on to get the correct email?

Currently we use below logic:

  1. Check if mail field has value, if yes use mail field as email
  2. If mail is null, then check user principal name. If UPN has #ext# (for external users), then use alternate email field as email.
  3. If UPN do not have #ext# then use UPN as email.

Will this work? Or external user's UPN can be edited to remove #ext# which would cause problem with our logic?

Thank you!

Microsoft Security | Microsoft Entra | Microsoft Entra ID
{count} votes

1 answer

Sort by: Most helpful
  1. Olaf Wrieden 1 Reputation point Microsoft Employee
    2022-01-05T01:34:25.413+00:00

    My colleague ran into this issue while attempting to retrieve a user's email address. I am not an AAD expert (nor speak on behalf of Microsoft) but I have been crossing paths with AAD in side projects for a while. During this time I saw conflicting information about which attribute to deem the 'source of truth' for user emails.

    Background
    My first thought was also the mail attribute but to my surprise this was empty on occasion (some sources explain that this is the Exchange mail provisioned for the user at time of creation). The otherMails (or Alternative Email as it appears in the Portal) offered no help either. UPNs looked promising, until you realise that guests from other tenants or those who signed up via an external identity provider will have #ext# in the UPN, making it inconvenient to work with, as @Sushrut Paranjape points out.

    What worked
    This example shows how to get the user's associated identities (local and federated) via the Identity object (not returned by default)

    GET https://graph.microsoft.com/v1.0/users?$select=displayName,identities  
       
    {  
        "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(displayName,identities)",  
        "value": [  
            {  
                "displayName": "Test User",  
                "identities": [  
                    {  
                        "signInType": "userPrincipalName",  
                        "issuer": "contoso.onmicrosoft.com",  
                        "issuerAssignedId": "user@example.com"  
                    }  
                ]  
            }, ...  
         ]  
    }  
    

    issuerAssignedId = Unique identifier assigned to the user by the issuer. It is an email address depending on the signInType (some providers may only offer usernames).
    We then do some logic at our API to get issuerAssignedId where signInType = "emailAddress".

    In closing
    It is also worth noting that we were using Azure Active Directory B2C, which works really well with external (federated) identity providers. All in all, I can understand why this isn't as straight forward as one would expect. To ensure consistency, the above is simply the best way to abstract each identity provider's fields into its fundamental attributes so that developers working with AAD can reliably access the desired data.

    I hope this adds some clarity to the picture. Please let me know if this was helpful.

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.