Considerations for improved security in Application Center 2000 (328499)

MORE INFORMATION

General Security Considerations

Read your corporate security policy

To be responsive to security issues, make sure that you have answers to questions like the following:

• How do you respond to a breach of security?
• Where are backup files stored?
• Who do you want to permit access to the server?

Various books and Web sites discuss these topics. For more information, see the "References" section or visit the following SANS Institute Web site:

Subscribe to the Microsoft Security Notification Service

You can stay current with Microsoft security issues and fixes by subscribing to the Microsoft Security Notification Service. To receive automatic notification about security-related issues by e-mail, visit the following TechNet Web site, and then click Register:

Scan your system for updates

The Windows Update Web site can help you to detect the updates that are required on your system. To scan your system for updates, visit the Windows Update Web site, and then click Scan for updates: back to the top

Microsoft Windows 2000 Security Considerations

The Hisecweb.inf security template

This template has been designed to help you secure Microsoft Internet Information Services (IIS) at the operating system level. The template configures basic Windows 2000 system wide policy.

Text-based security templates

Windows 2000 includes text-based security template files that you can use to apply uniform security settings on computers in an enterprise.

Caution The current versions of the Hisecweb.inf template and the Basicsv.inf template may cause Application Center 2000 to stop responding. For additional information about text-based security templates, click the following article number to view the article in the Microsoft Knowledge Base:

Configure an Internet Protocol security policy

Microsoft recommends that you consider setting an Internet Protocol security (IPSec) packet-filtering policy on every Web server. This policy can help provide an extra layer of security if your firewalls are breached. Multiple levels of security technology are typically considered to be a good practice.

Generally, the best practice is to block all TCP/IP protocols except the protocols that you explicitly want to support, and to block all the ports except the ones that you must have open. You can use the IPSec administration tool or the IPSecPol command line tool to deploy IPSec policy.
For additional information about IPSec, click the following article number to view the article in the Microsoft Knowledge Base:
back to the top

Application Center and Microsoft Internet Information Services (IIS) 5.0 security considerations

Important user accounts

After you install IIS and Application Center, the following new local accounts are created on your server:

• IUSR_ComputerName
• IUSR_ClusterController
• ACA_ComputerName User
• ACL_ComputerName User
• SYSTEM

Additionally, the ACC_ComputerName account is created during cluster creation.

These accounts are described in more detail in the following points.

• IUSR_ComputerName
  By default, the IUSR_ComputerName is a member of the Guests group, and it is used for anonymous requests. You can help to secure the IUSR_account by using the IIS Lockdown tool. This tool applies NTFS file system permissions for the Guests group.
  
  Note If you use the Guests group in access control lists (ACLs), permissions are created that cannot be correctly replicated by using Application Center 2000 NTFS permission replication. If you decide to use the IIS Lockdown tool, turn off Application Center 2000 NTFS permissions replication. For more information, see the "Security During Synchronization" section later in this article. For additional information about how to determine the current security context of this account and about how to secure it, click the following article number to view the article in the Microsoft Knowledge Base:

  323640 How to secure the IUSER_<ComputerName> account

• IUSR_ClusterController
  This account is created on each server that is added to the cluster. The name of this account is IUSR_ClusterController (where ClusterController is the computer name of the cluster controller).
  
  By default, this account is the anonymous user account on the cluster controller. Application Center replicates this metabase setting to all servers in the cluster; therefore, each cluster member must have this same named account to handle anonymous connections. For additional information about how to set up this kind of account in the clustered environment (and thereby avoid issues with permission replication for anonymous accounts), click the following article number to view the article in the Microsoft Knowledge Base:

  318932 Cannot use the local IUSR account for content permissions

• ACA_ComputerName User
  This group is given access to the ACLog database in the Microsoft Application Center (MSAC) Microsoft Data Engine (MSDE) instance on each cluster member that has MSDE installed for logging purposes. This group is also granted permissions to launch and access all internal Application Center COM interfaces.
  
• ACL_ComputerName User
  This user is a member of the ACA_ComputerName group. This account is the identity for the following Microsoft COM+ applications that are installed by and used by Application Center:
  • AC Event Provider
  • AC Log Consumer
  • AC Load Balancer
  • AC Perflog Consumer: This application uses Microsoft SQL Server Integrated Security to connect to the MSAC MSDE instance. This account must be in the ACA_ComputerName group.
  
  
