Automatically Assign Users to Groups

[ZachBodenner]

Hello,

I need some help understanding my Enterprise Portal identity store. I have manually set up groups in Enterprise Portal (10.8.1) that roughly correspond to the Active Directory user groups within the organization (Parks, Police, Fire, Assessing, Engineering etc). The Portal is configured for single sign-on where users are simply presented with the blue ESRI sign in button and their AD credentials are passed to the Portal. Additionally, the Portal is configured to automatically create user account if they have not yet signed in. This is the thing I want to work on.

 My goal is to automatically place new users into Portal groups based on AD groups they are a part of, but this is where I get a little confused (I wasn’t primarily responsible for setting this up when we initially rolled out our Portal). So clearly there is some relationship between our Portal sign in configuration and our Windows AD. In the organization’s security settings, the login redirect hits our AD server, I can download the metadata xml, all that. But when I looking at the Identity Store config in the PortalAdmin directory, it shows that the Portal is configured with the type BUILTIN. I must not understand completely because it doesn’t seem to make sense that user store configuration would be built in if there is such a relationship with the actual AD.

How do I appropriately configure the Portal to allow for automatic group placement when a new member signs in for the first time (without removing any currently existing Portal users in the process, if at all possible)? I’m not sure if I’ve provided enough/the right info for anyone to help out, so let me know if there’s anything else I can provide.

Thanks!

[ReeseFacendini]

From what you described, it appears that your Enterprise deployment is configured with SAML and not the traditional Active Directory connection. To have users added to groups, you would need to edit the SAML configuration (Settings -> Security -> Logins) and verify Enable SAML base group membership is turned on. The link below details how to configure this in more detail

https://enterprise.arcgis.com/en/portal/latest/administer/windows/create-groups.htm#ESRI_SECTION1_5E... 

[ZachBodenner]

Ah yes, so I did do that, and then created a new group, set the property in the settings so that only members of "SEC-GroupName" can join. Then we created a test user belonging to that group in Active Directory (to have a fresh faced login) and then I used that account to sign in to the Portal for the first time and they were not placed into the Portal group.

[Scott_Tansley]

Do you know what your SAML2 Identity Provider is?  You have to configure it to broadcast the groups that your users belong to as a part of the SAML2 token exchange.

What is happening behind the scenes is that the IDP will send a token for 'user1' , and if that same token has the SEC-GroupName in it, then when they log in there is a 'text match' which gives them the privileges.

If user1 is logged in to the portal, and is later added to the group in the AD, then Portal is unaware of this until the user logs out and logs in (to the Portal).  This is because there isn't a direct connection to the AD.  The connection only happens at the point of the handshake between Portal and the IDP.  Therefore changes to the AD after that event do not get reflected in portal until the next handshake.

But I have seen some client sites where Azure AD (for example) has not been posting the group membership in the token, so Portal has nothing to match against.  You may need to check the IDP end of the equation as well.

[ZachBodenner]

I'm not 100% sure what the SAML2 provider is. Or rather, I know that we use Microsoft Active Directory (Microsoft Management Console?), but is that the same thing as the Provider? That would make the most sense to me anyway.

[Scott_Tansley]

Yeah so the MMC component is to do with old-skool (still important) management of an AD.  AD's and traditional Integrated Windows Authentication work great in internal environments with old-fashioned network protocols. 

SAML2 works as a technology layer on top of that which basically 'webifies' it so that you can authenticate to web apps and resources (like ArcGIS Enterprise) that 'may not' be hosted on your internal environment.  This is great for current/future architectures and the right choice.

Your IT department is going to need to guide you here on what you use.  That internal AD list of users/groups can be shared directly using Active Directory Federation Services, but that's a bit old hat itself now.  Changes to the AD can also be broadcast to Azure AD or to the likes of OKTA (and others). 

Each has different capabilities and configurations and some of that depends on licensing.

So if, for example, your organisation uses Azure AD, then your Azure Ad admin needs to confirm that they are broadcasting those groups as a part of the SAML2 token.  

[ZachBodenner]

Alright, that's good info. We do have ADFS, so if I read correctly, I would have the ability to share those group names with ADFS but SAML2 is the preferred method? Do you have any resources or walkthroughs that you know of that I could point the other IT folks to for reference?

[Scott_Tansley]

Apologies, I didn't see this response.  The instructions for configuring ADFS are here:

https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-adfs.htm

Make sure you enable the SAML based group membership in the portal - you can edit it after the fact as well:

• Enable SAML based group membership—Enable this option to allow organization members to link specified SAML-based groups to ArcGIS Enterprise groups during the group creation process.

You will be able to export the SP metadatafile, which you pass to you network administrator who need to pay particular attention to:

With this claim, AD FS sends attributes with the names givenname, surname, email, and group membership to ArcGIS Enterprise after authenticating the user. ArcGIS Enterprise then uses the values received in the givenname, surname, and email attributes and populates the first name, last name, and email address of the user account. The values in the group attribute are used to update the user's group membership.

Note:

If you selected the Enable SAML based group membership option when registering AD FS as the SAML IDP, membership for each user is obtained from the SAML assertion response received from the identity provider every time the user successfully signs in. For information on linking SAML groups, see Create groups.

After it's configured, and it's easy on both end, you start creating groups in portal and if the syntax of the group name is an exact match of the name presented by ADFS then you'll get the auto assignment your looking for.

[ZachBodenner]

Thanks again for following up. I already have a bunch of groups - I'm kind of doing this retroactively. Does the selected ADFS group name applied to the group need to happen before any members are present in the group, or should it just apply to any new sign-ins? The reason I ask is because I'm fairly certain I've done these steps but my test of a new user didn't assign them to a group as I expected.

[Scott_Tansley]

Has your network admin set ADFS to forward groups?  The last message said they were hopeful they could do this.