INTRODUCTION
The modern paradigm of an Enterprise environment has brought along with it a need for complex authentication scenarios. Whether it’s a need to authenticate different divisions within a company, or internal company users with external shareholders, there are a wide variety of situations that must facilitate authenticated access beyond a single identity store.
Esri's ArcGIS for Server (10.1 – 10.4.1 or, by its new name, ArcGIS Enterprise for 10.5+ users) solution is well documented to support a single identity store. This works well for facilitating authentication to a slew of commercial-off-the-shelf front-end web application solutions Esri offers along with custom-built apps. From a solution architecture standpoint this is limiting because the server itself doesn’t handle complex authentication. There are forum posts that can be dug up that reference this, and a conversation with ESRI has provided some clarification with regards to Active Directory. Esri’s ArcGIS for Server/ArcGIS Enterprise can leverage a single global AD catalog but cannot support multiple global catalogs. Additionally, ArcGIS for Server/ArcGIS Enterprise does not support the use of Active Directory Federation Services.
This presents a challenge for custom front-end applications or even applications built using Esri's Web-App Builder that require users from two separate AD catalogs to authenticate. The solution was always that the front-end application had to exist twice under different URL’s and authenticate against different back-end ArcGIS for Server/ArcGIS Enterprise environments, or the front-end application had to build its own way to address authentication upfront and leverage a service account to facilitate communication to the ArcGIS for Server/ArcGIS Enterprise environment.
Recently Esri has introduced the concept of injecting ArcGIS for Portal or ArcGIS Online, which can handle use of more complex authentication, in order to alleviate these issues. While this may be plausible for some scenarios, it’s not necessarily going to work for all scenarios. This means there is still a gap, or call it a shortcoming, in the ability to architect solutions where complex authentication can occur against ArcGIS for Server/ArcGIS Enterprise.
PROBLEM SET
As a large government organization, the Ohio Department of Transportation has a need to authenticate users who are internal to the organization and external to the organization. These users are managed in two separate AD forests and have two different global catalogs.
A need arose to be able to facilitate authentication across both of these AD’s from front-end applications. Requirements dictated that for ease of user access, a single URL was to be used so that confusion didn’t occur for internal versus external users. Additionally, for the purposes of resources (with regards to cost, infrastructure management, etc.), it was not prudent to have multiple back-end server architectures in order to facilitate this multiple authentication need.
This meant that a solution needed to be evaluated in order to streamline the environment to a single vertical architecture, maintain the single URL for front-end users, and be able to leverage the power of AD with regards to permissions, groups, and users without inadvertently giving external or internal users more access than they should have.
SOLUTION
After posts to the EsriI Idea’s website and escalated tickets submitted through the Esri helpdesk, there was no helpful solution presented to ODOT for leveraging the ArcGIS for Server/ArcGIS Enterprise with this sort of complex authentication need. With no answers on if or when an out-of-the-box solution at this level would come, as well as no details for workaround options, it seemed our work was cut out for us: Leveraging existing architecture, industry standards, and best practices to create a solution to facilitate the use of multiple AD forests with separate global catalogs.
Doing this involved many trial and error scenarios and rigorous testing to vet potential solutions. In the end, it took the use of the one-way trust configuration option for AD as defined by Microsoft and a lesser-used option for configuring authentication in ArcGIS for Server/ArcGIS Enterprise. As a note, we have continuously referenced the standard naming used by ESRI of ArcGIS for Server (10.0 – 10.4.1) and ArcGIS Enterprise (10.5 +) because we have tested this in environments as far back as 10.2 and as recent as 10.5 to confirm it worked, and we saw similar behavior.
With no existing scenarios providing much to work from, our first efforts involved options for configuring authentication with an LDAP or shoe-horning the ADs in as an LDAP. After short review it was obvious that this made no sense. We next considered options for using ADFS but were able to confirm there was no existing or workaround way that made sense to integrate ArcGIS for Server/ArcGIS Enterprise with ADFS. In our research we dug into a solution from Microsoft called Active Directory Lightweight Directory Services, but that led down a path of adding additional management needs from AD administrators and went against the initial requirements/intentions. A final scenario we explored was the use of a third-party tool to act as a middleware, (there are a variety out there such as Crowd), but this came at extra cost and meant a new tool to manage and configure.
This left a scenario we had previously considered but had also ruled out because we hadn’t been able to determine the Esri configuration needed to make it work. The following will provide references, screen shots and explanations for implementing a solution to use a one-way trust in AD along with an ESRI authentication method against IIS web servers in order to authenticate users across the ADs.
WORKAROUND
The solution, while effective, has had a few drawbacks — which is not surprising as it’s not deemed a supported workflow from Esri— but none has proven to cause functional issues. They have been more minor annoyances at the administration level.
NOTE: This workflow is a functional solution but may or may not meet the needs of all organizations. This workflow is structured based on specific available tools, architecture, and requirements. Applying this in a different environment or scenario may not provide needed results or function correctly due to a variety of architectural and network configurations, for all of which we can’t possibly account.
DISCLAIMER:The Ohio Department of Transportation and author of this paper assume no responsibility and cannot be held liable for any corruption of data sets, databases, or subsequent breaking of applications or other negative impacts due to attempts to leverage this solution. It is the responsibility of the individual to follow IT best practices with regards to backing up data and working solutions through the development, testing, and production environments. While this is specific to authentication and poses little threat to data, various trackers and monitors that leverage user details can in fact be impacted and must be considered.
1. Properly configure a one-way trust in the appropriate direction between the AD forests. This is very well documented by Microsoft and they provide a variety of configuration scenarios based on where the work is being done and directional needs. This workflow can be followed from this site or one of the configurations on the left tab.
2. Properly configure an n-tier environment for ArcGIS as illustrated below. This does require the use of IIS. (This has been confirmed to work in IIS 7.5 on Server 2008R2 and IIS 8.5 on Server 2012R2). NOTE: This illustrates a Test and Production n-tier for a single project and brings in additional complexities, but basic examples can be found on the web.
3. Configure ArcGIS for Web-Tier authentication by changing the setting in the Admin Directory for “Authentication Tier” to use “Web Adaptor.” Follow the directory path at the top of the image to make this change: Home > Security > Config > Update
4. Configure the Identity Store used by ArcGIS for Server/ArcGIS Enterprise to leverage your Active Directory that has the one-way trust with the secondary Active Directory. This uses a less common configuration documented by ESRI here. (NOTE: We have not tested situations in which the Active Directory has multiple one-way trusts, but since this leverages Microsoft workflows and they support this scenario, it is feasible this would work.)
5. In IIS, configure the Web Adaptor to use Integrated Windows Authentication.
6. Run tests authenticating to REST services using credentials from each of the AD forests.
OBSERVATIONS
All the core functionalities continue to work as designed by ESRI, and users from both AD global catalogs can be authenticated. Groups must be managed from the AD that trusts the secondary (i.e. external users AD trusts internal users AD, but internal users AD does not trust external users AD, so in this scenario groups must be managed at the External AD, but users from either AD are able to be added into the group).
There are two drawbacks to implementing this workaround that have been identified so far, which are more of an annoyance than anything. The first has potential user impacts and the second has administrator impacts. Each are manageable and have simple solutions to resolve the annoyance if necessary.
1) Since this is not an Esri supported scenario, there is a potential implication to users that want to navigate the REST endpoint in a web browser directly. The implication occurs based on the AD catalog the user is under. Here is a breakdown to illustrate how this occurs. The same user was leveraged in both logins but has been omitted in the image for security reasons.
The user, logged in using an account from the primary AD that trusts secondary ADs, retains full capability to browse the REST endpoint. It can be seen below that the user has the ability to navigate (left side hyperlinks) based on the primary AD domain used (top right corner login).
URL = https:///arcgis/rest/services/
This capability is lost if the user logs in using credentials from the secondary AD that is trusted by the primary AD. As can be seen below, the left side is now blank based on the login in the top right corner:
URL = https:///arcgis/rest/services/
This DOES NOT mean that the secondary AD is broken. The secondary AD account can still access the REST endpoint; the user simply must know the exact path to hit since he/she is not able to browse to it. In the example below the user is logged in at the top right corner using the secondary domain but clearly has access and the ability to hit the REST endpoint, can still perform queries, etc.
URL = https:///arcgis/rest/services///FeatureServer
The explanation for why this occurs is that to facilitate the secured service needs of the ArcGIS Server, Windows Authentication is in place. Both Internet Explorer and Chrome will attempt to use IWA, so a user attempting to navigate the REST, whose local system login credentials match that of an approved account for access to the ArcGIS for Server/ArcGIS Enterprise using the secondary AD, will be authenticated in the browser via IWA. This creates the non-navigable REST. The workaround to this is simply to have users that fit this situation install Firefox, which will not use IWA. They can manually login using the primary AD account.
As a note, another approach to handle this with regards to unsecure services would be to install a secondary web adaptor that can be configured for anonymous authentication. That web adaptor would then allow for browsing in any web browser, as the user’s credentials would not be passed as part of IWA, but this doesn’t allow the user to see the secured services.
2) The other primary annoyance is log files generated when logins occur using the secondary AD accounts. This also is clearly an example of not being an Esri supported workflow. Despite the secondary AD fully working, properly having its credentials authenticated, and having access to everything, the Esri tools still throw out messages into the log files identifying that an issue has occurred. These can be easily parsed and removed by Administrators by making a copy of the log files, opening the copy via some text editor such as Notepad++, and doing find/delete calls on any of these error messages to filter for relevant logs.
CONCLUSION
All initial tests and usage of this solution have proven successful and resolved a long-standing issue with resolving complex authentication at the ArcGIS for Server/ArcGIS Enterprise level. Despite recent work (mostly released in 2016 and 2017) by Esri to address complex authentication needs via ArcGIS Online and Portal authentication models, there will still be a need for complex authentications that facilitate custom-built applications that could be better built and architected without the added complexities of managing a Portal or ArcGIS Online environment.
The Enterprise world is still rapidly growing for the use of GIS and Esri tools in particular. There is, and looks like there will be, an ongoing need for this sort of solution into the future. Until ArcGIS for Server/ArcGIS Enterprise can handle more complex authentication scenarios natively, for those working in a Windows-based shop, this uses technology and architectures that probably already exist and requires minimal change for a big payoff.
ODOT is going to continue to leverage this and test it as it’s leveraged in different environments for different needs. While no present scenario exists to facilitate additional AD instances, it would be interesting to see if it would work in the Esri environments where the primary AD has one-way trusts down to more than a single secondary AD.
With the continuing growth, there will always be new obstacles and new solutions. ESRI has been responsive and worked to update its product suite to meet these. While this specifically has not yet been met at the server level, they have addressed it at the web-tier/dissemination level of their architecture visions. Hopefully, based on the solution provided here and customer needs as illustrated on the Ideas site and the forums, this authentication advancement can be integrated with out-of-the-box functionalities.
For more information, contact Scott Fierro, GISP, CADD/GIS Administrator, Ohio Department of Transportation, scott.fierro@dot.ohio.gov.