Both single sign-on and anonymous access to Portal for ArcGIS (10.4)

Jump to solution
05-24-2016 12:06 AM
New Contributor III

We've set up our Portal environment using Integrated Windows Authentication (IWA) giving our user a single sign-on experience using Windows Active Directory (AD). The problem we're facing is that any content being accessed by someone without a name user are asked to log on to the Portal even though the content is shared with "everyone".

We want our named users to have the full Portal experience whereas our non-named users should only have access to content that are shared with "everyone". Is there a way to configure both single sign-on and anonymous access to the Portal?

0 Kudos
19 Replies
New Contributor III

Did you get this question answered?

 Is it possible to have a Single Sign-On environment for users in Active Directory (don't have to log in to Portal) and anonymous access? 

0 Kudos
Esri Notable Contributor

It's possible if you set up a SplitDNS type approach. Public users are routed to an external entry point, ( that's configured with anonymous access, while internal users are routed to an internal entry point with the same FQDN ( This entry point is configured with IWA.

Aside from that, SAML is your best bet.

0 Kudos
by Anonymous User
Not applicable

Hi Jonathan Quinn, are you able to please provide more info on how to go about this with a split DNS? I'm trying to do just that (two web servers, one internal with IWA and one external with anon auth). I have set WebContextUrl but I when I install the second Web Adaptor it replaces the first.

I also note in the 10.7 docs that:

Portal for ArcGIS only supports a single DNS.

0 Kudos
Esri Notable Contributor

I'm assuming that the note meant "single FQDN", which is more appropriate.

On each Web Adaptor machine, what happens if you reach the Portal via the Web Adaptor? Does it resolve and take you to the Portal home page?

0 Kudos
by Anonymous User
Not applicable

I've since discovered that, if you register a Web Adaptor with the same URL as another, the first WA no longer appears in .../portaladmin/system/webadaptors. The first WA continues to work, at least for the first few hours (i.e. it might stop working later after the security tokens expire?). Regardless, this isn't a good solution because future admins won't see the full picture of WAs at .../portaladmin/system/webadaptors.

My solution was to set the Portal's WebContextURL property (e.g. and then register the WAs with unique URLs based on their machine names' FQDNs (e.g. and To do this, for each IIS machine I had to:

  1. Acquire an SSL certificate for the machine name FQDN (e.g.,
  2. Bind IIS to that FQDN on HTTPS (in addition to the common web context URL's FQDN),
  3. Visit the WA config page using that FQDN (e.g.,
  4. Configure the WA as usual.

Both WAs now appear in the list because they have unique URLs. Even though the WAs are registered with different URLs, they're still accessed using the common web context URL as IIS remains bound to that FQDN as well as the machine's FQDN.

My presumption is that this is because multiple WAs would normally only be used in high availability deployments. In this scenario, all WAs would have unique URLs, and they would sit behind a load balancer using the web context URL. Therefore, all WAs are expected to have unique URLs. A split DNS needs a bit of trickery to get around this because the WAs genuinely share the same URL.

0 Kudos
Occasional Contributor II

Hey Guys. If you're here you must be stumped. Some super smart folks in our organization have figured this out and I just want to post their findings. They are OK with me sharing it. I didn't do this, i'm simply conveying what worked for us and our client.  (I'm NOT this smart)

Requirement: Allow public access to publicly-shared items in Enterprise GIS, which using IWA for internal users. Server federated w/Portal, client to publish map services, maps and apps to share, some with general public, others with internal users. Does not want anyone to have to log in (except internal users that will have to authenticate with IWA with their domain account on first access).

Software: ArcGIS Enterprise 10.8.1


  • Two Web Adaptor locations:
    • Portal and Server WAs in the DMZ to be accessed by the general public, allow anonymous access
    • Portal and Server WAs within the network (on the Portal box), IWA configured
  • Trusted sites added:
  • Routing:
    • Split DNS configured in Palo Alto w/assistance from <IT CONSULTANT>
    • External DNS routs traffic to DMZ server
    • Internal DNS routs traffic to Portal/WA server
  • Web Adaptor configuration:
    • Installed, configured Server WAs, no complications
    • Set Portal WebContextURL to
    • Installed, configured Portal WA on DMZ box, backed up WebAdaptor.config
    • Installed, configured Portal WA on Portal box *from internal FQDN URL*, Windows Authentication only in IIS, backed up WebAdaptor.config
    • Initial configuration of Portal WA using external URL would only allow one WA to remain, configuration of one cleared out configuration of the other. This seems to be specific to Portal, as Server doesn't do this. But Portal must be unregistering a WA when you try to register a new one on the same URL.
    • At the end, both Portal WAs remained configured in Portal, although I think the WebAdaptor.config on the internal box was cleared out and had to be manually overwritten from backed up file.
    • Manually changed URL in both WebAdaptor.config files from <URL>https://portalfqdn.intranet.url.local:7443</URL> to <URL></URL>. The external WA worked without doing this, but the internal one didn't, so I made the change in both. (Why did I have to do this? Did it have something to do with having the WebContextURL configured? Did it have something to do with internal networking configuration? I only had to do it for the internal WA even though both had the server name as the URL in WebAdaptor.config.)
  • Testing:
    • All testing in incognito or after clearing cache
    • WA changes tested after recycling App Pool
    • Accessed externally, clicked 'Sign In' link, directed to standard Portal sign-in page, indicating that DMZ WA is being used and no IWA was applied
    • Accessed while on VPN, clicked 'Sign In' link, prompted for IWA sign-in
    • Published sample map service, granted public access, accessed externally without login
0 Kudos
Occasional Contributor

I created a second machine and installed my Portal and Server Web Adaptors redundantly. The first machine uses IWA and the second uses anonymous authentication. Internal users are directed to the first server and external users are sent to the second server, but all of them use the same WebContextUrl as a point of entrance.


0 Kudos
New Contributor III

I'm trying to do the same - have internal users go to one server and external to another.

Did you have to do any trickery to get the redundant Portal WA installed? I have tried several times, and the last one installed is what shows up in PortalAdmin. I have yet to get more than one Portal WA installed at the same time.

0 Kudos
Occasional Contributor

As You can see above in my screenshot, I indeed managed to install both Portal WA on different machines pointing to the same Portal.

In my Enterprise 10.9.0 environment, the existing WA was not overwritten. This is, what happened to You?


0 Kudos
New Contributor III

I did get mine working... I found the following order to work for me:

1. Install Portal

2. Install a web adaptor on the Portal server

3. Set the WebContextURL

4. Install the 2nd web adaptor (in my case this one is in the DMZ.

Question for those who are using both IWA and SAML on the same Portal - how do you handle the different usernames? In my setup, the username sent to Portal is different between IWA and SAML:



The first one came from IWA (username@domain) and the second from ADFS (email address). This creates a problem for managing users and content.

0 Kudos