Portal for ArcGIS SAML Group Membership - #BUG-000122852
Hey all -
Chiming in here with what worked for us. We're still on 10.8.1. I got our organization AD IT specialist involved for the Azure AD admin center stuff.
1) In Azure Active Directory admin center, we added a group claim to the Portal application and configured it to use "Groups assigned to the application" and the Source attribute of "sAMAccount Name". I think returning only the groups assigned to the application resolves the issue of a user being a member of too many groups (as not all their groups will be returned, only the ones associated with Portal in Azure AD). This gets done once per application (i.e., per Portal - if you have Dev, Test, and Prod you would set this up three times, but once it's set it's set for good).
2) Still in Azure AD admin center, we also associated the groups of interest with the application (the Portal of interest; ours is named Portal for ArcGIS TEST). As new Portal groups are set up to track AD groups, those AD groups will need to be added here, particularly if you have the claim set to only return 'Groups assigned to the application'.
3) In ArcGIS Portal, I configured a group per the normal instructions for linking SAML groups. In our case, the Enterprise group name was just the group name, no domain prefix. I think this is because the Source attribute set in Azure AD admin center is just the group name. There is a dropdown option for using a prefix but we didn't use that one.
4) As mentioned by WilliamShoop, the SAML decoder extension (https://chrome.google.com/webstore/detail/saml-message-decoder/mpabchoaimgbdbbjjieoaeiibojelbhm) was very useful for checking the group attribute format in the SAML response. Install it, log into Portal, then check the SAML response available in the extension.
Good luck,
Jena
@frobertsmaf Sorry I missed this. I left that position soon after I posted that, but have now returned. Our AD links had broken in the meantime, so I fixed them and wrote up more comprehensive notes. I hope they help whoever finds this thread next (or you if you're still stumped - if so, let me know).
-----------------------------------------------------------------
This requires work done in two separate places: Azure Active Directory and Portal. The Portal Adminstrative Directory logs can be used for verification during testing, but no configuration is done there. The Esri directions are a start, but don’t cover the Azure AD side of things.
Azure Active Directory
https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Overview
This will take you to the Azure AD for the organization to which you are logged in. If you can’t get in, talk to your IT Azure administrator.
Configure group claim
This should only need to be done once for the entire Portal, although I’ve had to re-do it after upgrades, so … {shrug}. I think you will need to do it for each Portal in a Dev/Test/Prod scenario.
Go to Manage > App Registrations in the left side column
In “All Applications”, search for and select the name of your Portal application (note that this may be slightly different than what you call Portal in the Esri space – talk to your Azure admins if you need help finding the right application); this will go to a new page
From the (new) left side column, select “Manage > Token configuration”. If you do not have permissions for this, click on Manage > Owners” and contact one of those folks to grant you access. In my experience, any owner can add another owner but talk to your IT Azure administrator(s) to be sure that’s okay in your organization.
Click “Add groups claim” and configure:
Your exact interface will depend on your Azure version.
My organization's interface configuration as of 03/2025:
Associate groups with application
This needs to be done for each Portal-AD group tracking pair. At this point, you should be an owner so should have permissions to do this.
Go back to the original Azure URL.
In the left side column, select Manage > Enterprise Applications
In the search box, type Portal (or whatever is a good search word based on the name of your particular Enterprise application in your particular Azure AD)
Select your Portal application; it will switch to a new page
In the (new) left side column, select Users and Groups.
In the top menu, select + Add user/group
On the left side, click None Selected
Search for the AD group of interest. Check the box next to the group of interest and then click Select at the bottom of the panel. For multiple version of the same group names (e.g., with different prefixes), I used trial and error to figure out which to use.
Click Assign.
The group should now show up in the list of Users and groups. This means that the group is now ready to be linked to in Portal.
Portal
Group creation
In Portal, create a new group.
Name it the same as the Active Directory name – this formatting will make those groups readily apparent. Nevertheless, still note that AD linkage in the description. [this was personal preference for our own administrative purposes, not something that is functionally critical]
Who can view this group? Select either Only group members or People in the organization (just not Everyone) [again, organization specific]
Who can join this group? Select Members of an enterprise group. Enter the group name exactly as it shows up in Active Directory. At some point Esri may work out a dropdown list to choose from but right now they don’t have that capability for the type of SAML authentication used by my organization. Do not preface the group name with a domain.
Configure other settings as appropriate.
Note that users are only added to the group as they log into Portal, so upon initial creation the group will be empty other than the owner.
Member addition
When users log into the Portal, they get some kind of authentication response token in the background. When the request is made by the Portal application (because of how we configured it in Azure), the response contains group membership info for that user, for the AD groups associated in Azure for the Portal application. However, that authentication token is good for some period of time (maybe 24 hours?). This means that if someone has an existing token, and an AD group they are of a member of is created in Portal while their current token is still valid, that person won’t show up in the AD-linked group until their token is refreshed.
This process can usually be forced using an InPrivate/Incognito window that will require a “fresh” login and thus a new authentication request. This is very helpful for testing so you don’t have to wait 24 hrs to get results.
Portal Administrative Directory
You can view the user authentication and first-time addition to an AD-linked Portal group in the Portal Admin Directory logs.
Log into the Portal Admin Directory. Typically this is https://{your organization}/portal/portaladmin
Select Resources> Logs
Select Supported Operations > Query
Change the Log Level to Verbose. I think the user login and group membership are actually logged at the Info level, but Verbose is just what I always use when combing through the logs.
Leave the other items as defaults and/or empty to get the most recent entries.
When a user logs in with a fresh token, you should see a couple log entries that show that login.
There should be a separate log entry that says “Adding users [{username}] to group ‘{AD-linked group name}’ (id: {group item id}).”
If you only see the user login entries, the AD linkage didn’t work.