ArcGIS for Server Permissions vs. Server Permissions

[MattDeveney]

Hello,

We are currently trying to get our GIS for Server (10.2.2) set up and are battling with our IT department on permissions/rights, etc. I am new to the world of servers and permissions within them.  We would like to create and manage geodatabases, users, etc. on the server (SQL Server), as well as have administrative access to GIS Server Manager.  IT is stating that in order to do this, we would need to be granted administrative permissions to the server itself, which also houses other information on other databases that they do not want us to have access to.  Is it a true statement that we would need to be granted administrative rights to the entire server in order to administer the GIS portion of the server?  Isnt it best for a GIS server to be independent (storing nothing else but GIS for Server)?  Any information about this topic would be greatly appreciated.

[ScottFierro2 · Accepted solution]

This is really 2 different questions: 1 for SQL DB and the other for ArcGIS for Server.

With regards to SQL, this is kind of right. So in order to do the initial configurations there is a requirement of being admin however not of the entire server and even the admin that is needed can be altered to further limit you down while boosting IT warm-fuzzy. Not knowing how familiar you are with SQL Server here are some basics. SQL Server is a software install that resides on a server that is probably running Windows Server as its Operating System (OS). The user that is the admin over the entire server (windows) does have control over the SQL Server. However, the SQL Server instance has its own structure of accounts and there is a designated admin user over the entire SQL Database instance and this is most likely controlled by your DBA if you have one (has full admin of the SQL DB configuration and all databases within it but doesn't necessarily have control over anything else out at the OS level).

This drills further down and as a simple way to explain this let's use the analogy of the good old Milk Man and his deliveries. He had crates (SQL Server DB instance) and these crates were subdivided down to hold the individual glass milk jars (a SQL database) but there were many milk jars per crate then within the glass milk jars was the milk (the tables, views, feature classes, etc.). So your milk man (SQL DBA) has admin control over the entire crate and all the jars in that crate (individual SQL databases of which many can exist within a single SQL instance) BUT each jar in the crate has its own admin as well. This is where you would finally come I but as I said this can be controlled more.

So your SQL DBA builds a brand new empty SQL DB called TEST and assigns the user TESTER as the DBO for the DB. You will need to work together with the SQL DBA because they will have to give you the username and password combo OR they come sit down and enter these credentials to make a connection in ArcCatalog to the TEST DB. At this point we want to get SDE installed and your SQL DBA should know what this means but the statement should be: TESTER IS DBO. This will allow SDE to get installed and now you have an enterprise geodatabase. Depending on the trust/relationship with IT/SQL DBA they may let you continue to manage this new SDE with the TESTER account or may not. If they do, then the SQL DBA would make a change to be: TESTER AS DBO. This still leaves you as admin over the SDE DB without you having ability to change the entire SQL Server or the Windows Server. If they don't go that route because they want to have sole control over TESTER account then they can add a new account, GISADMIN and then make the same statement: GISADMIN AS DBO. Won't get into all the variances but this change from IS DBO to AS DBO does have some differences but none that will likely ever impact you directly, it does help further nest you down into your isolated area to have admin control over just the SDE DB but allows them to retain control of various system files within the SDE and this ability to have some level of admin permissions may come into play for you at times if there is a need to run some of the ESRI driven admin tools.

That was more than I expected but ok here goes for the other part which is ArcGIS for Server. Again, this is a software installation that occurs on server also probably having Windows Server as its underlying OS. So same as above, the admin for the ArcGIS for Server install does not have to be (and for security really shouldn't be) the admin of the Windows Server OS. Assuming that the IT staff does the install of ArcGIS for Server for you then there is a required account that will need to setup which is the admin account over the ArcGIS for Server install and they never have to give you this.

Now the part of this that again comes down to those relationships and trust will be the configuration of permissions within the ArcGIS for Server install. ArcGIS for Server uses role based permissions that can be tied to an identity store (such as Active Directory) or it has the ability to have its own store that gets manually created. Either way is fine but what you want is to have your user account set to have the role of ADMINISTRATOR. This will grant you full control over the settings and configurations within the ArcGIS for Server install. This does open up doors though which would allow you to inadvertently bring the ArcGIS for Server instance to a screeching halt because you could make changes to things such as directory folders to be used by the installation, or modify clusters, etc. If that trust isn't there then it might be getting our account set to be in the Publisher Role and as things arise that require administrator access and you bug them enough to do things they eventually build the trust etc. and work with you to give you the administrator privileges. At the end of the day when it's not viewed by staff to "be working" it's in most cases going to land at IT's doorstep somewhere so if you are working at the GIS Administrator level but outside of IT the relationships and trust are an inevitable consequence.