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 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.

On Linux/Solaris, the SOM account and the installation owner are the same account.

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.

• On Linux/Solaris:

The SOC account and the installation owner are the same account. The GIS Server Installation allows you to specify the installation owner, which is also the SOM and SOC accounts.

On Windows:

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:

• Ability to start and activate container processes
• Write access to the system temp directory

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.

On Linux/Solaris, the installation creates a local GIS Server user account "admin". The GIS server uses this account as the ArcGIS Web services account. The default password is "admin". You can change the password in Manager.

On Windows, 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

• On Windows, the above-mentioned accounts are used internally by the GIS server and need only have limited permissions on the machine. Chances are you'll only encounter them when you're installing ArcGIS Server on other machines or when you're giving the GIS server permissions to access your data. In most cases, it's sufficient to use the default account names suggested by the postinstallation (ArcGISSOM, ArcGISSOC, and ArcGISWebServices) and let the postinstallation create the accounts for you. When you let the postinstallation create the accounts for you, it will grant the minimum permissions necessary.
• For security purposes, ESRI recommends that you make the SOM and SOC accounts local instead of specifying domain accounts. This ensures that a malicious user could not use the accounts to acquire administrative privileges on other machines in your network. On Linux/Solaris, it also limits the chances of Server not working properly due to certain network account policies. When you choose to let the installation on Linux/Solaris or the postinstallation on Windows create the accounts for you, it creates local accounts.
• If your data resides on a machine that contains no components of ArcGIS Server, you may need to use the operating system tools to create the SOC account on that machine. You should give the SOC account the same user name and password (and UID on Linux/Solaris) that it has on all the other machines in your system. Then you can grant the account access to your data.