Security-Related Policy Settings

SP2 provides many enhancements designed to provide increased security for corporate networks. These changes include the following security features which you can manage by using Group Policy:

The DCOM infrastructure provides new access control restrictions to help minimize the security risks posed by network attacks. You can use Group Policy to manage the new computer-wide restrictions to control call, activation, and launch requests on the computer. You can also specify exceptions to the DCOM activation security check by using policy settings.

Security Center, a new service in SP2, acts as a central location for modifying security settings, and providing security information, recommendations and updates. You can enable a Security Center Group Policy setting to centrally monitor computers in your organization to ensure that they contain the most recent security patches and to alert users if their computers are at risk.

On This Page

Distributed COM
Security Center

Distributed COM

DCOM extends the Component Object Model (COM) to support communication among objects on different computers. With DCOM, your application can be distributed at locations that make the most sense to your customer and to the application.

COM provides two categories of security permission, Launch security permission* *and Access security permission. Launch security controls which objects a client is allowed to instantiate; that is, which classes a client is allowed to launch and retrieve (activate) objects from. Access security specifies how security operates at the per-call level on an established connection from a client to a server object.

For more information about DCOM, see “Component Object Model” on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=20922.

DCOM Changes in SP2

In SP2, the DCOM infrastructure provides new access control restrictions to help reduce the risk of a successful network attack.

COM provides computer-wide access control lists (ACLs) that govern access to all call, activation, or launch requests on the computer. You can think about these access controls as an additional AccessCheck call that is done against a computer-wide ACL on each call, activation, or launch of any COM server on the computer. This access check is in addition to any AccessCheck that is run against the server-specific ACLs. If this AccessCheck fails, the call, activation, or launch request is denied. In effect, this check provides a minimum authorization standard that must be passed to access any COM server on the computer.

The following new ACLs can be configured by using Group Policy:

• A computer-wide ACL for launch permissions to cover activate and launch rights. This is the MachineLaunchRestriction setting.

• A computer-wide ACL for access permissions to cover call rights. This is the MachineAccessRestriction setting.

The use of these computer-wide ACLs provides a way to override weak security settings specified by a particular application by using code (for example, CoInitializeSecurity) or by configuration such as application-specific security settings. Checking these ACLs provides a minimum security standard that must be passed, regardless of the settings of the specific server. To manage these computer-wide ACLs, it is recommended that you use Group Policy.

The MachineLaunchRestriction and MachineAccessRestriction ACLs are checked when the interfaces exposed by the RpcSs service or DCOM application are accessed; these ACLs provide a method to control who has access to this system for DCOM applications. These ACLs also provide a centralized location where you can set general authorization policy that applies to all COM servers on the computer. RpcSs is a system service that runs during system startup. This service manages activation of COM objects and the running object table and provides helper services to DCOM remoting infrastructure.

Table 5 lists the default computer restriction ACLs in Windows XP with SP2.

Table 5    Computer Restriction ACLs

Permission	Administrators	Everyone	Anonymous Logon
Launch	Local Launch - Allow Remote Launch - Allow Local Activation - Allow Remote Activation - Allow	Local Launch - Allow Local Activation - Allow
Access		Local Access - Allow Remote Access - Allow	Local Access - Allow

Although many COM applications provide some security-specific code (such as calling CoInitializeSecurity), applications might use weak security settings which might allow unauthenticated access to the process. There is currently no way for an administrator to override these settings to enforce stronger security in versions of Windows earlier than Windows XP SP2.

COM infrastructure includes the RpcSs service. RpcSs exposes RPC interfaces that are remotely callable. Because some COM servers allow unauthenticated remote access, as explained in the preceding section, these interfaces can be called by anyone, including unauthenticated users. As a result, RpcSs can be susceptible to attacks by malicious users using remote, unauthenticated computers.

In versions of Windows XP earlier than Windows XP with SP2, it was difficult for an administrator to determine the exact level of exposure of the COM servers on a computer. An administrator could get an idea of the exposure level by systematically checking the configured security settings for all the registered COM applications on the computer; however, given the large number of COM servers in a default installation of Windows XP, that task becomes daunting. There is no way to view the settings for a server that incorporates security in the software, other than reviewing the source code for that software.

