Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Securing COM, COM+, and DCOM Applications Using Component Services

Component Object Model (COM), COM+, and Distributed COM (DCOM) applications are managed from the Component Services console, as displayed in Figure 4-31. You can manage security for these applications inasmuch as the application provides interfaces for doing so. COM+ applications, for example, may define roles that have specific privileges and permissions within the application. You can manage roles using the console if roles have been defined in the application.

Security for all COM, COM+, and DCOM applications consists of the following:

Setting user rights, audit, and resources permissions such as those set on NTFS folders and files.

Setting system-wide properties that will be used by all applications that you do not manage explicitly.

Setting Application properties for each application that you want to manage explicitly.

Adding users and groups to roles in role-enabled COM+ applications.

Ensuring only administrators can modify application settings and add users to roles.

Limiting the number of administrators who can modify COM+ security.

WARNING: Don't Adjust Existing COM+ Application Properties

It is not recommended that you adjust application properties because applications may contain code that requires the default settings to be in place. Modifying settings may cause an application to fail, become unstable, or behave less securely. Unless you thoroughly understand the application and know why modifying settings can improve security, you should leave settings as they are. The best time to question the default settings used on an application is during its development.

Configuring Security for COM and COM+ Application Interaction

A number of properties can be configured:

Authentication level for calls

Authorization

Security Level

Impersonation

Identification

Launch Permissions

Access Permissions

Authentication Level for Calls

An identity is a characteristic such as a user ID or computer name. Authentication is the process by which an identity proves it is who it claims to be. Calls to COM+ components may be restricted to users with a specific role, in which case authentication is used to determine if the user is who they say they are, and then their membership is checked.

NOTE: Resource

You can learn more about managing COM+ applications from the platform Software Development KIT (SDK). You can locate a copy online at the MSDN site, http://msdn.microsoft.com.

Authentication level is specified in the Component Services tool, or it can be managed programmatically using Administrative SDK functions. COM+ server and client applications can require authentication. Authentication can be set to a range of degrees, from none to encryption of every packet and all method call parameters. The following list is ordered from no authentication to the highest level. Authentication is negotiated between the client and the server, and the more secure setting of the two is used. You can control authentication from the server side by setting authentication to the highest level you desire. Machine-wide settings (the default is connect) are used if the authentication level is not set for an application. Authentication levels are as follows:

None
No authentication occurs.

Connect
Credentials are checked only when a connection is made.

Call
Credentials are checked at the beginning of each call.

Packet
Credentials are checked, and verification that all called data is received takes place.

Packet integrity
Credentials are checked, and verification that call data has not changed in transit takes place.

Packet privacy
Credentials are checked, and verification that all information in the packet, including sender's identity and signature, are encrypted

To set machine-wide authentication level, follow these steps:

Authorization

If role-based security is available in the COM+ application, enable authorization checking. Users who access the application are checked for role membership before being authorized to do anything in the application. To enable authorization checking, follow these these steps:

Security Level

The security level sets the level at which access level checks are performed in role-enabled COM+ applications. Access checks can be set at the component level or at the process level. Setting access checks at the component level enables roles. Roles can be assigned to components, interfaces, and methods within the COM+ application. Process-level access checks apply only to application boundaries.

To set a security level, follow these steps:

Perform access checks only at the process level

Perform access checks at the process and component level

Impersonation and Delegation

When a server makes a call on behalf of a client and uses the client's credentials instead of its own, it is performing impersonation. Resource access is thus expanded, or restricted, depending on what the user can do. For example, you may need the server application to access data in a database, in which case you would want it to be able to get any data that the client has permission to access.

Impersonation levels are as follows:

Anonymous
Client is anonymous as far as the server is concerned. The server can impersonate the client, but no information about the client is in the impersonation token.

Identify
The default; the server can obtain the client's identity and can impersonate. Used for determining access-checking levels.

Impersonate
Default for COM+ server apps. The server can impersonate the client but is restricted. The server can access resources on the same computer as the client. If the server is on the same computer as the client, it can access network resources on the client's behalf. If it is not, it can only access resources on the computer it resides on.

Delegate
The server can impersonate the client, whether or not it is on the same computer as the client. Client credentials can be passed to any number of machines.

To set the impersonation level, follow these steps:

Delegation is a special type of impersonation used over the network. The server and client applications do not reside on the same computer, and yet the server uses the client's identity to access resources on a third remote machine. Delegation is controlled with the Active Directory Service. To set delegation, see Chapter 8, "Trust." Two requirements must be met:

The identity the server is running under (the account it uses to run its service) must be marked "Trusted for delegation."

The client application must be running under an identity that is not marked as "Account is sensitive and cannot be delegated."

Identification

COM and COM+ applications may run as a service. When they do, they run within the security context of an account or the Local System. If they are not implemented as a service, they may impersonate or act on the authority of the user account used to run them.

Application identity is set during application installation and is only relevant for server applications. Identity is the user account that the application runs under and uses when it calls other applications and resources. Library identity is not set. Library COM+ applications use the identity of the host. Using a specific account, either Local service or an assigned user account is more secure than allowing the identity to be interactive. Interactive means that the COM+ application runs with the authority of the logged on user. If, for example, the local administrator is logged on, COM+ applications could be running with his authority and could be used to make calls and access resources, even for clients. If no one is logged on, then the application cannot be run. Identity can be set to this:

Interactive
The user who is logged on

Local service user
An account with minimal permissions to run a locally accessible service

A specific valid user account

WARNING: Password Storage for COM+ Identity

COM+ stores passwords in LSA secrets, and thus an administrator can obtain them. Be sure to use an account created just for the COM+ application and deny the account the right to log on locally.

Launch Permissions

Launch permissions specify a list of users who can be granted or denied permission to run or launch component model applications. When set in the properties of the computer, permission to launch is conferred for all applications that do not set their own launch permissions list. The default list is INTERACTIVE (anyone logged on locally), SYSTEM, and Administrators.

To set launch permissions:

Launch Permissions can be set for individual applications. Examine a few applications, and you will learn that most simply use the default, but there are exceptions. If you open the properties for Automatic Updates, as shown in Figure 4-35, you can see that the launch permissions are customized. They are restricted to the SYSTEM and Administrators, while the default permissions are INTERACTIVE, SYSTEM, and Administrators.

Setting launch permissions is a good way to restrict software use. You can set launch permissions on any Component Services application and allow only certain users to run them. For example, the default for Media Player is the default settings: Administrator, SYSTEM, and INTERACTIVE. If you want to restrict startup (launch permissions), use (access permissions), or configuration (configuration), you can make those adjustments here.

WARNING: Modifying Settings

Before you jump in and modify settings, you need to understand the impact of your actions. If you don't know what an application is doing, don't change its settings. If you do know, consider where you might want to restrict the application's use. If you feel no need to manage Media Player so closely, well then, how about NetMeeting? Should NetMeeting sessions be run from a server? Any desktop? By anyone? You can easily make locking down Component Services applications a part of a comprehensive security policy strategy. Just make sure it does not become part of a strategy that makes systems unusable.

Limiting Application Privilege with Library Applications

There are two types of COM+ applications: applications and libraries. Libraries are hosted by another process, which means they run under the host security rather than their own user's identity. Their privilege is only that assigned to the host. Library applications may participate in authentication by default, but they can be configured not to use authentication by disabling it. (This is not a good idea.) A COM+ application can be deliberately limited by developing it as a library application. It can only access the resources that its client, the host process, can access. When calls are made outside of the application, or access to resources such as files depends on a security descriptor, they appear to be the client. If you are developing an application that performs sensitive work, and you want to limit its use to only those with permissions to do that work, then make it a library application.

Assigning Users to Roles

Roles are user categories defined within an application by the developer. Like Authorization Manager-enabled applications, COM+ applications may define roles that dictate what a user can do when running the application. The roles enforce an access control policy specific to the application and are built into the application by the developers. Administrators assign Windows users and groups to application roles. An example of COM+ application roles can be viewed in the Component Services console. Open the console and expand My Computer, COM+ Applications, System Application, and then Roles. Expand each role and the Users container underneath it. The results are illustrated in Figure 4-36.

Each role also has a description that explains what the user who is assigned that role can do. For the System application, the roles, descriptions, and user groups are defined in Table 4-4.

An application that uses role-based security checks the role membership of a user every time he uses any part of the application. If he doesn't belong to the role that is authorized to access the resource or make the call, the call fails. You must carefully assign users to the roles that match their real-world roles. Application documentation should clearly state what each role means and what rights and permissions within the application it has. Administrators need to know which users' business needs map to the defined role. A breakdown in communications here can mean that a user who needs to do her job can't do it or that some unauthorized individual might gain access he shouldn't.

Even if you do not want to configure COM+ application security or don't have applications that have built-in roles for you to administer, you should manage roles on the System Application. These roles determine who can install COM+ applications and who can administer COM+ applications and the COM+ application environment. By default, the local Administrators group is a role member. While only members of the Administrators group can administer COM+ security, you may want to restrict administration further. To do so, follow these steps:

Setting Software Restriction Policies for a COM+ Application

A Software Restriction Policy can be set directly in COM+ Application properties on a Windows Server 2003 server. By default, the system-level Software Restriction Policy security level is set the same for all server applications because they all run in the same file, dllhost.exe. If you need to change the policy for specific COM+ applications, you do so by setting Software Restriction Policies directly in the properties of a COM+ application. Software Restriction Policies set here take precedence over system-wide policy settings.

To set COM+ application Software Restriction Policy, do this: