Site Server - Building a More Secure Site Server - Data Center

April 1999 

The Purpose of this Document

Securing a Microsoft® Site Server data center (a Site Server installation designed to store information for access by multiple users in multiple locations) is a complex process. This document provides guidelines that, if followed carefully, will help to increase the security of a Site Server data center. The nature of the Internet community makes constant vigilance necessary in order to maintain appropriate security. Note that it may be necessary to augment these guidelines with other measures to assure security at a level appropriate for your site. See the section in this document titled "Additional Disclaimer."

Executive Summary

In order to secure a Site Server data center, the platform software (Microsoft® Windows NT® Server and Microsoft® SQL Server™) must be secured. The application software has to be secured at the level of individual files and directories.

Policies must be in place that authenticate incoming users and govern which users have access to which resources. The user information employed for authentication, authorization, and personalization must be protected to maintain the integrity of the security policy and the privacy of the users. Finally, each type of service or application has its own special security requirements and vulnerabilities.

This document addresses the issues that you must consider when setting up a secure Site Server data center. In many cases, this document will direct you to other resources that provide detailed information about individual security issues.

Background: Security in a Site Server Data Center

A Microsoft® Site Server data center contains all of the hardware, network, and application software needed to make the Site Server site functional. Site Server 3.0 contains a wealth of configuration options that allow the creation of a variety of types and sizes of Site Server data centers. By default, Site Server provides the baseline for a secure Site Server data center, but does not define a comprehensive policy for all types of security attacks that may occur. Building a secure Site Server data center requires that the Commercial Service Provider (CSP) defines, and then implements, a set of security policies for the Site Server components, Microsoft® Windows NT® and Microsoft® Internet Information Server (IIS), and other computers in the data center. Security, along with capacity and robustness, should be considered during the design of the Site Server 3.0 implementation. After the data center goes live, service operators should monitor their services for both attacks and the real-world impact of security policies on their services.

An attack on a system is any unwanted access to system resources, such as the disk storage or processor, as well as unwanted access to or modification of data. This includes both illegitimate access to computers running in the data center, and unauthorized access by individuals who might have legitimate access to resources in a different context. Users who may have legitimate access to different parts of the system include anonymous users visiting a Web site, paying customers, and the staff at the CSP. An attack may be passive or active.

• An active attack occurs when someone deliberately attempts to break into the system. An example of such an attack is the solitary hacker who breaks into a Web site and replaces the content with a manifesto demanding freedom for a hacker colleague.

• A passive attack is a loss of security arising from an action that was not intended to breach the system's security. For example, a passive security breach occurs when an entry-level technician, performing maintenance on a database, glances at unencrypted end-user personal data and passwords. 

You can combine several tools to secure your system:

• User Authentication. Identify users or clients before allowing any access to the system, based on information stored in the Membership Directory. You can allow anonymous access to all, part, or none of your system. 

• Membership Directory Access Control Lists (ACLs). Identify the rights of specific users or groups of users regarding containers or objects in the Membership Directory. 

• Windows NT ACLs. These include both normal resource ACLs and file sharing ACLs. 

• Secure Communications. You can use Secure Sockets Layer (SSL)/Transport Layer Security (TLS) communication and certificates to secure most communication between the Application servers and the Lightweight Directory Access Protocol (LDAP) servers. This approach is particularly important if the LDAP servers and/or their TCP ports are accessible from the Internet. 

• Virtual Directory permissions, blocklisting, and other service-specific security methods. Each of the services available for Site Server has special security features. 

To provide a more secure Site Server data center 

1. Windows NT Server must first be secured. Windows NT security is well documented. Most security breaches are due to failures in the implementation of security policies.

2. Computers running Microsoft® SQL Server™ must be secured. SQL Server security is also well documented. This document will focus on the specific requirements for using SQL Server with Site Server services in a secure environment. 

3. The Membership Directory, its access controls, and key Membership Directory administrative accounts are the next stage in defining and implementing a Site Server security policy.

4. After securing the Membership Directory, applications like Web and its supporting Internet Information Server features must be secured.

5. After the data center is built, operators must monitor servers and applications for security breaches, as they would monitor the data center's health.

The remainder of this document describes in detail areas to consider when defining a security policy to protect against both active and passive attacks by legitimate and illegitimate users.

For more information about these and other important security issues, see the "Site Server Security" section in the Site Server 3.0 documentation, and the Security topic in the "Personalization & Membership (P&M)" section of the Site Server 3.0 documentation.

This section assumes that you have an understanding of Microsoft® Windows NT® security and Internet Information Server security (see "Security" in Internet Information Server, Server Administration, which is part of the Windows NT 4.0 Option Pack documentation).

Consult the following source materials for security information concerning platform products:

• For security information concerning Microsoft products, go to https://www.microsoft.com/security/, and then choose among the white papers and product information listed in the contents pane.

  Under White Papers:

  • Click Security: An Overview to view Microsoft Product Security: An Overview. 

  • Click Securing Windows NT to view Securing Windows NT Installation. 

  Under Information by Product: 

  • Click Windows NT to view "Windows NT Security Information." 

  • Click Internet Information Server to view "Internet Information Server Security Information." 

  • Click Visual InterDev to view "Microsoft Visual InterDev Security Information,"specific to Microsoft® Visual InterDev™. 

• Additional security information concerning Windows NT is available in the Windows NT online Help and the Windows NT Resource Kit.

• For additional information about IIS security, see "Security" under Server Administration in the "Internet Information Server" section of the Windows NT 4.0 Option Pack documentation. 

• Active Server Pages (ASPs) are an important IIS facility for Web functions. To view the white paper Implementing A Secure Site with ASP, go to https://www.microsoft.com/isn/techcenter/security.htm . 

• For information about SQL Server security, consult the SQL Server documentation. 

Security Concepts

The concepts described below are important throughout this document.

Authentication

Authentication refers to the process of verifying a user's claimed identity, usually by some form of password checking. The "Authenticating Users" section later in this document discusses the authentication options available with Microsoft® Site Server.

Access Control and Permissions

Permissions define what access rights an authenticated user has to specific files, directories, or other resources.

Access control entails determining the users and groups who can gain access to a given object, and what actions they can perform. An access control list (ACL) associated with the object, directory, or file contains entries that indicate the group or user who has access, and the type and scope of the access.

Access control can be applied to:

• Membership Directory objects and their attributes. The Membership Directory always enforces any access controls applied to its objects. You can use Membership Directory accounts or groups in the ACLs of Membership Directory objects. 

• Windows NT applications, directories, and files. Windows NT Server always enforces any access controls applied to its directories and files. The Microsoft® Site Server Authentication Service provides Windows NT group names for you to use in Windows NT ACLs in order to grant permissions to users with only Membership Directory accounts.

For a detailed discussion of security, see the topic Site Server Security in the Site Server 3.0 documentation.

For information about using Membership Directory ACLs and Windows NT ACLs, see the following topics in the "P&M" section of the Site Server 3.0 documentation:

• Managing Access Control 

• Membership Concepts 

Term List

Security-Specific Terms	Meaning
User	An individual user connected to a service.
Concurrent Users	Users active on the system at a particular time; a subset of total users calculated based on user profile.
User	A person who has information stored in the Membership Directory.
Attributes	Specific information associated with a file or an object.
Site Server Authentication Service	Software component that uses information in the Membership Directory to authenticate users that attempt to access Site Server services.
Membership Directory	Repository for all user information, including passwords.

Securing Hardware and the Network Infrastructure

As with most data centers or other large networks for storing sensitive information, security for a Site Server data center begins at the infrastructure. Most companies have policies for securing equipment that handles sensitive information. This chapter highlights considerations that are particularly important to Site Server data centers.

Physical Security Measures

It is a well-established practice in corporate information systems departments to maintain server computers in a secure area that is not accessible to unauthorized personnel.

An individual with physical access to a server computer can disrupt service by turning off hardware or software or changing settings. They can damage or steal data, and can install unauthorized software. To some degree, these risks are mitigated by the use of administrative accounts and passwords, but not all system elements are protected by these precautions.

To protect server computers from physical access by unauthorized users 

• Maintain server computers in a secure area, with access limited to the smallest number of people that is practical.

Protecting Backup Data 

Regular data backups are critical to assuring the integrity of a Site Server installation. For information about backup procedures, see Backing Up Critical Data in the "P&M" section of the Site Server 3.0 documentation.

If your archives of backup media are inadequately secured, passwords and other valuable data can be stolen from backup copies. It may also be possible for an intruder to substitute an altered version of a backup file and cause the system to be restored from the altered data, in order to create unauthorized user accounts, change user attributes, or otherwise disrupt service.

To protect your backup data 

• Maintain strict physical control of backup media. 

• Strictly limit the number of people authorized to perform backup or restore operations. 

Firewalls/Network Security

Servers may be secured against intruders through the use of firewalls. Companies connected to the Internet typically use firewalls to protect their private networks. Large organizations configured with subnetworks may also use firewalls to control access to confidential or other sensitive information on their intranet. Firewalls provide network security by allowing only certain authorized activities to be accomplished between internal networks and the Internet.

Because they are designed to exclude entire sets of users from entire servers, firewalls are more useful in some circumstances than in others. For example, because the range of Internet Protocol (IP) addresses to include or disallow is specified on a per-HTTP-server basis, there is no way to employ a firewall to restrict access to a subset of HTML documents on a single server. Similarly, Web applications that require user logon passwords must rely on a mechanism other than the firewall. Many users have IP addresses that are dynamically assigned, either by their ISP or a private network with Dynamic Host Configuration Protocol (DHCP), so it is not feasible to admit or exclude users on the basis of a single IP address.

Note For information about using firewalls with dial-in access servers, see Dial-in Access (ICS/RAS) later in this document.

To use firewalls to protect against unauthorized users 

• Install Site Server 3.0, Commerce Edition behind a firewall. For more information, see the "Managing Security in Commerce and Ad Server Sites" section in the Site Server, Commerce Edition documentation. 

• Locate the LDAP Service behind a firewall that prevents public access. For more information, see Protecting Sensitive Data Communications in the "Site Server Security" section of the Site Server 3.0 documentation. 

To protect against unauthorized NetBIOS users 

• Unbind all NetBIOS traffic from the network interface and services exposed to the Internet. Removing the NetBIOS traffic from an Internet-exposed LAN will help stop hacker attacks. 

DNS

A full discussion of Domain Name System (DNS) setup and architecture is beyond the scope of this paper. For information about configuring DNS for large networks, see the white paper DNS and Microsoft Windows NT Server 4.0, which is available at https://www.microsoft.com .

When planning your use of DNS, consider the following:

• If you use Microsoft Windows Internet Naming Service (WINS) for its DNS dynamic update feature, remember that non-Microsoft-based hosts cannot register in WINS and that WINS registration is not secure. 

• If you maintain computers such as Web servers outside a firewall so that they can be publicly accessed over the Internet, you will need to place separate DNS server computers inside and outside of the firewall. DNS for the external and internal networks should be isolated from one another to prevent external clients from obtaining the names and addresses for internal resources. 

• You can use DNS reverse lookup to enhance security by confirming the identity of each incoming client. However, if you are using Microsoft WINS and Microsoft DNS, reverse lookup may not always function in an efficient manner. 

Securing Windows NT Server

Security issues for Microsoft® Windows NT® Server have been described in detail in a number of white papers (some of which are listed in the table below). This document will address the aspects of Windows NT Server security features that are especially important to a Microsoft® Site Server installation.

Important Windows NT hot fix updates are released periodically for Windows NT between Service Pack releases. Some hot fixes are security-related and can protect your site against newly-discovered types of attack. Be sure to stay current and install hot fixes as they become available.

For information about Windows NT Security, see the Microsoft Windows NT Server Resource Kit available from Microsoft Press.

Pointers to Windows NT security papers 

Security Event Descriptions	https://support.microsoft.com/default.aspx?scid=kb;en-us;174074&sd=tech  The information in this article applies to: · Microsoft Windows NT Workstation versions 3.5, 3.51, and 4.0 · Microsoft Windows NT Server versions 3.5, 3.51, and 4.0
Standard Security Practices for Windows NT	https://support.microsoft.com/default.aspx?scid=kb;en-us;166992&sd=tech  The information in this article applies to: · Microsoft Windows NT 3.1 · Microsoft Windows NT Advanced Server 3.1 · Microsoft Windows NT Workstation 3.5, 3.51, and 4.0 · Microsoft Windows NT Server 3.5, 3.51, and 4.0

Administrative Accounts

Consider the administration model for your installation early in the planning process. For example, who will monitor and maintain which computers? In very large installations, there are often multiple administrators, often with varying levels of rights to make administrative changes.