The DCOM computer-wide access restrictions help mitigate these security problems, and they also allow you to disable incoming DCOM activation, launch, and calls.

Before you use these DCOM policy settings, it is recommended that read the information about changes to DCOM in the “DCOM Security Enhancements” section in “Part 2: Network Protection Technologies” of the “Changes to Functionality in Microsoft Windows XP Service Pack 2” white paper on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=29126. This white paper provides more detailed information about the DCOM changes.

As with all Group Policy settings, it is strongly recommended that you fully test the DCOM policy settings in a test environment before you deploy the policy settings to computers in your production environment. For more information, see the “Staging Group Policy Deployments” chapter of the “Designing a Managed Environment” book of the Microsoft Windows Server 2003 Deployment Kit on the Windows Server System Web site at https://go.microsoft.com/fwlink/?LinkId=30650.

  Caution
If these DCOM policy settings are used incorrectly, it can cause applications and Windows components that use DCOM to fail.
The Deny 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.

Using Group Policy to Manage Computer-Wide DCOM Access Restrictions

To manage the computer-wide ACLs in an enterprise, you can use the following Group Policy settings in Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options:

• DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax. You can use this setting to grant access to all the computers to particular users for DCOM application in the enterprise through Group Policy.

• DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax. You can use this setting to grant launch or activation permissions to all the computers to particular users for DCOM application in the enterprise through Group Policy.

DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax

This policy setting determines which users or groups might access DCOM application remotely or locally. This setting is used to control the attack surface of the computer for DCOM applications.

You can use this policy setting to specify access permissions to all the computers to particular users for DCOM applications in the enterprise. When you specify the users or groups that are to be given permission, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. If the security descriptor is left blank, the policy setting is defined in the template, but it is not enforced. Users and groups can be given explicit Allow or Deny privileges on both local access and remote access.

The registry settings that are created as a result of enabling the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting take precedence over (have higher priority) the previous registry settings in this area. RpcSs checks the new registry keys in the Policies section for the computer restrictions, and these registry entries take precedence over the existing registry keys under OLE. This means that previously existing registry settings are no longer effective, and if you make changes to the existing settings, the computer access permissions for any users are not changed. You should take care to correctly configure their list of users and groups.

The possible values for this policy setting are:

• Blank. This represents the local security policy way of deleting the policy enforcement key. This value deletes the policy and then sets it as Not defined state. The Blank value is set by using the ACL editor and emptying the list, and then pressing OK.

• SDDL. This is the Security Descriptor Definition Language representation of the groups and privileges you specify when you enable this policy.

• Not Defined. This is the default value.

    Note
  If the administrator is denied permission to access DCOM applications due to the changes made to DCOM in SP2, the administrator can use the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting to manage DCOM access to the computer. The administrator can specify which users and groups can access the DCOM application on the computer both locally and remotely by using this setting. This will restore control of the DCOM application to the administrator and users. To do this, open the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax setting, and click Edit Security. Specify the groups you want to include and the computer access permissions for those groups. This defines the setting and sets the appropriate SDDL value.

DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax

This policy setting determines which users or groups might launch or activate DCOM applications remotely or locally. This setting is used to control the attack surface of the computer for DCOM applications.

You can use this Group Policy setting to grant access to all the computers to particular users for DCOM application in the enterprise. When you define this setting, and specify the users or groups that are to be given permission, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. If the security descriptor is left blank, the policy setting is defined in the template, but it is not enforced. Users and groups can be given explicit Allow or Deny privileges on local launch, remote launch, local activation, and remote activation.

The registry settings that are created as a result of this policy take precedence over the previous registry settings in this area. RpcSs checks the new registry keys in the Policies section for the computer restrictions; these entries take precedence over the existing registry keys under OLE.

The possible values for this Group Policy setting are:

• Blank. This represents the local security policy way of deleting the policy enforcement key. This value deletes the policy and then sets it to Not defined state. The Blank value is set by using the ACL editor and emptying the list, and then pressing OK.

• SDDL. This is the Security Descriptor Definition Language representation of the groups and privileges you specify when you enable this policy.

