Windows Client Security

Security Contexts

Beginning in SAS®9, separate client and server security contexts within the SAS Workspace Server are not supported. All file access checks are now performed solely with the user ID under which the server was launched. The additional level of security checking, which was based on the client user ID, has been removed.

This change affects sites that were relying on two levels of access checking, one under the ServerUserID and an additional level under a ClientUserID that can be distinct. Before upgrading to SAS®9 from SAS 8, the following sites should review their security policies:

sites that launch COM workspace servers by using the "This user" identity setting in the dcomcnfg utility
sites that use COM+ pooling
sites that use Web applications configurations where the site administration has control of the client security settings

IOM Bridge for COM Security

Specifying the ServerUserID

When using the IOM Bridge for COM, the spawner uses the client-provided login name and password to launch the server. The server receives its ServerUserID (OS process user ID) from the login name that is provided by the client. The operating system then performs access checks by using the ServerUserID.

Specifying Encryption

The IOM Bridge for COM supports encryption of network traffic between the client and the IOM server. Weak encryption support (through the SASPROPRIETARY encryption algorithm) is available with Base SAS software. Stronger encryption requires a license to SAS/SECURE on the server machine.

On the Windows platform, the SAS/SECURE license allows the encryption algorithms that are available through the CryptoAPI to be used. On other platforms, encryption algorithms are included in the SAS/SECURE software.

Note: The SAS/SECURE Client for Windows must be installed on the Windows client machines in order to use the CryptoAPI. For more information, see Client Installation.

When you define a ServerDef, you can use the BridgeEncryptionAlgorithm and BridgeEncryptionLevel attributes to specify the encryption algorithm and the types of information that are encrypted. For more information, see the Object Manager package documentation (sasoman.chm.)

COM and DCOM Security

Specifying the ServerUserID

On Windows NT, the COM Service Control Manager (SCM) is responsible for launching COM and DCOM processes. The SCM reads values from the Windows registry to determine which identity to use when launching a process. These registry settings are configured by using the Windows dcomcnfg utility on the server.

The ServerUserID is set under the Identity tab for the properties of the SAS.Workspace application.

You can choose one of the following options for the identity to use to run the IOM server (the ServerUserID):

Interactive User

allows the interactive user to kill the SAS server process through the task manager, because the interactive user owns the process. This is a security risk for the interactive user, because SAS will be running under this user's ID. Someone must be logged on, or the SAS process will not run.

Note: For SAS®9 and later, there is no longer an additional level of security checking that is based on the client user ID. All file access checks are performed based solely on the user ID of the interactive user. This setting is not recommended for production environments.

Launching User

specifies the default option and is more secure than the other two identity settings. This option ensures that the ServerUserID is the same as the client who created it. This setting provides a single-signon environment for launching the server. However, it does require the use of network authentication to set up the identity of the server. The Windows NT LAN Manager (NTLM) network authentication mechanism, which is the default if any Windows NT4 machines are involved or if Windows 2000 Kerberos is not set up, cannot pass the client identity across more than one machine boundary. If you configure IOM servers to use "launching user" for DCOM connections, then the servers cannot access network files unless special Windows registry settings are adjusted on the file server. The servers also cannot deliver events back to a DCOM client unless one of the following is true:

The client permits everyone to access its COM interfaces by setting the authentication level to Everyone.
The client turns off authentication and authorization by setting the authentication level to None.

This user

enables you to configure a specific user name and password to run the IOM server. This option has the same security considerations as the interactive user, but you do not have to worry about always having someone logged on. Also, the identity does not change based on who is logged on.

Note: For SAS®9 and later, there is no longer an additional level of security checking based on the client user ID. All file access checks are performed based solely on the user ID that you specify for This user.

Specifying Encryption

For DCOM, encryption is enabled by using an authentication level of Packet Privacy.

Authentication and Impersonation Levels for COM and DCOM Security

Authentication levels must be set on both the client and server machines. The stronger of the two authentication levels is then selected. Here are the available authentication levels:

None

The client is not authenticated. It is not possible for the server to determine the identity of the caller.

Connect

The client is authenticated when the connection is first established and never again.

Call

The client is authenticated each time a method call is made.

Packet

Client authentication occurs for each packet. There might be multiple network packets used for a given call.

PacketIntegrity

Each packet is authenticated and verified to have the same content as when it was sent.

PacketPrivacy

All data is encrypted across the wire. Note that for local COM, the authentication level appears to be PacketPrivacy, but no encryption actually occurs on the local machine.

For more information about authentication levels, see the Microsoft documentation.

The impersonation level that is set on the client machine determines the impersonation level to use for the connection. The impersonation level that is set on the server machine is not used. Here are the available impersonation levels:

