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."
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.
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.
You can combine several tools to secure your system:
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).
For general information about controlling access to services, see IP Filter Settings for Windows NT at ftp://ftp.microsoft.com/services/isn/ossbss/security/ipFilters.xls.
Consult the following source materials for security information concerning platform products:
Under White Papers:
Under Information by Product:
The concepts described below are important throughout this document.
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.
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:
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:
| 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. |
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.
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.
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.
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.
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 http://www.microsoft.com/ntserver/nts/deployment/planguide/dnswp.asp.
When planning your use of DNS, consider the following:
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 | http://support.microsoft.com/support/kb/articles/q174/0/74.asp
|
| Standard Security Practices for Windows NT | http://support.microsoft.com/support/kb/articles/q166/9/92.asp?FR=0
|
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.
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.
OR
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.
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.
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.
Windows NT provides valuable information about attempts to gain access to Site Server services and files.
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:
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:
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.
Network share permissions provide a second level of access control for a Microsoft® Site Server installation.
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:
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 Q155363.
! 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.
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.
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.
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.
Value Name: RestrictAnonymous
Data Type: REG_DWORD
Value: 1
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:
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.
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.
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.
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.
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.
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:
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.
Do one of the following:
Note The ACLs must be set on the group containers, not just on the group objects themselves.
Note Removing the SUPERBROKER value removes the ACL-bypassing privilege from the Authentication Service accounts. These accounts must then be in the cn=GRPBRKRdirectoryname 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.
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:
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:
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.
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:
For information about configuring IIS to work with SQL Server, see the Microsoft Knowledge Base articles available at http://support.microsoft.com/support.
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.
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).
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.
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.
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.
An intruder could grant bypass-ACL-checking privilege to an account, thereby giving it total control. Use the following to safeguard against this:
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.
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.
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.)
For information about creating databases to work with Commerce Server, see the following topics in the Site Server 3.0 Commerce Edition documentation:
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.
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.)
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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 | http://support.microsoft.com/support/kb/articles/Q189/5/95.asp
The information in this article applies to:
|
| RAS Support for Security Dynamics ACE/Server | http://support.microsoft.com/support/kb/articles/q129/3/00.asp
The information in this article applies to:
|
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.
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.
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:
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).
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:
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.
Windows NT Authentication mode supports the following identification and authentication methods:
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:
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:
For information about the IIS Grant/Deny feature, see the IIS documentation.
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.
For information about using this command, see PMAdmin Set Master in the "P&M" section of the Site Server 3.0 documentation.
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.
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:
Do one or more of the following:
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:
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.
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:
In addition, the following counters provide useful information:
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:
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:
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.
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:
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:
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.
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:
For information about these commands, see the following topics in the "P&M" section of the Site Server 3.0 documentation:
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.
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.
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.
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.
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.
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.
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.
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.
For information about administrative groups, see the following topics in the "P&M" section of the Site Server 3.0 documentation:
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:
When a Membership Directory is created, it is unsecured, although a default set of secure ACLs is provided.
For information about Membership Directory access, see the following topics in the "Personalization & Membership (P&M)" section of the Site Server 3.0 documentation:
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.
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.
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.
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 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.
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.
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.
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.
Most Site Server services can take advantage of the Microsoft® Internet Information Server (IIS) IP filtering feature (also known as logon restrictions or blacklisting). 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.
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.
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.
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.
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.
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.
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.
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.
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 http://www.microsoft.com/isn/whitepapers/security.asp.
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:
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.
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.
The following measures also prevent users from discovering the account by examining the registry.
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:
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:
It may be possible for computer vandals to detect credit-card information transmitted using a GET directive on an HTML form. To prevent this:
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.
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.
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.
This is the same as setting the Site.DisableHTTPS value to zero (0).
For information about installing a certificate in IIS, see the SSL section in this document.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
There should not be any content problems, except possibly for Macintosh files, which are unsupported.
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.
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.
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.
Problems can occur if content protected with ACLs is based on local computer groups that do not exist on the remote computer.
These settings must be consistent with each other. If the individual files allow Everyone to have Full Control yet the file share or Web virtual directory restrict access, the resulting behavior may seem to be inconsistent or undesirable.
| For information about: | See: |
| How to Use Reverse Proxy with SSL in Proxy Server 2.0 | Knowledge Base Article ID: Q184030 |
| Additional Proxy Server 2.0 Configurations | Knowledge Base Article ID: Q177153 |
| Configuring Server Proxy Parameters | Proxy Server 2.0 online documentation |
| Enabling 128-bit Encryption for Routing and Remote Access | Knowledge Base Article ID: Q169895 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: Q176820 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: Q143475 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: Q189746 The information in this article applies to: Microsoft Content Replication System Microsoft Content Deployment Microsoft Proxy Server version 2.0 |
Information in this document, including URL and other Internet web site references, is subject to change without notice. The entire risk of the use or the results of the use of this resource kit remains with the user. This resource kit is not supported and is provided as is without warranty of any kind, either express or implied. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 1999-2000 Microsoft Corporation. All rights reserved.
Microsoft, FrontPage, Outlook, Visual InterDev, Windows and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries/regions.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Additional Disclaimer
NOTICE REGARDING INFORMATION AND SERVICES AVAILABLE IN THIS DOCUMENT. In no event shall Microsoft, and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of any guidelines, documents, provision of or failure to provide services, or information available from this document.