• SYSTEM
  Application Center 2000 requires that the SYSTEM account have Full Control permissions to the whole file system. This account is used to apply the changes that occur during the replication process or during the deployment process.

The following account is created during cluster creation, where ComputerName is that of the original cluster controller: When computers are added to the cluster, a duplicate account is created on the newly added members. This user is a member of the ACA_ComputerName group. This account is used to manage cluster communication for authentication across members, to replicate content, and to administer cluster members.

Credentials that you must have to run Application Center

You must have the following credentials to use Application Center 2000:

• Administrator account (local or domain): to start the Application Center user interface and to manage a cluster. If the account is local, you must have the same password for both servers.
• Three sets of administrative credentials:
  • Credentials for the source server.
  • Credentials for all the targets.
  • Credentials for the server that is running either Application Center 2000 or the Application Center 2000 MMC. These credentials can be used with the Deployment Wizard to deploy from cluster to cluster.
• Administrative credentials on the target server: to add or remove a cluster member.

Credentials that are used on the target computers during a deployment must have Full Control permissions to the $ACSRPL$ directories at the root of each hard disk drive.

back to the top

Security during synchronization

Both the SYSTEM account and the Administrator account must have Full Control permissions to the $ACSRPL$ directories at the root of each hard disk drive to successfully synchronize with Application Center. The $ACSRPL$ directory is located on the root of the drive and does not appear until the server becomes a synchronization target.

Synchronization across boundaries

Application Center tries to synchronize ACLs across boundaries between local servers, workgroups, domains, trees, and forests.

ACLs that are synchronized on servers that are in the same domain, in the same tree, or in the same forest work correctly after synchronization; their security identities (SIDs) are still relevant because they are still in the same forest. However, ACLs that are synchronized across forest boundaries do not work correctly.

SIDs are relevant only to the original, source forest. ACLs that are created on workgroup servers refer to the local servers and, except for well-known SIDs (for example, administrator), are not valid on any other server.

You must manually correct any ACLS that are not correct on the targets .

Alternatively, you can decide not to replicate ACLs. In this case, the ACLs are inherited from the directories that are on the target. Then you can set the ACLs with whatever local user accounts are valid at the directory level. When you do so, the files inherit ACLs from the parent directory.

ACL changes are not synchronized

If you change the ACLs on a file, the changes are not automatically synchronized by Application Center unless the file has changed in some way (for example, the content of the file was altered or one of the file attributes has changed).

Windows 2000 user accounts are not synchronized

Application Center does not synchronize or deploy Windows 2000 user accounts. To have these accounts replicated to your member servers, you must use another method. Microsoft recommends that you create a Windows 2000 domain to share and use Microsoft Windows NT accounts across multiple members.

Synchronizing to and from FAT and NTFS file systems

FAT file systems do not support ACLs. If you synchronize or deploy from a member that has a FAT file system to a server that has an NTFS file system, the files that are delivered to the NTFS file system inherit the ACLs from their new parent directories.

Transfer protocols

Application Center synchronization occurs on the management-traffic adapter and uses three transfer protocols:

• DCOM: for intra-cluster synchronization control information.
• HTTP: to synchronize files, including COM+ components, both intra-cluster and inter-cluster.
• RPC: for inter-cluster synchronization control information - for example, from a staging cluster to a production cluster.

Caution Although Distributed COM (DCOM) and remote procedure call (RPC) communication is made more secure by using the same encryption mechanism (RPC packet privacy) that Microsoft Windows 2000 Server uses, HTTP file transfer is not encrypted. Therefore, do not store passwords in files (for example, in ODBC connection strings in Active Server Pages [ASP]). If sensitive information is being transported, and if security is an issue, encrypt these files before you send them, and then decrypt these files after synchronization.

Additionally, you can use IPSec Policy to provide effective encryption of HTTP traffic.

Permissions and account considerations

DCOM permissions that you must have to run Application Center

By starting the DCOM configuration tool (Dcomcnfg.exe) from a command prompt, you can check default security permissions.

