Introduction to DCOM/RPC

Distributed Component Object Model\Remote Procedure Call

The security that Windows XP SP2 applies to DCOM and RPCs prevents many network-based exploits that target these services. Therefore, careful consideration is required before changing security settings that affect network communications.

Distributed Component Object Model

Windows XP SP2 applies DCOM security to the COM server component to prevent anonymous access. The permissions are split into two ACLs:

• Launch and Activate Permissions

• Access Permissions

The system-wide ACLs are located in the Component Services management console, under My Computer Properties. Figure 3.20 shows this dialog box, which allows configuration of computer wide and default application DCOM security.

There are two ACLs for each permission type:

• Edit Limits. Sets computer wide permissions.

• Edit Default. Defines default application permissions. An administrator can then accept the default application permissions for each separate COM application or customize permissions individually. These permissions can be configured in the specific application properties in the COM services management console.

Figure 3.21 shows the DCOM security configuration interface for a specific application.

Computer-wide ACLs are stored in the registry at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Ole \MachineAccessRestriction= ACL

and

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Ole \MachineLaunchRestriction= ACL

Computer-wide restrictions permission settings can be pushed through Group Policy. You can use Active Directory Group Policy to configure computer-wide settings using the following path:

Windows Settings\Security Settings
\Local Policies\Security Options

Figure 3.22 shows Group Policy settings for DCOM Machine Access permissions configuration.

When Group Policy is in effect on a computer, it is honored and the local machine computer-wide restriction permission is ignored.

Configuration of the DCOM ACL creates a new security descriptor in the registry.

If you implement a COM server and expect to support remote activation by a non-administrative COM client or remote unauthenticated calls, you should initially consider whether this is the best configuration. If so, you need to change the default DCOM configuration for computer-wide limits (Edit Limits).

If you implement a COM server and override the default security settings, you should confirm that the application-specific Launch permission ACL grants Activation permission to appropriate users. If it does not, you need to change your application-specific Launch permission ACL to give activation rights to the appropriate users, so that applications and Windows components that use DCOM do not fail.

Caution: If these computer-wide restriction permissions are used incorrectly, it can cause applications and Windows components that use DCOM to fail.

The Deny access control entry (ACE) should be used judiciously. You should carefully assess its implications before you apply it. A Deny ACE could result in unintended results and may lock users out of certain functionality to which they need access. Depending on the security group for which you set the Deny ACE, this restriction could affect administrators on the local computer.

DCOM applications can also be exempted from activation security checks by editing the registry at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Ole\AppCompat\ActivationSecurityCheckExemptionList

Add a value with a value name of the application ID taken from the DCOM Config section of the Component Services MMC, and a value data of:

0 The application is not exempt from the activation security check

1 The application is exempt from the activation security check

Configure this list using Group Policy at:

Administrative Templates\System\Distributed COM
\Application Compatibility Settings

Remote Procedure Call

Windows XP SP2 provides developers and administrators the ability to secure RPC communications through the following settings:

RestrictRemoteClients registry key. The path to the key may not already exist but should be created at

HKEY_LOCAL_MACHINE\ SOFTWARE\Policies\ Microsoft\Windows NT\RPC.

The RestrictRemoteClients registry value accepts three values:

0 – Bypasses the new interface restrictions. Behavior is the same as Service 
Pack 1.

1 – (Default) Restricts access to all RPC interfaces. All remote anonymous calls are rejected by the RPC runtime. If an interface registers a security callback and provides the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag, this restriction does not apply to that interface. If the key does not exist (default), the system assumes this value for the key.

2 – Imposes the new interface restrictions without exemptions. This is the same as a value of 1, except that the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag does not result in exempting an interface. With this value, a system cannot receive remote anonymous calls using RPC. Applications that use DCOM might not work correctly if this value is set. This new security model allows an administrator to limit the system attack surface for the RPC protocol.

EnableAuthEpResolution registry key. The path to this key may not already exist but should be located at

HKEY_LOCAL_MACHINE\ SOFTWARE\Policies \Microsoft\Windows NT\RPC.

This value must be set on the client to enable authenticated communication with the RPC Endpoint Mapper on the remote computer running Windows XP SP2. This configuration is required with the Windows XP SP2 default setting of RestrictRemoteClients. The allowed values for EnableAuthEpResolution are:

0 – Disabled

1 – Enabled

RPC interface registration flags. Three new interface registration flags have been created, which make it easier for an application developer to secure an RPC interface.

RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH. When this flag is registered, the RPC runtime invokes the registered security callback for all calls, regardless of the call security settings. Without this flag, RPC rejects all unauthenticated calls before they reach the security callback. This flag works only when a security callback is registered.

RPC_IF_SEC_NO_CACHE A security callback is registered for an interface to restrict access to that interface. The typical security callback impersonates the client to determine if the client has sufficient rights to make a call to the interface. If a particular client identity passes a security callback once, it usually passes the same security callback every time. The RPC runtime takes advantage of this pattern by remembering when an individual client identity passes a security callback and skips the security callback for subsequent calls by that client to the same interface. This feature is called security callback caching and has existed since Windows 2000. For Windows XP SP2, use the RPC_IF_SEC_NO_CACHE flag to disable security callback caching for a given interface. This configuration is useful if the security check might change, possibly rejecting a client identity that was previously permitted.

RPC_IF_LOCAL_ONLY. When an interface is registered with this flag, RPC rejects calls made by remote RPC clients. In addition, local calls over all ncadg_*protocol sequences and all ncacn_* protocol sequences (except for named pipes, using ncacn_np) are also rejected. If a call is made on ncacn_np, RPC allows the call only if it comes from Server Service. Ncalrpc calls are always allowed through.

The default security configurations in Windows XP SP2 may cause some compatibility issues. The following three options are available to resolve these issues. These options are listed in order of preference.

• Require your RPC clients to use RPC security when contacting your server application. This is the best method to mitigate security threats.

• Exempt your interface from requiring authentication by setting the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag during interface registration. This configures RPC to allow anonymous connections only to the interface of your application.

• Force RPC to exhibit the same behavior as earlier versions of Windows by setting the RestrictRemoteClients registry key to “0”. RPC then accepts anonymous connections to all interfaces. This option should be avoided if possible because it reduces the overall security of the computer.

To view additional information regarding this technology in this guide, click the following links:

Introduction to DCOM/RPC

Application Compatibility Testing for DCOM/RPC