In conjunction with your administration model, you must create a security model for your installation that maps out who has the rights to perform what functions, both at the computer level and at the Membership Directory container level. For information about administration in the Membership Directory, see "Securing User Information" later in this document.

Use the Windows NT User Manager for Domains to create, delete, or modify Windows NT administrative accounts and groups.

Note If you are using the Microsoft® Site Server Membership Directory to authenticate users, you will need to use the Membership Directory Manager (MDM) tool to administer certain administrative accounts and groups. In particular, groups for administering many of the Site Server services are created and maintained in the Membership Directory and automatically propagated to Windows NT. For information about using the Membership Directory Manager, see Using Membership Directory Manager from MMC in the "P&M" section of the Site Server 3.0 documentation.

To increase the security of all Windows NT accounts 

• Manage strict account policies. For maximum security, do not define multiple accounts with the same name on a domain.

• Choose difficult passwords. Make sure that passwords are not easy to guess. For example, do not create passwords that use your own name or other information that is readily available to others.

  Important When setting up management accounts, you must define a unique password for each account. If you do not, it may be possible for a user to log on remotely using the management account even if the user's account does not have privileges on the remote computer but does have privileges on the local computer and the logon password matches. Requiring a separate password on every management account reduces the possibility of unauthorized access occurring. 

• Limit the membership of the Administrators group. The Administrators group on the local computer is the owner of all files and directories on the computer, including those of all Site Server services.

  Change the default Administrator account. Microsoft® Windows NT® Setup creates a built-in account for administering the local computer. This account is named Administrator. As a precaution against unauthorized access to your server by means of this account, you may want to:

  • Remove the built-in Administrator account, since administrative permissions are associated with the group rather than the account. 

  • Create another, not well-known administrator account and add it to the Administrators group. 

    OR 

  • You can rename the Administrator account. 

• On each computer, check all the local user accounts and remove any that are not required by the Site Server components or local administrators or operators. 

Securing Services and Files

On drives formatted with the Windows NT File System (NTFS), you can assign permissions for individual files or for entire directories. Each file or directory can be assigned its own access control list (ACL). NTFS is recommended for all production Site Server data centers. ACLs can be set only on an NTFS drive. ACLs are part of each resource's properties.

Windows NT checks the permissions for every resource before allowing access.

Important In order for Microsoft® Internet Information Server (IIS) to function correctly, you must give the Everyone security principal access (at least at the read-only level) to directories containing content files. This requirement may change in future releases of IIS.

Note If you deny a group access to a resource, and then grant resource access to a specific member of that group, the denial to the group supersedes the granting of access to the specific user. Denial of access is the default setting, so there is no need to specifically assign this.

Windows NT also provides an auditing service, which you can use to track file access. The audit policy determines the amount and type of security logging that Windows NT performs. Audit policy is set using Windows NT User Manager for Domains.

For information about controlling access to the files and applications used by Site Server, see Managing Access to Content Directories and Files in the "P&M" section of the Site Server 3.0 documentation.

Securing Silent Setup Script Files 

Any server-side include (.ssi) file used by Silent Setup for Site Server may contain, in clear text, one or more account names and passwords used as service accounts for Publishing and for Search. In the case of Search, the account requires Windows NT administrative privileges.

Note On Web servers that support .ssi, the include capabilities are disabled by default. They can be activated by the administrator of the Web server. If they are enabled, the server only parses files with a Multipurpose Internet Mail Extensions (MIME) type of either text/x-server-parsed-html or text/x-server-parsed-html3. Neither of these MIME types exists in most standard MIME types. Therefore, by default, no files are parsed for server-side includes even if .ssi is enabled. If the administrator of the Web server enables .ssi, .ssi can still be configured to turn off #exec includes by modifying the configuration files for the Web server.

If the Feedback Form is altered to create a file with the proper .ssi extension, and if the server is configured to allow executable server-side includes, then the new content can execute arbitrary programs on the server.

To protect account information in Silent Setup files 

• Use ACLs to set restrictions on who can read such files under NTFS, and maintain physical control of any diskettes or file printouts containing them. 

Securing the Setup Log File 

Site Server Setup creates a file called MSS_Setup.log that contains many details about the Site Server installation. By default, this file is created in the C:\Temp directory.

To protect setup information in the Site Server Setup log file 

• Set access control or put this file in a place where only authorized individuals can read it. 

Monitoring File Access Activity

Windows NT provides valuable information about attempts to gain access to Site Server services and files.

Windows NT Security Event Log 

There are a number of audit categories that you can turn on as part of the audit policy of the server to generate Windows NT Security Log events. Windows NT audit policy is defined in the User Manager under the Policies menu.

The most important audit categories include:

• Logon and Logoff. Use this category to monitor who logs on locally to the server computer. (This will not audit users who log on through the Membership Directory.) 

• File and Object Access. Use this category to audit changes to files and directories on the server and look for events such as the introduction of unauthorized scripts or executable programs. Auditing is activated for specific files or directories by setting Auditing on the Security Properties tab in Windows NT Explorer. 

• User and Group Management. Use this category to monitor changes to Windows NT groups, in particular the membership of the Administrator group. (This will not audit changes to groups in the Membership Directory.) 

• Security Policy Changes. Use this category to keep track of changes made to the User Rights, Audit, or Trust Relationships policies. 

Windows NT Application Event Log 

Check for error messages in the Windows NT Application Event Log. A higher-than-expected incidence of messages concerning events such as the following can indicate an attempt to compromise the system:

• Problem with connection 

• Received corrupt data 

• Illegal access attempt intercepted 

• Failed logon attempt 

For message text and details concerning interpretation and recommended actions in response to specific P&M messages, see Windows NT Server Events in the "P&M" section of the Site Server 3.0 documentation.

Setting Share Permissions

Network share permissions provide a second level of access control for a Microsoft® Site Server installation.

To protect shared files from unauthorized access 

• Check network services and permissions on network shares. Verify that permissions are set on network shares to prevent access by unauthorized users. In addition, verify that you are running only the services that you need and unbind any unnecessary services from your Internet adapter cards. 

  Site Server 3.0 creates a NetBIOS share that is shared to the world. This represents a security risk because intruders can gain access to a directory where they can place arbitrary files.

  1. Install Microsoft® Site Server 3.0 Personalization & Membership (P&M) only. This is necessary for any SITE SERVER component that needs to point to the Membership Directory database. 

  2. Open a command prompt and type net share. A list of local shares will be displayed. Notice that a NetBIOS share called TMLBQueue exists.

  3. On this share, everyone has read/write access. This is a definite security breach. This share should exist only on computers using the List Builder Service, which comes with Site Server 3.0.

Securing the Registry

Many areas of the registry are not protected by access control lists (ACLs), potentially allowing individuals with local or remote access to change or disrupt operations, and/or obtain a variety of secret information, including:

• Any account names and passwords used by the Active User Object (AUO) in accessing secondary data stores. 

• The privileged account name and password, if any, used by the AUO to access the Membership Directory. 

Potential Registry Security Hazards

There are several registry keys that must be set appropriately, or the registry will be open to potential security breaches.

Note The winreg key will not be present if Microsoft® Windows NT® 4.0 Service Pack 3 is not installed. For more information, see Microsoft Knowledge Base article 155363.

! STRONG WARNING Using the Registry Editor incorrectly may cause severe and irreparable damage to the registry, and may require you to reinstall your operating system. Use the Registry Editor at your own risk.

To protect the registry 

• Remove the Microsoft® Windows NT® right to log on locally at server computers from all users except administrators. 

• For additional security, restrict remote access to the registry.

• Go to https://www.microsoft.com/security/ to view various articles about Windows NT security. 

The following section describes potential security hazards to the registry and their solutions:

valuename 

The valuename registry key allows .reg files to be associated with Regedit.exe. If improper permissions are set on valuename that specify a command association with registry files, associations can be changed by non-administrators.

• Set permissions on HKEY_LOCAL_MACHINE \Software \Classes \regfile
  shell\open\command key valuename to disallow write access for non-administrators. 

Schedule 

The HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Schedule key controls the schedule service. Server Operators have permission to write to this registry tree, allowing them to manually schedule jobs to be run by the schedule service, which normally executes under the system user context. If the scheduler key has incorrect permissions, an intruder who has penetrated local security can raise the Server Operator's access level to Administrator. From there they can gain access to another computer, or possibly even create a domain account.

1. From the Start menu on the local computer, click Run.

2. Type regedt32, and then click OK. This opens the Registry Editor.

3. Through the Security menu, remove write access to the Schedule key for Server Operators. 

null session 

If shares are enumerated through a null session, an intruder could engage in password guessing attacks and lock out all users in that domain or host.

1. From the Start menu, click Run. Type regedt32,and then click OK. This opens the Registry Editor.

2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
   Control\LSA. 

3. On the Edit menu, click Add Value and use the following entries:

   Value Name: RestrictAnonymous
   Data Type: REG_DWORD
   Value: 1 

4. Restart the system to apply the changes. 

winlogon 

If the winlogon key has incorrect permissions, it could be used to change a user's rights or access level.

The HKEY_LOCAL_MACHINE \Software \Microsoft \Windows NT\CurrentVersion\winlogon key has two values that can be used to cause a process to execute, either upon system startup or when a user logs on:

• The programs pointed to by the System value run under the system user context after startup, and could be used to change a user's rights or access level.

• The UserInit value runs applications when a user logs on. The default settings for this key allow Server Operators to write these values, either of which could be used to raise a System Operator's access level to Administrator.

Through the Security menu, remove write access to the winlogon key for Server Operators.

CurrentVersion, Run, RunOnce, RunOnceEx, App Paths, and Uninstall keys 

The default permissions on the HKEY_LOCAL_MACHINE \SOFTWARE Microsoft\Windows\CurrentVersion key allow members of non-Administrator groups special access, including the right to set values or modify subkeys. These permissions give members of non-Administrator groups the ability to add a value to the Run, RunOnce, and RunOnceEx keys that contain the name of a program to run when the computer starts.

The permissions also give group members the ability to create subkeys under the App Paths and Uninstall keys. The App Paths key contains entries specifying the location of registered programs and their search paths for DLLs. The Uninstall key contains the name of a program to run when uninstalling the software.

To prevent abuse of these rights, replace special access with read access for non-Administrator groups.

Note Removing the ability for members of non-Administrator groups to create subkeys and to set values may cause a software installation to fail if installed by a user account without Administrator privileges. Applications that execute a program during the uninstall process must be able to create a key under the HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall key. The same adjustments applied to the Run, RunOnce, RunOnceEx, and App Paths keys may also impair the ability of some users to install software on the host.

Note The Uninstall key contains subkeys for each application. These subkeys contain the name of an executable to uninstall the application. Changes to non-Administrator group permissions must be propagated to all subkeys under HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. Changes to non-Administrator group permissions for HKEY_LOCAL_ MACHINE\ SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths keys must also be propagated to all subkeys.

To change the default access permissions

1. Open the Registry Editor (regedt32.exe).

2. Go to HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows
   CurrentVersion\. 

3. Locate and select the Run key.

4. From the Security menu, select Permissions. 

5. Select one of the non-Administrator groups, such as Everyone, Power Users, Users group, users not assigned to groups, or custom groups. Do not select Administrators, Creator Owner, System, or Domain Administrator. 

6. Click Replace Permission on Existing Subkeys.

7. In the Type of Access field, select Read.

8. Repeat steps 5 through 7 for the remaining non-Administrator groups, and then click OK.

9. Repeat steps 3 to 8 for the RunOnce, RunOnceEx, App Paths, and Uninstall keys. 

Considerations for Multiple Content Computers

In a secure Site Server installation, many of the Site Server services depend on accounts and group memberships to access secured resources (such as ASP files). A typical Site Server installation may include a number of computers that store such content files. The following topics address specific issues to consider when setting up your content store computers.

IIS Anonymous Account

Microsoft® Internet Information Server (IIS) must be able to provide Web content to anonymous users. It does so by using the IIS anonymous user. During installation, IIS Setup creates an account named IUSR_computername (where computername is the name of the computer where IIS is installed). This is the IIS anonymous account. IIS Setup also generates a random password for this account, and adds the account to the Guests group.

When requesting a resource from Windows NT, IIS uses the IIS anonymous account to impersonate the user, meaning it supplies a user account that represents the user.

Using the anonymous account does not compromise security. Anonymous users have access only to files that have been explicitly shared through IIS. Other files are not visible to them. Even if anonymous users could access other files, they cannot complete the authentication because they do not have access to the password of the IIS anonymous account.

If you have multiple computers storing content (such as Web pages) that must be available to one or more IIS computers, each computer must have a copy of the IIS anonymous account.

To set up the IIS anonymous account for content access 

1. Use User Manager for Domains on the IIS computer to set a new password for the IIS anonymous account. 

