Accounts used by the GIS server

As your GIS server does its work, it needs to start and stop processes, read and write data to locations on the file system, and communicate between machines. To do these things securely, the GIS server uses three operating system accounts: the ArcGIS Server Object Manager (SOM) account, the ArcGIS Server Object Container (SOC) account, and the ArcGIS Web Services account. You are asked to provide the names of these accounts when you run the ArcGIS Server postinstallations. These accounts can have any name and can be assigned to any account already existing in your organization. However, it is important to understand why these accounts are necessary before deciding whether existing accounts in your domain should be used or if you should let the postinstallation create these accounts for you.

The SOM account

The SOM account runs the ArcGIS Server Object Manager Windows service. This process manages the container processes on the container machines as well as the GIS server's configuration information and log files. Consequently, the SOM account has privileges to write to the locations where the server configuration information and log files are stored (<ArcGIS Server install location>\server folder). It also has privileges to start container processes on the container machines.

The SOC account

Container processes actually host the services and do the work. Container processes are started by the server object manager but run as the SOC account. Therefore, the SOC account must have read access to any GIS resources (maps, locators, data) that preconfigured and application-specific services require to do their work. In addition, the SOC account must have write access to the server directories of the GIS server so that services running in container processes can write their output. These aspects of the SOC account are important for administering your site, especially when considering privileges on shared network drives, and so on.

One important aspect of the SOC account is that, since the container processes run as that account, a user who connects to the GIS server can do anything that the SOC account can do. Because developers are free to create their own objects on the server, they have access to a wide range of functionality, including the ability to read data that the SOC account has read privileges on. More important, developers can edit, delete, and otherwise affect files that the SOC account has write privileges to.

It can be dangerous to use a domain account with many privileges as the SOC account for your GIS server. The SOC account should only have enough privileges to access necessary data and perform the task of running services. The ArcGIS Server installation can create SOC accounts with the following minimum privileges on each container machine:

It is up to the GIS server administrator to grant this account access to any necessary data and write privileges to the server's output directories.

The GIS Server Post Install allows you to specify the SOM and SOC accounts.

The ArcGIS Web Services account

The ArcGIS Web Services account is used to process Web service requests on the GIS server. This account is used internally by the Web server to communicate with the GIS server when a user makes an Internet connection.

Like the SOM and SOC accounts, you can either specify an existing account or have the postinstallation create the account for you.

You will be asked to enter the ArcGIS Web Services account when you run the Web Services Post Install on the Web server machine and when you run the GIS Server Post Install on the SOM. You should enter the same account information on the SOM that you do on the Web server. The postinstallation will add the account to the agsadmin group on the SOM.

You can use either a local or domain account for the ArcGIS Web Services account. Using a domain account for the ArcGIS Web Services account does not pose the same security risk that it does for SOM and SOC accounts, as long as you do not give the domain account any privileges other than inclusion in the agsadmin group.

Best practices


8/22/2012