Latest Contributions by JeffSmith

Hi @slu_se  The ability to add OIDC users on ArcGIS Enterprise 11.3 in advance is possible using the workflow you are following but it is difficult to get the user login information to match correctly.  Using the command-line utility, the format of the text file is as follows (from the help doc). <login>|<email address>|<name>|<role>|<user type id>|<description>|<IdP UserName>|<first name>|<last name>  The <login> is the ArcGIS username and just needs to be unique on your Enterprise system.  It can be anything.  The <IdP UserName> is what needs to match up with the OIDC user identifier.  This is the difficult part.  By default Enterprise uses the "sub" attribute in the <IdP UserName> field.  The problem for some OIDC providers (ex Entra ID), is this value cannot be pre-determined before a user logs in.  That makes it impossible to pre-create these users in Enterprise.   To solve this, in Enterprise 11.3, the ability to configure the OIDC provider with an alternate IdP username  claim field was added.  For 11.3, this can only be updated through the api though.  The ability to define this in the main Portal Home app was added in 11.4.  If you are using Entra ID, an example of a claim attribute that can be used instead of "sub" would be "oid".  This matches the object id of the user and can be retrieved for each user from the Entra ID site. ... View more

Hi @VirgilioPalmi  Regarding the CORS request - yes, I'd recommend leaving IIS without any configuration and adding specific domains to the list of "Allow origins" inside Portal under Organization > Security. Regarding the frame-ancestors, we added the ability to define content-security-policy headers for the /home and /apps endpoints in the 11.4 release.  The /home app has the frame-ancestors CSP enabled by default.  The CSP for /apps is empty by default but adding the frame-ancestors can be easily done.  If you are using an earlier release, you can add the frame-ancestors CSP header through IIS but you may need to limit it to /home or /apps depending on your existing apps or services. ... View more

Hi @Bernd_Loigge  Yes, you are correct.  The esri_aopc cookie only gets set for specific clientIds - "arcgisonline" is one of them.  Another one you could use is "arcgisstorymaps".  The StoryMaps app needs the esri_aopc cookie to load properly. ... View more

Hi @riteshpurbey  Yes, you can use NGINX on your web server without a web adaptor.  That will work fine.  NGINX will need to listen on port 443 and you'll need to define a unique "location" directive for both Portal and Server and proxy to ports 7443 and 6443 respectively.  Make sure to include the X-Forwarded-Host header as well that matches the hostname of the web server.  Here is an example: location /portal/ { proxy_http_version 1.1; proxy_pass https://example.domain.com:7443/arcgis/; proxy_set_header X-Forwarded-Host "nginx.hostname.com"; } location /server/ { proxy_http_version 1.1; proxy_pass https://example.domain.com:6443/arcgis/; proxy_set_header X-Forwarded-Host "nginx.hostname.com"; }   You will also need to define the "WebContextURL" system property for both Portal and Server.  More information on that can be found in the help doc. ... View more

Hi Felipe, I'd be careful with some of those headers.  The "X-Esri-Authorization" header should not be hard-coded to "Token".  That gets used by some of the Esri apps as a way to send the token as a header rather than a query parameter.   Also, the "Strict-Transport-Security" header for HSTS can be enabled through a security option in the portaladmin api.  If you prefer to enable HSTS through IIS, that's ok.  Just make sure they are not enabled in both places. The other headers are fine.  I don't consider them important for the cookie creation though.  Are you saying the cookie was not created when those headers were not included? ... View more

@Marc_Graham - That's a good suggestion.  I'll try to get that updated. ... View more

Hi @Marc_Graham, A couple of thoughts on this.  If you want to secure an OGC layer, the recommended way is to publish it to an ArcGIS Server that is not federated with a Portal.  In addition, this ArcGIS Server needs to be configured with web-tier authentication (Basic, Digest, IWA, or client-certificate auth).  When an OGC client tries to access the layer, they will be prompted to enter credentials (or provide a client certificate) prior to gaining access.  This should work.   The problem with other configurations (Server federated with Portal or Server configured with non-web-tier authentication) is it utilizes token-based authentication and most OGC clients do not know how to handle that.  The 499 response code that is returned when trying to access a secured OGC layer is only understood by ArcGIS clients.  There is not a comparable response code that I'm aware of that indicates to an OGC client that an OAuth2 access token needs to be generated and used to access the OGC layer. There are a few OGC clients that can handle generating and sending an access token (QGIS and FME are  two I can think of), but it is not part of the OGC spec so I don't think there are many others.  This is why we document that OGC layers need to be open and shared with everyone or secured with web-tier authentication to be accessible. ... View more

@JonasLeksell2 You are right; that should not be happening.  I would recommend contacting Support to get a bug logged for that. ... View more

If your deployment is on Windows, have you installed the Web Adaptor Reliability Patch?  One of the issues addressed in the patch is related to cookies and sounds similar to the behavior you are seeing. Most of those apps rely on the esri_aopc cookie for authentication.  Do you see that cookie in your browser developer tools? ... View more

@BenjaminRitter This auto-login process you are describing has been available in Portal for quite a while.  If SAML is the only enabled login type, you should be automatically redirected to the SAML login after you click the "Sign In" button.  What release are you testing this on?  If you want to eliminate even having to click on the "Sign In" button, you can disable the "Allow anonymous access to your portal" option under Organization > Settings > Security. ... View more

I wanted to follow-up on this based on some recent findings and because of the bug that was logged related to this issue (BUG-000164666).  This issue is caused by how Windows handles network address resolution when IPv6 is disabled on a network adaptor.  Information on this is outlined in this Windows Server KB article. In short, when you disable IPv6 on a network adaptor, Windows still resolves the internal hostname of the server to the IPv6 localhost address (::1).  This is the source of the issue.  For security reasons, the publishing tool blocks requests to localhost and returns the 999999999 error in these scenarios.  There are 2 ways to address this: As mentioned and confirmed by many, you can enable IPv6. If enabling IPv6 is not an option or not desired, you can add the "DisabledComponents" registry value as outlined in the Windows Server help doc and set the value to "0x20" (technically "0xFF" works as well but is not recommended by Microsoft).  Once the server is restarted, Windows will link the internal hostname of the server to the regular IPv4 address and the publishing process will succeed. ... View more

Hi.  Just wondering if the machine name where your Enterprise is installed happens to be mapped to the localhost IP address (127.0.0.1).  There was a security enhancement added recently that limits some communication directly to localhost and I'm wondering if that may be involved here. ... View more