• Not Defined. This is the default value.

    Note
  If the administrator is denied access to activate and launch DCOM applications due to the changes made to DCOM in SP2, this policy setting can be used for controlling the DCOM activation and launch to the computer. The administrator can specify which users and groups can launch and activate DCOM applications on the computer both locally and remotely by using the DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting. This restores control of the DCOM application to the administrator and specified users. To do this, open the DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax setting, and click Edit Security. Specify the groups you want to include and the computer launch permissions for those groups. This defines the setting and sets the appropriate SDDL value.

Special Considerations for Delegation of Group Policy Results and Computer-Wide DCOM Access Restrictions

If you are delegating access to Group Policy Results, you must enable the Windows Firewall: Allow remote administration exception policy setting on target computers. To permit remote access for the targeted User, Group, or built-in security principal, you must also set these DCOM security policy settings on target computers**:**

• DCOM Machine access restrictions in Security Descriptor Definition Language (SDDL) syntax

• DCOM: Machine launch restrictions in Security Descriptor Definition Language (SDDL) syntax

    Note
  In SP2, in addition to the DCOM computer-wide restrictions, more specific DCOM security rights are introduced which include an Activation right. However, there might be a few scenarios in which you might want to exempt an application from the Activation rights for application compatibility reasons. The policy settings for activation security check exemption must be used judiciously. You can use the new policy settings to specify an exemption to DCOM Activation security checks, as the next section describes.

Using Group Policy to Specify Activation Security Check Exemptions for DCOM

The DCOM Activation security check is done before a DCOM server process starts, and before an object activation request is dispatched to the server process. This access check is done against the custom Launch permission security descriptor if it exists on the DCOM server, or against the computer launch permissions defaults.

As an example of the DCOM activation security check changes in SP2, consider the following scenario. Prior to SP2, when a COM server specified a Launch permission set to Deny, that restriction only applied to launching the server. With SP2, setting the Launch permission to Deny affects both launching and activating (creating) an object within the COM server. This means that a user who was previously able to create objects in the COM server prior to SP2 (assuming the server was already running), can now be prevented from doing so in Windows XP with SP2 (because Activate access is denied). To address scenarios such as this, the recommended approach is to re-configure the Launch ACL to allow such users to activate objects by setting the appropriate (local or remote) Activate privilege to Allow.

In many cases, ISVs configure custom DCOM activation security settings for their applications. Therefore, you might need to contact the application’s vendor (ISV) to determine if they have an updated version of their application.

If re-configuring the Launch ACL, as described previously, is not an appropriate approach for your particular situation (perhaps due to large-scale deployment scenarios), you can use the new DCOM policy settings to exempt such COM servers from the new DCOM computer-wide security check.

The default computer restriction ACLs are listed in the “DCOM Changes in SP2” section, earlier in this document.

Define Activation Security Check exemption

This policy setting allows you to view and change a list of DCOM server application IDs (AppIDs) which are exempted from the DCOM Activation security check.

DCOM uses two lists of DCOM server AppIDs, one list is configured by using the Define Activation Security Check exemption Group Policy setting, and the other is created by the local computer administrators. The AppID key is one of the registry keys that COM uses; it groups the configuration options for one or more distributed COM objects into one centralized location in the registry. This key includes the AppID named value, which identifies the AppID GUID that corresponds to the named executable.

If you configure the Define Activation Security Check exemption policy setting, DCOM ignores the second list, unless the associated Allow local activation security check exemptions policy setting is also enabled. You must use curly-brace format for any DCOM server AppIDs that you add to the list of DCOM server AppIDs by using this policy setting, for example, {b5dcb061-cefb-42e0-a1be-e6a6438133fe} (this AppID number is intended as an example only). If you enter a non-existent or improperly formatted AppID, DCOM adds it to the list, but it does not check for errors.

If you enable this policy setting, you can view and change the list of DCOM activation security check exemptions defined by Group Policy settings.

You can use one of the following values:

• 1. If you add an AppID to this list and set its value to 1, DCOM does not enforce the Activation security check for that DCOM server.

• 0. If you add an AppID to this list and set its value to 0, DCOM always enforces the Activation security check for that DCOM server regardless of local settings.

    Note
  DCOM servers added to this exemption list are exempted only if their custom launch permissions do not contain specific Local Launch, Remote Launch, Local Activate, or Remote Activate permissions set to Allow or Deny for any users or groups. The exemptions for DCOM Server AppIDs that you add to this list apply to 32-bit version, and the 64-bit version of Windows Server 2003, if present.

