BUG-000122852: Portal for ArcGIS does not refresh the membership fo..
We discovered this bug last year during our 10.7 install and configuration. This is a key feature we were hoping to leverage and have since been unable to do so and required a third party integration be developed to sync our portal with employee directory.
It is still in the new status. Can someone from ESRI shed some light on the path of this bug being fixed? Has anyone else experienced this bug? Any work arounds?
Mathias
Based on the information provided in the bug, this issue cannot be reproduced. I have tested this on 10.7 and later releases and in all cases the group membership is refreshed correctly each time the enterprise user logs in. Access to content within those groups is updated as well. If a user is removed from an enterprise group and the SAML assertion at the next login reflects this, the group membership within Portal gets updated and the user is not able to access content shared with the linked group.
Jeff
Jeff,
Thank you for taking the time to respond to my inquiry. Could the underlying operating system version and/or ADFS version be the difference in reproducing and not reproducing the error?
Using SAML Tracer in Chrome I am able to see the SAML responses and claims. The XML being returned for the Group claim looks like the following. Do you see the same?
Also, the group name values are blurred but are like the following "myDomain\the_group_name". Is this the valid format Portal is looking for? I have tried configuring Portal groups with and without the domain name value.
Thank you,
Mathias,
Yes, the SAML response looks correct and matches the response I see when using ADFS. The format of the group name that Portal expects depends on what you type in when you link the Portal group to the enterprise group. When using SAML-based enterprise groups, there is not a way to search or query for valid groups. The format and name of the enterprise group must be known beforehand and the user linking the Portal group just types it in. During a login, Portal compares that with the attribute values that are passed in through the SAML assertion (case-insensitive) and adjusts membership accordingly.
Keep in mind for SAML-based groups, there is not a way to refresh the membership through portaladmin. There is also not a regular 24-hour full refresh. The only refresh occurs when a user logs in.
Hello,
We just discovered the same issue on ArcGIS Enterprise 10.8 !
When configuring a group viewable and joinable by only "Members of an Enterprise Group", users can't see them even when they are in the group.
It used to work ! The funny thing is that they can see old groups created with older version of Portal for ArcGIS that are configured the exact same way !!!
I decoded the reply from SAML when logging in:
And of course when trying to access webmap from that group, I get 403 error.
This is a big issue for us !!
Good morning all,
Not sure if this applies to everyone in this thread or that ESRI is aware but in our enterprise, we saw that only certain users were unable to be added to Portal groups via SAML. We configured our SAML-group based membership with Azure AD and when I tested with my account, I was assigned to the appropriate Portal groups based on my AD groups, but later found out not all users were being assigned. Upon investigating I found the article at the bottom of this message describing SAML responses that causes this behavior. If a user is a member of a lot of AD groups, the SAML response with provide a link instead of a listing of the user's AD groups. The link does not work with the GIS Portal, because it is specifically looking for the listing of AD groups to link it to the Portal groups. To fix this we are working with our server team to configure Azure AD to only send over the AD groups related to our Portal, so the list is not cumbersome. Using the SAML Message Decoder Chrome extension you can see the difference in the response AD list vs link:
Working Account
<Attribute Name=http://schemas.microsoft.com/ws/2008/06/identity/claims/groups>
<All groups listed…..>
Defective Account
<Attribute Name=http://schemas.microsoft.com/claims/groups.link>
<AttributeValue>https://graph.windows.net/3a86ebff-1254-450e-bd5e-161fedab6b9a/users/275ed1e6-0b3b-4662-9dae-5b60f14a7ea5/getMemberObjects</AttributeValue>
https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-saml-tokens
I hope this helps,
Bill
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
@JenaF I haven't seen many people use this function of ArcGIS Enterprise. Would you be willing to chat with me about how you guys set it up? Sorry to but you but you seem to be the latest one to post on this topic. If you have other refrence materials you used if you can provide them that would be great!
@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.
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.
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:
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.
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.
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.
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.
We use a different way, and this is to set the group claim to 'Security groups' option and then in the advanced section add a prefix filter. This way you don't have to keep adding groups into your enterprise app and only the AD groups you actually require are passed in the group claim. A little bit naming standards need to be done for this to work.
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
