rastrauch I will try to keep this short without deep diving the technical details. Essentially, we have 2 AD forests, 1 for internal users 1 for external users, and we have a need to be able to authenticate users from either domain. The limitation to this has always been at the ArcServer level in which only 1 identity store can be used and ESRI staff has stated that it can read 1 global catalog which in our case = 1 AD forest.
The hang up with this was that in order to address issues with locking down services on the ArcServers the only viable option is supporting 2 mirrored environments. Well that solves your issue at the ArcServer end but then introduces a considerable amount of work at your front end applications along with addressing how your single endpoint to the user base (a single website URL) simultaneously supports users from either forest through a combination of secured and unsecure services across your 2 ArcServer environments.
Ideally the single ArcServer environment would simply address authentication across both. So we are in the final stages of testing our solution that makes this works and expect to roll out a production solution shortly. I will be writing up a paper that walks through building out an environment that can support these dual forest authentication issues and the logic/reasons behind it.
The purpose to this post was the only situation in which we found issues with our test to occur is with the use of an internal AD service account not being able to authenticate but all user accounts authenticate just fine. Expectedly, since this is a non-ESRI supported configuration we anticipated speed bumps and the service account access into the REST endpoint for a secured service was the only issue we encountered. In our digging into things the only explanation is that within AD the service account doesn't have normal attributes (first/last name, email, etc.) populated. We confirmed this issue by building a generic service account into the internal AD configuring permissions to a secured service letting it fail, then populating every field that is populated for our typical users and the service account got in. Not something that's a show stopper we can populate the fields on service accounts, not ideal but its a workaround solution so happens, but it brought us to a good general knowledge point yet to be answered, what are the minimum required attributes? Simply due to time we aren't going to systematically walk through testing of populating various configurations of attribute fields in AD to solve this so took it to ESRI and then here.
This means there are specific attributes that ESRI is expecting at authentication but nobody could tell us which attributes. The use case would be for scripted processes that we run nightly being able to leverage the secured REST endpoints all via the service account.
