ArcGIS Enterprise integration with Azure Active Directory - how to get entreprise groups?

[LaurePillet2]

Hi All,

newly i have succeeded in integrating our ArcGIS Enterprise (10.8.1) with  our Azure Active Directory (following the steps of https://community.esri.com/t5/arcgis-enterprise-blog/walk-through-of-azure-active-directory-integrat...)

Our users are now automatically signed-in to ArcGIS Enterprise with their Azure AD accounts.

But  i am facing an issue trying to add entreprise groups in ArcGIS Portal in order to share items.

Nothing happens when searching for groups to add.

Does anyone face the same issue?

[TonyContreras_Frisco_TX]

The first things to verify are that your Azure AD is set up to support Group Claims and that you have set up Portal to use enterprise groups.

When you sign in, use a tool like SAMLTracer to view the information Azure returns during sign in. If Group claims are properly set up, you will see a lists of groups you are in with the format you should use to set up in ArcGIS Portal. (note that you are not able to search for Enterprise Groups that use SAML, such as Azure AD) Then use this information to create your groups following the Help documentation.

[Scott_Tansley]

Hey,

Good work on getting SAML2 configured and users signing in.  I'm trying to read between the lines and think this may answer your question:  

If a user is in the following groups (in Azure AD):

• AllUsers
• GisTeam
• GISAdmins

Then those groups won't automatically exist in the ArcGIS Enterprise.  i.e. they are not auto populated by the Azure AD integration.  So there is nothing to search.  Quite literally, you'd need to create the groups in Portal (manually, python etc..)  with exactly (same syntax) as the Azure Ad groups and then "Enable SAML based group membership".  See the instructions from Tony above.

The easiest way to think of this working is that when the SAML2 token is received from Azure AD, it will 'text match' (in effect) the groups that you're in above and give you access.  So if you create the following groups in Portal:

• GisTeam
• GISAdmins

Then your user will get access to those groups.  If in Azure AD you remove them from GISAdmins, then the next time they login they will only be able to access GisTeam.  

Once you've created the groups in Portal, and enabled them for SAML2, then you'll be able to search for them.

I hope this helps?

[Scott_Tansley]

Just to add.  When we used to work with Integrated Windows Authentication, there was a direct link from the Portal to the Active Directory and so you could search for groups and 'join' them to Portal groups.  

With SAML2 there is no direct link.  ArcGIS Enterprise only gets information on a per-user basis at the time that user logs in.  The group information is held in the SAML2 Claim (token).  There is no direct connection from Portal to the Azure AD to perform the search.  So you have to know the names of the groups that exist in the Azure AD and how they're 'sent' to the Portal so that you can create the groups.

In the original IWA model everything was on your network and so it was easy to 'chat' about groups because of the tight integration.  Now, with SAML2, it's all messages being thrown from one component Azure AD to the other, ArcGIS Enterprise, with a packet of information about the user.   

It completely changes the emphasis of creating groups, and puts the onus on the GIS Admin to know the names of the groups in the Azure AD.  Also bear in mind that some organisations add Aliases in Azure Ad to tidy up naming in the internal AD, so the AD group name may not be sent in the SAML2 claim. 

[LaurePillet2]

Hello Scott,

thanks you so much  for your explanations.

it helps me a lot to understand how all this works and it makes sense.

i did some investigations to find out how group belongings are sent over SAML message in order to add these groups in Portal.

with SAML Tracer,  i got the payload of the SAML message and group belongings   looks like this:

<Attribute Name=http://schemas.microsoft.com/ws/2008/06/identity/claims/groups>

<AttributeValue><group-id- 1></AttributeValue>

<AttributeValue><group-id- 2></AttributeValue>

...

</Attribute>

as you can see, ids are sent and not the group names.

it is quite difficult / impossible to find out which groups to add/manage  for further sharing purposes in Portal.

i need to have explicit group names as in Azure AD.

Any idea how to configure the content of SAML message for exposing groups belongings with group names?

thanks in advance for your help.

regards.

[Scott_Tansley]

Hi,

Typically I don't get involved with the Azure AD side of the fence.  the clients I work with generally have their own Sys Admins who make everything work on that side.  However, the documentation I provide them is:

https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/arcgisenterprise-tutorial

with additional information here:

https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-azure-active- directory.htm

That said, note Tony's comments above and the link to:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims 

Sorry, that's all I have on the Azure side of things.

[tigerwoulds]

I believe Portal does not support automatically importing groups from Azure AD. Once you have Azure AD set as your Portal IDP, there is some 'manual' work involved to create a Portal group and link it to an Azure AD group. I used to work with Azure AD in ArcGIS Enterprise 1081 at a previous org, so I will try to remember the steps.

There is a Portal setting to enable SAML group-based membership, make sure this is checked in your Portal IDP settings. Then, create a new group with the exact name as it appears in Azure AD. In the group creation/settings, check the box that says to use SAML groups. 

Then if a user was a member of that group in Azure AD,  they would be a member of that Portal group the next time they signed in. This was confusing to me at first, but I found that users need to sign out and sign back in before the group membership list in Portal is updated. 

I always had to set up groups this way in order to link them to my Azure AD groups. This probably could have been scripted to create the groups we needed but I never got around to it.