Choosing the Logon Account

You can choose to run an instance of Microsoft SQL Server 2005 Analysis Services (SSAS) in the security context of many different accounts. However, we recommend that you use a domain or local user account as the logon account for Analysis Services. Whether you use a domain or local user account depends on whether Analysis Services needs to connect to network resources, as described in the following list:

  • If Analysis Services needs to connect to network resources in the security context of its logon account, run the instance of Analysis Services in the security context of a dedicated domain user account.
  • If Analysis Services does not need to connect to network resources in the security context of its logon account, run the instance of Analysis Services in the security context of a local user account or a domain user account.

Also, after you select a logon account, we recommend that you do not use that logon account for any other purpose. Limiting the use of the logon account helps protect the encryption of the connection strings and passwords.

Using a Dedicated Domain User Account as the Logon Account

A domain user account is a user account that is created within Active Directory directory service. This account is a member of the Authenticated Users group in the domain. A service that is running in the security context of a domain user account presents the Kerberos ticket of the domain user account to remote servers. A service that is running in the security context of a domain user account can access resources on the remote server to which Authenticated Users or the specific user account has access permissions.

Using a Local User Account as the Logon Account

A local user account is a Windows user account that is created on the local computer. A service that is running in the security context of a local user account presents the access token for the local user account to remote servers. If a matching user name and password are configured on the remote server, a service that uses a local user account will be able to access resources on the remote server to which the identically named account has permissions. Although this scenario will work, maintaining these separate accounts and keeping their passwords synchronized increases management overhead.

Using Other Accounts as the Logon Account

In addition to a dedicated domain user account and a local user account, you can run an instance of Analysis Services in the context of the following accounts:

  • Local System
    This a predefined local account that has administrator rights on the local computer. A service that is running in the security context of the Local System account presents the local computer's credentials to remote servers. A service that is running in the security context of the Local System account cannot establish an authenticated session because the Local System account does not belong to the Everyone group in the domain. As a result, a service that uses this account can only access network resources by using a null session.
  • LocalService
    This is a predefined local account that has authenticated user rights on the local computer. A service that is running in the security context of the LocalService account presents anonymous credentials to remote servers. As a result, a service that uses this account can only access network resources that permit anonymous access.
  • NetworkService
    This is a predefined local account that has authenticated user rights on the local computer. A service that is running in the security context of the NetworkService account presents the local computer's credentials to remote servers as an Authenticated User, that is, a user who is a member of the Everyone group in the domain. As a result, a service that uses this account can access resources on the remote server to which Authenticated Users have access permissions. To enable a service that uses this account to access a remote resource, you can specifically add the name of the server that is running Analysis Services to the remote resource.

When the accounts in the previous list, or any other accounts, the best security practice is to run Analysis Services in the security context of an account that has the least possible rights. The Local System account is appropriate for the development environment, but this administrative account is not recommended for the production environment because it has too many rights. The LocalService and NetworkService accounts are also not recommended. Although designed to be used as service logon accounts that have minimal rights, the LocalService and NetworkService accounts are not recommended for Analysis Services because encrypted Analysis Services connection strings and passwords can be decrypted by the Analysis Services logon account. This means that another Windows service that is running under the same logon account as Analysis Services can decrypt these connection strings and passwords.

Specifying the Analysis Services Logon Account

After you decide which logon account context to use, you specify the logon account during setup on the Service Account page. The setup process grants the specified logon account all necessary rights on the local computer, including:

  • Bypass traverse checking
  • Token object creation
  • Security audit generation
  • Locking of pages in memory
  • Replacement of a process level token

The Analysis Services logon account is also granted NTFS full control permissions to all files in the instance of Analysis Services. Necessary rights on remote servers, such as to data sources, must be specifically granted to the logon account.

Note

The Analysis Services logon account has no permission to log on to an instance of Analysis Services, although it does have full control access to all files in the instance of Analysis Services.

See Also

Concepts

Granting Network Resource Access Rights to the Logon Account
Granting Additional Rights for Specific Tasks

Help and Information

Getting SQL Server 2005 Assistance