The authentication method you use with your organization and whether you allow access to it from outside your firewall help shape how you implement a highly available ArcGIS Enterprise deployment.
The following are true for all the scenarios described in this topic:
- The portal machines (Portal1 and Portal2) store content in the same directory, which has been placed on a highly available file server.
- The GIS Server machines (HostingServer1 and HostingServer2) in the hosting server site share common server directories and a configuration store, which have been placed on a highly available file server.
- A highly available relational data store is composed of a primary machine (DataStore1) and a standby machine (DataStore2) that are registered to the hosting server site. ArcGIS Data Store has a built-in failover mechanism whereby the standby relational data store becomes the primary data store machine if the primary machine fails. The data store checks the condition of the ArcGIS Server machines for the site with which it is registered, so you can configure the data store through either ArcGIS Server machine URL.
- HTTPS and HTTP are enabled for both Portal for ArcGIS and ArcGIS Server. If HTTP is disabled for all components, the HTTP ports (80, 6080, and 7080) can be removed from the examples. Administrative URLs require HTTPS communication.
- For architectures involving load balancers, health checks have been configured to determine the availability of the back-end targets and balance traffic using a round-robin algorithm. While the example hosts loadbalancer.example.com and internalloadbalancer.example.com are used in the diagrams, this can be replaced with a DNS alias assigned to either component via internal or external DNS servers.
Differences in client-portal communication and authentication protocols are described in the following sections. More information about the URLs used in a highly available deployment can be found in High availability in ArcGIS Enterprise.
Built-in users and clients have access to the portal through ports 80 and 443
In this scenario, portal authentication uses built-in users, and all communication between clients (shown at the top of the diagram) and the portal occurs inside the firewall.
In the example, clients access the organization through the load balancer via the Organization URL—in this case, https://loadbalancer.example.com/portal/home/—and the ArcGIS Server site's REST directory can be reached through https://loadbalancer.example.com/server/rest/services. The highly available portal (two Portal for ArcGIS machines, Portal1 and Portal2) communicates with its highly available hosting server site through the Administration URL (https://loadbalancer.example.com/server/admin) defined during federation. The machines in the hosting server site (HostingServer1 and HostingServer2) communicate with the portal through the same endpoint as clients (https://loadbalancer.example.com/portal) using the privatePortalURL defined in the portal's system properties. Both the ArcGIS Server Administrator Directory URL and the privatePortalURL go through the load balancer (LoadBalancer) to account for redundancy. If one Portal for ArcGIS machine fails or is inaccessible, the hosting server can still communicate with the remaining machine, because the load balancer will direct traffic to that machine. Similarly, if one of the hosting server machines fails or is inaccessible, the load balancer will continue to direct traffic from the Portal for ArcGIS machines to the remaining ArcGIS Server machine.
Built-in users with public access to the portal
In this scenario, portal authentication uses built-in users, and at least some clients will access the portal from outside the firewall. Administrative access from outside the firewall should be disabled.
Clients access the organization and the ArcGIS Server REST endpoint through the load balancer outside the firewall (LoadBalancer), typically through a DNS alias assigned to loadbalancer.example.com. The portal communicates with the hosting server site through a second load balancer (InternalLoadBalancer) inside the firewall (https://internalloadbalancer.example.com:6443/arcgis, the green lines in the diagram). The hosting server communicates with the portal through the privateportalURL, which also goes through InternalLoadBalancer (https://internalloadbalancer.example.com:7443/arcgis, the orange lines in the diagram), so communication does not have to pass through the firewall. If one portal machine fails, the hosting server can still communicate with the remaining portal machine, as the internal load balancer will send requests to the remaining portal machine. Similarly, if one of the GIS Server machines fails, the internal load balancer will direct traffic from the portal to the remaining GIS Server machine.
Access from clients outside the firewall directly to the GIS Server site will also go through the load balancer (LoadBalancer) outside the firewall (red line in the diagram).
Administrator access to the ArcGIS Server Administrator Directory and ArcGIS Server Manager is blocked by setting rules on the load balancer (LoadBalancer) outside the firewall (red line in the diagram).
IWA or LDAP authentication with client access internal
In this scenario, portal users authenticate using Integrated Windows Authentication (IWA) or Lightweight Directory Access Protocol (LDAP) authentication, and all clients accessing the portal are inside the firewall.
When public access to the portal is not required but clients will authenticate with the portal using IWA or LDAP authentication, each machine in the highly available portal requires a web adaptor (WebAdaptor1 and WebAdaptor2). The load balancer (LoadBalancer) sends traffic to the web adaptors, which then balance requests between the two portal machines (Portal1 and Portal2). Any communication from the ArcGIS Server machines to the Portal for ArcGIS machines must bypass the authentication challenge at the web tier through the web adaptor. Therefore, the load balancer is configured to listen on ports 7080 and 7443, and that traffic is sent directly to the portal on ports 7080 or 7443 through the privatePortalURL.
Since public access to the portal is not required, the load balancer can be used for both the Services URL and the Administration URL for the hosting site. The privatePortalURL is https://internalloadbalancer.example.com:7443/arcgis and the hosting site machines communicate with the portal machines over this URL (the orange lines in the diagram). The Organization URL is https://loadbalancer.example.com/portal and both the Services and Administration URLs for the hosting site are https://loadbalancer.example.com/server.
SAML or ADFS authentication with public access to the portal
In this scenario, users authenticate using Security Assertion Markup Language (SAML) or Active Directory Federation Services (ADFS), but some clients accessing the organization are outside the firewall. In this case, you need to disable administrative access to the ArcGIS Server machines of the hosting server site for security purposes. The section below describes the two configurations to accomplish this.
Note:
Using SAML or ADFS authentication for your portal renders it unnecessary to configure web adaptors with the portal. While you can use ArcGIS Web Adaptor with your portal in the following two scenarios, it adds no functional benefit to the configuration.
Secure a publicly accessed portal using rules set in the load balancer
In this scenario, clients connect through the load balancer (LoadBalancer) outside the firewall (red line in the diagram), which sends traffic directly to the two portal machines (Portal1 and Portal2) on ports 7443 and 7080 and the two GIS Server machines (HostingServer1 and HostingServer2) on ports 6443 and 6080. Rules in the load balancer block access to the ArcGIS Server Administrator and ArcGIS Server Manager URLs.
The load balancer outside the firewall cannot communicate through ports 6080, 6443, 7080, or 7443. Another load balancer (InternalLoadBalancer) is configured inside the firewall to enable communication between the portal and the hosting server. The portal will communicate with the hosting server using the URL defined for the Administration URL during federation (green lines in the diagram) and the hosting server will communicate with the portal through the privatePortalURL (orange lines in the diagram), so communication does not have to pass through the firewall. The internal load balancer ensures redundancy if one of the GIS Server machines or portal machines fails.
The privatePortalURL in this scenario is https://internalloadbalancer.example.com:7443/arcgis. The ArcGIS Server site Administration URL used during federation is https://internalloadbalancer.example.com:6443/arcgis.
Secure a publicly accessed portal using web adaptors on the GIS Server site
In this scenario, clients connect through the load balancer (LoadBalancer) outside the firewall (red line in the diagram), which sends traffic directly to the two portal machines (Portal1 and Portal2) on ports 7443 and 7080 and sends traffic to two web adaptors (WebAdaptor1 and Webadaptor2) that are configured with the ArcGIS Server machines (HostingServer1 and HostingServer2). Another load balancer (InternalLoadBalancer) manages the traffic between the portal machines and the hosting server site and ensures redundancy if one of the GIS Server machines or portal machines fails.
Clients access the portal through the load balancer (LoadBalancer) https://loadbalancer.example.com/portal/home/, which sends traffic to the two portal machines over ports 7080 and 7443. Since the portal is configured with SAML or ADFS authentication, the SAML or ADFS provider authenticates users when they access the portal.
Clients can access the hosting server site through the load balancer (LoadBalancer) outside the firewall, which sends traffic to the GIS Server web adaptors (WebAdaptor1 and WebAdaptor2). The web adaptors forward traffic to the GIS Server machines over ports 6080 and 6443.
The ArcGIS Server machines communicate with the portal through the privatePortalURL (https://internalloadbalancer.example.com:7443/arcgis, the orange lines in the diagram), so communication does not have to pass through the firewall. The hosting server site is federated to the portal using https://loadbalancer.example.com/server for the Services URL. This traffic goes through web adaptors WebAdaptor1 and WebAdaptor2, which are configured to block administrator access to ArcGIS Server Manager and the ArcGIS Server Administrator Directory. A second load balancer (InternalLoadBalancer) is used for the Administration URL (https://internalloadbalancer.example.com:6443/arcgis, the green lines in the diagram) defined during federation to provide redundancy.