2. Use User Manager for Domains on the content computer to recreate the IIS anonymous account. 

   Important The IIS anonymous accounts on the IIS and content computers must have identical user names and identical passwords. 

For information about using User Manager for Domains to modify accounts, see Managing your computer's security with User Manager for Domains in the Windows NT online help.

For information about configuring the IIS anonymous account, see Configuring the Anonymous Access Account in the "Microsoft Internet Information Server" section of the Windows NT 4.0 Option Pack documentation.

To set up a domain-level IIS anonymous account 

1. If needed, use User Manager for Domains on the domain controller to create an IIS anonymous account. 

2. Use the Internet Service Manager Microsoft® Management Console (MMC) snap-in to configure IIS to use the new account. 

For information about using User Manager for Domains to modify accounts, see Managing your computer's security with User Manager for Domains in the Windows NT online help.

For information about configuring the IIS anonymous account, see Configuring the Anonymous Access Account in the "Microsoft Internet Information Server" section of the Windows NT 4.0 Option Pack documentation.

Membership Directory Group Mapping

The Site Server Authentication Service provides Windows NT group names for you to use in Windows NT ACLs in order to grant permissions to users with only Membership Directory accounts. For details about this mechanism, see the P&M Group Mapping to Windows NT Groups topic in the "P&M" section of the Site Server 3.0 documentation.

When you use the Membership Directory to authenticate users (Membership Authentication mode), you avoid creating Windows NT accounts for your users. In order to authorize users to gain access to Windows NT objects (such as newsgroup directories or ASP files) the Authentication Service uses a special Windows NT account called the impersonation account. Once a user has been authenticated, the Authentication Service uses this account to give the user a security context in Windows NT, although the user does not actually have a Windows NT account.

To support the impersonation scheme, the Authentication Service maps the groups that you create in the Membership Directory to groups that it creates on the local Windows NT Server computer. As indicated in the following diagram, an authenticated user will have a Windows NT security context complete with Windows NT group memberships. You can then use these groups in the access control lists (ACLs) of Windows NT objects.

Note A user cannot be a member of more than 994 groups if the option is enabled to map Membership Directory groups directly to Microsoft Windows NT. This is a Microsoft Windows NT 4.0 limitation.

If you do not want to use this group mapping function, you can disable it using the Personalization & Membership (P&M) command-line interface.

Note If you use domain groups, and you have not set up the Authentication Service on the primary domain controller (PDC), you must create the groups manually and then configure the Authentication Service to use domain groups.

For information about group mapping features (including how to disable mapping), see the following topics in the "P&M" section of the Site Server 3.0 documentation:

• Administrative Group Mapping 

• Non-administrative Group Creation and Mapping 

• Mapping Membership Directory Groups to Windows NT Domain Groups 

For information about using Membership Authentication mode with Windows NT ACLs, see the following topics in the "P&M" section of the Site Server 3.0 documentation:

• Managing Access Control 

• Membership Concepts 

• Setting the Windows NT Impersonation Account 

• Authentication Service Configuration Commands 

Considerations for Multiple Communities 

One potential disadvantage of hosting multiple customer communities in a single Membership Directory is that with Windows NT group autocreation turned on (the default), the Authentication Service will automatically create corresponding Windows NT groups for all groups in the Membership Directory (except those in the ou=NTGroups container). If there are many customers, each with many groups, the number of groups can become quite large and create an inconveniently large number of groups on the Application server computers.

To limit the number of groups created on a given Application server computer 

Do one of the following:

• Turn off Windows NT group auto-creation and manually create any groups you need on a particular computer. The primary disadvantage of this approach is that any new groups must also be created manually, requiring maintenance effort whenever groups are added. This option is probably not practical for Site Server installations. 

  Use access control lists (ACLs) on the groups in the Membership Directory. The Authentication Service will auto-create Windows NT groups only if the corresponding group in the Membership Directory is visible to the Authentication Service account. If groups are created within specific containers in the ou=Groups container in the Membership Directory, you can:

  • Set ACLs on each customer's container so that only the Authentication Service accounts (and Membership Directory administrator accounts) for that customer to have permission to read this container. 

    Note The ACLs must be set on the group containers, not just on the group objects themselves. 

  • Remove the SUPERBROKER value from the ds-privileges attribute of the Authentication Service accounts whose functions must be limited. 

    Note Removing the SUPERBROKER value removes the ACL-bypassing privilege from the Authentication Service accounts. These accounts must then be in the cn=GRPBRKR directoryname group in the Membership Directory in order to have the necessary permissions to authenticate users. 

    For more information about the SUPERBROKER value, see Disabling the Bypass-ACL-Checking Privilege in the Site Server documentation. 

PDC/BDC Considerations

If IIS is installed as a stand-alone server, the IIS anonymous account exists only in the local computer's account database. If IIS is installed on a primary or a backup domain controller, the IIS anonymous account is in the domain directory services database of user accounts, and you can log on remotely from any computer in the domain.

Site Server P&M is designed primarily for installation on Windows NT Server stand-alone servers. However, you can install P&M on a primary domain controller (PDC). If you do, then the groups created by Authentication Service group mapping will be domain groups.

A Membership Server instance using Windows NT Authentication can be created on a backup domain controller (BDC) in the same way as on a stand-alone server or primary domain controller (PDC). However, a Membership Server instance using Membership Authentication on a BDC is not a recommended configuration and requires additional manual steps that would occur automatically on a stand-alone server.

When using Site Server P&M on a BDC with Membership Authentication, certain Site Server groups and accounts must be created as domain groups and accounts. These include:

• Windows NT Impersonation Accounts. A Windows NT impersonation account must be created for each new Membership Server instance that you create using Membership Authentication Mode, and the same user name and password must be set in the Site Server Authentication Service configuration of that Membership Server. 

• Windows NT Groups for Membership Authentication Group Mapping. The Authentication Service cannot automatically create Windows NT domain groups for mapping of Membership Directory groups. Either the domain groups must be created and maintained manually, or a Personalization & Membership Server instance with the Authentication Service must be installed on the PDC to enable automatic creation of groups. 

For information about working with P&M on a BDC, see the following topics in the "P&M" section of the Site Server 3.0 documentation:

• Important Group and Account Issues for BDC Installations 

• Creating a New Membership Authentication Instance on a BDC 

• Creating Windows NT Groups in Membership Authentication Mode 

Securing SQL Server

Microsoft® SQL Server™ offers a wide range of configurable access rights, including rights to create databases, perform updates to existing databases, add stored procedures, and manage user accounts. In addition to an internal security framework, SQL Server may be configured to use Windows NT authentication processes for its own connections. A complete discussion of SQL Server security features is outside the scope of this paper. See Part 4, "Security," in the Microsoft SQL Server Administrator's Companion for more information.

Deploying SQL Server to Work with Site Server

Microsoft® SQL Server™ offers three types of login security: standard security, integrated security, and mixed security (a combination of standard and integrated security). Standard security is required for SQL Server to work with the Membership Directory. Standard security is also recommended for SQL Server to work with Commerce Server sites, such as business-to-consumer sites.

Standard security is the default security login mode defined by the SQL Server Setup program. In this mode, SQL Server has its own login validation scheme for database login IDs and passwords that is separate from Microsoft® Windows NT®. Access to the database and its objects is determined by security settings within SQL Server itself. Authentication involves comparing the provided database login name and password against similar information maintained in the SQL Server database.

Standard security is the default setting; if you need to change from one of the other settings to standard security, use SQL Server Enterprise Manager. For information about the security login modes, see Setting the Server Security Options in Part 4 of the Administrators Companion 6.0, part of the SQL Server 6.5 Books Online.

When using SQL Server standard security, there are several ways to ensure access to the SQL Server database from ASP pages that allow Anonymous access and from the LDAP Services that control the Membership Directory. Any of the following methods can be used, depending on the needs of your configuration:

• Install SQL Server on the same computer as Microsoft® Internet Information Server (IIS). Most Microsoft® Site Server installations are too large for this option to be practical. 

  Install SQL Server on a different computer than IIS, and do one of the following:

  • Use Transmission Control Protocol/Internet Protocol (TCP/IP) to connect the two computers, and on the SQL Server computer, add a Windows NT local user account with the same name as the local IIS anonymous user account. Note that the passwords must match exactly. 

  • Make the IIS anonymous user account a member of the domain where SQL Server resides (or install IIS on the domain controller). 

For information about configuring IIS to work with SQL Server, see the Microsoft Knowledge Base articles available at https://support.microsoft.com/support .

SQL Server on IIS Computer

If SQL Server is installed on the same computer as IIS, when SQL Server attempts to validate the IIS user account (whether it is IUSR_computername or an authenticated user), the account is located in the local user database. Therefore, no problems with authentication occur.

SQL Server on Remote Computer

If SQL Server resides on a separate computer from IIS, the SQL Server installation must support TCP/IP connections. Although the connection between the two computers uses a non-authenticated protocol, access to SQL Server is granted based on database login ID and password.

To configure SQL Server to use TCP/IP connections, use SQL Server Setup. For information about setting this option, see Chapter 3, Server Options in the "SQL Server Setup 6.0" section of the SQL Server 6.5 Books Online.

You must recreate the IIS anonymous account on the SQL Server computer. If you have ASP pages (such as Commerce pages) that allow anonymous access, those ASP pages must use this account to access the SQL Server computer. Similarly, the Site Server LDAP Service also uses this account when accessing the SQL Server computer for Membership Directory operations. When you install IIS, the anonymous account is created with a random password. Before you can recreate the account, you must reset the password.

As an alternative to creating matching local accounts, you can create a domain-level IIS anonymous account and configure IIS to use that account (this is the default configuration if you install IIS on a domain controller).

To set up the IIS anonymous account for SQL Server database access 

1. Use User Manager for Domains on the IIS computer to set a new password for the IIS anonymous account. 

2. Use User Manager for Domains on the SQL Server computer to recreate the IIS anonymous account. 

   Important The IIS anonymous accounts on the IIS and SQL Server computers must have identical user names and identical passwords. 

For information about using User Manager for Domains to modify accounts, see Managing your computer's security with User Manager for Domains in the Windows NT online help.

For information about configuring the IIS anonymous account, see Configuring the Anonymous Access Account in the "Microsoft Internet Information Server" section of the Windows NT 4.0 Option Pack documentation.

To set up a domain-level IIS anonymous account 

1. If needed, use User Manager for Domains on the domain controller to create an IIS anonymous account. 

2. Use the Internet Service Manager MMC snap-in to configure IIS to use the new account. 

For information about using User Manager for Domains to modify accounts, see Managing your computer's security with User Manager for Domains in the Windows NT online help.

For information about configuring the IIS anonymous account, see Configuring the Anonymous Access Account in the "Microsoft Internet Information Server" section of the Windows NT 4.0 Option Pack documentation.

SQL Server and the Site Server Membership Directory

The Microsoft ® Site Server LDAP Service uses the Microsoft® SQL Server™ Administrator account to gain access to the database that contains the Membership Directory. In the ordinary course of operations, all contact with the database should be through the Site Server software. With few exceptions (such as index optimization, operations using SQL Server Enterprise Manager and regular data backups), it is strictly inappropriate to perform any operations directly on the database. Therefore, access to the SQL Server Administrator account and password should be carefully controlled.

To protect the Membership Directory from direct access

An intruder could grant bypass-ACL-checking privilege to an account, thereby giving it total control. Use the following to safeguard against this:

• Do not use the default SQL Server Administrator account named sa. Create a new SQL Server Administrator account with a hard-to-guess account name and password. 

• Write down the account name and password and put them in a safe.

• Never leave this information written down in an easily-accessible place. 

SQL Server and Site Server, Commerce Edition

Standard security is the recommended security configuration for use with Commerce Server and Microsoft® Internet Information Server (IIS). You can use SQL Server Enterprise Manager to check or change the security configuration.

To ensure that Commerce and SQL Server communicate in a secure manner 

• When using Standard security, SQL Server maintains a list of database login names and passwords that are authorized to access the database. See the SQL Server 6.5 Administrator's Companion in the SQL Server 6.5 Books Online for details of securing this information. 

• If Microsoft Internet Information Server (IIS) and SQL Server are hosted on separate computers, the protocol used to connect the computers determines the type of authentication used. In some cases, this authentication involves a Microsoft® Windows NT® user account and password, which is separate from the database login name and password. 

• When Standard security is used, the Commerce Server site's connection string contains the data source name (DSN) or user name and password that enables access to the database. The DSN must be configured to use TCP/IP connections. Use the Open Database Connectivity (ODBC) Control Panel to configure DSNs. For information about securing this DSN, see the Windows NT online documentation. 

  Important If you are using Standard security, when you create a DSN to connect to the database, be sure to select With SQL Server authentication using a login ID and password entered by the user. Otherwise the DSN might attempt to override the Standard security setting. 

