The emails attribute is an attribute in the SCIM standard, which is what Azure AD communicates to GitHub with. emails[type eq "work"].value is how GitHub has decided to represent a user's work email address, and Azure AD sends a value to that. That value is based on the attribute mappings in the provisioning configuration, specifically the source attribute chosen and any functions/expressions used to modify that value. The question I'd look into is: Do both apps have the same mapping for emails[type eq "work"].value - the same source attribute/function(s) on the source? If you're seeing that Azure AD is sending different values for the same user, it seems like the source data is different somehow - either the mapping is different or the value has changed at some point.
Issue with Azure AD user provisioning for GitHub Enterprise Cloud
We are working on GitHub Enterprise Cloud and we have configured SAML single sign on with Azure AD for our GitHub environment. We have 2 environments in GitHub like Sandbox and Production.
So we have created the 2 separate Enterprise Applications, one for Sandbox Github and another one for Production Github. Also we have setup the automatic provisioning and deprovisioning of users in GitHub through Azure AD SSO.
The issue we are facing is that, whenever we add a new user in the Enterprise application for Production GitHub, the invitation is sent to the user on his email address(for example, firstname.lastname@ssss .com), which is the correct and expected behavior.
However when we try to do the same in our Enterprise application for Sandbox GitHub, the invitation is getting sent to user NT account(USER123@ssss .com) and not to the user's email address.
We have created 2 Distributions Lists in Azure AD to manage users, one for production github users and another one for sandbox github users and for both the DLs, the user's email address(firstname.lastname@ssss .com is shown in the Email field.
I have checked the provisioning logs of both the enterprise apps in Azure and I found one difference in the logs.
For Production, its showing "Emails[type eq "work"].value" field as user's email address(for example - firstname.lastname@ssss .com).
However for Sandbox, its showing "Emails[type eq "work"].value" field as NT account(for example - USER123@ssss .com), because of this difference the invitation is being sent to user's NT account instead of email address in Sandbox environment.
So I would like to know why its picking up the different fields for these 2 enterprise apps, even if all the single sign on configuration is same for both(I have verified the configuration).
Where I can find this "Emails[type eq "work"]value" field and how I can modify it to use it the email address for my Sandbox environment?
Please look into this issue and suggest.
Please let us know if anymore information is required from my side.
Just checking in to see if the below answer helped.
Sign in to comment
0 additional answers
Sort by: Most helpful
Hi @Danny Zollner
Thanks for your reply.
I will verify the mapping for emails[type eq "work"].value on both the environments and try to see if I will find any difference.
Hi @Sandeep G-MSFT Yes, it helped.