Default access permissions	Default launch permissions
INTERACTIVE Allow Launch	INTERACTIVE Allow Launch
SYSTEM Allow Launch	SYSTEM Allow Launch
	ADMINISTRATOR Allow Launch
	IUSR_ComputerName Allow Launch
	IWAM_ComputerName Allow Launch

Local Security Settings for the IIS and Application Center Accounts

Access this computer from network	Log on as a batch job	Log on locally
IUSR_ComputerName	IUSR_ComputerName	IUSR_ComputerName
IWAM_ComputerName	IWAM_ComputerName	ACC_ComputerName
See Note	ACL_ComputerName

Note When you set up the ACL_ComputerName account during the installation of Application Center 2000, you must select the Access this computer from network check box. For additional information about assigning user rights and credentials, click the following article number to view the article in the Microsoft Knowledge Base: However, because the account is created during installation, you must grant the Access this computer from network option to a group that will contain newly created local accounts during Application Center 2000 installation. Granting this option to the Authorized Users group during Application Center 2000 installation is sufficient. You can remove this option from the group after Application Center 2000 is installed.

Windows Management Instrumentation (WMI) namespace permissions

This section discusses Application Center, Windows Management Instrumentation (WMI), Microsoft Health Monitor 2.1, and security.

Any authenticated user can read the Application Center and the Health Monitor namespaces. However, only an administrator or the cluster user group account (identified by ACA_ComputerName) can write to the Application Center and the Health Monitor namespaces (that is, create an instance of existing classes or of new classes). Therefore, both the Administrator and the ACA_ComputerName group must have Full Control permissions on the following WMI namespaces:

• root\Cimv2
• root\Cimv2\MicrosoftHealthMonitor
• root\Cimv2\MicrosoftHealthMonitor\PerfMon
• root\MicrosoftNLB
• root\MicrosoftApplicationCenter

Component Object Model (COM) components that are not required

Because some COM components are not required for most applications, Microsoft recommends that they be disabled if you know that no other programs require any of the COM components.

Important Some programs may require the component that you want to disable. Contact the vendor of any third-party applications to determine the requirements of a component before you disable the component.

For example, consider disabling the File System Object component. However, be aware that disabling the File System Object component also removes the Dictionary object, and Site Server 3.0 requires the File System Object.

If you want to disable the File System Object, run the following command at a command prompt:

Firewall considerations

This section describes two architectural topologies for firewall usage in the Application Center cluster environment.

Scenario 1 A staging server is separated from the production environment by means of a firewall.

For a graphical representation of this topology, see the Application Center 2000 Resource Kit at the following Microsoft Web site: For deployment to succeed, the firewall must have the following two ports open:

• Port 4244: Provides access for content and replication control information by using RPC.
• Port 4243: Provides access for file deployment by using HTTP.

By default, Application Center uses these ports. These ports must allow communication from the source (stager) to the target cluster controller (production). You can reconfigure these ports the way that you want. You may have to open additional ports if you require name resolution traffic flow.

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
To change the ports that the Application Center 2000 Replication Service binds to, use Registry Editor to add the following registry keys: When the registry key value is created, it uses the hexadecimal number system. Make sure that you change the number format to decimal format before you assign a port value; otherwise, you receive unexpected results.

Note Make sure that you assign a unique value to each of the two keys that corresponds to ports that are not used by another application.

Scenario 2 The staging server and the production environment are separated from the Internet by means of a firewall.

To permit traffic through the firewall, you must open certain ports under the firewall configuration settings. The front-end firewall is the first point of protection for Internet sites. Therefore, the firewall should block all ports except Web port 80 and Secure Sockets Layer (SSL) port 443.

Network adapter cards and security considerations

Cluster members can be configured with two network adapters:

• A load-balanced (front-end) adapter communicates with clients.
• The management-traffic (back-end) adapter manages administrative communication in a cluster between members.

Microsoft recommends this dual interface architecture for security reasons because no back-end administrative data can be transmitted across the Internet.

Whenever Network Load Balancing is used, two network adapters are required. If the cluster does not use load balancing, only one network adapter is required. (However, a second network adapter will be used if it is available.)

Note Having a single network adapter introduces the risk of inappropriate data usage because all network traffic is routed through the same network adapter. This is especially significant if the cluster is serving content that is bound for the Internet. Consider this issue when you make decisions about cluster architecture.

back to the top