• When SQL Server uses Standard security, it is possible for shopper pages to use a DSN without a trusted connection and for management pages to use another DSN with a trusted connection. With this configuration, anonymous customers can visit the shopping site, but only managers can visit the management pages. 

• If SQL Server resides on a separate server computer from IIS and a TCP/IP connection is not feasible, you can configure the SQL Server computer to enable the Guest user account. 

  By default, the Guest account provides limited access. The administrator should make sure that the Guests group is not given any additional privileges. (Many companies have security procedures that do not allow the Guest account to be enabled.) 

• Use some form of data encryption when appropriate, including while performing client data transactions involving sensitive client data and during site replication.

• Verify that any database accesses performed within the application protect the integrity of the database. 

For information about creating databases to work with Commerce Server, see the following topics in the Site Server 3.0, Commerce Edition documentation:

• Preparing the Database 

• Creating Database Login Names 

• Securing the Site's Database 

SQL Server and Other Applications

Special care must be taken to ensure that database permissions are properly maintained when scripts and executables comprising a Web-based application attempt to query or conduct transactions against a database. To avoid security complications, the user ID and password required to gain access to the database are usually embedded in the script initiating the query or transaction. Because HTTP is essentially stateless, when a Web client performs an action requiring a database access, the query, user ID and password need to be sent together in a single transmission. This is not generally considered a secure practice, since clients usually send request data to the Web server in plain ASCII format. If this information is stored in the script code located on the server, it is less likely to be compromised.

Monitoring Membership Directory Database Logon Failures

You can configure Microsoft ® SQL Server™ to keep track of failed logon attempts. To do this, start SQL Server Setup, and then click Setting the Server Security Options. Under Audit Level, click Failed Login.