Allow local activation security check exemptions

This policy setting allows you to specify that local computer administrators can supplement the Define Activation Security Check exemptions list.

If you enable this policy setting, and DCOM does not find an explicit entry for a DCOM server application ID (AppID) in the Define Activation Security Check exemptions policy (if enabled), DCOM looks for an entry in the locally configured list.

For more information about COM and the AppID key, see “COM Registry Entries” in the COM SDK Documentation in MSD*N *at https://go.microsoft.com/fwlink/?LinkId=32831.

Security Center

Security Center is a new service in SP2 that provides a central location for changing security settings, learning more about security, and ensuring that users’ computers are up to date with the essential security settings that are recommended by Microsoft.

In a Windows domain environment, you can use Group Policy to enable the Security Center to monitor users’ computers to ensure that they have the latest security updates and to notify users if their computers are at risk. By using the Security Center policy in your organization, you can help ensure that users are running up-to-date antivirus software, and that the users’ computers are being automatically updated with the latest critical updates from Microsoft.

The Security Center service runs as a background process and checks the state of the following components on the user’s computer:

• Firewall. The Security Center checks whether Windows Firewall is on or off. It also checks for the presence of some other software firewalls by querying for specific WMI providers made available by participating vendors.

• Virus protection. The Security Center checks for the presence of antivirus software using queries for specific WMI providers that are made available by participating vendors. If the information is available, the Security Center service also determines whether the software is up to date and whether real-time scanning is turned on.

• Automatic Updates. The Security Center checks to make sure that Automatic Updates is set to the recommended setting, which automatically downloads and installs critical updates to the user’s computer. If Automatic Updates is turned off or is not set to the recommended settings, the Security Center provides appropriate recommendations.

If a component is found to be missing or out of compliance with your Security Policy, the Security Center alerts users by placing a red icon in the notification area of the user’s taskbar and by providing an Alert message at logon. This message contains links to open the Security Center user interface, which provides information about the problem and recommendations for fixing it.

In cases where users are running firewall or antivirus software that is not detected by Security Center, the user has the option to set the Security Center to bypass alerting for that component.

In Control Panel, Security Center also serves as a starting point for Control Panel items related to security and security-related Web links. By default, the Security Center feature applies to all computers in workgroups, that is, computers that are not participating in a Windows domain.

You can use a Group Policy setting to centrally manage the Security Center feature for computers in a Windows domain. The Turn on Security Center (Domain PCs only) policy setting is accessed in the Group Policy Object Editor in the Computer Configuration\Administrative Templates\Windows Components\Security Center node.

Using Group Policy for Security Center

If you enable the Turn on Security Center (Domain PCs only) policy setting, Security Center monitors essential security settings (firewall, antivirus, and Automatic Updates), and notifies users when their computers might be at risk. By default, the Turn on Security Center (Domain PCs only) policy setting is not enabled. When the Security Center is turned off, neither the notifications nor the Security Center status section are displayed. Note that you can not use Group Policy to disable the Security Center for users that are not members of a Windows domain.

  Note
In Windows XP SP1, the service pack could be installed using the /quiet option to make the installation of the Service Pack transparent to the user. However, if SP2 is installed using the /quiet or /q option, Security Center in Control Panel is displayed upon the first interactive logon after installation, so that users can review their security settings. It is recommended that you communicate this expected behavior to your users so that the experience does not cause unwarranted concern.
When SP2 is installed in a domain environment, Security Center is controlled by the Security Center: Turn on Security Center (Domain PCs only) policy setting which is not enabled by default.

There is no change in behavior caused by the Security Center itself that would affect an application or service. However, the Security Center helps enforce the use of Microsoft and third-party security-related components that might raise compatibility or other issues. For example, see the “Windows Firewall” section of the* *“Changes to Functionality in Microsoft Windows XP with Service Pack 2” document on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=29126.

For more information about using Security Center, see *"*Changes to Functionality in Microsoft Windows XP with Service Pack 2”document on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=29126.