Been working through some interesting testing and scenarios with the use of ESRI's security model options and configurations. One such scenario we are seeing mixed results with.
Use of some of our Active Directory (AD) service accounts (no AD attributes populated for first/last names, e-mail, etc.) fails to authenticate while all other things considered they are identical to valid user accounts we have (these have nearly all of AD's attribute fields populated) which successfully authenticate.
Sent this up through ESRI support channels and it reached one of ESRI's senior support advisors who seemed to have a wealth of knowledge on Server present and past but he wasn't certain on these details.
So wondering if anyone can point to a site or knows of the specific AD attributes that are implicitly required to exist for successful authentication when using a web-tier configuration on IIS 7.5 in conjunction with AD?
I'm just curious as to the reasoning behind getting a service account to work in this manner? We use a service account to authorize our AD access, but have not tried what you are doing. I'm not sure or a case I would need that in Server.
In Portal (which I'm just starting to play with) and it's named users, I can see where this may have some use. Our Online doesn't use our AD and is not federated, we do use one or two of our named-user accounts as a generic "Department Name" user so things will eventually be published by the department and not individuals. For Portal (for use used as an in house AGOL with both internal only and external access, potentially), I have thought of using our AD but still having a generic user. I'm not sure how easy this will be, or if a mix is possible, in which case, I could see what you are proposing as being useful.
So, I'm curious is this is the type of thing you are shooting for, or if there is another reason? In any case, I'm also interested in hearing more.
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.