This will cause log records of failed logon attempts to be created in the Windows NT Event Log or in the SQL Server error log. (For additional information about how to configure SQL Server logging, see the Microsoft SQL Administrator's Companion, Chapter 3.)

Dial-in Access (ICS/RAS)

Site Server 3.0 provides an updated version of Internet Connection Services for RAS (ICS/RAS). One of the components of this package is Internet Authentication Services, Commercial Edition (IAS/C), which functions as a Remote Authentication Dial-In User Service (RADIUS) server.

To implement the procedures described in this section, use an account that is a member of the Windows NT Administrator group. This section assumes that the Administrator has followed all of the Microsoft® Windows NT® security procedures. The Administrator must be aware of the strengths and weaknesses of the various types of authentication, and must select one accordingly. For example, when using Password Authentication Protocol (PAP), passwords are sent in clear text from the user's desktop to the Network Access Service (NAS). The PAP password is encrypted over the Internet, but if the request is configured to pass through an intermediate RADIUS proxy, then it can be decrypted at the proxy. Refer to RFC 2138 to for details on the RADIUS protocol, and the various authentication protocols.

To enhance the security of the configuration, IAS/C should reside on computers separate from the other computers in the system. The computers that run IAS/C can also perform routing functions.

To ensure a secure installation of RADIUS 

• Do not leave the service unprotected during installation or operation. The site must be secured from both the intranet and the Internet.

• Set all of the IAS/C files, executables, DLLs, configuration and data files with the most restrictive ACLs possible.

• Create a RADIUS_Administrator group at installation time. Give this group exclusive permissions to execute the ADMINUI.EXE.

• Restrict the AUTHSRV.EXE so that it is writable only by the Windows NT Administrator account and/or RADIUS_Administrator group, and executable by the system. 

• Restrict the associated DLLs used by IAS so that only the Administrator and/or RADIUS_Administrator group can write them, and only the system can load them. 

• Make the configuration files writable only by the RADIUS_Administrator group, and readable only by the Windows NT System account.

• Restrict the Help file to the RADIUS_Administrator group. 

Authentication

The RADIUS server communicates with external authentication databases to authenticate users. These authentication databases can be the Site Server Membership Directory, Open Database Connectivity (ODBC), Windows NT domain, or even another RADIUS server.

For ODBC, the RADIUS server makes a SQL query to retrieve the user name and password from the ODBC database. Refer to the ODBC and database documentation for details on how to secure an ODBC connection.

For the Windows NT domain, the RADIUS server forwards the request to the domain. Communications between the RADIUS server and the back end data stores is generally performed using Windows NT security.

To protect the back end interactions 

• Place these servers behind firewalls, where they communicate only within a trusted network that is tightly controlled.

Firewalls and Security on the PPTP Server

The PPTP filtering built into Windows NT Server allows a stand-alone PPTP server to regulate traffic between the Internet and the private network. Nonetheless, some organizations may want the additional security a firewall provides.

The following three methods are available for adding a firewall to a Virtual Private Network:

• Placing the firewall on the Internet, with the firewall between the Internet and the PPTP server. 

• Placing the PPTP server on the Internet, with the firewall between the PPTP server and the private network. 

• Installing the Routing & Remote Access Service (Routing & RAS) on the PPTP server and implementing a firewall on the same computer. 

Securing a RADIUS Server by Using a Firewall

You must have a firewall in place to protect any of the services running on any operating system. The firewall may be a Windows NT computer with Windows NT Proxy, or a third party firewall package. The firewall may run on the same computer as the RADIUS server.

This firewall should enable the User Datagram Protocol (UDP) traffic for the RADIUS server only for those ports used by the RADIUS server. For more security, you may opt to allow traffic only from specific IP Addresses, of NAS or RADIUS proxy, to the RADIUS server.

One option is to use the Windows NT Proxy service to hide the server's IP address. This way, the proxy IP address is exposed as the RADIUS address. You can also use a third party firewall and enable the UDP traffic for the RADIUS server only for those ports used by the RADIUS server. For more security, you can allow traffic to only come into the RADIUS server from specific IP Addresses of NAS or RADIUS proxy that you specify.

Ensuring Users Have Proper Access to Functionality and Content

Users are administered by using whatever back-end database is available, generally the Membership Directory, Windows NT, or ODBC. If the authentication database is Windows NT, then the RADIUS server checks the dial-in bit in accordance with a Quick Fix Engineering (QFE) update. For the Membership Directory, all users who are enabled in the Membership Directory are given dialup access.

RADIUS is generally used to authorize dialup access, and can be used to control user access to a specific network. This can be done by configuring the RADIUS profile with the right filters or by creating a mandatory tunnel. Enabling PPTP filtering on the tunnel server can further enhance security. However, with a standard RADIUS installation, the user should first check the NAS documentation to see what filters the NAS supports, or if it offers mandatory tunneling.

Delegating Administration

There are two aspects involved in administration: administration of users and administration of the RADIUS server. The delegation of user administration is a feature of the authentication database. By default, the Administrator on the Windows NT computer can administer a RADIUS server. They can also give Administrator access for the computer running the RADIUS server to anyone else. However, the administration responsibility for a RADIUS server can not be delegated in parts.

Ensuring Content Is Protected Properly

RADIUS is generally not used to control access to specific parts of Web content. However, RADIUS can be used to restrict user access to certain parts of the network, such as sites, or hosts. RADIUS can also be used to restrict access to individual Virtual Private Networks.

Monitoring RADIUS Against Inappropriate Access

Through the network, by using the Performance Monitor (PerfMon) tool, the Administrator can monitor activity at the RADIUS sever. By auditing event logs, the Administrator can see who has been granted or denied.

To prevent inappropriate password access

• Choose a long shared secret that does not contain words that can be found in any dictionary in any language. 

Knowing When Your System Is Under Attack

The PerfMon Management Information Base (MIB) has counters that show the current number of malformed packets. The Administrator can set a PerfMon trigger to alert them when any malformed packets are discovered. The server also logs malformed packets, which go into the event log. The Administrator can also set a PerfMon trigger or an event log pager to alert them in the event of an attack.

To reduce the risk of an attacker replying with an intercepted response 

The secret is the password shared between the client and the RADIUS server. Repetition of a request value in conjunction with the same secret could permit an attacker to reply with a previously-intercepted response.

• The Request Authenticator value should be unpredictable and unique over the lifetime of a secret.

• Because it is expected that the same secret may be used to authenticate with servers in disparate geographic regions, the Request Authenticator field should exhibit global and temporal uniqueness.

To lessen the risk of an attacker masquerading as a server 

An attacker may trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Access-Request.

• The Request Authenticator value in an Access-Request packet should be unpredictable and unique.

Although protocols such as RADIUS are incapable of protecting against theft of an authenticated session by way of real-time active wiretapping attacks, generation of unique, unpredictable requests can protect against a wide range of active attacks against authentication.

To reduce the risk of attacks using the least secure method 

It is not anticipated that a particular named user would be authenticated by multiple methods. This would make the user vulnerable to attacks that negotiate the least secure method from among a set of methods.

Within or associated with each RADIUS server, there is a database that associates user names with authentication information or secrets.

• For each named user there must be only one method employed to authenticate that user name. If a user must employ varying authentication methods under different circumstances, then distinct user names must be employed, each of which identifies exactly one authentication method.

• Maintaining the physical security of the computer is important in order to prevent someone from logging in and tampering with it. Passwords and other secrets should be stored so that access to them is as limited as possible. Ideally, the secrets should be accessible only to the process requiring access in order to perform the authentication. 

• The secrets should be distributed with a mechanism that limits the number of entities that handle, and thus gain knowledge of, the secret. Ideally, an unauthorized person should never gain knowledge of the secrets.

Troubleshooting

For information about user connectivity, see the online help that ships with the product.

For information about user access problems, see the online help that ships with the product.

For information about:	See:
PPTP Performance & Security Upgrade for Windows NT 4.0 Release Notes	https://support.microsoft.com/default.aspx?scid=kb;en-us;189595&sd=tech  The information in this article applies to: Microsoft Windows NT Server 4.0 Microsoft Windows NT Workstation 4.0
RAS Support for Security Dynamics ACE/Server	https://support.microsoft.com/default.aspx?scid=kb;en-us;129300&sd=tech  The information in this article applies to: Microsoft Windows NT Workstation 3.51 Microsoft Windows NT Server 3.51 Microsoft Windows NT Server 4.0 Microsoft Windows NT Workstation 4.0

Authenticating Users

Microsoft® Internet Information Server (IIS) authenticates users before allowing access to any applications (for example, Web sites). You can set different authentication methods (such as Automatic Cookie Authentication or Clear Text/Basic Authentication), and you can set these methods at different levels (site, virtual directory, file, and so on).

The set of available authentication methods depends on the authentication mode. You must select your authentication mode when you set up the Site Server deployment. Once your system is deployed, use IIS to set your authentication methods.

Authentication Modes

Microsoft® Site Server 3.0 supports two security modes: Membership Authentication mode and Microsoft® Windows NT® Authentication mode. Each mode has a specific set of identification and authentication methods. The preferred mode depends entirely on the needs of a particular site. Intranet and Internet sites have different security needs, as do sites that host large user communities. Because the Membership Directory can store more user accounts than the Windows NT security database, Membership Authentication mode is normally appropriate for Site Server installations.

The Site Server Authentication Service coordinates user authentication when user accounts are stored in the Membership Directory. It interacts with Application servers (such as Web servers), Security Support Provider Interface (SSPI), and the Membership Directory.

For information about authentication modes, see Authentication in the "P&M" section of the Site Server 3.0 documentation.

Anonymous Access

When setting authentication methods on Web and other Application virtual servers (sites), virtual directories, and files, you can use the IIS Allow Anonymous Access setting when you want all users to be able to log on to the server and receive access to public content. In this case, "public users" are represented by the Everyone group in Windows NT. Access control takes precedence over the Allow Anonymous Access setting. This arrangement makes it possible to allow public access to some areas and use access control lists (ACLs) to restrict access to others.

Two groups make public access possible on objects that are protected by ACLs:

• Public. The P&M group, to which every account in the Membership Directory is automatically added. When Membership Authentication is used, an access control entry (ACE) for this group exists in the default ACL on the Membership Directory Manager node. This ACE grants all users full control over all Membership Directory objects, and overrides all other default ACLs. You can remove the Public ACE to enable default Membership Directory ACLs. 

• Everyone. The Windows NT group, to which every account in the Windows NT Server directory database is automatically added. By default, this group is on the ACL in every file and directory (except for certain system files), but you can change the access granted to it from Full Control to a lesser permission such as Read. In the Membership Directory, this group is granted full control on the root Directory Information Tree (DIT) object by default when Windows NT Authentication is used. 

On the Web site or other Application server, the Allow Anonymous Access setting operates in conjunction with ACLs to control whether or not authentication occurs (that is, whether the user is asked for credentials).

• If Allow Anonymous Access is enabled and the ACL on the requested resource grants access to the Everyone group, authentication does not occur. The user is logged on anonymously.

• If Allow Anonymous Access is enabled and the ACL on the requested resource does not grant access to the Everyone group, authentication occurs.

• If Allow Anonymous Access is disabled, authentication occurs, regardless of the contents of the ACL on the resource.

• If client certificates are accepted or required for a requested resource, the Client Certificate Authentication process occurs regardless of the Allow Anonymous Access setting on the Application server, virtual directory, or file, or the ACL existing on the resource. 

For information about anonymous access to an installation secured with Membership Authentication, see the following topics in the "P&M" section of the Microsoft® Site Server 3.0 documentation:

• Authentication 

• Developing a Security Model 

• Setting Access Control on Application Server Content 

• Setting Access Control on Membership Directory Objects 

• Anonymous Accounts 

• Authentication and Anonymous Logons 

If a Site Server installation secured with Membership Authentication accepts anonymous logons, the anonymous users are logged on as an IIS anonymous account for access to Windows NT resources, or as a Membership Directory anonymous account for access to Membership Directory resources. For information about the IIS anonymous account, see IIS Anonymous Account in the "Securing Windows NT Server" section of this document. For information about the Membership Directory anonymous account, see Authentication Methods on the LDAP Service later in this document.

Authentication Methods

Windows NT Authentication mode supports the following identification and authentication methods:

• Anonymous 

• Clear Text/Basic Authentication 

• Windows NT Challenge/Response Authentication 

• Client Certificate Authentication 

Membership Authentication mode supports these methods:

• Anonymous 

• Clear Text/Basic Authentication 

• HTML Forms Authentication 

• Distributed Password Authentication (DPA) 

• Client Certificate Authentication 

• Automatic Cookie Authentication 

As stated previously, Membership Authentication mode is normally appropriate for Site Server installations. However, remember that if you use Clear Text/Basic Authentication, the user name and password will be sent in clear (unencrypted) text that can be stolen by others on the Internet.

For information about the authentication methods that you can use with Site Server, see Authentication Method Details in the "P&M System Reference" section of the Site Server 3.0 documentation, and the following topics in the "Site Server Security" section of the Site Server 3.0 documentation:

• Understanding Automatic Cookie Authentication 

• Understanding HTML Forms Authentication 

• Understanding How DPA Works with HTTP Proxy Servers 

• Understanding the DPA Realm Name 

To authenticate users for administrative applications or scripts 

• Apply controls similar to those already described in this topic to any ASP pages or CGI scripts you create that access or modify sensitive data, such as custom administrative pages.

• Do not use cookie-based methods. Such methods are vulnerable to replay attacks. 

• Use a strong authentication method such as Client Certificate Authentication or HTML Forms Authentication with Secure Sockets Layer (SSL)/Transport Layer Security (TLS).

• If you use Clear Text/Basic Authentication for this purpose, it is strongly recommended that you also use SSL/TLS. 

Restricting Logons 

Logons to Application servers can be restricted by computer, by Domain Name System (DNS) domain, and by account. To grant or deny logons to specific computers, groups of computers, and domains, you can use the IIS Grant/Deny feature.

For individual accounts, when using Membership Authentication, the P&M Authentication Server automatically denies logons to accounts whose logon attempts fail repeatedly within a short period of time.

For information about denying access, see the following topics in the "P&M" section of the Site Server 3.0 documentation:

• Allowing Anonymous Site Logons 

• Authentication Service Commands and Switches 

• Restricting Logons to Application Servers 

• Setting Access Control on Application Server Content 

• Short-term Authentication Service Logon Deny for Accounts Only 

To restrict logons to a service by an IP address or domain 

For information about the IIS Grant/Deny feature, see the IIS documentation.

To configure settings for temporarily restricting logons by an account 

The Authentication Service associated with a Membership Server instance automatically monitors failed logon attempts by accounts. If an account makes 25 incorrect attempts at a password in three minutes, the account is denied the ability to log on for three minutes. After three minutes, the counters are reset.

• Use the PMAdmin Set Master command from the command line to change the values for the number of attempts allowed and the number of minutes before resetting the counters. These settings affect all services that reside on the computer and use the Membership Directory for authentication. 

  For information about using this command, see PMAdmin Set Master in the "P&M" section of the Site Server 3.0 documentation. 

Tracking Account Status 

When the Authentication Service processes a logon request from a user who wants access to application content, it checks the account-status attribute of that user. Accounts without an active status (value = 1) are not authenticated in Membership Authentication mode.

Note If a client accesses the LDAP Service directly without using the Authentication Service, the LDAP Service checks the account-status attribute if the Membership Directory is secured with Distributed Password Authentication (DPA) but not if it is secured with Clear Text/Basic authentication.

For information about the account-status attribute and canceling user accounts, see Removing Canceled User Accounts in the "P&M" section of the Site Server 3.0 documentation.

To prevent users with expired or inactive accounts from gaining access to the Membership Directory 

• Delete inactive accounts frequently. 

Web-based Administration (WebAdmin) 

Administrators must belong to the appropriate Windows NT groups in order to administer services using WebAdmin. In Membership Authentication mode, these group memberships can be assigned in the Membership Directory. They propagate automatically to Windows NT.

The WebAdmin pages are stored in the \Microsoft Site Server\SiteServer\Admin directory, which is the SiteServer/Admin virtual directory for both the Default Web Site and the Administration Web Site. By default, the local Windows NT Everyone group is granted Read permissions, including the right to execute programs, on this directory. The local Windows NT Administrators group is granted Full Control.

The default Windows NT Authentication methods on this directory are:

• Clear Text/Basic Authentication 

• Windows NT Challenge/Response Authentication 

The Allow Anonymous Access option is disabled.

These settings prohibit non-administrative users from posting scripts into that directory. Any user who can authenticate using a Windows NT account on the WebAdmin computer can view the WebAdmin pages, but if the user does not have the necessary permissions on that computer, they will be unable to execute the service administration functions.

To protect passwords and other sensitive information used with WebAdmin 

• If you are operating WebAdmin under Clear Text/Basic Authentication, you must configure the SiteServer/Admin virtual directory that contains the WebAdmin pages to also use Secure Sockets Layer (SSL)/Transport Layer Security (TLS), so that passwords and data will be encrypted in transmission. Use SSL/TLS both between the client browser and the Web server, and between the Web server and the LDAP Service.

To prevent unauthorized users from seeing the WebAdmin pages 

Do one or more of the following:

• Reduce the Everyone group permissions to the WebAdmin directory. 

• Delete the SiteServer/Admin virtual directory from one or both Web sites on each Site Server computer. 

• Put sites with WebAdmin on non-standard ports. 

Commerce Site Manager Pages 

Every site generated by the Site Server, Commerce Edition Site Builder Wizard has a set of Active Server Pages (ASP)-based manager pages that are secure but accessible over an intranet or the Internet. Access to a site's manager pages is restricted to the Windows NT user accounts that are members of that site's Commerce_ sitename _ WebSiteInstance  group on the server computer.

The default Windows NT Authentication methods on these pages are:

• Clear Text/Basic Authentication 

• Windows NT Challenge/Response Authentication 

The Allow Anonymous Access option is disabled.

The directory that contains a site's manager page files is protected by access control lists (ACLs) that permit access only to members of the Administrators group and the site's Commerce_ sitename _ webinstance group on the server computer. These ACLs are described in Windows NT File System Security Settings for Commerce Server Sites in the "Commerce Server Security" section of the Site Server 3.0, Commerce Edition documentation.

Because each Commerce Server site has its own Commerce_ sitename _ webinstance group, the operator of one Commerce Server site cannot access the manager pages of other Commerce Server sites hosted on the same computer.

Monitoring Authentication Activity

The following Microsoft® Windows NT® Performance Monitor counters can provide useful information that may indicate attempts to breach the authentication policy.

Each authentication method has the following counters:

• Accounts created 

• Authorization failures 

• Authorization failures per second 

• Authorization successes 

• Authorization successes per second 

In addition, the following counters provide useful information:

• Connections attempted by Denied users 

• Logon Operation Failures 

• Logon Operation Failures per second 

• Logon Operation Successes 

• Logon Operation Successes per second 

• Membership Directory Connection Status 

• Membership Directory Connection Dropped 

• Membership Directory Connection Failed 

• Membership Directory Connection Succeeded

• Requests sent to the Membership Directory 

• Requests Served from cache 

Authentication Methods on the LDAP Service

The Microsoft® Site Server Lightweight Directory Access Protocol (LDAP) Service that is associated with a given Membership Directory is used by the Authentication Service to authenticate logons to that Membership Directory. For this reason, for a given Membership Server running an LDAP Service, you set authentication methods on the LDAP Service to protect the Membership Directory from unauthorized logons.

In order to gain access to the Membership Directory, the client must specify the authentication method it uses. Therefore, you must set methods on the LDAP Service that accommodate the clients that need access to the Membership Directory. When using Membership Authentication, all Microsoft® Site Server services and tools require that the Clear Text/Basic Authentication method be set on the LDAP Service.

Note The authentication methods required by P&M tools are set by default.

All LDAP Service authentication methods are described in detail in Authentication in the "P&M" section of the Site Server 3.0 documentation.

If Membership Authentication is being used, then the user name and password are stored in the Membership Directory, and one or more of the following Membership Authentication methods can be set on the LDAP Service:

• Allow Anonymous (enabled by default). 

• Distributed Password Authentication (DPA) (Membership 1.0 Compatibility; for information, see LDAP Service Commands and Switches in the "P&M" section of the Site Server 3.0 documentation). If you enable DPA on the LDAP Service, users will be unable to bind anonymously to the Membership Directory, even if Allow Anonymous is enabled. 

• Clear Text/Basic Authentication (enabled by default and required by all P&M tools and services). 

If you set Allow anonymous, the user can log on anonymously. ACLs on Membership Directory objects determine the objects the user sees. The Membership Directory has a default anonymous user account, cn=Anonymous, for anonymous access to Membership Directory objects. The user can gain access to the Membership Directory as this account when all of the following conditions are true:

• Membership Authentication is used. 

• The user is requesting an object in the Membership Directory. 

• Allow anonymous is set on the LDAP Service. 

For information about anonymous accounts used with the Membership Directory, see Anonymous Accounts in the "P&M" section of the Site Server 3.0 documentation:

For information about security for the LDAP Service, see the following topics in the "P&M" section of the Site Server 3.0 documentation.

• Developing a Security Model 

• Allowing Anonymous Site Logons 

• Authentication Method Details 

• Setting up the LDAP Service for Dynamic Data 

• Setting Authentication Methods on the LDAP Service 

Monitoring LDAP Service Activity 

The LDAP Service Log can be configured to maintain a record of all LDAP transactions against the Membership Directory, showing type of activity, user identity, and various additional details, as discussed in Setting Up LDAP Logging Options in the "P&M" section of the Site Server 3.0 documentation. Look for unusual activity, such as LDAP operations that do not normally occur.

The following Windows NT Performance Monitor counters provide useful information about LDAP Service authentication activity:

• ACL Failure 

• Authentication Failure 

• Basic Binds 

• Basic Binds per sec 

• Bytes Received 

• Bytes Received/sec 

• Bytes Sent 

• Bytes Sent/sec 

• Connection Attempted 

• Connection Current 

• Connection Max 

• Connection Total 

• DPA/NTLM Binds 

• DPA/NTLM Binds per sec 

Restricting Logons to LDAP Servers 

Personalization & Membership (P&M) provides protection against users who try to access secured areas by means of password-guessing attacks. You can distinguish these attacks from the inevitable and innocent forgotten password logons by setting a limit to the number of failed logons that is high enough that it will not exclude the innocent user, yet low enough to thwart the malicious user.

For a given Membership Server instance that contains an LDAP Service element, restrictions can be set for the following conditions:

• Short-term logon deny. Password failures are monitored for IP addresses and accounts and temporarily refusing logons. This feature can be turned on and off for any Membership Server. 

  Note Short-term logon deny for accounts logging on to Membership Server instances is also automatically enforced by the Site Server Authentication Service when Membership Authentication is used. 

• Permanent logon deny. Logons to the Membership Directory are refused for specific IP addresses. This feature can be implemented for a given Membership Server by adding IP addresses to a text file. 

Use the P&M command-line interface to turn these features on and off for a given LDAP Service. Use the Windows NT registry to change the configuration parameters used for monitoring logon failures. For information about the commands, see PMAdmin Set LDAP in the "P&M" section of the Site Server 3.0 documentation.

For information about denying access, see the following topics in the "P&M" section of the Site Server 3.0 documentation:

• Allowing Anonymous Site Logons 

• Managing Authentication on the LDAP Service 

• Membership Server Commands and Switches 

To monitor failed attempts to log on to an LDAP Service by an account or an IP address and deny access on a temporary basis 

• Use the PMAdmin Set Master command from the command line to change the IP address and account logon deny settings. These are computer-level settings. 

For information about these commands, see the following topics in the "P&M" section of the Site Server 3.0 documentation:

• PMAdmin Set LDAP 

• PMAdmin Set Master 

To permanently deny an IP address access to a given LDAP Service 

• Include the IP addresses to be blocked in a file named ipblist.instanceID.txt. Instance ID is the number of the Membership Server instance for the LDAP Service in question. This file must reside in the Winnt\system32\inetsrv directory. 

  Important You must add one blank line at the end of the iplist.instanceID.txt file (that is, you must add two carriage returns after the last line of text). The blank line at the end of the file is required for the file to run. 

  If you monitor failed logons using Windows NT Event Viewer or Performance Monitor, and you find that an IP address is consistently failing on a given Membership Server instance of an LDAP Service, you can add this IP address to the text file to permanently deny logons from this address. 

  For information about using Windows NT Event Viewer and Performance Monitor, see the Windows NT Server documentation. 

Response to Password-Guessing Attacks

If there is a significant increase in the value shown for one or more of the Failed Authentications counters, this can be an indication that someone is trying to break into your system. Mistaken password entries will usually stop after a few tries, while malicious attempts continue until they are terminated. It is recommended that you set these counters to trigger an administrative console alert when they surpass baseline values.

In cases of repeated authentication failure, Site Server can automatically put the offending user account or Internet Protocol (IP) address on a short-term access denial list. If you believe you are encountering intrusion attempts, you have the option of permanently denying access to an offending user account or IP address. Site Server features for short-term and permanent logon denial are discussed in Restricting Logons to LDAP Servers and Restricting Logons to Application Servers in the "P&M" section of the Site Server 3.0 documentation.

Securing User Information

User and group objects in the Membership Directory can be protected with Membership Directory ACLs. When you set up your security strategy, keep in mind what kind of administrative accounts you will need and what kinds of access you will allow.

Administrative Accounts

When you use Membership Authentication, administrative accounts for your users and services reside in the Membership Directory. If you use Windows NT Authentication, administrative accounts reside in the Microsoft® Windows NT® Server directory database. Because Windows NT Authentication mode is not practical for Microsoft® Site Server installations, this document focuses on Membership Authentication mode.

To protect against inappropriate use of administrative accounts 

• Create accounts or account groups with narrowly-defined permissions for specific purposes, instead of using an existing account or group that is more powerful than necessary. 

For information about the default privileges granted to Microsoft® Site Server administrative account groups, see Site Server Administrative and System Security Groups and Accounts in the "P&M" section of the Site Server 3.0 documentation.

For information about managing Membership Directory accounts, see the following topics in the "P&M" section of the Site Server 3.0 documentation.

• Managing the Membership Directory Administrator Account 

• Understanding the Bypass-ACL-Checking Privilege 

• Managing Site Server Administrative Account Groups 

• Managing the SQL Server Administrator Account 

• Understanding Membership Directory Account Status 

SuperAdministrator

In a Membership Directory that uses Membership Authentication mode, the built-in Administrator account has full permissions to that Membership Directory. Although this account is present in Membership Directories that use Windows NT Authentication, it has no function in that situation because security accounts under Windows NT Authentication are stored in the Windows NT Server directory database.

The name of this account, Administrator, cannot be changed, and the account cannot be deleted. It is created with the default password password.

In Membership Authentication mode, the Administrator account has unique characteristics to facilitate Site Server installation and to ensure that no individual can inadvertently or maliciously lock out all access to a Membership Directory by setting overly-restrictive ACLs. The Administrator account is not subject to access control restrictions of any kind in the Membership Directory, and for this reason is sometimes referred to as a super administrator account. This account possesses a special DS-Privileges attribute value of SUPERBROKER. For more information about the operation of this feature, see Understanding the Bypass-ACL-Checking Privilege in the "P&M" section of the Site Server 3.0 documentation.

If this account's password is compromised (obtained by an unauthorized party), there is a security exposure to the integrity of the server. Security of the applications running on the server is threatened, as well as other data and services on that server. Even if the password is changed, the account name is known, making it an easy target for a password-guessing attack. Short-term logon denial can slow, but not prevent, such attacks. A form of denial-of-service attack can in fact be conducted by trying to guess the Administrator password. Repeated failures can cause the Administrator account to be denied access, which can interfere with administrative operations.

In addition, if you turn the default site into a production site without making any changes, the site will have a well-known administrator account name and password that can be easily compromised. If this happens, then data theft and service disruption are possible. The default site may also contain sample or test accounts, and may have been compromised if, as is likely, it has been operated under lesser security than a production site.

For information about logon-deny settings, see the following topics in the "P&M" section of the Site Server 3.0 documentation.

• Short-term LDAP Logon Deny for Accounts and IP Addresses

• Short-term Authentication Service Logon Deny for Accounts Only 

To protect against misuse of the Administrator account 

• Use accounts in the SiteServer Administrators group, which do not have the bypass-ACL-checking privilege, for ordinary operations. Reserve the original Administrator account for emergencies (for example, if the new super administrator account is accidentally deleted). 

• Never use a super administrator account in scripts, or leave the password written down in a place where it is easily accessible. Strictly limit the availability or dissemination of any administrative account name or password to the smallest number of people practical. This is particularly important with reference to these most powerful accounts. 

• Do not convert the default site to a production site. Instead, create a new site with a new super administrator account, as explained earlier.

Member Administrators

As mentioned in the previous section, use accounts in the SiteServer Administrators group, which do not have the bypass-ACL-checking privilege, for ordinary operations in the Membership Directory. You can also create new administrative groups.

If you have subdivided your ou=Members container, see the section "Delegated Administration in Multiple Communities" for additional information.

To protect user information while delegating Membership Directory administration tasks 

• Use (or create, if necessary) specific administrative groups for specific levels of Membership Directory access or specific functions. Use Membership Directory ACLs to control the different permission levels of the different groups. 

• Limit overlap between the permissions of different administrative groups. 

• When setting ACLs, be aware of inheritance settings. 

Windows NT Administrative Groups

In a Membership Directory that uses Membership Authentication mode, groups with administrative permissions in Windows NT reside in the ou=NTGroups, ou=Groups container. These groups map directly with no prefix to groups that are automatically created in the Windows NT directory database during Site Server installation.

A user added to such a group in the Membership Directory effectively becomes a member of the corresponding group in Windows NT when logging on to a resource secured by that Membership Directory. Therefore, these Membership Directory groups must be secured so that they do not become a "back door" for inappropriately adding users to a computer's Windows NT groups.

To protect the integrity of Windows NT group memberships 

• Do not change the default access control entries (ACEs) on the ou=NTGroups container. By default, only members of the Administrators group in the Membership Directory (cn=Administrators, ou=NTGroups, ou=Groups) and accounts that bypass ACL checking can create groups in the ou=NTGroups container or add members to the Administrators group in the Membership Directory. This follows the Windows NT model, which allows only an administrator to add other users to the Windows NT Administrators group. Any member of the Administrators group in the Membership Directory is permitted to add members to the other Site Server administrative groups. 

• If you do not need any of the users stored in the Membership Directory to have Windows NT administrator rights, the Administrators group in the ou=NTGroups container can be deleted. Windows NT administrators will then have to log on to Windows NT under Windows NT Authentication.

• Create one or more accounts in the SiteServer Administrators group for routine Site Server administrative operations. 

• Promptly delete the accounts of individuals who should no longer have administrative permissions. 

• If you judge the risk of account group mapping without prefix to be too great, you can turn off the feature that maps groups in the ou=NTGroups container to groups in Windows NT. Doing this will place some limitations on your ability to administer the server remotely. These limitations are discussed in Administrative Group Mapping in the "P&M" section of the Site Server 3.0 documentation.

For information about administrative groups, see the following topics in the "P&M" section of the Site Server 3.0 documentation:

• Site Server Administrative Security Groups 

• P&M Administrative Groups 

• Administrative Abilities in the Membership Directory 

Membership Directory ACLs

Use the Membership Directory Manager (MDM) snap-in from Microsoft® Management Console (MMC) to set access control on Membership Directory objects. You can use access controls to set permissions that allow appropriate access by administrators, as well as to control access by the world at large to security account information and personalization attributes.

For information about using Membership Directory ACLs, see the following topics in the "P&M" section of the Site Server 3.0 documentation:

• Managing Access Control 

• Membership Concepts 

Securing a New Membership Directory

When a Membership Directory is created, it is unsecured, although a default set of secure ACLs is provided.

To secure a new Membership Directory: 

• Use Membership Directory Manager to remove the Public group or Everyone group access control entry (ACE) from the root object of the Membership Directory. This allows the default access control restrictions to take effect. 

• If you want to ensure that clients accessing the Membership Directory must authenticate, use the Personalization & Membership MMC snap-in to disable Allow anonymous for the LDAP Service. 

For information about Membership Directory access, see the following topics in the "Personalization & Membership (P&M)" section of the Site Server 3.0 documentation:

• Securing a Membership Directory 

• Managing Authentication on the LDAP Service 

ACL Inheritance

By default, an access control entry (ACE) applies to only the object on which it is set. You can use the Inheritance feature to apply permissions to existing child objects, and to child objects that are added in the future. If you change an inheritable ACE in the object ACL, the change takes effect on the child objects that are subject to inheritance.

Note Automatic inheritance is not transferred to existing dynamic objects (objects in the Dynamic Directory). Dynamic objects that are created subsequently within the container do inherit ACLs in the manner described.

In addition, when you create a new object within a container, the ACL on the new object inherits all inheritable ACEs from its parent (superior) container. These inherited ACEs include all inheritable ACEs on the parent that were inherited from its parents, and so on, up to the root container. If you do not want an object to inherit ACEs, you can exclude the object from inheritance using the Protect this object from inheritance setting.

Note Protect this object from inheritance also allows you to remove existing inherited ACEs. Otherwise, inherited ACEs cannot be modified or removed.

For information about ACL inheritance in the Membership Directory, see About Granularity and Inheritance in the "P&M" section of the Site Server 3.0 documentation.

Authentication Service Cache/AUO Considerations

When the Site Server Authentication Service retrieves a user's attributes for authentication, it caches those attributes. Because the Authentication Service bypasses ACL checking, this cache has all the user properties (except password), not just the subset that the user may be authorized to access.

When an ASP script creates an Active User Object (AUO) instance for that user, the new AUO will check the Authentication Service cache for the user's attributes. By doing so, it saves a query to the Membership Directory. However, if some of the user's attributes have ACLs that prevent the user from accessing them, these ACLs will not be effective. The Authentication Service cache can contain attributes that the user does not have permission to see.

Note AUO will only obtain the user's password if the user has permission to see the password.

Once the script executes a setinfo or a getinfo statement, AUO can only access attributes for which the user is authorized. This is because subsequent reads and writes go through Active Directory Service Interfaces (ADSI) instead of to the Authentication Service cache. Only attributes for which the user has write permissions can be written.

To prevent users or script authors from viewing or attempting to modify attributes that were not intended for such use 

• Consistently do a getinfo or setinfo in each of your AUO scripts to retrieve only permitted data from ADSI before displaying properties. Do this only if you want to burden your script authors with this responsibility and you trust them to carry it out consistently where applicable. Scripts written to go initially to ADSI will lose the performance advantage of starting from data in the Authentication Service cache. Scripts that do not need to go initially to ADSI can retain the performance advantage. 

• Disable AUO access from the Authentication Service cache by using the following command-line command: 

pmadmin set master /auocache:off

This setting affects all Membership Server instances on the computer, and makes all scripts operate without the performance advantage of initially using the Authentication Service cache. For information about this command, see *PMAdmin Set Master* in the "P\&M" section of the Site Server 3.0 documentation. 

Delegated Administration in Multiple Communities

If your users are segregated into community containers within the ou=Members container, it may make sense to have different people administer the different containers using separate accounts, while a senior administrator manages overall schema changes and other Directory Information Tree (DIT)-wide operations. Adjust the access control lists (ACLs) on each container to allow the different administrator accounts the right to add and change objects in the respective containers. However, be aware that the Personalization & Membership (P&M) ACL model is quite powerful and sophisticated, so practice manipulating ACLs on a test site before working on your production installation.

For information about ACLs, see the topic Managing Access Control in the "P&M" section of the Microsoft® Site Server 3.0 documentation and the white paper Hosting Multiple User Communities with a Membership Directory in the Site Server 3.0, Commerce Edition Resource Kit.

Dynamic Directory Considerations

Dynamic data is subject to the same considerations as static data, with the following exception:

Note LDAP clients must refresh dynamic objects in order for them to remain active. Any client can refresh any dynamic object. Access control restrictions do not apply to the Refresh operation.

Checking for Spurious Accounts

One form of attack is the creation of large numbers of spurious user accounts. This is most likely to occur in an Internet environment, where the site's user registration page is exposed to the public. Excess accounts take up space and can slow the performance of your site.

To detect and identify spurious accounts 

• Monitor the rate of account creation. A spike in this figure may indicate an account-creation attack, although it can also be caused by events such as marketing promotions.

• Review your user accounts periodically, looking for suspect accounts. Watch, for instance, for accounts that have large numbers of user names formed as numerical increments to a base name, or accounts that share common information with many other accounts). You can use Site Server Analysis to create diagnostic reports for this purpose.

Securing Applications

General Considerations

Content Modification Permissions for Visual InterDev and FrontPage

Microsoft® Visual InterDev™ and Microsoft® FrontPage® both allow an administrator to control the types of access individual users are permitted on either a site-wide or per-project basis.

Three access levels are available: user access, authoring access, and administrative access. Individuals with user access to a Web project are permitted to browse the project, but may not modify it in any way. Individuals with authoring access are permitted to add, delete and update files from the project, but may not alter permissions for themselves or any other users. This latter capability is available only to someone with administrative access. These security features guarantee that only those individuals who are authorized to make modifications have access to the relevant data.

Because many site replication tools use the Transmission Control Protocol/Internet Protocol (TCP/IP) to transfer information from one computer to another, they have the potential to expose all of a site's information to a sufficiently-motivated individual with a packet sniffer or similar technology. FrontPage and Visual InterDev offer mechanisms for ensuring that data is secure during transfer between servers. FrontPage applies proprietary encoding for all transmissions between the FrontPage client and server, while Visual InterDev employs Secure Sockets Layer (SSL)/Transport Layer Security (TLS) for the same purpose for sites that support it.

Isolating Applications

A system is more secure when you isolate applications. Slightly more memory is used this way, but the server will be less likely to stop if an application stops responding. You can use Internet Service Manager to set a specific application to run in a separate memory space, as an isolated application.

IP Filtering

Most Site Server services can take advantage of the Microsoft® Internet Information Server (IIS) IP filtering feature (also known as logon restrictions or blocklisting). In this way, services can deny access to specific IP addresses, or grant access to only specified addresses. For information about using this feature with the various Site Server services, see the appropriate section of this document.

IIS FTP Service

Unlike most IIS services, the File Transfer Protocol (FTP) service as delivered in IIS 4.0 cannot use the Membership Directory to authenticate users (future Site Server releases will address this problem). However, you can still use the FTP service for anonymous users without needing a separate authentication strategy.

To protect an FTP server while allowing anonymous access 

• If you plan to allow anonymous access to the FTP server, note that FTP sends Windows NT user account information in clear text, which may be visible over the Internet. 

• If your FTP server is configured for anonymous access, advise users to log on by typing anonymous as the account name and their e-mail address as a password to avoid clear-text exposure.

Secure Communications

Secure communication methods encrypt information sent from client to server or between servers. Secure Sockets Layer (SSL)/Transport Layer Security (TLS) encryption can protect most communications. Credit card transactions can also be protected with Secure Electronic Transaction (SET) encryption.

SSL/TLS

Secure Sockets Layer (SSL)/Transport Layer Security (TLS) is a mature security standard designed to provide privacy between two communicating applications by encrypting the entire channel. International SSL/TLS encryption is limited by law to 40 bits. 128-bit SSL/TLS is permitted within the U.S. and Canada. Banking institutions may use 128-bit SSL/TLS internationally.

SSL/TLS resides between HTTP and TCP/IP. With SSL/TLS, all data sent between the server and the browser is encrypted, requiring that both the server and browser support the protocol. Both Microsoft® Internet Explorer and Netscape Navigator currently support SSL/TLS. Any page that contains sensitive information, such as credit card numbers, should use SSL/TLS to protect it from prying eyes. Be aware, however, that HTML pages using SSL/TLS will download more slowly, because the data must be encrypted on the sender's side and decrypted on the client side. Therefore, using SSL/TLS indiscriminately will slow site performance.

For information about implementing SSL/TLS while using the Membership Directory for authentication, see Using Secure Communications in the "P&M" section of the Site Server 3.0 documentation.

Caution Unless your site is configured to use SSL/TLS for all sessions, it may be possible for a customer's cookie to be captured by unauthorized individuals. Although the user logs on using an SSL/TLS-secured page at initial access, when a globally unique identifier (GUID) is issued (in a cookie or a URL), if the remainder of the application is running under a nonsecure protocol, there are opportunities for the user's authorization GUID, encoded in the cookie or the URL, to be detected from those nonsecure pages.

SET

Secure Electronic Transaction (SET) is an Internet protocol developed by a consortium led by MasterCard and Visa. This 56-bit security standard is specific to financial transactions. Rather than encrypting the entire flow of communications, as is done with SSL/TLS, it encrypts only the financial transaction information. After the SET 1.0 specification was released in June 1997, payment vendors initiated interoperability trials. Widespread SET usage is expected in 1998/1999. One challenge to broad SET adoption is the requirement for client-side certificates. The infrastructure and process for issuing these credentials is not well established for consumers. Therefore, it is likely that SET will be first adopted in volume for procurement card-based purchases between businesses.

If you use a payment provider that is compliant with SET, you can encrypt transactions between your Commerce Server-based site and an acquiring financial institution. Consult your payment provider for additional information.

For information about using SET with Commerce Server, see the Microsoft® Site Server 3.0, Commerce Edition documentation.

Virtual Directory Permissions

Microsoft® Internet Information Server (IIS) adds a layer of security on top of the NTFS file security system. NTFS settings determine what permissions are granted by IIS. For example, a directory can be configured in Microsoft® Windows NT® to grant access to everyone, but that same directory can be configured in IIS not to be read or written. Consequently, the file can be accessed locally or through a network (if the directory is shared), but not through a client browser accessing the site through the Web server.

You can use Internet Service Manager to verify or change access permissions on virtual directories, physical directories, or files. You can also use it to verify or change application settings/permissions on virtual directories and physical directories.

Web Site Considerations

For detailed information about Web sites and Web site security, see the Windows NT 4.0 Option Pack documentation.

This section discusses the most important considerations for securing Web sites in a Site Server installation, especially when e-commerce activities and scripts that access secure data are involved.

Monitoring Web Site Activity

IIS offers a variety of logging formats that track Web site activity, showing type of activity, user identity and/or Internet Protocol (IP) address, and various additional data. For information about IIS logs, see the topic Logging Web Site Activity in the "Internet Information Server" section of the Windows NT 4.0 Option Pack documentation.

Secure Techniques for ASP Pages

The Windows NT security context in which any ASP script executes controls what the script is allowed to do, under both Windows NT Authentication and Membership Authentication. A script runs in the context of the current user or as Anonymous, unless credentials (an account name and password) are hardcoded into the script or obtained from the user at run time. The greater the permissions of the user, the greater the permissions of the script.

Scripts can also run outside the IIS process context (Out Of Process mode). In the case of Site Server, Commerce Edition, scripts run in the context of the Microsoft® Transaction Server (MTS) process and use the I_WAM_USER account. The script has the permissions of the account that is used. Account names and passwords hardcoded into scripts are visible in clear text.

For more information about script security, see the white paper Implementing A Secure Site With ASP, at https://www.microsoft.com/isn/techcenter/security.htm .

To prevent an unauthorized user from obtaining sensitive information 

In order to deter an unauthorized user with read access to a script directory from obtaining sensitive account name and password information that is hardcoded into the script, perform the following measures:

• Write scripts to run in the user context or prompt for credentials.

• Only use accounts coded into scripts when there is no alternative, for example, when the script must bind to an external resource such as a remote computer running Microsoft® SQL Server™, the LDAP Service, or a Web server.

• Give access to scripts only to individuals with a legitimate need to have access, such as developers.

To protect against poorly-written or malicious Web pages 

The following precautions pertain especially to Web pages that perform harmless actions when run by a typical user, but perform privileged and unauthorized activity when run by a system administrator.

• When browsing Web pages on a server, be certain that you are logged onto the system by way of a normal user account, and not one that has administrative privileges on that server.

• When using Web pages for administration, do not access the Web pages using an account that has administrative privileges on that server unless you are sure that the pages were authored by a trusted source, have not been modified by unauthorized personnel, and actually require administrative privileges to execute properly.

• Do not allow unauthorized users to post content to your Web site or modify existing Web pages, especially pages used to perform service administration or user management functions. 

• Do not allow Web pages or script files to be posted to your production system without proper approval and control. 

To configure IIS Web sites to use IP filtering 

• IIS Web sites can be configured to reject HTTP requests from specified IP addresses or to accept requests only from other specified addresses. This can be done using Internet Service Manager.

Using a Privileged Account with AUO Scripts 

As with other scripts, scripts that access data using the Active User Object (AUO) run in the context of the current user, unless credentials are hardcoded into the script or obtained from the user at run time. However, with the AUO there is also the option of running as a preconfigured, privileged account. In this case, the account name and password are stored in clear text in the Windows NT registry.

To protect against misuse of the preconfigured account 

The following measures also prevent users from discovering the account by examining the registry.

• Whenever possible, configure the AUO to run in the context of the current user.

• Only use a preconfigured or hardcoded account for the AUO when there is no other choice, for example, when managing a remote Membership Directory under Windows NT Authentication. 

Web Pages with Commerce

Commerce Server sites and Ad Manager sites consist of physical files and directories as well as Microsoft Internet Information Server (IIS) Web applications and virtual directories. Multiple Commerce Server sites can be placed on a single Web site, or each Commerce Server site can exist on a different Web site.

Microsoft® Site Server 3.0, Commerce Edition inherits Secure Sockets Layer (SSL) support by running on top of IIS. Secure Electronic Transaction (SET) support is provided by a number of third parties, providing customer choice among varying vendor implementations and cost recovery models.

For information about encryption pipeline components, see the following topics in the Site Server 3.0, Commerce Edition documentation:

• New Server Platform Features 

• Encryption and Digital signing 

• The Transmit Pipeline 

For information about certificates and encrypted transactions, see the "SET" section in this document, or see the Site Server 3.0, Commerce Edition documentation.

For information about setting security properties in Commerce Server, see the following topics in the Site Server 3.0, Commerce Edition documentation:

• Managing Security in Commerce and Ad Server Sites 

• Modifying the Security Properties of a Commerce Server Site from MMC 

• Modifying the Security Properties of a Commerce Server Site from WebAdmin 

• Site Creation, Operation, and Administration 

• Granting and Revoking Access to Manager Pages from MMC 

• Granting and Revoking Access to Manager Pages from WebAdmin 

• Granting and Revoking Access to Manager Pages from the Command Line 

To prevent theft of credit card information transmitted using GET 

It may be possible for computer vandals to detect credit-card information transmitted using a GET directive on an HTML form. To prevent this:

• Use POST rather than GET for transmitting credit-card information. All Commerce Server sample sites use the POST directive for this purpose. 

To avoid compromising credit card number security in non-SET transactions 

Pipeline logging can compromise the security of credit card numbers in non-SET transactions by writing these values to a file. Therefore, pipeline logging must never be enabled in a production environment.

• Use the SetLog method of the MtsPipeline and MtsTxPipeLine objects only in development or testing environments, as this enables developers to analyze the operations of a pipeline configuration. 

To secure the Order Form from alteration 

• Ensure that an order form has not been altered between presentation of the order and final purchase configuration by using the Page.VerifyWith and Page.ProcessVerifyWith methods. 

The Page.VerifyWith method outputs hidden tags that contain specified values from the OrderForm object. When the order form is submitted, the Page.ProcessVerifyWith method on the target page stores these fields in a Dictionary object in the OrderForm. This is then passed to the order processing pipeline (OPP). One of the components in the OPP compares the original values with the values from the hidden fields. If there is a mismatch, possibly indicating a security breach, an error is displayed to the shopper.

To secure servers hosting multiple Commerce Server sites 

• When hosting multiple Commerce Server sites, you must create a separate data source name (DSN) and database for each site. 

• If you must set up an FTP drop box folder for site operators to leave files on your server, you can set Write-only permission on the folder to ensure site operators cannot see or copy files contained in the folder.

• To avoid clear-text exposure of account information when site operators log on with anonymous access, they must log on by typing anonymous as the account name and typing their e-mail address as a password.

• Use Commerce Server's encryption pipeline components to encrypt order forms when writing them into databases. 

Enabling HTTPS

By default, HTTPS, the Web server security software for Windows NT, is disabled in the Commerce Server sample sites and in sites created with the Commerce Server Site Foundation Wizard. This allows you to create and test sites without causing an error, even on a server where a server certificate is not installed.

To enable HTTPS 

For information about installing a certificate in IIS, see the "SSL" section in this document.

Web Pages with Microsoft Transaction Server

One of the important features of Active Server Pages (ASP) is the ability to invoke components using scripting code. In very high-volume environments, performance and scalability may suffer when many users simultaneously instantiate and release many middle-tier components. Furthermore, building component-based applications where transactions span multiple components has traditionally been beyond the skill level of most developers.

To solve these problems, Microsoft has developed Transaction Server (MTS), a component-based transaction processing system for developing, deploying, and managing high-performance, scalable, and robust enterprise Internet, and intranet server applications. MTS defines an application-programming model for developing distributed component-based applications. It also provides a run-time infrastructure for deploying and managing these applications.

Microsoft Transaction Server also provides a distributed security service that is integrated with Windows NT security, making it easy to prevent unauthorized access to business applications, even if the application includes prebuilt components purchased from third parties.

ASP supports the definition of complex queries for retrieving and updating data. Both also support calling SQL Server stored procedures, which are a pre-compiled collection of Transact-SQL statements. There are a number of circumstances under which it may be preferable to use a stored procedure to perform database operations.

To protect operations that include Microsoft Transaction Server 

• Some large or complex operations may benefit from being accessible only as stored procedures to ensure data security. A complex data operation involving many steps that affect multiple tables can be wrapped up in a stored procedure, allowing for a complete rollback if part of the operation fails. 

Site Server Analysis

For full details about Site Server Analysis and its security capabilities, see the "Site Server Security" and "Site Server Analysis" sections in the Site Server 3.0 documentation.

Data Export Security

The P&M Export ASP file on a Membership Server computer exports user data to a Site Server Analysis server computer or to anybody else who can run the P&M Export ASP file. (Passwords cannot be retrieved by this method.) This file can be easily found and run by any SiteServer Administrators group member or other individual with sufficient rights.

To prevent unauthorized users from retrieving or modifying user data and to prevent denial-of-service attacks 

• Retain tight access control lists (ACLs) on this ASP file (Microsoft Site Server\Bin\P&M\Html\Dsexport.asp), giving the minimal set of permissions to the smallest possible number of accounts. To accomplish this, it is recommended that you create a separate group with read-only access to member objects. 

Scheduled Jobs

Both Direct Mail and Site Server Analysis use scheduled jobs that contain an account name and password in clear text. In the case of Site Server Analysis, this information is stored in a batch file. In the case of Direct Mail, this information is stored in the Direct Mail package. By default, this information is not secured.

The batch file for scheduled imports contains the clear-text copy of the password for PMExport.dll. This file is not secured by default in any way. A user with access to the server where these items reside can easily find them and learn the account name and password. With this password, anyone can gain access to PMExport and retrieve the entire user database. If this is the Administrator account in the Membership Directory or in Windows NT, an individual with access to the Site Server Analysis computer will be able to obtain full administrative privileges.

To protect account information in batch files used for scheduled jobs 

• Do not use administrative accounts for Direct Mail or Site Server Analysis jobs.

• Create new accounts for these jobs that have the minimum permissions required and are not used by real users to log on. If any of these accounts do show up in logs, then you know they are being used improperly. The minimum permissions are Read-only permission in the ou=Admin, ou=exportConfig container and Read-only permission in the ou=Members container. 

• Put Direct Mail and Site Server Analysis on dedicated, physically-secure computers, and restrict access to authorized administrators only. 

• Place ACLs on directories where jobs are deposited, so that only authorized administrators can read/write the directories. 

Site Server Content Deployment Service

Content can be deployed onto end-point production servers in a Web farm using the Microsoft® Site Server Content Deployment Service (CDS). Administrators must minimize the threat of an attack by restricting rights for the Administrator account. They must make certain they have the administrative rights to the server on which that account resides. There must be an account with the same user name and password (shared secret) for replication on each server. This account is used to write content to the slave server. There is an account for the entire server (called the default authentication account), and you may specify an authentication account for each project. Access to files residing on production servers must be more restrictive than on staging servers.

In order to secure your system properly, it is important that you read and understand Securing Your Site in the "Publishing" section of the Site Server 3.0 documentation.

Protecting ACLs During Publishing

Content Deployment allows replication of content files and their access control lists (ACLs) from staging servers to production servers.

The Content Deployment security model is based on the registry. During installation, the files and Web administration pages are put into the Microsoft Site Server directory, wherever that directory is installed. Next, the registry keys are added to HKLM\software\microsoft\crs. There are several default security ACLs that are placed on the registry tree. The local Administrators, local SiteServer Administrators, and local SiteServer Publishing Administrators groups all have Full Control. The local SiteServer Publishing Operators group has Read access. If confidentiality of the deployed content is important, then a separate Virtual Private Networking (VPN) service should be utilized to encrypt the data while in transit.

The Content Deployment service runs as a LocalSystem context. Information used to retrieve name/password for credentials is stored in either the default account registry key (CRS\UserName), or the account registry key for the specific project (CRS\Projects\project name\UserName). Locking down the site requires that you lock down the registry and the content rather than locking down the directories SiteServer or crstemp, which are the working directories for Content Deployment.

Note Before locking down the site or the registry, it is crucial that you read the Windows NT and Site Server 3.0 online documentation. Also see the Securing the Registry section earlier in this document.

Provided they have access to modify the ACLs on the source files, an individual with access to a Content Deployment project on the staging server could intentionally or accidentally modify the ACLs and cause the content to be replicated to production servers with incorrect permissions. An individual could cause a blank directory to be replicated over a full one, or otherwise disrupt the intended content at the production server.

To prevent intentional or unintentional ACL modification 

• Permit only authorized administrators to have access to Content Deployment projects on staging servers and production servers. 

• Secure the content directories to the correct users. 

Encryption for Content Replication

In order to use encryption for content replication, you must set up some BeforeSendScripts to prepare the data, and then an AfterReceiveScript to undo the prepared data when the content arrives. It may also be possible to use a crypto router in between. Or you can use Point-to-Point Tunneling Protocol (PPTP).

Managing Users

To maintain security while managing users, Content Deployment applies ACLs to the registry. The administrator using MMC, Web Administration, or command line administration tools can do this. Based on which ACLs are applied to the registry, users may, or may not, perform a replication. Delegation of administration is enabled at the global and project levels.

For more information, see Securing Your Site in the "Publishing" section of the Site Server 3.0 documentation.

Managing Content

As a failsafe, Content Deployment replications to the root of any drive are not allowed. This is because Content Deployment is a functioning tool, and as such, an unwary user could harm your file structure by creating a project to replicate to a non-optimal location, such as your Windows NT directory. Content Deployment would then replace it with the user's content, thereby deleting most of the Windows NT directory.

However, Content Deployment does allow replication of .cab files that can extract to perform harmful tasks on your system.

To ensure that content is properly protected, Content Deployment can replicate files with ACLs on them. The only caveat to locking down ACLs is that the user context for the replication must have access to the files or the content will not be replicated. This is because a user must start the replication of the files from one computer to another. When that user logs in, the system assigns a user context to the process under which the user logged in. That user must have the appropriate rights and privileges to start the replication and to access all of the files that are being replicated. When the Content Deployment replication starts, the Content Deployment process will impersonate the user context that started the replication. If the user does not have access to a file that needs to be copied, an error will occur.

Ensuring Users Have Proper Access to Functionality and Content

Content Deployment Service (CDS) security is accomplished by controlling the registry and file access. The Site Server Publishers Operators group has read access to the registry, and they have privileges to start replication of projects, but no privileges to modify them. The SiteServer Publishers Administrators group has write access to the registry; they can start replications, and can also add, remove, and modify the projects in the registry. The other option is for a user to have no access to a registry, in which case they will receive an Access Denied message.

Knowing When Your System Is Under Attack

Most attempted attacks will stop at the first set of packets that tries to authenticate the attacker by using Windows NT Challenge/Response Authentication. At this point, the administrator can recognize the attack by failed logins and error messages in the CDS event log.

A programmatic attack could possibly be carried out if a hacker understood the protocol or analyzed the interactions between Content Deployment and Content Deployment for UNIX. If so, they might be able to hack their way through to the UNIX computer, which in turn might give them a valid Windows NT account/password that could give them some level of access to the Windows NT computer. If that happened, then your content and accounts would be in question. This is not very likely to occur, however. Hacking a protocol that is undocumented is not an easy task to undertake, and the protocol is difficult to comprehend, even for the developers with the code in front of them.

To help prevent the problem that such an attack would create, you must ensure that the account you are using for replications has only limited privileges on the source and destination computers.

Troubleshooting

Sometimes a user can connect to and administer the server, but replication fails. This problem generally occurs when the user is an administrator on both the source and the target servers, but the Default Authentication account has insufficient privileges on the destination server. The Default Authentication account must be a member of the SiteServer Publishing Administrators group, and must have write access to the destination directory.

User Connectivity

Check the events log and it will inform you of a connectivity problem, and will also give some recommendations. The Content Deployment documentation also goes into this.

Content Problems

There should not be any content problems, except possibly for Macintosh files, which are unsupported.

User Access Problems

The events log will reveal any user access problems. The administration tools will show these as errors, and the Administrator must then fix the security problem.

Site Server Push

Microsoft® Site Server Push delivers information to users as specified in Channel Definition Files (CDFs). CDFs are managed and information is delivered by Active Channel Server. Information is gathered for delivery by Active Channel Agents (ACAs). Push is a powerful technology that has the capability to deliver not only Web pages, but also embedded or attached files, including software.

Software that damages a user's computing environment may be distributed either maliciously or by accident, through improper behavior or by incompatibility with existing programs. In addition, Channel Agents could select inappropriate material for propagation, possibly due to unintended or deliberately-misleading identifying information set on content. The propagation of improper material through your site could cause embarrassment or more serious problems, possibly including legal liability. Rogue material could induce users to connect to Web sites that impersonate trusted sites, where they could inadvertently disclose sensitive information such as passwords, personal identification numbers (PINs), or credit-card numbers.

For full details on Site Server Push and its security capabilities, see the "Site Server Security" and "Site Server Push" sections in the Site Server 3.0 documentation.

To control the material propagated by Push Active Channel Agents 

Keep the number of authorized Active Channel administrators to a minimum.

• Establish and enforce a clear policy about which sites are approved sources for CDFs, to limit your exposure to malicious, harmful, or otherwise inappropriate material that might be gathered and propagated from external sites. 

• Prevent incorrect configuration of Push jobs by restricting access to CDF files. Do this by removing the Everyone group from CDF file ACLs, or by changing the access granted to Read access. 

• Maintain proper access control over internal sites from which Channel Agents gather material. 

Site Server Search

Microsoft® Site Server Search is protected by the Membership Directory and by Microsoft® Windows NT® ACLs. For full details on Site Server Search and its security capabilities, see the "Site Server Security" and "Site Server Search" sections in the Site Server 3.0 documentation.

Specific difficulties can arise from the security mechanisms available for Site Server Search.

• Users cannot access search results when the search catalog is propagated to a computer other than the Search server computer. 

• The search results appear to return all results even if the user is not authorized for some of the content. When the user attempts to access the URL, the appropriate access controls are applied. However, it would be less confusing to avoid returning such URLs in the first place. 

To ensure that users can access search results that are propagated to a remote computer 

Problems can occur if content protected with ACLs is based on local computer groups that do not exist on the remote computer.

To prevent search results from including URLs for content the user is not authorized to see 

Appendix A

Where to Find More Information

For information about:	See:
How to Use Reverse Proxy with SSL in Proxy Server 2.0	Knowledge Base Article ID: 184030
Additional Proxy Server 2.0 Configurations	Knowledge Base Article ID: 177153
Configuring Server Proxy Parameters	Proxy Server 2.0 online documentation
Enabling 128-bit Encryption for Routing and Remote Access	Knowledge Base Article ID: 169895 The information in this article pertains to: switching from RAS to RRAS
Differences Between 128-bit and 40-bit versions of Service Pack 3 & Service Pack 4	Knowledge Base Article ID: 176820 The information in this article applies to: Microsoft Windows NT Workstation version 4.0 Microsoft Windows NT Server version 4.0 Microsoft Windows NT Server, Enterprise Edition version 4.0
Windows NT System Key Permits Strong Encryption of the Windows NT Directory database	Knowledge Base Article ID: 143475 The information in this article applies to: Microsoft Windows NT Workstation version 4.0 Microsoft Windows NT Server version 4.0
How to Use Proxy Server with Content Replication System	Knowledge Base Article ID: 189746 The information in this article applies to: Microsoft Content Replication System Microsoft Content Deployment Microsoft Proxy Server version 2.0