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 !!
Hi. I understand your frustration with this. There are many factors involved in some of these issues and while we try to perform testing in different configurations and scenarios, there are some that definitely get missed. I searched through our bug fixes for 10.8.1 and found one related to SAML group membership that you might be encountering.
BUG-000121049 - If an ArcGIS group links to a group in the SAML Identity Provider (IDP) is owned by a SAML user who is not listed as a member of the group in the SAML assertion response, the group membership of the user fails to update.
Since yours was working previously though and started failing after the upgrade, this may not apply to you. Due to the complexity in this issue and since you have 2 environments that behave differently, I would recommend contacting our Support team.
Thanks for your reply Jeff Smith.
I am still investigating and I found out why it was working on one deployment and not the other: it was because I tested with a newly created account !
I deleted an account on production as it was only a 'viewer' and did not have any item, asked him to login again, and after initial login it worked ! User could access the group he could not see before because his account had been created again in Portal.
It means that group membership is computed at account creation but not computed for new groups. Does that help to identify the possible issue ?
BTW, I don't think it is BUG-000121049 as I am member of that of the group in the SAML response and creator of the group.
Thanks !
Nicholas,
I agree with you. It sounds like it has something to do with the old accounts that have been upgraded from earlier releases. Have the enterprise accounts on your production system been through multiple upgrades or were those accounts created at 10.7.1? I can't think of too much that was added for users between 10.7.1 and 10.8 but if they are older, there could be something else. The group refresh is supposed to occur every time a user logs in, not just when the account gets created. The debug logs should reveal the group refresh during login. Do you see anything there?
In fact it has nothing to do with the old accounts nor the upgrade as I am able to reproduce the issue on brand new 10.8 environment.
I was misguided because group membership is correctly computed at account initialization but not afterward so the test was different.
Following your recommandation, I enabled logging to debug mode and created to 2 groups 'TEST-SAML' and 'TEST-SAML2' configured as member of the organization group 'gis-esriportal' and tried to log in with an account not initialized on ArcGIS Enterprise and member of the group 'gis-esriportal':
As you can see the user 'foobar' is correctly added to the groups 'TEST-SAML' and 'TEST-SAML2' as it is a member of 'gis-esriportal'.
Then, I created a third group 'TEST-SAML3' configured membership to the very same enterprise group 'gis-esriportal'.
If I try to log in once again with the test account (after signing out, clearing cookie and incognito mode), the following is logged:
So it seems like it does test for membership but according to ArcGIS Enterprise, it is not member of 'gis-esriportal' group.
Then I delete the account on 'ArcGIS Enterprise' and tried to log in again:
User is added to 'TEST-SAML3' group this time.
Any idea what could be the issue ?
Thanks
Based on the logs it looks like you might have a "Windows" group store configuration defined in Portaladmin > Security > Config. Can you double-check that? The refresh group membership logs that are appearing when it fails are unique to Windows or LDAP group store configurations. The SAML enterprise group logs match the first one and the last one where it worked.
Currently it is possible to enable SAML enterprise groups when you configure SAML and also have an Active Directory or LDAP group store defined in portaladmin. When this happens they conflict with each other and you see weird results. We are working on an enhancement to only allow one or the other.
Thanks for your reply.
Unfortunately, we did not configure any store and they are currently configured as built-in:
Thanks for checking. From your previous message it looks like you have all three of your SAML-TEST groups linked to the same 'gis-esriportal' group. Is that correct? There is an outstanding issue related to having multiple Portal groups linked to a single SAML enterprise group. The behavior is inconsistent. Can you confirm in your production environment if you have more than one Portal group linked to a single SAML group?
Indeed, the three groups are linked to the same 'gis-esriportal' enterprise group.
I confirm that if I change it to another enterprise group it is working without having to delete the user.
So I believe we are having the same 'issue related to having multiple Portal groups linked to a single SAML enterprise group'.
FYI, doing this test, I noticed something strange in the log. Though, the user is added to the new group, the tests are failing.
Here is the test I did: I created one ArcGIS Enteprise group called 'TEST-SAML-FOUND' and linked it to enterprise group 'gis-esriportal-2'. As you can see on the screenshot below, though tests are failing ("Is user in group took 1 ms to test if user foobar@company.com was in group gis-esriportal-2. Value: false. Tested formats: [company.com\foobar, foobar, foobar@company.com]), it is nevertheless added to the ArcGIS Enterprise group "TEST-SAML-FOUND":
Yes, what you are seeing in the debug logs there is a separate issue (relatively minor in my mind). When the linked enterprise group is added or changed, we have logic in place to automatically clear and refresh the group membership. This works great for Windows or LDAP enterprise groups but cannot be done for SAML groups because there is no way to query a SAML idp. The bug here is that with SAML groups enabled, it should only clear the existing group membership and not attempt to do a refresh. Fortunately this does not appear to be breaking anything. The group membership is still getting cleared as expected and the attempted refresh is simply failing. It does cause confusion though when looking at the debug logs.
Thanks for your explanation.
And regarding the 'issue related to having multiple Portal groups linked to a single SAML enterprise group', do you have anything logged on your side ? Any hope to have it solved for 10.8.1 ?
It is very convenient to be able to create multiply groups to classify though it is linked to the same enterprise group.
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.
