How to Reduce Exposure of the SASTRUST Password

Note: This is an advanced, optional configuration that can reduce the exposure of a privileged service account. Consider using these instructions if the standard protections (host protection of configuration files and encryption of the sastrust password in those files) is not sufficient for your environment. On hosts other than Windows, these instructions might not provide a clear security benefit.

In the standard configuration, the OLAP server and the object spawner read the sastrust ID and password from their configuration files during initialization. These components use the sastrust credentials to connect to the metadata server and read the metadata that they use to perform their tasks. For example:

The spawner uses the SAS Trusted User identity to read metadata about the servers that it launches.
The OLAP server uses the SAS Trusted User to discover schemas and cubes and to impersonate each requesting user.

The primary reason to remove the sastrust credential from configuration files is to enhance security in a Windows environment. For sites that don't use Integrated Windows authentication, removing the sastrust credentials makes sense only if you prefer the exposure of using the trusted peer protocol to the exposure of storing the credentials in two host-protected files.

Note: Another reason might be to avoid having to update the sastrust password in the configuration file. However, maintenance isn't usually a concern because sastrust is usually an internal account with a password that doesn't expire.

To remove the sastrust credentials from configuration files:

Locate the sasv9_meta.cfg file that is in your equivalent of SAS/Config/Lev1/. Make a backup copy of the file. In the original file, delete your version of these lines:
```
-metauser "sastrust@saspw"
-metapass "{sas002}3CD4EA1E35CA49324AOC4D63"
```
Locate the file metadataConfig.xml file that is in your equivalent of SAS/Config/Lev1/ObjectSpawner. Make a backup copy of the file. In the original file, delete your version of this entry:
```
<Login Name="Metadata Login" UserId="sastrust@saspw" 
 Password="{sas002}3CD4EA1E35CA49324AOC4D63"/>
```
Determine which account (or accounts) are used for the connections and, on Windows, what format you should use for the account ID in the following steps. For example:
- On UNIX, the spawner and the OLAP server run under a designated account that is identified during installation.
- On Windows, if these components run under the local system account, use the format system@machine-name (if you are using trusted peer) or machine-name$@Windows-domain (if you are using IWA). Otherwise, use the usual Windows qualified format (such as user-ID@Windows-domain).
To enable the spawner and the OLAP server to read the same metadata that sastrust reads, add a login such as this to the SAS Trusted User's Accounts tab in SAS Management Console:
```
DefaultAuth | connecting-account-ID | (no password)
```
If the components use different accounts, add one login for each account. For example:
```
DefaultAuth | myMachine$@myWinDomain | (no password)
DefaultAuth | invoker                | (no password)
```
You can ignore any messages about multiple logins within an authentication domain.
To make the connecting accounts trusted users, add their account IDs to your equivalent of the SAS/Config/Lev1/SASMeta/MetadataServer/trustedUsers.txt file. Use the same format for the user ID that you used in step 3. For example, the updated contents might look like this:
```
sastrust@saspw
myMachine$@myWinDomain
invoker
```
Note: The OLAP server uses its trusted user status to impersonate clients for metadata access control evaluations. The spawner uses its trusted user status to determine which servers each requesting user is permitted to use.
Restart the metadata server. Verify that the spawner and the OLAP server can still contact the metadata server. In the metadata server log, you should see a separate connection from each component. The connections will be either IWA (Integrated Windows authentication) or trusted peer.

Note: If you expect IWA but instead see trusted peer, make sure the metadata server has -sspi in its invocation command. If you expect trusted peer but the connection fails, make sure the metadata server has the trustsaspeer object server parameter specified.

How to Reduce Exposure of the SASTRUST Password

See Also