I am one of a few Administrators on a portal. The portal has been set up with Integrated Windows Authentication (IWA) so that Active Directory (AD) groups can be linked to Portal for ArcGIS.
One of my fellow administrators created a new group and associated it with Users from an Enterprise Group using AD. I am a member of this particular Enterprise Group in AD, however when I log into portal using my administrator privileges and click 'Groups', I am not recognised as a member of this group. We double checked AD and I am definitely a member of the associated group.
What might be causing this issue?
When was your AD account added to the AD group? Was it before or after the Portal group was created? I remember a couple years ago working with a customer and there was a period of time we had to wait for any new users added to an AD group to be recognized by the Portal group.
I would try restarting the Portal service to see if the Portal group then picks up your account.
My AD account was added to the AD group about the time the portal was created. The portal has been stopped and started several times since.The administrator that created the group is the only person that seems to be able to link content to it. Likewise when I create a separate group with the same AD Enterprise Group for users, I am the only person that can link content to it.
If you run portaladmin/security/groups/getUsersWithinEnterpriseGroup, does that return the expected list of AD users that are members of that group? I'm wondering if there is something unique about that group that might prevent Portal from being able to retrieve members. Are you seeing this issue for other enterprise groups as well or just this group?
It looks like (at 10.5.1 at least) that the group is only allocated to existing accounts.
If a new user is created, after the group is created, they don't get the group access.
I hope I'm wrong, and if so can someone please let me know how to have a new user account granted the Portal group that is a copy of an AD group.
When a new enterprise user is created, their enterprise group membership is not determined until they first login. This means if you have already created a Portal group and linked it to an enterprise group, when you create a new enterprise user, that user won't immediately become a member of the group. The user should become a member the next time the group membership is refreshed (either when the user first logs in or when the full membership refresh occurs which is scheduled for midnight by default).
If you need to user to become a member of the group sooner, you'll need to manually refresh the user membership through the portaladmin api (portaladmin/security/users/refreshMembership).
Hi Jeff Smith
I am not seeing that behavior.
I suspect as we have "enableAutomaticAccountCreation":true and IWA.
The account is automatically created and logged in at the at same time.
Is this a bug?
Some more details ... appears* this may work for the first login.
We were testing by deleting the account and rejoining the portal.
The subsequent logins to the Portal do NOT get allocated to the AD group.
*hard to confirm 'first' login as once account deleted the group assignment doesn't work
The configuration with "enableAutomaticAccountCreate" set to true and IWA should work fine. After you delete and recreate these accounts with a login, can you confirm the account is added to the group after you manually run the refreshMembership operation? It might also help to set your logs to DEBUG and review them when the account gets created during the login. You should be able to see if the refresh membership operation is occurring.
Ok ... with the help of DEBUG logs, it's working as you expected, though not quite how I would like
The first login does work.
Then after deleting and re-adding the account the logs show:
Refresh user membership: No refresh. Interval time has not elapsed.
Can a users interval time please be reset to zero after each account creation has been detected?
As a workaround for now, we'll see how lowering membershipRefreshIntervalHours goes.