Azure Active Directory - unable to retrieve extended attributes (groups)

Help
, ,
1

After following guide to linking Azure Active Directory (AAD) as IdP to Auth0, adding all the required permission to the AAD application in Azure Console and following the extra steps for configuring (as described in Step #2 - auth0 dot com/docs/connections/enterprise/azure-active-directory/v2#2-configure-the-permissions).

08
081778×858 275 KB

I have added three groups to one test identity within the AAD.

31
311547×772 92.1 KB

And checked the IdP settings

  • Extended Attributes > Extended Profile: true
  • Extended Attributes > Get user groups: true
  • Extended Attributes > Include all the groups the user is member of, even if the user is not a direct member: true
  • Max number of groups to retrieve: 2

How can I make sure that the groups are retrieved from the AAD when user logs-in? Because in the identity the groups I have assigned to this user in the AAD are not retrieved. When I open the profile within Auth0 (as Raw JSON) no groups array is found:

Raw JSON (sensitive data masked)
{
“upn”: “live,com#hotmail,com",
“azure_id”: "SX9j”,
“given_name”: “pet****”,
“family_name”: “van****”,
“nickname”: “live,com#hotmail,com",
“tenantid”: "8dd8”,
“email”: “pete****”,
“oid”: “36a8****”,
“email_verified”: true,
“name”: “hotmail,com van”,
“updated_at”: “2019-05-27T12:54:02.337Z”,
“user_id”: “waad|SX9ji****”,
“picture”: “",
“identities”: [
{
“user_id”: "SX9ji”,
“provider”: “waad”,
“connection”: “examp****-waad”,
“isSocial”: false
}
],
“created_at”: “2019-05-27T12:45:46.702Z”,
“last_ip”: “****”,
“last_login”: “2019-05-27T12:54:02.337Z”,
“logins_count”: 2,
“blocked_for”: ,
“guardian_authenticators”:
}

2

Do you see any errors in the tenant logs when a user from Azure AD logs in?
Auth0 needs to do an API call to retrieve the groups and do to that it needs the client secret (API secret) in the Azure AD connection to be properly configured. If there’s a problem with the client secret, you will see an error in the logs.

3

@nicolas_sabena the Client ID and Client Secret from the Azure Active Directory are correctly configured in Auth0. In the logs there is only ‘SUCCESS’ events visible (Azure AD logs), and ‘Success Signup’, ‘Success Login’, ‘Success Exchange’ (in Auth0 logs).

Do you perhaps have some more details available on for example what error to expect when Client Secret is misconfigured, or an example of how the Raw JSON of identity profile should look like when groups are successfully synced?

The following rights are granted in the Azure AD which should be according to the documentation:

08
081778×858 189 KB

(although I must note that the Azure Portal seems to have gotten an update in the meanwhile sync the documentation has been written: Connect Your App to Microsoft Azure Active Directory)

4

Hi again @peter.vanvelzen.

Just tested on my side.

  • A wrong client secret would have different consequences depending on the protocol selected in the Azure AD connection configuration:
    • If you selected OpenID Connect (the default), an incorrect/expired client secret would generate a “Failed to obtain access token” and prevent the user from logging in.
    • If you selected WS-Federation, an incorrect client secret would generate a warning in the tenant logs with something like this:
      Unable to get access token: AADSTS7000215: Invalid client secret is provided.

  • If the permissions are not properly configured or granted, you would see a Warning in the tenant logs, with something like this:

    Unable to get extended attributes: {"odata.error":{"code":"Authorization_RequestDenied","message":{"lang":"en","value":"Insufficient privileges to complete the operation."}}

Now, there’s another problem here that unfortunately I missed from your first message: it seems that you are testing this with an @hotmail account (a Microsoft Account). Groups and extended profile information will only work for users directly created in Azure AD (those where the “source” is Azure Active Directory).

Can you try with a different user and see how it goes?

5

Good day @nicolas_sabena, indeed the issue seemed to be the use of @hotmail.com identity (so the list of groups does not get through from Azure AD to Auth0, even though the groups are assigned to the @hotmail.com user).

I can confirm now with creating a new user + assigning groups to user, when logging in the groups are retrieved as following:

"groups": [
    "Group - child",
    "Office 365 group",
    "Group - parent"
],

My only concern is that from this array there does not seem to be a way to distinguish from which tenant the groups originate, so what if I setup multiple tenants using Azure AD then theoretically one tenant could create a group with same name of group in another tenant to gain authorization - but this is a use case I will investigate further myself (e.g. by applying Auth0 rules/hooks).

1 Like
6

For users coming from Azure AD you’ll get a tenantid property that tells you the Azure AD tenant from where the user is coming from.

7

I understand it is possible to read the tenantid property to retrieve source of log-in. My concern which needs further investigation is more: the scenario where user’s identities from different AD’s have already been consolidated into one account (linked account functionality). And in this case what would happen if after logging in through first Azure AD (with e.g. group {“First_AD_group_”, “Admin”}, then logging in through a second connection Azure AD which happens to use same group naming.

There would need to be a way whether the “Admin” group was retrieved from Azure AD #1, or #2, or a way to apply hook to the profile creation/update event, to add prefix to new groups e.g. “First_AD_group_Admin”.

8

Oh, I see your point now.
Would you mind leaving that feedback at Auth0: Secure access for everyone. But not just anyone.? That goes directly to the Product team, so if you can explain the scenario there, this is great input for them.

In the meantime, if you plan on linking accounts from multiple Azure AD sources and use groups for authorization purposes, it might be a good idea to use Rules and talk directly to the Azure graph API to get the information directly from them.

There’s also a related issue that you might run into: Auth0 won’t fetch the users or extended profile for users coming from a different Azure AD than the domain defined for the connection (i.e. if you use the common authentication endpoint, combined with a “multi-tenant” app registration in Azure).

This gist fetches groups for users coming from a different tenant than the one used in the connection. You can tweak it to add the tenant name, or other information that could be useful for your authorization needs related to groups. :+1: