Enterprise Services

This section identifies the key review points that should be considered when you review your Enterprise Services applications and components . For more information about the issues raised in this section, see Chapter 17, "Securing Your Application Server."

When you review Enterprise Services applications consider the following issues:

• Accounts

• Files and directories

• Authentication

• Authorization

• Remote serviced component

Accounts

If you use an Enterprise Services server application, check which account you use to run the application. This is displayed on the Identity page of the application's Properties dialog box in Component Services. Review the following questions:

• Do you use a least privileged account?

  Check the account that you use to run your Enterprise Services server applications to ensure they are configured as least privileged accounts with restricted user rights and access rights. If you use the process account to access a downstream database, make sure that the database login is restricted in the database.

• Do you use the Interactive account?

  Do not use the Interactive account on production servers. This is only intended to be used during development and testing.

Files and Directories

Review the following questions to ensure that you are using NTFS permissions appropriately to secure the various files associated with an Enterprise Services application:

• Is the COM+ catalog secured?

  The COM+ catalog maintains configuration data for COM+ applications. Make sure that the following folder that maintains the catalog files is configured with a restricted ACL.

   %windir%\registration 

  Configure the following ACL:

   Administrators: Read, Write System: Read, Write Enterprise Services Run-As Account(s): Read 

• Are the CRM log files secured?

  If your application uses the Compensating Resource Manager, the CRM log files (.crmlog) should be secured with NTFS permissions because the log files may contain sensitive application data.

• Are your application DLLs secured?

  Make sure that the folder used to hold the DLLs of your application is configured with the following restricted ACL.

   Users: Execute Application Run as account: Execute Administrators: Read, Write and Execute 

For more information, see Chapter 17, "Securing Your Application Server."

Authentication

Serviced components can be hosted in a library application that runs in the client's process address space or in a server application that runs in a separate instance of Dllhost.exe. This is determined by the activation type specified on the Activation page of the application's Properties dialog box in Component Services. The client process for an Enterprise Services library application is usually the ASP.NET Web application process.

The settings discussed below are specified on the Security page of the application's Properties dialog box in Component Services.

Server Applications

If the Activation type is set to Server application, review the following questions:

• Do you prevent anonymous access?

  Check that your application uses at least call level authentication to ensure that clients are authenticated each time they make a method call. This prevents anonymous access.

• What impersonation level do you use?

  Check to make sure that you use at least identify level impersonation to allow downstream systems to identify your serviced component. By default, this is the process identity determined by the run-as account of the application. If your serviced components use programmatic impersonation, this may be an impersonated identity. Use delegate level only if you want the downstream system to be able to access remote resources using your serviced component's identity.

Library Applications

If the activation type is set to Library application, the authentication and impersonation settings are inherited from the host process. The review questions in this section assume the ASP.NET process is the host process.

• Have you disabled authentication?

  To check, view the Enable authentication check box setting on the Security page of the application's Properties dialog box. You should not disable authentication unless you have a specific requirement such as handling unauthenticated callbacks from a remote serviced component.

• What authentication level do you use?

  The authentication level specified on the <processModel> element in Machine.config governs the authentication level used for outgoing calls to remote serviced components or DCOM components. The higher of this value and the value configured at the remote server is used. Check the comAuthenticationLevel setting on the <processModel> element:

• What impersonation level do you use?

  This affects outgoing calls from the library component to other remote components. Check the comImpersonationLevel attribute on the <processModel> element in Machine.config.

   <processModel comImpersonationLevel=               "DefaultAnonymousIdentifyImpersonateDelegate" .../> 

Authorization

Serviced components in Enterprise Services applications use COM+ role based security to authorize callers . Review the following issues to ensure appropriate authorization:

• Are access checks enabled?

  This controls whether or not COM+ authorization is enabled or not. Check that Enforce access checks for this application is selected on the Security page of the application's Properties dialog box in Component Services.

• What security level do you use?

  Check the Security level specified on the Security page of the application's Properties dialog box in Component Services. Applications should use process and component level access checks to support granular authorization. This allows the application to use roles to control access to specific classes, interfaces, and methods .

  Note  

  Process and component level access checks must be enabled for library applications or you will not be able to use role-based authorization.

• Do you enforce component level access checks?

  To support authorization checks at the component, interface, and method levels, each component must be appropriately configured in the COM+ catalog. Check each component in your application to ensure that Enforce component level access checks is selected on the Security page of the component's Properties dialog box.

Remote Serviced Components

The following issues apply if you use remote serviced components, and communication is across a network. A typical scenario is an ASP.NET client communicating with an Enterprise Services application on a remote application server.

• Do you pass sensitive data?

  If so, what mechanism is in place to address the network eavesdropping threat? Make sure the link between client and server is encrypted at the transport level, for example, by IPSec. Alternatively, make sure your Enterprise Services application is configured for Packet Privacy level authentication, which forces the use of RPC encryption for all data packets sent to and from the application.

• Do you communicate through a firewall?

  Enterprise Services uses DCOM, which in turn uses RPC communication. RPC communication requires port 135 to be open on the firewall. Review your firewall and Enterprise Services configuration to ensure that only the minimal additional ports is open .

  The range of ports dynamically allocated by DCOM can be restricted or static endpoint mapping can be used to specify individual ports. For more information, see Chapter 17, "Securing Your Application Server."