topic Re: Federating Server error: Role store or user store of server is not BUILTIN in ArcGIS Enterprise Portal Questions

Federating Server error: Role store or user store of server is not BUILTIN

RajuGopinath — Thu, 24 Aug 2017 18:53:25 GMT

I am trying to Federate Server with portal and later enable hosting server. However, I am stuck with this error?

error: Role store or user store of server is not BUILTIN

Code: 400

Server/Portal- 10.5.1

Windows domain

Anybody getting same error while Federating?

Re: Federating Server error: Role store or user store of server is not BUILTIN

RamlaShihab1 — Mon, 02 Apr 2018 05:17:28 GMT

remove the securoty from windows to ArcGIS server

User Store:	ArcGIS Server Built-in
Role Store:	ArcGIS Server Built-in
Authentication Tier:	GIS Server
Authentication Mode:	ArcGIS Tokens

Re: Federating Server error: Role store or user store of server is not BUILTIN

PeterHanmore — Mon, 01 Oct 2018 14:11:58 GMT

I think the answer to my question may be implied, but I'll ask just to be sure.

Is there any way to use Windows Authentication for both Portal and ArcGIS Server? We currently use AD with token security on our ArcGIS Servers (v10.5.1) and would prefer not to have to switch to BUILTIN security in order to federate with Portal. The reason being that we will host non-Portal content on these servers also (i.e. outside of the 'Hosted' folder).

Re: Federating Server error: Role store or user store of server is not BUILTIN

MichaelSchoelen — Mon, 01 Oct 2018 14:22:14 GMT

If you decide to federate your ArcGIS Server with the Portal, you are allowing Portal to handle all of the authentication:

When you federate a server with your portal, the portal's security store controls all access to the server. This provides a convenient sign-on experience but also impacts how you access and administer the federated server. For example, when you federate, any users, roles, and permissions that you previously configured on ArcGIS Server services are no longer valid. Access to services is instead determined by portal members, roles, and sharing permissions. Before federating, review the information in Administer a federated server to learn more about how federating will impact your existing site.

So if a user attempted to access the Server directly, they would first be redirected to a Portal login page, then get passed along to the Server using a generated token after authentication.

If your portal is set to use AD authentication, your Server will also use AD authentication by proxy. You don't have to use built-in accounts at all.

As for your intent (putting non-Portal content on a hosting server), I assume you're talking about being able to add content to a server without going through the portal? If so, same concept. Users pushing content from desktop directly to the server will be prompted for their active directory credentials.