Anonymous

Impersonation is not allowed.

Identify

The server is allowed to know who is calling but cannot make calls by using the credentials of the caller.

Impersonate

The server can access resources by using the security credentials of the caller. The server cannot pass on the credentials. The IOM server attempts to impersonate the caller. This is the recommended setting.

Delegate

The server can access resources by using the security credentials of the caller and by passing on those credentials to other servers. SAS software does not currently support this option.

Programming Examples

This Visual Basic example retrieves the ClientUserID and the ServerUserID from the IOM server.

Public Sub sectest()
' This example prints both the client user ID and the server user ID.
' In SAS 9, the ServerUserID and the ClientUserID will always be the same.
' Create a local COM connection.
Dim sinfo As String
Dim swinfo() As String
Dim hwinfo() As String
Dim obWSMgr As New SASWorkspaceManager.WorkspaceManager
Set obSAS = obWSMgr.Workspaces.CreateWorkspaceByServer(
"MyServer", VisibilityNone, Nothing, "", "", sinfo)
' Get the host properties.
obSAS.Utilities.HostSystem.GetInfo swinfo, hwinfo
Debug.Print "ServerUserID: " & swinfo(
SAS.HostSystemSoftwareInfoIndexServerUserID)
Debug.Print "ClientUserID: " & swinfo(
SAS.HostSystemSoftwareInfoIndexClientUserID)
obSAS.Close
End Sub

COM Security Considerations for Client Applications

Here are some additional points to consider when developing client applications:

Always test your application and configuration before making sensitive information available to ensure that people who are not authorized cannot see the data.
Security settings and performance are inversely related. In general, the stronger the security, the slower things run. Security settings are highly configurable to allow the administrator to optimize performance for the required level of security.
No system is completely secure, even at the strongest security settings.
For maximum security when using the IOM Bridge for COM, use a BridgeEncryptionLevel of All and a strong BridgeEncryptionAlgorithm, such as RC4. For maximum performance, use a BridgeEncryptionLevel of None. (In this case, the setting for the BridgeEncryptionAlgorithm is ignored.)
In general, for maximum security with DCOM, use an impersonation level of Impersonate and an authentication level of Packet Privacy.

In SAS®9 and later, impersonation is not applied to workspace servers. For other IOM servers, an impersonation level of Impersonate is required.

In SAS®9 and later, the use of connectionless transports (mainly UDP) can cause difficulty with configuring and debugging. If your system (particularly Windows NT4) still uses a connectionless transport, then you might avoid complications by naming a connection-oriented transport (typically TCP) as the primary default.

COM Security Settings for Threaded Multi-User IOM Servers

In SAS®9, SAS Integration Technologies provides three new threaded multi-user IOM servers. Windows Component Services has an entry for each application as follows:

SASMDX.Server

SAS OLAP Server

SASOMI.OMI

SAS Metadata Server

StoredProcessServer.StoredProcessServer

SAS Stored Process Server, which provides interfaces to run user-written SAS programs (stored processes) to produce HTML output

If you do not specify the NOSECURITY object server parameter, then clients are authenticated when they connect to the server.

You can set DCOM security settings for each type of server individually. Use the Windows Component Services utility to specify security settings. In the Component Services utility, after you view the properties of a server, several tabs provide controls to customize the server's security.

Identity

controls the ServerUserID for COM launches. If you launch the server via COM (rather than via the object spawner), then the first client that connects must be a Windows client. For multi-user servers, select This user and specify a user ID and password under which the server will run. The server runs in its own logon session. Therefore, interactive logon and logoff activity on the same machine does not affect it. COM does not start the server with any environment variables and does not set a home directory. You should edit the SAS config file to remove environment variable references and to specify the "-sasinitialfolder" that you need at start-up.

General

controls the minimum client authentication level that the server accepts (which is also the level that the server uses on any outward calls). Connect (the default) is the minimum setting for the Authentication Level. Every COM client must also do the following:

define an authentication level of Connect or higher
set an impersonation level of Impersonate

These client settings can be specified by the client program on each calling interface or through one of two defaulting mechanisms:

a call to CoInitializeSecurity() in the client program
via the machine-wide default settings in COM security configuration

The ideal client program installs and uses an AppID of its own. However, some commonly used development languages, such as Visual Basic, do not provide an easy means to install and use an AppID.

Security

controls access, configuration, and launch permissions. These permissions can either be determined from machine-wide defaults or set up specifically for the particular IOM server application. Ensure that System is included in any of these permissions that you customize. You can use the access permissions editor to create a standard access control list to indicate who can use the server.

Location

indicates that the application should be run on this computer.

Endpoints

enables you to select the most used protocol. It is recommended that you use connection-oriented protocols such as TCP.