A change has been made in COM to provide computerwide access controls that govern access to all call, activation, or launch requests on the computer. The simplest way to think about these access controls is as an additional AccessCheck call that is done against a computerwide access control list (ACL) on each call, activation, or launch of any COM server on the computer. If the AccessCheck fails, the call, activation, or launch request will be denied. (This is in addition to any AccessCheck that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to access any COM server on the computer. There will be a computerwide ACL for launch permissions to cover activate and launch rights, and a computerwide ACL for access permissions to cover call rights. These can be configured through the Component Services Microsoft Management Console (MMC).

These computerwide ACLs provide a way to override weak security settings specified by a specific application through CoInitializeSecurity or application-specific security settings. This provides a minimum security standard that must be passed, regardless of the settings of the specific server.

These ACLs are checked when the interfaces exposed by RPCSS are accessed. This provides a method to control who has access to this system service.

These ACLs provide a centralized location where an administrator can set general authorization policy that applies to all COM servers on the computer.

By default, Windows Server 2003 SP1 computer restriction settings are as follows.

DCOM Computer Restriction Settings

Note
Distributed COM Users is a new built-in group included with Windows Server 2003 Service Pack 1 to expedite the process of adding users to the DCOM computer restriction settings.

By default, the Everyone group is granted local launch, local activation, and local access permissions. This should enable all local scenarios to work without modification to the software or the operating system.

By default, the Everyone and Anonymous groups are granted remote access permissions. This enables most COM client scenarios, including the common case where a COM client passes a local reference to a remote server, in effect turning the client into a server.

Also by default, only members of the Administrators group are granted remote activation and launch permissions. This disables remote activations by non-administrators to installed COM servers.

If you implement a COM server and expect to support remote activation by a non-administrative COM client or remote unauthenticated calls, then you should consider whether the risk associated with enabling this process is acceptable or if you should modify your implementation to not require remote activation by a non-administrative COM client.

If the risk is acceptable and you want to enable remote activation by a non-administrative COM client, you will need to change the default configuration for this feature.

You can change the configuration settings using either the Component Services Microsoft Management Console (MMC) or the Windows registry.

If you use the Component Services MMC snap-in, these settings can be configured on the COM Security tab of the Properties dialog box for the computer you are managing. The COM Security tab has been modified to enable you to set computerwide limits in addition to the standard default settings for COM servers. Additionally, you can provide separate ACL settings for local and remote access under both limits and defaults.

Alternatively, you can configure these ACL settings using the registry.

These ACLs are stored in the registry at the following locations:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction= ACL
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineLaunchRestriction= ACL

These are named values of the REG_BINARY type that contain data describing the ACL of the principals that can access any COM class or COM object on the computer. The access rights in the ACL are:

COM_RIGHTS_EXECUTE 1
COM_RIGHTS_EXECUTE_LOCAL 2
COM_RIGHTS_EXECUTE_REMOTE 4
COM_RIGHTS_ACTIVATE_LOCAL 8
COM_RIGHTS_ACTIVATE_REMOTE 16

These ACLs can be created using normal security functions.

Note
COM_RIGHTS_EXECUTE rights must always be present; absence of this right will generate an invalid security descriptor. Only users with Administrator rights can modify these settings.

RPCSS is a key service for the RPC Endpoint Mapper and DCOM infrastructure that is network facing. This service ran as Local System in previous versions of Windows. To reduce the attack surface of Windows and provide defense in depth, the RPCSS service functionality was split into two services. The RPCSS service with all the original functionality that did not require Local System privileges now runs under the Network Service account. A new DCOMLaunch service that includes functionality that requires Local System privileges runs under the Local System account; however, this service is not network facing.

This change reduces the attack surface and provides defense in depth for the RPCSS service because an elevation of privilege in the RPCSS service will now be limited to the Network Service privilege.

This change should be transparent to users because the combination of the RPCSS and DCOMLaunch services is equivalent to the previous RPCSS service provided in prior versions of Windows.

COM server applications have two types of permissions: launch permissions and access permissions. Launch permissions control authorization to start a COM server during COM activation if the server is not already running. These permissions are defined as security descriptors that are specified in registry settings. Access permissions control authorization to call a running COM server. These permissions are defined as security descriptors provided to the COM infrastructure through the CoInitializeSecurity API, or using registry settings. Both launch and access permissions allow or deny access based on principals, and make no distinction as to whether the caller is local to the server or remote.

The first change distinguishes the COM access rights, based on distance. The two distances that are defined are Local and Remote. A Local COM message arrives by way of the Lightweight Remote Procedure Call (LRPC) protocol, while a Remote COM message arrives by way of a remote procedure call (RPC) host protocol like transmission control protocol (TCP).

COM activation is the act of getting a COM interface proxy on a client by calling CoCreateInstance or one of its variants. As a side effect of this activation process, sometimes a COM server must be started to satisfy the client’s request. A launch permissions ACL asserts who is allowed to start a COM server. An access permissions ACL asserts who is allowed to activate a COM object or call that object after the COM server is already running.

The second change is that the call and activation rights are separated to reflect two distinct operations and to move the activation right from the access permission ACL to the launch permission ACL. Since activation and launching are both related to acquiring an interface pointer, activation and launch access rights logically belong together in one ACL. Because you always specify launch permissions through configuration (as compared to access permissions, which are often specified programmatically), putting the activation rights in the launch permission ACL provides the administrator with control over activation.

The Launch Permission access control entries (ACEs) are broken into four access rights:

• Local Launch (LL)
  
  
• Remote Launch (RL)
  
  
• Local Activation (LA)
  
  
• Remote Activation (RA)
  
  

The Access Permission security descriptor is split into two access rights:

• Local Access calls (LC)
  
  
• Remote Access calls (RC)
  
  

This allows the administrator to apply very specific security configurations. For example, you can configure a COM server so that it accepts local calls from everyone, while only accepting remote calls from Administrators. These distinctions can be specified through changes to the COM Permissions security descriptors.

Earlier versions of the COM server application have no way to restrict an application so that it can only be used locally without exposing the application on the network by way of DCOM. When a user has access to a COM server application, he or she has access for both local and remote use.

A COM server application might want to expose itself to unauthenticated users to implement a COM callback scenario. In this scenario, the application must also expose its activation to unauthenticated users, which might not be desirable because malicious users could use that scenario to gain unauthorized access to that server.

Precise COM permissions give flexibility to the administrator to control a computer’s COM permission policy. These permissions enable security for the described scenarios.

To provide backwards compatibility, existing COM security descriptors are interpreted to allow or deny both local and remote access simultaneously. That is, an access control entry will either allow both local and remote, or deny both local and remote.

There are no backwards-compatibility issues for call or launch rights. There is, however, an activation rights compatibility issue. If, in the existing security descriptors for a COM server, the configured launch permissions are more restrictive than the access permissions and are more restrictive than what is minimally needed for client activation scenarios, then the Launch Permissions ACL must be modified to give the authorized clients the appropriate activation permissions.

For COM applications that use the default security settings, there are no compatibility issues. For applications that are dynamically started using COM activation, most will have no compatibility issues, since the launch permissions must already include anyone who is able to activate an object. Otherwise, such applications would have generated activation failures even before applying Service Pack 1, when callers without launch permission try to activate an object and the COM server is not already running.

The applications of most concern for compatibility issues are COM applications that are already started by way of some other mechanism, such as Windows Explorer or Service Control Manager. You can also start these applications by way of a previous COM activation, which overrides the default access and launch permissions and specifies launch permissions that are more restrictive than the call permissions. For more details on addressing this compatibility issue, see "How do I resolve these issues?" in the next section.

If a system that was updated to Windows Server 2003 Service Pack 1 is rolled back to an earlier service pack, any access control entry that was edited to allow local access, remote access, or both, will be interpreted to allow both local and remote access. Any ACE that was edited to deny local access, remote access, or both, will be interpreted to deny both local and remote access. Whenever you uninstall a service pack, you should ensure that no newly set ACEs will cause applications to stop working.

If you implement a COM server and you override the default security settings, confirm that the application-specific launch permissions ACL grants activation permission to appropriate users. If it does not, you will need to change your application-specific launch permission ACL to give appropriate users activation rights so applications and Windows components that use DCOM do not fail. These application-specific launch permissions are stored in the registry.

The COM ACLs can be created or modified using normal security functions.