|
POST
|
Do the DEBUG logs indicate that the refresh is occurring? The group membership refresh operation runs in the background when the user logs in. If there are a lot of Portal groups linked to enterprise groups, this may take a while because it is iterating through each group to see if the user is a member of it. During this time the user wouldn't be able to access the group because the membership isn't updated yet. You should be able to observe in the DEBUG logs when refresh operation completes.
... View more
01-29-2019
03:12 PM
|
2
|
3
|
1972
|
|
POST
|
Hi Roberth, This can be done through https://portal.domain.com/arcgis/sharing/rest/community/users/*username*/delete where *username* is replaced with the enterprise username you are trying to delete.
... View more
12-26-2018
01:14 PM
|
3
|
1
|
1029
|
|
POST
|
Looking at the python code, the provider that is being sent to the portaladmin/security/users/createUser endpoint needs to be 'enterprise' instead of 'webadaptor'. I'll see if I can get help doc updated to fix this sample python code. I'm not sure why the error being returned doesn't indicate it is an invalid provider.
... View more
12-26-2018
01:04 PM
|
0
|
1
|
1317
|
|
POST
|
This issue has already been logged as BUG-000112506 and is unique to Edge or Internet Explorer when the portaladmin url is in the 'Local Intranet' security zone. There are a few workarounds until this issue gets addressed. One is to use a different browser. Another is to adjust the Internet Explorer options so the portaladmin url is not considered part of the 'Local Intranet' security zone. A third is to access the .pfx file using a UNC path instead of directly through the Q: drive. I agree with Jonathan that a better error message would be helpful here.
... View more
12-19-2018
08:35 AM
|
0
|
3
|
2130
|
|
POST
|
If you configure the user identity store JSON string to use the type "WINDOWS", the domain name will always be added to the end. There is not a way to remove that. If you specify the type "LDAP", you have more flexibility and can specify the "usernameAttribute". Since you are connecting to A/D, it sounds like you want the "sAMAccountName" to be the usernameAttribute. This would remove the need to type in the @mydomain at the end of each username. You can't use this with SSO though. If you want to enable SSO (IWA) as Anthony mentioned above, you have to use the type "WINDOWS".
... View more
10-22-2018
10:05 AM
|
2
|
0
|
1529
|
|
POST
|
Can you reproduce this issue in multiple browsers? I've seen some issues when using IE 11 to access parts of the Portal Home app and I'm wondering if that might be related to what you are seeing here.
... View more
08-20-2018
12:45 PM
|
0
|
4
|
2056
|
|
POST
|
I think this may be caused by an SSL certificate trust issue. I'd recommend checking the certificate used by Server over 6443. If this is a certificate that was imported into Server, can you confirm that Portal trusts the certificate authority that signed the certificate? If this is the default self-signed certificate that was generated when Server was installed, can you confirm that the hostname listed in the Server admin url matches the common name for the certificate? Another good way to test if Portal trusts the certificate is to use the checkUrl.jsp endpoint. https://portal.mydomain.com/portal/sharing/checkUrl.jsp?url=https://server.mydomain.com:6443/arcgis/admin If this comes back with an http 200 response, the certificate is trusted. If this comes back with an error, it is likely a certificate issue. Once the certificate is trusted, the Hosting Server should not be grayed out.
... View more
08-20-2018
10:34 AM
|
6
|
0
|
6008
|
|
POST
|
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.
... View more
07-31-2018
09:37 AM
|
2
|
6
|
5860
|
|
POST
|
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).
... View more
07-30-2018
01:08 PM
|
2
|
9
|
5860
|
|
POST
|
I wonder if the attributes used for your email address and full name in Active Directory are different. If you copy and paste the example from the help doc, the "userFullnameAttribute" is set to "cn" and the "userEmailAttribute" is set to "mail". If these are different in your environment, that could explain why they are coming back blank. An easy utility to use to check this is the SysInternals ADExplorer. Just query for your username and it will returns all of the attributes.
... View more
05-14-2018
05:01 PM
|
3
|
1
|
2725
|
|
POST
|
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?
... View more
03-20-2018
09:51 AM
|
3
|
1
|
5860
|
|
POST
|
The ArcGIS Online sites all use certificates signed by DigiCert which is trusted by default in Portal. Does the server where your Portal is installed use a forward proxy to gain Internet access? I'm wondering if that forward proxy might be decrypting and re-encrypting the request using its own certificate that Portal does not trust.
... View more
02-21-2018
05:02 PM
|
0
|
0
|
2084
|
|
POST
|
The only other option would be to use built-in roles. This would require an administrator to manage them manually.
... View more
04-07-2017
10:42 AM
|
0
|
0
|
1893
|
|
POST
|
While this is something we are considering for a future release, at this time Portal does not support retrieving role information from a SAML response.
... View more
04-07-2017
10:34 AM
|
0
|
2
|
1893
|
|
POST
|
Heather, The ldapURLForUsers property is tough because it is unique to your environment. Every environment is different. Your domain administrator should be able to tell you what the values need to be. The example from the documentation shows: ldaps://bar2:10636/ou=users,ou=ags,dc=example,dc=com In this case, "bar2" is the domain controller. The domain is example.com and is defined here with "dc=example,dc=com". There are two OUs in this example; OU=users is a branch or sub-OU of OU=ags. You don't always need 2 OUs. In fact you could set the ldap url to not have any OUs at all. You would likely notice significantly slower performance though because Portal would be searching the entire directory structure for each user rather than specific OUs.
... View more
01-10-2017
09:06 AM
|
2
|
4
|
1893
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 10-31-2025 04:09 PM | |
| 2 | 06-27-2025 11:47 AM | |
| 1 | 06-27-2025 10:37 AM | |
| 1 | 09-09-2020 08:47 AM | |
| 1 | 10-04-2023 08:40 AM |
| Online Status |
Offline
|
| Date Last Visited |
14 hours ago
|