Microsoft Commerce Server 2000: Site Deployment

During the Deployment phase, you install hardware and software and then test performance against the criteria set in the Planning and Development phases. The following personnel should be involved in the deployment phase:

• Site developers

• Testers

• System administrators

You deploy your site using the Project Goals and Requirements and Project Plan documents that you created during the Planning phase. Figure 14.1 shows a high-level view of the deployment process.

 

Figure 14.1 Deployment phase 

During the Deployment phase, you perform the tasks listed in the following table.

Task	Consists of
Implement your contingency plan	Implementing the initial phases of your contingency (or risk management) plan. For example, you identify the data that you need to back up for a full recovery.
Deploy your site	Installing the hardware and software required to run the Web site, deploying your platform software, installing Microsoft Commerce Server 2000, deploying Commerce Server features, and unpacking your application.
Secure your site	Securing your Commerce Server files, Commerce Server Business Desk, and databases and implementing the Commerce Server authentication method for your site.
Test your site environment	Testing the recovery time of your hardware, verifying your backup services are running, and testing that the failover configuration works.
Finalize your site environment before production	Removing extra logging that you used for debugging purposes, performing a final audit of the hardware and software, verifying that the current configuration is documented, and determining the process the deployment team will use to resolve problems when the site goes live.
Set up and perform initial operational procedures	Holding daily meetings with the development, test, and deployment teams to make sure the site is behaving as expected, revisiting the usage profile to determine how users are actually using your site, and performing initial backup and recovery testing of the production site.

The Deployment section of this book contains the chapters listed in the following table.

Chapter	Title	Description
14	Deploying Your Site	Deployment checklists How to implement your risk management plan How to deploy your site, including its architecture, hardware, and software How to secure your Commerce Server site, including how to implement Commerce Server authentication How to finalize your site environment before production How to perform initial operational procedures
15	Deploying Content	Deployment tools How to deploy content using Microsoft Application Center 2000 Examples illustrating how to use deployment tools in three different sites: small-to-medium, medium-to-large, and global Examples illustrating how to deploy the following types of content: campaigns, campaign items, expressions, COM+ applications, and databases
16	Testing Your Site	A general methodology for testing software Specific information about testing your Commerce Server site

Deployment Checklists

Before you deploy your site, review the following checklists to ensure that your planning is complete:

• Site architecture checklist

• Availability checklist

• Site development and testing checklist

• Business process checklist

• Platform security checklist

• Commerce Server security checklist

Each checklist is described in the following topics.

Site Architecture Checklist

Before you deploy your site, make sure you have planned and implemented your site architecture. Check for the following:

• A Microsoft Windows 2000 Server network is in place, containing at a minimum one Microsoft Active Directory domain controller. Windows 2000 Advanced Server is recommended if you are using Network Load Balancing or creating server clusters, both of which increase the availability of your site.

  Ideally, you need two computers to handle Active Directory efficiently. They would serve as replicated domain controllers. Your other computers would then join the domain.

• The Windows 2000 domain architecture for the Commerce Server servers has been determined and is documented.

• Server names, roles, ports, and required services are identified and documented.

  If possible, do not change the names of your servers.

• The necessary Internet domain names and Internet Protocol (IP) addresses have been obtained.

• Windows 2000, Internet Information Services (IIS) 5.0, and Microsoft SQL Server security models have been determined.

• Internet Explorer version 5.0 or later is installed. Business Desk client computers require Internet Explorer 5.5.

• Firewalls and proxy servers are in place.

• Initial users, groups, permissions, and policies are set up.

• Server hardware is installed at the site.

• Client hardware for Business Desk client computers is installed at the site.

• Network hardware and connections are in place and connectivity to the Internet has been established.

• Replacement hardware is available at the site.

• Windows 2000 Terminal Services has been set up, if you plan to use remote computers for Business Desk sessions.

Availability Checklist

Before you deploy your site, make sure you have planned for protecting against server failure using a combination of the following methods:

• Geographically dispersed data centers.

• Dual uninterruptible power supplies (UPSs).

• Data backups.

• Clustered database servers. In Windows Clustering, two servers sharing common data form a cluster that works as a single system.

• Data replication. Microsoft SQL Server replication is used to ensure synchronization among the database servers for a site. SQL Server offers replication options that include snapshot replication and transactional replication.

• Network load-balanced clusters for Web servers. Network Load Balancing provides availability and load balancing for Web (IIS/ASP-based) applications.

For additional information about high availability, see Chapter 6, "Planning for Reliability and High Availability."

Site Development and Testing Checklist

Before you deploy your site, make sure you have completed your site development and testing. Check for the following:

• Site development is complete.

• The site is packaged.

• A list of site resources has been documented.

• Names have been determined for site servers.

• Database names, user names, and passwords have been determined.

• Testing is complete. You have tested for the following items:

  • Browser compatibility

  • Content

  • Databases

  • Data validity and integrity

  • Links

  • Performance

  • Query response time

  • Routers

  • Search options

  • Server load

  • System recovery

  • Visual consistency

  You have tested the performance of your site using the Microsoft Web Application Stress (WAS) tool.

• An independent, outside company has completed a security audit of your site. Such a review is an effective means for discovering security risks.

For more information about testing your site, see Chapter 16, "Testing Your Site."

Business Process Checklist

Before you deploy your site, make sure you have planned and implemented your business processes. Check for the following:

• Workflows have been determined and tested.

• System administrators have received initial training and business managers, the primary users of Business Desk, have completed the Business Desk tutorial or have received other training that covers the specific tasks they are to perform using Business Desk.

• The server environment team has been identified and operational procedures have been determined (for example, change request, change control log, server update, maintenance schedules, and problem escalation procedures).

Platform Security Checklist

The platform security checklist addresses the following topics:

• Windows security

• IIS security

• Physical security

• Personnel security

Windows Security

The security features in Commerce Server are built upon security features in Windows 2000. For more information about Windows 2000 security, see Microsoft's security Web site, located at https://www.microsoft.com/technet/security/tools/default.mspx.

The following tables contain information about the tasks you should perform to configure security settings in Windows to help make your Web site more secure.

File System 

You can use the tasks listed in the following table to make your file system more secure.

Task	Reason
Use NTFS	The NTFS file system (NTFS) is more secure than the file allocation table (FAT) system. For information about converting your computer's hard disk from FAT to NTFS, see Windows 2000 Server Help.
Review directory permissions	By default, Windows creates new folders and assigns Full Control permissions to the Everyone group.
Set access control for the IUSR_<computer name> account	Setting access control for this account will help limit the access anonymous users have to your computer.
Store executable files in a separate directory	Storing executables in a separate directory makes it easier to assign access permissions and auditing.
Check NTFS permissions on network drives	By default, Windows creates new shared resources and assigns Full Control permissions to the Everyone group.

User Accounts 

You can use the tasks listed in the following table to make your user accounts more secure.

Task	Reason
Review user accounts often	Check for new accounts that were not created by a valid administrator. Review the rights given to the IUSR_<computer name> account. All users gaining anonymous access to your site have their rights assigned to this account. You can also use auditing to monitor when and who changes security policies.
Choose difficult passwords	Passwords are more difficult to guess if they consist of a combination of lowercase and uppercase letters, numbers, and special characters.
Maintain strict account policies	Keep track of what types of access are given to important user accounts and groups. This includes knowing who has the ability to change security policies.
Limit the membership of the Administrators group	This group typically has full access to the computer.
Assign a password to the Administrator account	By default the password used for the Administrator account is blank. To improve security, set a difficult password for this account, as discussed previously.

Services and Other Issues 

You can use the tasks listed in the following table to make your services more secure and to address other security issues.

Task	Reason
Run minimal services	Run only the services that are absolutely necessary for your purposes. Each additional service that you run presents an entry point for malicious attacks. For more information about services and security, see the Microsoft Windows 2000 Server Resource Kit.
Do not use PDC as a server	The primary domain controller (PDC) is constantly processing authentication requests. Running a Web service on the PDC decreases performance. It could also expose your PDC to attacks that could render your entire network non-secure.
Enable auditing	Auditing is a very valuable tool for tracking access to secure or critical files. You can also use auditing for tracking server events, such as a change in your security policy. You can archive audit logs for later use.
Use encryption if administering your computer remotely	Typically, remote administration involves the exchange of sensitive information, such as the password for the Administrator account. To protect this information over open networks, use Secure Sockets Layer (SSL) encryption.
Use a low–level account to browse the Internet	Using the Administrator, Power User, or another highly privileged account to browse the Internet can potentially open entry points on your computer for attack. Likewise, never browse the Internet from the PDC.
Back up vital files and the registry often	No security effort can guarantee data safety. For more information, see the Microsoft Windows 2000 Server Resource Kit.
Run virus checks regularly	Any computer on an open network is susceptible to computer viruses. Regular checkups can help avoid unnecessary data loss.
Unbind unnecessary services from your Internet adapter cards	Caution Be sure to check with your system administrator before unbinding services, because this could have unwanted effects on other users of your system.

IIS Security

IIS provides frontline security for your Web site, including authentication and Web permissions. The following tables describe tasks you can perform for authentication and Web permissions.

Authentication 

You can use the tasks listed in the following table to make your IIS authentication more secure.

Task	Reason
Use the most secure form of authentication possible	Use the most secure form of authentication that your clients support. For example, Integrated Windows authentication (NTLM) and Digest authentication are more secure than Basic authentication. You can also use client certificates for highly secure authentication.
One-to-one mapping versus many-to-one mapping	You can use either or both of these methods to map client certificates to Windows user accounts. One-to-one mapping offers a higher level of certainty, but requires a copy of the client certificate to be stored on the server. Many-to-one mapping is easier to implement and does not require a copy of the certificate to be stored on the server.

Web Permissions 

You can use the tasks listed in the following table to make your IIS Web permissions more secure.

Task	Reason
Synchronize Web and NTFS permissions	If Web permissions and NTFS permissions are not synchronized, the more restrictive of the two is used. You can synchronize these permissions manually or use the Permissions Wizard.
Use IP address restriction if you are administering IIS remotely	For more information, see "Granting and Denying Access to Computers" in the IIS 5.0 online documentation.
Use the most restrictive permission possible	For example, if your Web site is used only for viewing information, assign only Read permissions. If a directory or site contains Active Server Pages (ASP) applications, assign Scripts Only permissions instead of Scripts and Executables permissions. For more information, see "Setting Web Server Permissions" in the IIS 5.0 online documentation.
Write and Scripts and Executables permissions	Use this combination with extreme caution. It can allow someone to upload potentially dangerous executable files to your server and run them. For more information, see "Setting Web Server Permissions" in the IIS 5.0 online documentation.

Physical Security

You can use the tasks listed in the following table to implement physical security for your site.

Task	Reason
Lock the computer when you are away	When you are not at the computer, lock the desktop by pressing CTRL+ALT+DELETE, and selecting Lock Computer.
Use a password-protected screen saver	The time delay should be short so that no one can use the computer after you leave. The screen saver should be blank; animated screen savers can decrease server performance.
Lock up the computer	Keep the computer locked in a secure room in order to reduce the chance of access by malicious individuals.

Personnel Security

You can use the tasks listed in the following table to secure the appropriate levels of access for your site development and management personnel.

Task	Reason
Use different Administrator accounts	Each individual who has administrative privileges should be given a distinct user account and password. Using distinct user accounts and passwords will make it easier to track any changes that are made.
Use non-disclosure agreements	Using non-disclosure agreements can enforce further accountability by your personnel.
Periodically reassign accounts	To lower the risk of user account information being compromised, assign new user accounts to personnel with Administrator or other high-level privileges.
Quickly delete unused accounts	This will lower the risk of a disgruntled former employee or vendor gaining access to your network.

Commerce Server Security Checklist

Before you deploy your site, make sure you have planned and implemented your site security.

Use the following guidelines when setting up security for your site:

• Whenever possible, install IIS 5.0 and SQL Server on separate computers. Having users connect to the computers that store your databases presents security risks to your data. You should keep Web applications and databases on separate computers.

• Always keep sensitive data secure behind a firewall.

Use the following deployment guidelines to protect your site from internal attacks:

• Restrict physical access to all computers.

• Restrict the number of users logged on to all computers; give users only the minimum necessary privileges needed to get their work done.

• Change passwords frequently, especially after someone leaves your organization.

• Keep logs of all system activity and review them frequently.

• Keep all backups in a secure place.

• Use the Commerce Server CS Authentication resource to establish or change the authentication and identification method for your Commerce Server site.

Implementing Your Contingency Plan

A contingency (or risk management) plan describes preparations for events that could interrupt e-business services. An interruption could be caused by an event that ranges in severity from an application, system, or network failure to a complete loss of a business location.

The possible disasters that your contingency plan should cover include:

• Fire, sabotage, and theft

• Flood, natural disaster, pest damage, and building damage

• Industrial action and accidental damage

• Equipment loss or failure—computing, network, or environmental controls

• Software failure

• Data loss or corruption

Contingency planning uses risk management principles to identify threats to service, such as equipment failure or fire. Introducing countermeasures, such as an alternative network link, can eliminate vulnerable areas of the service design to limit the impact of a threat to your site. In the event of a major threat, the contingency plans for service continuity must provide the facilities, information, and procedures for a full recovery of service.

Technical Solutions for Risk Reduction

When you develop the technical solutions required for contingency planning, you must spend time reviewing your existing infrastructure to assess the risk of its failure. Where possible, make changes to the production environment to reduce risk. An e-commerce solution should not include any systems that are vulnerable to a single point of failure. Also, applications developed for e-commerce service should be designed to use technologies that allow for component failure or damage.

The design solutions considered here can help reduce risk and improve service availability. Because it is impossible to eliminate all risk, a contingency plan is an essential part of the overall risk management solution.

This section explains how you can use the following technologies in an e-commerce installation to reduce risk:

• Network Load Balancing

• Application Center COM+ Load Balancing (CLB)

• Windows Clustering

Network Load Balancing

Windows 2000 Network Load Balancing enhances the availability and scalability of Commerce Server applications. By combining the resources of two or more Web servers into a single load-balancing cluster, you can deliver a more reliable Web site.

Each server runs separate copies of your Commerce Server applications. Network Load Balancing balances the workload among servers by allowing the group of them to be addressed by the same set of cluster IP addresses.

You can use any of the following programs to install Network Load Balancing:

• Application Center

• Windows 2000 Advanced Server

• Windows 2000 Datacenter Server

Network Load Balancing provides a good solution to scale and mitigate the risk of a single failure in a front-end system that does not hold changing data. Network Load Balancing offers a good solution for front-end Web servers and front-end reverse proxy servers.

For information about installing Network Load Balancing, including hardware requirements, see the documentation for the product you will use for the installation.

Application Load Balancing

Application Center is designed to increase the scale, size, and availability of Web-based applications. Application Center builds onto the functionality of Network Load Balancing to increase the availability of application components.

Application Center ties the application components together in an application cluster. COM+ Load Balancing (CLB) distributes the workload across multiple servers running a site's business logic. It complements both Network Load Balancing and the Cluster service by acting on the middle tier of a multi-tiered clustered network, as discussed here, separating COM+ components into a middle tier.

Because the applications are tied together, the front-end server gets equal response from the back-end components. If any one of the application component servers were to fail, the other servers would share the load of the failed server. The application, not the computer, is being clustered.

This architecture splits the content servers (the front-end servers) from the application components and the data engines. It also separates the application components from the data engines.

Windows Clustering

While Network Load Balancing and Application Center mitigate risk for the Web server and Commerce Server layer, the failover clustering features in Windows Clustering mitigates the risk of using back-end services, such as SQL Server.

Failover clustering increases server availability. When a server fails, clustering allows the system to automatically switch the processing for a service to a working server. (Failover handles failed processors, motherboards, power supplies, and memory, but does not take failed disk arrays into account.) For example, an instance of SQL Server can quickly restore database services to a Web site or enterprise network even if the server running the instance fails.

Cluster Topology

Windows Clustering supports two-node failover clusters in Windows 2000 Advanced Server and four-node clusters in Windows 2000 Datacenter Server. The following three connections connect the servers together:

• Small computer system interface (SCSI) connection (each computer shares the same clustered disk array)

• Heartbeat network, second local area network (LAN) connection

• Standard LAN connection

The system is set up so that each application does not share resources with any other application, but takes over the resources of a failed processor unit.

Only one server can access a shared disk drive at any one time. If, for example, processor Unit One should fail, processor Unit Two takes over that role and the application.

For more information about Windows Clustering, see the Microsoft Windows NT Server, Windows 2000 Server, Windows 2000 Advanced Server, or Windows 2000 Datacenter Server documentation.

SQL Server Failover Clustering

The type of Windows Clustering failover cluster used by SQL Server 2000 consists of multiple server computers (up to four on Windows 2000 Datacenter Server) that share a common set of cluster resources, such as disk drives. Each server in the cluster is called a node. Each server, or node, is connected to the network, and each node can communicate with each other node. Each node runs the same version of Windows Clustering.

The shared resources in the failover cluster are collected into cluster groups. For example, if a failover cluster has four clustered disk drives, two of the drives can be collected in one cluster group and the other two in a second cluster group. Each cluster group is owned by one of the nodes in the failover cluster, although the ownership can be transferred between nodes.

Applications can be installed on the nodes in the failover cluster. These applications are typically server applications or distributed Component Object Model (DCOM) objects that users access through network connections. The application executables and other resources are typically stored in one or more of the cluster groups owned by the node. Each node can have multiple applications installed on it.

The failover cluster nodes periodically send each other network messages called heartbeat messages. If Windows Clustering detects the loss of a heartbeat signal from one of the nodes in the cluster, it treats the server as a failed server. Windows Clustering then automatically transfers the cluster groups and application resources of that node to the other nodes in the network. The cluster administrator specifies the alternate nodes to which cluster groups are transferred when any given node fails. The other nodes then continue processing user network requests for the applications transferred from the failed server.

Deploying Your Commerce Server Site

This section describes how to deploy the following aspects of your site:

• Site architecture

• Site platform software

• Commerce Server software

• Commerce Server features

Deploying Your Site Architecture

The site architecture specifies:

• The hardware you are using.

• The software that is installed on each computer and in which order.

• How the computers are connected together and which ports are open.

• How your hardware and software is secured.

During the Planning phase, you determine your hardware, software, and networking requirements, and document them in a site architecture diagram. During the Deployment phase, you deploy and test the site architecture.

When you deploy your site architecture, it is important that you document any changes that you make to the hardware or software configuration. This information must be accurate and immediately available at all times in order for your team to efficiently troubleshoot problems. In addition, this information will be helpful to new system administrators, testers, and developers who work on your site.

Figure 14.2 shows the hardware and software architecture for a small-to-medium size site.

 

Figure 14.2 Small-to-medium site hardware and software architecture 

This architecture diagram shows a basic Web service available to the Internet. The failover clusters take into account contingency planning requirements. The firewalls provide basic security; however, it is recommended that you create a separate network security architecture.

Installing Hardware and Software

First, you install the hardware and software you need to run the Web site, and also install the hardware you need to administer the site, such as computers for monitoring performance and network sniffers.

You install and configure the hardware and software as specified in your site architecture diagrams. Document all software, service packs, and hotfixes you install on each computer. If you need to make changes, be sure to update the site architecture document so you have a record of your current configuration. This information will be critical during the testing stage and when you are troubleshooting your site.

For instructions for installing Commerce Server and prerequisite software, see https://support.microsoft.com/support/commerceserver/2000/install/default.asp .

For detailed examples of installing Commerce Server in a multi-computer deployment, see the following topics in "Installing Your Site" in the "Deploying Your Site" section of Commerce Server 2000 Help:

• "Example A: Installing on a Four-Computer Clustered Configuration"

  This topic explains how to install Commerce Server and unpack applications on a four-computer configuration consisting of:

  • Two Web servers in a Network Load Balancing cluster. These servers also contain the Commerce Server administration tools.

  • Two SQL Server servers configured as a single server cluster. These servers are referred to by their shared cluster name.

• "Example B: Installing on a Three-Computer Non-clustered Configuration"

  This topic explains how to install Commerce Server and unpack applications on a three-computer configuration consisting of:

  • One SQL Server server (used for the Commerce Server Administration database).

  • One SQL Server server used for the Commerce Server databases.

  • One Web server that hosts your applications.

Deploying Site Platform Software

This section contains information about deploying Application Center and Active Directory in your site platform environment.

Application Center

To make Application Center aware of the Commerce Server applications, including Business Desk, you must access each Commerce Server application (Web site) manually on each Web server (by computer name) with the browser.

Active Directory

You can use the following deployment information when you include Active Directory in your site.

Commerce Server Does Not Extend Active Directory Schema

If you are using Active Directory for user profiles, note that Commerce Server does not extend the underlying Active Directory schema because changes to the Active Directory schema are irreversible.

To review the mapping of profile definition properties to Active Directory attributes, see the ProfileAD_SQL.xml file that is installed with Commerce Server.

Limit User Names to 20 Characters

A Windows logon_name must be used to create a user in Active Directory; the maximum length of that name is 20 characters. This enables backward compatibility with Windows NT 4.0.

If your site does not allow e-mail names longer than 20 characters, then you can permit users to use their e-mail name as their logon name.

Deploying Commerce Server Software

This section contains information about installing, packaging, and unpacking your Commerce Server application.

Installing Commerce Server

You can use the following deployment information when you install Commerce Server.

Commerce Server Requires SQL Server

Commerce Server requires SQL Server 7.0 or SQL Server 2000. You can use an Oracle database in addition to SQL Server, but you cannot use Oracle in place of SQL Server.

You must store design-time information (for example, the profile definition store and the catalog design-time tables) in a SQL Server database. For the Profiling System only, you can store run-time information exclusively in an Oracle database. For all other Commerce Server components, you must store run-time information in a SQL Server database.

The Product Catalog System requires the full-text search feature of SQL Server. The Administration and Commerce Server Direct Mailer databases use SQL Server, and the Business Analytics System uses the data warehousing capabilities of SQL Server.

The Commerce Server 2000 OLE DB provider supports any data source that either conforms to LDAP-v3 protocol or has an OLE DB provider with support for specified interfaces and ANSI SQL support.

SQL Server Servers in a Different Domain than Web Servers

If your SQL Server server is in a different domain than your Web server (for example, they are separated by a firewall), you must open a security context between the Web servers and SQL Server servers in the two domains. Use the Net use command on a resource on the SQL Server server from the Web server.

For example, type Net use * <\\<computer name>\<share name> /U:<domain name>\<user name>. You will then be prompted for a password.

To use the Net use command over a secure channel, use ipc$. For example, type net use * <\\computer1 name\ipc$> /U:<domain1 name>\joeuser.

Host Names

Commerce Server by default uses the computer name of the first computer installed in an Administration database* *as the host name in Uniform Resource Locators (URLs) generated in sites. Typically, you will want to change the host name so that Commerce Server uses a Domain Name System (DNS) host name, for example, www.microsoft.com.

For information about setting the non-secure and secure host names, see "Renaming an Application" in the "Managing Commerce Server Applications and Web Servers" section of Commerce Server 2000 Help.

Packaging Your Application

When the development team is finished developing and testing the application, they package it into a Commerce Server Site Packager file (with a .pup extension). You can then unpack and deploy the application in a multi-computer environment. This section contains information about what data and settings are included when an application is packaged.

Resources and Data

The following table lists the resources and the data packaged in a Site Packager file.

Resource	Data packaged
App Default Config	All property values.
Campaigns	The following tables in the Campaigns database: IndustryCode, Customer, EventType, Campaign, CreativeType, CreativeSize, Creative, CreativeProperty, Creative_PropertyValue, CampaignItemTypes, CampaignItem, OrderDiscount, DmItem, AdItem, CreativeTypeXref, PageGroup, PageGroupXref, TargetGroup, Target, TargetGroupXref, OrderDiscountExpression, OrderDiscountMisc.
CS Authentication	Settings in the AuthSetup.ini file. When you unpack a site, you can create a new resource or point to an existing one.
Commerce Server Data Warehouse	None. When you unpack a site, you can create a new Data Warehouse resource or point to an existing one.
Direct Mailer	None. Confirms the existence of Direct Mailer in the site. Which Direct Mailer global resource to use is specified during unpacking. When you unpack a site, you can point to a Direct Mailer resource. You must use Commerce Server Setup to create a new one.
Predictor	None. Confirms the existence of a Predictor resource in the site. Which Predictor global resource to use is specified during unpacking. When you unpack a site, you can point to a Predictor resource. You must use Commerce Server Setup to create a new one.
Product Catalog	The following tables in the Catalogs database: CatalogAttributes, CatalogDefinitions, CatalogDefinitionProperties, CatalogGlobal, CatalogUsedDefinitions, CatalogEnumValues, CatalogStatus, CatalogCustomCatalogs, CatalogCustomPrices, CatalogSet_Info, CatalogSet_Catalogs, CatalogToVendorAssociation, x_ProductsComplete, x_Relationships, x_Hierarchy.
Profiles	Schema script and data script. Defaults are <commerce_server_root>\Profilesql.sql and <commerce_server_root>\PopulateProfileSql.sql, respectively. Existing databases are not packaged. When you unpack a site, you can create a new resource or point to an existing one.
Transactions	The following tables in the Transactions database: TransDimension, TransCategory.
Transactions Config	The following tables in the Transactions Config database: Decode, Region, RegionalTax, ShippingConfig, TableShippingRates.

IIS Settings

When you package a site, Site Packager includes many of your IIS settings. It does not package an IIS Web Site (such as Default Web Site), but it does package the files in the physical root folder of the application and all of its physical child folders and files.

To view IIS settings for an application, folder, or file 

1. Click Start, point to Programs, point to Microsoft Commerce Server 2000, and then click Commerce Server Manager.

2. In the Commerce Server Manager window, expand Internet Information Services, expand the name of the Web server containing an application, expand the name of the IIS Web site in which the application resides, right-click the name of an application, folder, or file, and then click Properties.

The Properties dialog box for the application appears.

The following tables list the settings for the Virtual Directory and Directory Security tabs in the Properties dialog box, and indicate which ones are packaged when you use Site Packager.

Virtual Directory Tab 

Field	Whether it is packaged
Script source access	Packaged
Read	Packaged
Write	Packaged
Directory browsing	Packaged
Log visits	Packaged
Index this resource	Packaged
Application name	Not packaged
Starting point	Not packaged
Execute permissions	Packaged
Application protection	This is always set to Medium when unpacking
Application Configuration settings (shown after Configuration is clicked)	Not packaged

Directory Security Tab 

Field	Whether it is packaged
Anonymous access	Packaged
Anonymous access account	Not packaged
Basic authentication	Packaged
Basic authentication domain	Not packaged
Digest authentication	Packaged
Integrated Windows authentication	Packaged
IP addresses and domain name restrictions	Not packaged
Secure communications (SSL certificates)	Not packaged

Note Nothing in the Documents, HTTP Headers, and Custom Errors tabs is packaged. The Unpack.vbs script file for Business Desk adds custom errors for Business Desk after unpacking.

IIS Virtual Directories 

If you have virtual directories located within the application, the virtual directory object and the folders and files in the path it points to will not be packaged. If you want to package these folders and files, copy them to a folder in the physical path of the application before packaging them.

NTFS Permissions 

NTFS permissions and access control lists (ACLs) on folders and files are not packaged. You can use the Unpack.vbs script (or create a Post*<package name>*.vbs script) to apply NTFS permissions automatically after unpacking.

Unpacking Your Application

After your hardware and software are installed, you deploy your Commerce Server application on the test computers. To move the Commerce Server application from the development environment to your test and production environments, you use Site Packager. The site developer packages the Commerce Server application on the development environment, including IIS 5.0 settings (metabase), file system, resources from the Administration database, and SQL Server databases.

When you unpack the application, you unpack the Commerce Server site (or portions of it) onto other computers.

Two global resources—Predictor and Direct Mailer—are installed by using Commerce Server Setup; all other global resources are installed using Site Packager. Before you unpack a site that requires the global resources Predictor or Direct Mailer, you must use Commerce Server Setup to install them.

In most cases, you use Site Packager for the initial deployment of your site. For future deployments, incremental updates, and rollbacks, use other tools, such as Application Center or other content management products. For information about deploying content, see Chapter 15, "Deploying Content."

Site Packager

You can refer to the following deployment information when you use Site Packager.

Install Resources Before Unpacking

You must install resources before you can unpack them. For example, if you have installed the Predictor resource, you can unpack it when it is part of a package. If you do not install the resource, it will unpack, but it will not work.

Do Not Unpack to Remote Servers

Site Packager does not unpack application data to remote servers. However, you can unpack resources to remote servers.

For example, if you have the Retail Solution Site on one computer and the Business Desk application on another computer, you must package each of these separately, creating two packages, and unpack them separately.

Packaging Extended Profile Schemas

Site Packager doesn't automatically package extended profile schemas. You must create an SQL script before packaging your site, and then supply your script when prompted during the packaging process.

When you package an application, the IPuP object for Profiles copies data into the package in the following order:

1. Profile definition schema (from the profile definition store of the site) in the form of Extensible Markup Language (XML).

2. CatalogSchema.sql from the Commerce Server root.

3. If the data store is SQL Server, it prompts you for the user data and data store schema script files.

4. If the data store is Active Directory, it prompts you for the data population script file.

5. Site terms definition schema in the form of XML.

In Steps 3 and 4, if you don't supply any file names, you will receive a warning message. If you dismiss the warning message, the corresponding files are not copied into the Site Packager package.

The same IPuP object also copies the following expression store files into the Site Packager package:

• The expressions defined, streamed out in the form of XML

• The Es_create.sql and Es_stored_procs.sql files from the Commerce Server root directory

Deploying Commerce Server Features

This section contains information about deploying the following Commerce Server features:

• Product Catalog System

• Direct Mailer

• Profiling System

• Data Warehouse

Product Catalog System

You can use the following deployment information when you use the Product Catalog System.

Create CommerceCatalogs Shared Folder

To enable business managers to import and export catalogs using Business Desk, it is recommended that you create the CommerceCatalogs shared folder on the server. If business managers use the CommerceCatalogs share, they will not have to specify the complete path and file name to perform a catalog import or export.

Maximum Number of Product Catalogs

SQL Server 2000 (or SQL Server 7.0, depending on your implementation) determines the maximum number of product catalogs you can create. Commerce Server uses one SQL Server full-text catalog for each Commerce Server product catalog.

There is a SQL Server limitation of 256 full-text catalogs per server. However, you can have multiple tables in one SQL Server full-text catalog, and the tables are full-text searchable.

There is no limit to the number of category hierarchies you can create in a catalog.

No Sharing Product Data Across Catalogs

To have a product appear in multiple catalogs, you must manually add the product data to each catalog. You cannot share product data across catalogs.

Sharing Catalogs Across Sites

To share a product catalog with more than one Commerce Server site, you can create and manage the catalog in one site. Then on other sites, you can set the connection string for the Product Catalog resource to point to the Catalogs database.

Note You cannot make the Product Catalog resource a global resource.

Name Restrictions for Catalogs

In Commerce Server product catalogs, at the application level (Business Desk), note the character restrictions for the following properties:

• Property Definition Name. Do not use the characters /, <, >, &, (, and ). Also, a numeral is not allowed in the first position. Do not use characters that are not accepted in an XML tag name.

• Product Definition Name. No restrictions.

• Category Definition Name. No restrictions.

• Category Name. Do not use the characters <, >.

• Catalog Name. Do not use the characters <, >, [, ], and apostrophe (').

• Custom Catalog Name. Do not use the characters <, >, [, and ].

In the Catalog application programming interface (API), note the character restrictions for the following properties:

• Property Definition Name. Do not use the characters [, ], comma (,), and double quotation mark (").

• Product Definition Name. No restrictions.

• Category Definition Name. No restrictions.

• Category Name. No restrictions.

• Product Name. No restrictions.

• Catalog Name. Do not use the characters [, ], comma (,), double quotation mark ("), and apostrophe ('). Also, a Catalog Name should not begin with the number sign (#).

• Custom Catalog Name. Do not use the characters [, ], comma (,), double quotation mark ("), and apostrophe ('). Also, a Custom Catalog Name should not begin with the number sign (#).

Importing Product Variants

When you import a catalog with product variants, you must use XML to preserve your variants. Comma-separated value (CSV) files do not support product variants.

Creating Categories with the Same Name

To create categories with the same display name, first create a property definition called Display Name. Then add the property definition to the category definition.

Implementing Order Fulfillment

If multiple vendors supply the products on your site, you can use the Splitter component in Commerce Server to divide an order among the appropriate vendors. When a user selects a product, it will be sent to the correct vendor for fulfillment.

The Splitter component divides an order into groups based on a list of item keys. For example, in the Accept stage, the Splitter component can be used to divide orders by catalog and vendor; in the Shipping stage it can be used to divide an order into shipments by shipping methods and addresses.

Direct Mailer

Refer to the following deployment notes when you use Direct Mailer:

• Direct Mailer cannot be installed on a SQL Server cluster.

• Direct Mailer requires SQL Server to be installed locally.

• Direct Mailer can process one million mails per day, 5 KB in size, personalized. It can process up to one million personalized messages in 24 hours.

• Direct Mailer can process one million mails per day, 5 KB in size, non-personalized. It can process up to two million non-personalized messages in 24 hours.

Profiling System

You can refer to the following deployment information when you use the Profiling System.

Multivalued Properties

Multivalued properties are able to store more than one value. However, you cannot search on multivalued properties.

The way the underlying store handles multivalued properties depends on whether the store is Lightweight Directory Access Protocol (LDAP) or ANSI SQL. Consider the following:

• LDAP stores such as Active Directory support multivalued properties; Commerce Server provides no special processing.

• ANSI SQL stores such as SQL Server 2000 do not natively support multivalued properties. In this case, the provider handles multivalued properties by appending all values together separated by semicolons and stores them in a single column. This is transparent to the user.

Note the following requirements for storing multivalued properties in ANSI SQL stores:

• Only string properties can be multivalued; multivalued numbers are not supported.

• The total length of all strings appended together cannot exceed the maximum size of the underlying column.

• The individual values cannot contain semicolons.

• The delimiter between values is a semicolon (;).

Profile Definition Properties Must Be Keys

The Profiling System only supports profile definition properties marked as keys (for example, join key and primary key) to be mapped to a string type or an integer column. Support for other data types (such as uniqueidentifier) does not exist.

The user ID in the UserObject table is a globally unique identifier (GUID) stored in an nVarchar field. The impact on index size and performance is insignificant.

Multiple Baskets and One User Profile

You can associate multiple baskets with a single user profile. This may be helpful if you have a site where account managers manage multiple baskets for each customer and want to be able to preserve baskets across sessions.

To do this, use the OrderGroup template feature to save each customer's basket as a template. You can then use the OrderGroupManager object to get a list of all templates that belong to a particular dealer/account manager. This is easy to implement, and the Commerce Server Order Management API directly supports it.

Multiple Addresses for Users

If you use SQL Server to store user profiles, by default, the addresses are stored in a separate SQL table and referenced by the user ID (GUID) as one column in the Address table. There is, by design, no limit to the number of addresses a user profile can have. However, you can configure your site to work differently.

Extracting the Profile Catalog from Profile Definition

To extract the profile catalog from a site, you can package the site that contains the catalog, and then unpack only the Profiles resource on the new site.

Data Warehouse

You can refer to the following deployment information when you use the Data Warehouse:

• You must install the online analytical processing (OLAP) client on the same computer as the one on which the Data Warehouse resource is unpacked.

• The logged on user must be an OLAP administrator to unpack the OLAP resource.

• If you are using SQL Server 7.0, you must install the Runtime Objects option "Analysis and Data Warehouse" (available when performing a Custom installation) on the same computer as your Web server.

Securing Your Site

It is critically important that you completely secure your Commerce Server site. This section addresses the following topics:

• General security elements

• Platform security

• Network security

• Database security

• Web server security

• Commerce Server security

• Security and authentication scenarios

• Site security deployment notes

General Security Elements

This section describes the main security elements that you can use to secure an e-commerce site:

• Authentication

• Access control

• Certificates

• Encryption

• Auditing

Authentication

Commerce Server supports seven authentication methods: three authentication methods provided by Commerce Server (Windows Authentication, Custom Authentication, and Autocookie), and four authentication methods provided by IIS (Anonymous, Basic, Integrated Windows, and Certificates). For more information about Commerce Server authentication methods, see "Commerce Server Security" later in this chapter.

Commerce Server cannot detect which of the IIS authentication methods is in use. When you use any of these authentication methods, except Anonymous, Commerce Server can access the ASP environment and programmatically request the name of the user (currently logged on) using server request variables.

The security features that IIS provides are fully integrated with Windows. Commerce Server supports the following four IIS authentication methods that you can use to confirm the identity of anyone requesting access to your Web sites:

• Anonymous authentication. Allows anyone access without asking for a user name or password.

• Basic authentication. Prompts the user for a user name and password, which are sent unencrypted over the network.

• Integrated Windows authentication. Uses hashing technology to identify the user without actually sending the password over the network.

• Certificates. Employ digital credentials that can be used to establish an SSL connection. They can also be used for authentication.

You can use these methods to grant access to public areas of your site, while preventing unauthorized access to your private files and directories.

Access Control

Using NTFS access permissions as the foundation of the security for your Web server, you can define the level of file and directory access granted to Windows users and groups. For example, if a business decided to publish its catalog on your Web server, you would need to create a Windows user account for that business and then configure permissions for the specific Web site, directory, or file. The permissions would enable only the server administrator and the owner of the business to update the content for the Web site. Public users would be allowed to view the Web site, but could not alter its contents. For more details about setting NTFS permissions, see "Setting NTFS Permissions for a Directory or File" in the IIS 5.0 online documentation.

Web Distributed Authoring and Versioning (WebDAV) is an extension of the Hypertext Transfer Protocol (HTTP) version 1.1 that facilitates file and directory manipulation over an HTTP connection. Through the use of WebDAV "verbs," or commands, properties can be added to and read from files and directories. Files and directories can also be remotely created, deleted, moved, or copied. Additional access control can be configured through both Web server permissions and NTFS. For more information, see "About Access Control" and "WebDAV Publishing" in the IIS 5.0 online documentation.

Certificates

Certificates are digital identification documents that allow both servers and clients to authenticate each other. They are required for both the server and the browser belonging to the client to set up an SSL connection over which encrypted information can be sent. The certificate-based SSL features in IIS consist of a server certificate, a client certificate, and various digital keys. You can create these certificates with Microsoft Certificate Services or get them from a mutually trusted, third-party organization called a certification authority (CA). For more information about setting up certificates and keys, see "Setting Up SSL on Your Server" in the IIS 5.0 online documentation.

Server Certificates

Server certificates provide a way for users to confirm the identity of your Web site. A server certificate contains detailed identification information, such as the name of the organization affiliated with the server content, the name of the organization that issued the certificate, and a public key used in establishing an encrypted connection. This information helps to assure users of the authenticity of Web server content and the integrity of the secure HTTP connection.

Client Certificates

With SSL, your Web server also has the option of authenticating users by checking the contents of their client certificates. A typical client certificate contains detailed identification information about a user, the organization that issued the certificate, and a public key. You can use client certificate authentication, along with SSL encryption, to implement a highly secure method for verifying the identity of your users.

Encryption

You can enable users to exchange private information with your server, such as credit card numbers or phone numbers, in a secure way by using encryption. Encryption "scrambles" the information before it is sent, and decryption "unscrambles" it after it is received. The foundation for this encryption in IIS is the SSL 3.0 protocol, which provides a secure way of establishing an encrypted communication link with users. SSL confirms the authenticity of your Web site and, optionally, the identity of users accessing restricted Web sites.

Certificates include keys used in establishing an SSL secure connection. A key is a unique value used to authenticate the server and the client in establishing an SSL connection. A public key and a private key form an SSL key pair. Your Web server uses the key pair to negotiate a secure connection with the Web browser to determine the level of encryption required for securing communications.

For this type of connection, both your Web server and the Web browser must be equipped with compatible encryption and decryption capabilities. During the exchange an encryption, or session, key is created. Both your server and the Web browser use the session key to encrypt and decrypt transmitted information. The degree of encryption, or strength, of a session key is measured in bits. The greater the number of bits comprising the session key, the greater the level of encryption and security. Although these greater encryption key strengths offer greater security, they also require more server resources to implement. The session key of your Web server is typically 40 bits long, but can be 128 bits long depending upon the level of security you require.

You can use Commerce Server to generate new encryption keys. For information, see "Generating a New Encryption Key" in Commerce Server 2000 Help.

Auditing

You can use security auditing techniques to monitor a broad range of user and Web server security activity. You should routinely audit your server configuration to detect areas where resources might be susceptible to unauthorized access and tampering. You can use the integrated Windows utilities, the logging features built into IIS 5.0, or ASP applications to create your own auditing logs.

For highly sensitive information, you should seek the assistance of a professional security consulting firm. A consulting firm can help you establish proper security policies and procedures.

Platform Security

This section discusses some issues to consider when you secure the platform for your e-commerce site.

Separating Users from Internal Domains

If you use Active Directory for your site and for your internal organization, you should use separate domains. Administering user data outside of your corporate network might require more administrative time and effort, but the security improvement is usually worth the cost. If you share a domain for internal and external use, it is possible for external user data to wind up in your internal Active Directory global catalog. If you have a reason to use your internal Active Directory in your site, it is a good idea to put your Business Desk server on the same side of the firewall as your Active Directory domain controller. The risks of sharing internal and external Active Directory information include site defacement, fraudulent purchases, account changes, denial of service, and virus placement.

Securing Cookies

By default, cookies travel in clear text. It is possible for intruders to intercept information contained in cookies and use that information to impersonate users. However, cookies can be encrypted. Commerce Server employs authentication and anonymous cookies that are encrypted to enhance security. To help secure cookies, use encryption, and embed the IP address of the client in them. This allows the target server to verify that the correct user actually sent the cookies.

Using Scripts to Set Permissions on Folders

Site Packager does not package or unpack any NTFS folder or file permissions (ACLs). Make sure you secure the files and folders that contain your site after you unpack it. A good way to do this is to use the scripting hooks of Site Packager to change folder permissions while or after you run Site Packager.

Limiting Access to Your Site

Site Packager does not affect Windows access control lists (ACLs). After you unpack a site, you should lock down some of the files and folders on your Commerce Server site by changing permissions on them. You can also limit access to files by setting Web server permissions.

When you limit access to the files and folders on your site, you should consider the following:

• Business Desk users must have access to the log file in the Profiles folder before they can save changes to a profile definition. A business manager must also have access to the log file in the Profiles folder to be able to save any changes made in the Profile Designer module. The IIS Web server permissions have read access turned off by default when you use the Commerce Server Solution Sites, but you can increase security by also denying read access on this folder's NTFS permissions.

• If you use pipeline logging to debug a pipeline, be aware that sensitive information appears in clear text in the log files. Make sure you secure against read access the Pipelines\Logfiles folder, which contains these pipeline log files.

• If, when you unpack a non-Business Desk application, you use an Unpack.vbs script file that you created, make sure you delete or secure the file immediately after unpacking. The file exists in the root directory and can be accessed by anonymous users. Unauthorized use of this script could lead to denial of service or the breaking of site settings. This file does need to be present, however, if you repackage the site.

  In the Commerce Server Solution Sites, the Unpack.vbs file is secured by default.

• You can set file and folder permissions only on drives formatted to use NTFS.

• To change permissions, you must be the system administrator or have been granted permission to do so by the system administrator.

• Groups or users given Full Control permissions for a folder can delete files and subfolders within that folder regardless of the permissions protecting the files and subfolders.

• If the check boxes under the Permissions box are shaded, or if the Remove button is unavailable, then the file or folder has inherited permissions from the parent folder.

Web Farms Using Proxy Accounts

Consider the case of a user, with a valid ticket that contains a proxy account ID, who visits a new site on a Web farm. AuthFilter uses the proxy account ID to retrieve the profile of the user. Because the proxy account ID does not have a profile associated with it, the ticket is considered invalid. The user is denied access and is redirected to the login page.

To avoid this, add the custom guid property to the ticket using the AuthManager object. After the guid property has been set, AuthFilter uses it to access the password cache instead of the proxy account ID. When the GUID is not found in the password cache, AuthFilter uses the user ID from the MSCSAuth ticket, instead of the proxy account ID, to look up the profile. In this case, the profile should exist, and the user is redirected to the originally requested URL.

Using Windows Authentication with Active Directory in a Web Farm

If you are using Active Directory, you cannot get clear text passwords from Active Directory, so you must enable sticky sessions. Active Directory support in a Web farm requires sticky sessions.

If you are using Active Directory and SQL Server aggregation, you can capture a password from the Login.asp page and store it in the user's profile store in SQL Server. The password is then accessible from another server and the custom code in Login.asp can log the user in transparently. This authentication process does not require sticky sessions.

You do not need to maintain two passwords. The password from Active Directory is cached only in SQL Server. Users must explicitly change their passwords in SQL Server.

Note The proxy client works in a Web farm, because it requires keeping an SQL store of the password and allows credentials to be re-submitted to Active Directory. This issue relates to the fact that IIS and Active Directory require both a user ID and password to authenticate a user and load it into the token cache.

You can also use Application Center to implement a workaround to an Active Directory implementation without sticky sessions. Application Center has the Request Forwarder that starts before Integrated Windows (NTLM) authentication. This enables Network Load Balancing without sticky sessions, although the actual request is "stuck" to one physical Web server. This solves issues with proxied client access (for example, as used with AOL).

Note that this Application Center feature works only if cookies are supported on the client side. Cookieless browsing requires sticky sessions.

Securing an Intranet (Supplier) Site

When you secure an intranet site, you must use Standard Authentication to SQL Server 2000. You cannot use Windows NT Authentication to SQL Server. Because Windows NT Authentication is not supported, all connections to the SQL Servers are under the same account.

All Business Desk users have the same access to the SQL Server databases. You cannot differentiate SQL Server access among Business Desk users by creating multiple SQL Server accounts, each with different access rights.

Hosting Sites for External Customers

If you are an Application Service Provider (ASP) hosting sites for external customers, you must ensure a secure environment if you host multiple sites on a single computer. Any environment where multiple sites are hosted on the same computer (or in a Web farm) introduces additional risk. Any scripts or code uploaded to the Web farm must be carefully inspected to ensure there is no unexpected or potentially malicious corruption of the Administration database. Users from one site might be able to read data from other sites because the Administration database is shared.

Network Security

To implement network protection in an e-commerce site, you use the following security elements:

• DMZ

• Firewalls

• Network segregation

• Data encryption using SSL

• Credit card information security

• Intrusion detection

DMZ

A DMZ (derived from the military term demilitarized zone) consists of front-end servers, back-end servers, and firewalls. The firewalls protect the front-end servers from the public network and filter traffic between the corporate network and back-end servers. A DMZ provides a multilayer protection system between the Internet and the internal network of an organization.

To provide protection, the DMZ contains:

• A firewall that protects the front-end servers from Internet traffic.

• A set of "security hardened" servers that support the services provided by the application. These servers are set up so that dangerous Internet services, such as file sharing and telnet, are disabled.

• A firewall that separates the back-end servers from the corporate networks and enables communication between the back-end servers and a few servers within the corporate network.

A DMZ is an important element for securing a site. However, you need to take additional security measures to protect data stored by the back-end servers. You can also store extremely sensitive data or data that's needed elsewhere in your enterprise outside the DMZ, although doing so has negative performance implications and runs a risk, however small, of opening your corporate network to hacking.

Firewalls

Firewalls are often implemented at the network protocol layer and used to filter incoming network traffic. You can configure a firewall to pass or block packets from specific IP addresses and ports. To implement a firewall, you can use a network router and configure it or you can buy dedicated firewall hardware with enhanced capabilities. More sophisticated firewalls can detect denial-of-service attacks and provide network address translation (NAT) to hide the addresses of the resources behind the firewall.

For a Microsoft Windows Server 2003 site, you configure both Internet-facing and internal firewalls. The Internet-facing firewall must provide access to services such as HTTP, LDAP, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP) mail. To secure the firewall further, you can close all ports except port 80 (for HTTP) and port 443 (for Hypertext Transfer Protocol Secure (HTTPS) and SSL) and block access to all IP addresses except the IP address of your Web cluster. You might also need to support a virtual private network (VPN) for a business-to-business site.

You need to restrict access to services that can potentially damage the system, if a Web user can access them. For example, you must remove access to the telnet service. For a business-to-business site, it is possible to set up your firewall so your site will respond only to requests that come from one of the known list of IP addresses your customers and vendors use.

Internal firewalls restrict traffic between back-end servers and the internal network and protect the resources in the internal network from destructive attacks. You must configure these firewalls to support only those services and protocols that are required for managing the DMZ components.

If the Web server hosting the Commerce Server application and the SQL Server computer are separated by a firewall, you should open the following ports in the firewall:

• Port 135. Remote procedure call (RPC) End Point Mapper (EPM) Transfer Control Protocol (TCP)/User Datagram Protocol (UDP)

• Port 1433. TDS (for SQL Server traffic)

• Port 5100-5200. Microsoft Distributed Transaction Coordinator (MSDTC) (The EPM dynamically assigns it a port.) 1024->65,535

For more information, see the following Microsoft Knowledge Base articles:

• 191168 - INFO: Failed to Enlist on Calling Object's Transaction, located at https://support.microsoft.com/default.aspx?scid=KB;en-us;191168&sd=tech .

• Event ID 12293: Transacted Commerce Server Pipeline Failure, located at https://support.microsoft.com/default.aspx?scid=KB;en-us;248403&sd=tech .

• "Using Distributed COM with Firewalls" – a white paper by Michael Nelson, located at https://www.microsoft.com/com/wpaper/dcomfw.asp .

Network Segregation

You can segregate the network within a DMZ using two or more network interface cards (NICs) in each computer. Network segregation allows you to:

• Separate different types of Internet traffic and route them to different Web servers. For example, HTTP requests can be routed to one set of Web servers and FTP requests can be routed to another cluster. This doesn't necessarily help with security, but it can help with load balancing.

• Separate Internet traffic from the back-end traffic and prevent direct access to the internal network. The NICs can be configured to allow only packets appropriate for the server.

• Avoid IP forwarding between the front-end servers. The only publicly accessible IP address is the virtual IP address used by the load-balanced front-end server cluster. Disabling IP forwarding is crucially important to the security of your site.

You can also use network segregation to separate network traffic from management traffic, thus preventing management traffic from passing through firewalls.

Data Encryption Using SSL

In an e-commerce site, you process sensitive information, such as customer credit card numbers. This data must be encrypted and transmitted over a secure channel. For implementing secure data transfer, you use Secure Sockets Layer (SSL).

To implement this functionality, you need to acquire a digital certificate and install it on your server(s). You can apply to one of the certification authorities for a digital certificate. Some of the commonly known commercial certification authorities are VeriSign, CyberTrust, and GTE.

SSL is a scheme for protocols such as HTTP (named HTTPS when secure), FTP, and Network News Transfer Protocol (NNTP). When you use SSL to transmit data:

• The data is encrypted.

• A secure connection is established between the source and destination servers.

• Server authentication is enabled.

Credit Card Information Security

You should store credit card information only in encrypted format. When a customer uses a credit card to pay for a product on your site, the credit card information must be transmitted over a secure channel. To do so, you should put the ordering form or page on a secure server. The customer can identify a secure form by looking at its URL; Web pages that require SSL for data transmission have URLs beginning with "https" instead of "http." Also, a lock icon is displayed in the status bar of the browser. The browser checks for the digital certificate and verifies it. It then uses the public key within the certificate to encrypt the information. After the customer submits the information, it is transmitted over a secure channel to the server.

Using SSL is processing-intensive because data must be encrypted and decrypted. Also, SSL servers must maintain their state between requests because a secure channel is needed for a specific user—the same key pair is used to decrypt the information sent back as was used to encrypt it. This can cause problems in a load-balanced site that routes client requests based on the availability of a server and does not maintain state on the servers. To avoid these problems, you need to set up Network Load Balancing so that it has client affinity for HTTPS (port 443).

Because HTTPS can slow the processing of other Web pages on the same server, you might also want to segregate HTTPS pages on a few Web servers in the cluster that are dedicated to processing requests associated with sensitive data. This will prevent the degradation of performance on the site as a whole. You can also use hardware accelerators to avoid affecting the performance of a site without compromising site security.

Intrusion Detection

An intrusion detection system (IDS) can identify attack signatures or patterns, generate alarms to alert the operations staff, and cause the routers to terminate connections with hostile sources. These systems can also prevent denial–of-service attacks. A denial-of-service attack occurs when a hacker sends fragments of TCP requests masked as legitimate TCP requests or sends requests from a bad IP source. The server cannot handle so many requests and displays a denial-of-service message to legitimate site users. An IDS provides real-time monitoring of network traffic and implements the "prevent, detect, and react" approach to security.

You should implement an IDS in front of a firewall in every security domain. Although IDSs are necessary for security, you should consider the following issues associated with their use:

• They are processing-intensive; an IDS can affect the performance of your site.

• They are expensive.

• An IDS can sometimes mistake normal network traffic for a hostile attack and cause unnecessary alarms.

There are a number of third-party tools available for intrusion detection. For example, you can use Cisco's NetRanger or ISS's RealSecure for real-time network traffic monitoring. Enhancing and developing IDS technology is an ongoing process within the computer industry.

Database Security

This section describes the deployment of security features in Active Directory and SQL Server.

Active Directory Security

Active Directory provides protected storage of user account and group information by using access control on objects and user credentials. Because Active Directory stores not only user credentials but also access control information, users who log on to the network obtain both authentication and authorization to access system resources.

For example, when a user logs on to the network, the Windows 2000 security system authenticates the user with information stored in the Active Directory. Then, when the user attempts to access a service on the network, the system checks the properties defined in the discretionary access control list (DACL) for that service.

Because Active Directory allows administrators to create group accounts, administrators can manage system security more efficiently. For example, by adjusting a file's properties, an administrator can permit all users in a group to read that file. In this way, access to objects in Active Directory is based on group membership.

In Commerce Server, user information, including passwords, credit card numbers, and phone numbers are stored in clear text in the Profiles database. SQL Server secures this information against unauthorized access; however, to improve its security, consider using Active Directory to store this sensitive user data.

When determining whether to use Active Directory or SQL Server, consider the following questions:

• Applications such as Microsoft Exchange Server require an operating system security context. Do you need a security context for users?

• Do you need to authenticate site visitors with their Windows 2000 security context?

• Do you need to protect file system content? Will some of the file system content be WAV files or other blobs?

• Do you have complex group membership requirements?

If you answer yes to any of these questions, then you should consider using Active Directory.

For information about using Active Directory and SQL Server together, see "Using Active Directory and SQL Server" later in this chapter.

SQL Server Security

A user passes through two stages of security when accessing SQL Server: authentication and authorization (permissions validation). The authentication stage identifies the user using a login account and verifies only the ability to connect to an instance of SQL Server. If authentication is successful, the user connects to an instance of SQL Server. The user then needs permissions to access databases on the server, which is done by granting access to an account in each database, mapped to the user login. The permissions validation stage controls the activities the user is allowed to perform in the SQL Server database.

SQL Server can operate in one of two security (authentication) modes:

• Mixed mode (Windows Authentication and SQL Server Authentication). This is the required configuration for using Commerce Server.

  Mixed mode allows users to connect to an instance of SQL Server using either Windows Authentication or SQL Server Authentication. Users who connect through a Windows NT 4.0 or Windows 2000 user account can make use of trusted connections in either Windows Authentication mode or mixed mode.

  SQL Server Authentication is provided for backward compatibility. For example, if you create a single Windows 2000 group and add all necessary users to that group, you must also grant the Windows 2000 group login rights to SQL Server and access to any necessary databases.

• Windows Authentication mode (Windows Authentication). Windows Authentication mode allows a user to connect through a Windows 2000 user account.

Using Active Directory and SQL Server

If your site requires both the access control provided by Active Directory and the performance of SQL Server, you should use both Active Directory and SQL Server together to store user profile information. In this scenario, you store data that is associated with user credentials and data that is static in an Active Directory data store. You would store the remaining data (such as dynamic data) in SQL Server.

For example, you might want to divide the attributes as shown in the following list:

• User profile data stored in Active Directory:

  • User name

  • Password

• User profile data stored in SQL Server:

  • Credit card

  • Home address, city, state, postal code

  • Home phone number

  • Date/time of last visit

  • Favorite color

  • Last page visited

  • Year-to-date total spent on site

For detailed instructions for setting up your site to use Active Directory and SQL Server, see "Configuring a Sample Supplier Solution Site" in Chapter 3, "A Supplier Scenario."

Web Server Security

IIS Web server permissions can be set up to limit the access of anonymous users to your applications, and can also be used to limit the viewing of source code over the Internet, even for users with Windows permissions (or access control entries (ACEs)).

It is important to understand the distinction between Web server permissions and NTFS permissions. Unlike NTFS, Web server permissions apply to all users accessing your Web sites. NTFS permissions apply only to a specific user or group of users with a valid Windows account. NTFS controls access to physical directories on your server, whereas Web server permissions control access to virtual directories on your Web site.

When you use Site Packager to package a site, it will pick up the Web server permissions as set in the source site. For example, if you have the Execute Permissions setting set to "Scripts and Executables" in the root folder of the application on the source computer, the virtual root folder on the destination computer will have the same setting.

For example, the following table describes how the IIS permissions are set in the Commerce Server Solution Sites.

Folder	Permissions
Root	Set Execute permission to "Scripts and Executables."
Pipeline, Include, Template	Deny permission to "Read", "Write," and "Execute."

Commerce Server Security

In a Commerce Server installation, one of the ways in which you implement security is by authenticating users. In this section the following topics are addressed:

• Using AuthFilter and the AuthManager object

• Authenticating users in a Web farm

• Using Commerce Server authentication modes

• Using Commerce Server authentication features

• Securing Business Desk

• Securing Commerce Server databases

• Limiting access to Commerce Server services

• Providing access to Commerce Server resources

• Commerce Server and Microsoft Outlook Web Access (OWA) integration

• Active Directory and anonymous users on the Supplier site

• Adding products to a basket without an account

Using AuthFilter and AuthManager

Commerce Server provides two tools to implement user authentication and identification: the AuthManager object and AuthFilter.

• AuthManager is a COM object that exposes methods for identifying users and controlling access to dynamically generated content. For example, a site developer could invoke the GetUserID method of the AuthManager object to identify a user based on a cookie or a query string.

• AuthFilter is an Internet Server API (ISAPI) filter that is used at the IIS Commerce Server application level. It can be applied to all users visiting the application. You configure properties used by AuthFilter at the global CS Authentication level. You configure the authentication mode at the application level. You can choose the following authentication modes: Windows Authentication, Custom Authentication, and Autocookie.

When you configure the AuthManager object and AuthFilter, the authentication properties are stored in the Administration database. The CS Authentication resource interacts with the Config objects to store and retrieve the properties from the Administration database.

The Solution Sites do not use AuthFilter because they are designed to support cookieless shopping.

The following table summarizes the differences between the features supported by AuthFilter, the AuthManager object, and the Solution Sites.

Feature	AuthFilter	AuthManager	Solution Sites
Checks whether session cookies (non-persistent cookies) are supported	Yes	No	Yes
Supports cookieless shopping	No	Yes	Yes
Provides granular access control using ACLs	Yes	No	No
Supports custom login pages for retrieving Windows credentials	Yes	Yes	No
Provides URL case correction	Yes	No	Yes

Commerce Server extends the authentication methods supported by IIS 5.0 in two ways. First, it adds granular access control for dynamic content through AuthFilter. Second, it provides a way to use Windows Authentication or Custom Authentication in an Internet environment where you need to address a wide range of browsers. Commerce Server provides this support for Windows and Custom Authentication.

Authentication Using AuthFilter

For authentication using AuthFilter, if a profile is stored in SQL Server, you can retrieve the password in clear text through a profile object (with the user_security_password property) and compare it with the one input by the user.

If the profile is stored in Active Directory and you want to perform authentication using Active Directory Service Interfaces (ADSI), you must perform the following steps to retrieve the password:

1. Use Business Desk to extend the default schema.

2. Use SQL Server Enterprise Manager to add new a column (such as u_Pref1).

3. Use the Profiles resource in Commerce Server Manager to map the password property to the new column.

You will be able to retrieve the password for all the subsequently created profile instances.

Authenticating Users in a Web Farm

Commerce Server supports the single authentication of a user in a Web server farm. For example, if a user is authenticated on one Web server, and then is redirected or load-balanced to another Web server, the second Web server does not prompt the user to log in again.

When the user is redirected to the second Web server, AuthFilter reads the user cookie and identifies that the cookie contains the user ID and that it is valid. If you are using Custom Authentication mode, no other steps are performed. If you are using Windows Authentication mode, Commerce Server performs the following steps:

1. It redirects the request for the secured page to the Login.asp file. This redirect is transparent to the user.

2. In the Login.asp file, using the user ID, it queries the Profiles data store for the user profile. This returns the user login ID and password in clear text.

3. It appends the login ID and password to the URL, and then redirects the request for the secured page.

4. The filter intercepts the request for the secured page, removes the user ID and password from the URL, and stores the login ID and password in the ISAPI filter cache.

5. The filter then displays the secured page to the user. The user ID and password are not transmitted to the user.

If the request is sent with the Post method using non-sticky load balancing, any information contained in the header body is lost during the required redirection. Only use the Post method with sticky load balancing. If you use non-sticky load balancing, always use the Get method and HTTPS for additional security.

When you use AuthFilter, follow these deployment scenarios:

• Have all sites in the same directory, for example, www.microsoft.com/bookstore and www.microsoft.com/msdn. Do not have one site in the subdirectory of another site, for example, www.microsoft.com and www.microsoft.com/bookstore.

• Use dissimilar names for sites in the same directory. A site name should not be a subset of another site name, for example, www.microsoft.com/retail and www.microsoft.com/retail2.

These requirements are due to the dependence of AuthFilter on cookies. If AuthFilter is not used and the ticket is placed in a URL query string, then a site can be in a subdirectory of another site.

Using Commerce Server Authentication Modes

When a user logs in to your site, Commerce Server authenticates the user by verifying the login and password against the login and password stored in the Profiles database. After Commerce Server verifies the user information, it creates a non-persistent cookie and stores it in the ISAPI filter cache for the application. The cookie specifies that the user is authenticated and is allowed to see secured pages on your site.

When you use AuthFilter, you can choose the following authentication modes:

• Windows Authentication mode

• Custom Authentication mode

• Autocookie mode

• Windows Authentication with Autocookie mode

• Custom Authentication with Autocookie mode

Windows Authentication Mode

In Windows Authentication mode, AuthFilter uses Windows Authentication—through ACLs—to control access to the site. Anonymous and registered users can access the site, depending on the ACLs. Registered users are tracked; anonymous users are not tracked.

When you select the Windows Authentication mode, AuthFilter looks up the access rights for users in Active Directory. When a user logs in to a site running in this mode, AuthFilter retrieves the user name and password from the HTTP request and stores it in a cache. It also sets a cookie that is valid only for the duration of the user session. Other pages that the user visits during the session can then check the cookie. In Windows Authentication mode, ACLs determine access to any resource on the Web site.

A user is validated by setting a session cookie that contains an MSCSAuth ticket. An MSCSAuth ticket contains a user ID, the last login time, and a time window specifying how long the ticket is valid after the last login time. No expiration date is specified for the cookie and the cookie is deleted after the session expires. A validated user does not automatically have access to a requested URL. The credentials of the user, once validated, are checked against the access rights of the URL that are maintained through ACLs.

Windows Authentication supports a Web farm scenario with a single login, and it supports using proxy accounts. When you use Windows Authentication mode, you should note the following:

• When Windows Authentication mode is enabled, the security of the site is automatically set to IIS Basic authentication. This must not be changed, because it allows IIS to notify AuthFilter of events.

• After unpacking a Solution Site for use with Commerce Server, the files contained in the <site name>\AuthFiles folder have anonymous access enabled. If these files are not used, you should delete them.

Custom Authentication Mode

In Custom Authentication mode, you can use AuthFilter to provide a custom authentication process to control access to the site while still using the base services (URL correctness, cookie support, and ticket validation) of AuthFilter.

If you need to implement Custom Authentication, you can still use AuthFilter to integrate it into your site. If you select Custom Authentication, AuthFilter will check for a valid MSCSAuth ticket. If the valid MSCSAuth ticket is not found, the user is redirected to a login page, where you can do your own custom authentication by validating credentials and setting MSCSAuth ticket upon success.

For example, you could use the Profiling System to retrieve access rights from the user profile when a user logs in. The Profiling System retrieves user information from a data source. This data source could be a SQL Server database, the Windows 2000 Active Directory, another OLE DB-compliant data source, or a valid LDAP-v3 store.

In the Custom Authentication mode, AuthFilter performs the following steps after being notified that an SF_NOTIFY_PREPROC_HEADERS event has occurred:

1. It checks for site configuration properties in the local site cache and, if not found, it reads the site configuration properties from the Administration database using a SiteConfig object and stores them in the site cache.

2. It detects whether the requested URL is correct and automatically corrects for case sensitivity in the URL.

3. It checks for session-cookie support and, if unavailable, AuthFilter redirects the user to the ASP page specified in the s_NoCookie_Form ("No-Cookie form" in the Commerce Server Manager UI) property of the CS Authentication resource. Usually this page notifies the user that cookies are required and that the user should resubmit the request after cookies are enabled.

4. It checks whether the cookie contains an MSCSAuth ticket, and if it does not, AuthFilter redirects the user to a login page.

5. If the cookie contains an MSCSAuth ticket, AuthFilter checks the current time against the last login time on the ticket to see if it is within the time window specified in the ticket.

6. If the current time is past the time window specified in the ticket, the user is redirected to the login page as a non-validated user.

7. If the current time is within the time window, the ticket is considered valid, and the user is redirected to the login page as a validated user. If the current time is within five minutes of the last login time plus the time window, the last login time on the ticket is changed to the current time so an active user can continue browsing.

Autocookie Mode

In Autocookie mode, you can use AuthFilter to permit anonymous users to access the site. AuthFilter automatically generates a persistent cookie (MSCSProfile ticket) so a user can be tracked.

When you choose Autocookie mode, AuthFilter always checks to see whether the browser has this anonymous cookie. If the anonymous cookie is not in the browser, then the filter redirects the user to the AutoCookie Form.

Autocookie mode enables Commerce Server to keep track of anonymous users between pages and across sessions. A unique ID is generated to identify the user and, if required, a profile is created to store information about the user.

When a user sends a request to access a site, AuthFilter performs the following steps after being notified by IIS that an SF_NOTIFY_PREPROC_HEADERS event has occurred:

1. It checks for site configuration properties in the local site cache and, if not found, AuthFilter reads the site configuration properties from the Administration database using a SiteConfig object and stores them in the site cache.

2. It checks whether the URL is correct and automatically corrects for case sensitivity in the URL.

3. It checks for cookie support on the browser.

4. If cookies are not supported, the user is redirected to the ASP page specified in the s_NoCookie_Form ("No-Cookie form" in the Commerce Server Manager UI) property of the CS Authentication resource. Usually this page notifies the user that cookies are required and that the user should resubmit the request after cookies are enabled. By default, an ASP page named Nocookie.asp is supplied for this purpose. This file is located in the AuthFiles folder in the Commerce Server installation directory.

5. If a cookie is returned, AuthFilter checks whether it contains an MSCSProfile ticket.

6. If the MSCSProfile ticket exists, AuthFilter uses a valid Windows user account to impersonate the user in IIS.

7. If the requested URL has anonymous access rights, the URL is returned.

8. If the ticket does not exist, the user is redirected to the ASP page specified in the s_AutoCookie_Form ("AutoCookie Form" in the Commerce Server Manager UI) property of the CS Authentication resource.

Windows Authentication with Autocookie Mode

The mixed authentication mode of Windows Authentication with Autocookie accepts both anonymous and registered users and enables you to track both types. This mode is useful for sites where part of the content is available to everyone and the rest is available only to registered users.

The primary differences between this mixed mode and Windows Authentication mode are as follows:

• The mixed mode allows tracking of anonymous users.

• In mixed mode, an anonymous user must have a valid MSCSProfile ticket to access any URLs regardless of the ACL settings. In Windows Authentication mode, an anonymous user does not need a ticket and can access any URL with anonymous access rights.

Custom Authentication with Autocookie Mode

The mixed authentication mode of Custom Authentication with Autocookie allows both registered and anonymous users access to the site, and allows tracking of the anonymous users through persistent cookies. Instead of controlling access using Windows ACLs, the site developer can supply a custom authentication process.

Using Commerce Server Authentication Features

This section describes the following authentication features that Commerce Server supports:

• Multi-domain, single login capability

• Cookie sharing across domains and applications

• Anonymous users who register

• Single sign-on support

• Clear text password in Active Directory

• Proxy accounts

• Prevention of distributed denial-of-service attacks

• Enabling only the most secure version of Integrated Windows authentication

Multi-Domain, Single Login Capability

Commerce Server provides multi-domain, single login capability. In this scenario, cookies are shared between domains with their domain property. The domains must have a common sub-domain name. For example, premier.microsoft.com and msn.microsoft.com can share cookies with the microsoft.com domain name.

However, two domains such as microsoft.com and microsoft.uk cannot support single-login capability; they cannot share cookies because the subdomain name is not common. In this scenario, users are required to log in again each time they switch domains. For more information about Passport integration, see "Integrating with Passport" in Commerce Server 2000 Help.

To use multi-domain single login, you set two authentication properties at the site level: "Set cookie path to application" and "Number of shared domain levels." You must set "Number of shared domain levels" to at least two, and use domains that share the same top-level name, for example, msn.microsoft.com and premier.microsoft.com.

Cookie Sharing Across Domains and Applications

You can share cookies across domains, which enables you to track users across multiple domains and applications. For multiple domains to share cookies, the domains must have a common sub-domain name. For example, msdn.microsoft.com and premier.microsoft.com can share cookies with the domain property set to ".microsoft.com." You cannot set the domain to ".com."

If you do not want to share cookies across domains, you can instead share them across applications. To do this, you set the path property on the cookie to the application. For example, you would set the property to "/retail" to share the cookie across all applications in a retail site. To share cookies between applications that do not have the same virtual directory, you must set the path property to the root (/).

When a cookie is shared among multiple domains, two properties are set on the cookie, domain* *and path. This resembles the following:

";domain=DomainName;path=Path"

The domain property is used to specify the domains for which the cookie is valid. The path property is used to specify the subset of URLs in the domain for which the cookie is valid.

Before sending a request, the client browser checks to see if a cookie is available that contains a domain property that matches the last part of the fully qualified domain name of the host specified in the requested URL. If such a cookie exists, the path property of the cookie is compared to the path name component of the requested URL. If they match, the cookie is sent with the request.

On the server side, while setting the property, if the value of the domain property is not specified, it defaults to the host name of the server that generated the cookie. Only hosts within the specified domain can set the domain property on the cookie. The most general path property is "/". If the path property is not specified, it defaults to the path of the virtual root of the IIS application that generated the cookie.

In Commerce Server, each site has its own cookies by default; however, the AuthFilter allows these cookies to be shared.

To share cookies between sites in the same domain, set the b_CookiePath_ApplicationScope property (clear the "Set cookie path to application" check box in the Commerce Server Manager UI) to False. This causes the host to set the path property to "/". If the b_CookiePath_ApplicationScope property is True, the path property is set to the current application path.

To share cookies between domains, set the u_CookieDomain_Scope property ("Number of shared domain levels" in the Commerce Server Manager UI) to the required number.

Anonymous Users Who Register

A user who visits a site anonymously receives an MSCSProfile ticket. If the user decides to register, the user receives an MSCSAuth ticket. The user now has two cookies in the HTTP header containing different tickets. The order of the tickets is unknown and can vary between requests. AuthFilter recognizes this and automatically searches all cookies for an MSCSAuth ticket before searching for an MSCSProfile ticket.

Both cookies get logged in the Web log file in the order they appear in the HTTP request header. The Web server log import DTS task imports the first cookie it finds. That one user can appear to be two users to the DTS task if it finds hits in the log file with the cookies in different orders. This compromises the ability to track the user and might produce erroneous visit and user calculations.

The solution is to map the user IDs from both the MSCSAuth ticket and the MSCSProfile ticket to the same user ID. Then set the MSCSProfile ticket to an empty string, which causes the MSCSProfile ticket to be deleted.

Single Sign-On Support

Single Sign-On (SSO) support allows a user who successfully logs on to one site or server access to other sites and servers without having to log on again. AuthFilter in Windows Authentication mode provides support for the following, using cookies:

• SSO between domains.

• SSO in a Web farm scenario. For more information, see "Authenticating Users in a Web Farm" earlier in this chapter. Support for SSO in a Web farm is also included in Custom Authentication mode using cookie sharing.

Clear Text Password in Active Directory

User passwords in Active Directory are stored in an encrypted format. To access this password in clear text, the following two options are available when the password is initially retrieved in the login page:

• Extend the profile schema by adding a new property to store the clear text password. Extending the schema must be performed through the Profile Designer module in Business Desk.

• Create a custom cache to store the clear text password.

Proxy Accounts

When a user accesses a site using a proxy account, the process for the login page is the same as with the Post method. However, the user ID is used to retrieve a proxy account ID and password, and these credentials are set into the URL query string and stored in the password cache instead of the user ID and password. On subsequent visits to the site, the proxy account ID, instead of the user ID, is used to access the password cache.

The proxy account credentials can be stored in an extended property of the default profile schema or by some other means. You extend the profile schema using the Profile Designer module in Business Desk.

To track individual users when using proxy accounts, add the custom guid property to the ticket using the AuthManager object. After it is set, AuthFilter uses the guid property to access the password cache instead of the proxy account ID.

Prevention of Distributed Denial-of-Service Attacks

A distributed denial-of-service (DDOS) attack is an attempt to shut down a server by repeatedly logging on with a known valid user ID and an incorrect password. By default, AuthFilter does not associate each password cache entry with one, and only one, client session. When a user logs in with a valid user ID, the password cache is updated with the submitted password. A malicious user can use this technique to disrupt service. The malicious user does not gain entry to the site, but forces a registered user who is active when the password is changed to log in again.

To avoid the attack, AuthFilter can store an additional property in the cache in addition to the user ID and password. This property is generally a globally unique identifier (GUID) and is used to distinguish between different client sessions using the same user ID and possibly different passwords.

On the login page, the GUID is placed on the ticket of the user as a custom property, guid, by the SetProperty method of the AuthManager object. Additionally, the property is appended to the query string for the redirected URL.

After the guid property has been set, AuthFilter uses it to access the password cache instead of the user ID. When a user logs on with the same user ID but with a different password, AuthFilter identifies this as a different user and a new entry is made in the password cache instead of overwriting the original password. AuthFilter then follows the same steps as for a new user.

Enabling Only the Most Secure Version of Integrated Windows Authentication

If you use Integrated Windows authentication and the client computers connecting to your Web server use Windows 2000 or Windows NT 4.0 Service Pack 3 or later, you can configure your Web server to use only the strongest version of Integrated Windows authentication, NTLMv2.

You can set a Windows policy to specify that only the latest version of NTLM is used. In the Local Security Policy of your Web servers, set the LAN Manger Authentication Level policy to "Send NTLMv2 response only\refuse LM & NTLM" to use the most secure setting.

Securing Business Desk

This section provides the following information about securing your Business Desk application:

• Securing Business Desk sessions

• Securing Bdrefresh.asp and RefreshApp.asp scripts

• Limiting access to Business Desk modules

• Securing Business Desk user access to Catalogs

Securing Business Desk Sessions

When Site Packager unpacks a Commerce Server Business Desk application, it is configured to use Integrated Windows authentication. Although this secures client authentication, the Business Desk session itself passes data in clear text. To provide security for Business Desk sessions, consider allowing only Business Desk clients inside your Internet firewall. To provide additional security, you can use SSL for Business Desk connections. For more information about SSL, see "Setting Up SSL on Your Server" in the IIS 5.0 online documentation.

Securing Bdrefresh.asp and RefreshApp.asp

You should use IP address access restrictions to limit permissions on Bdrefresh**.**asp and RefreshApp.asp so that unauthorized users cannot run these scripts. By default, Bdrefresh.asp and RefreshApp.asp are set to anonymous access, which is required in order for Business Desk users to publish changes to the Web site. To secure these files, grant access to specific Business Desk users by using IP address access restrictions in IIS.

The Bdrefresh.asp script clears the Business Desk cache. The RefreshApp**.**asp script clears the Profiles cache. Clearing either of these caches repeatedly could lead to a denial of service for users. These files are located in the root folder of an unpacked Solution Site.

There are other files similar to Bdrefresh.asp and RefreshApp.asp included with the Commerce Server Solution Sites. You should also secure these files.

Limiting Access to Business Desk Modules

You can prevent specific users from accessing particular Business Desk modules. You do this by setting ACEs on Business Desk ASP files. Each Business Desk module has a main ASP file that is checked for ACEs before it is added to the Business Desk navigation pane. If the logged-in user running Business Desk does not have Read permission on the main ASP file for that module, the module will not be exposed in the navigation pane for that user.

The following table shows the files on which you can set ACEs for each Business Desk module.

To control access to this category and module	Set an ACE on this ASP file
Analysis/Reports	Analysis\Analysis_reports.asp
Analysis/Completed Reports	Analysis\Analysis_report_viewer.asp
Analysis/Segment Viewer	Segviewer\Modellist.asp
Campaigns/Campaign Manager	Marketing\Cmanager.asp
Campaigns/List Manager	Marketing\Listmanager.asp
Campaigns/Campaign Expressions	Marketing\Targetexpr.asp
Campaigns/Target Group	Marketing\Target_group.asp
Campaigns/Reference Tables	Marketing\Reftable.asp
Campaigns/Publish Campaigns	Productionrefresh\refresh.asp
Catalogs/Catalog Designer	Catalogs\Designer\List_categorydefinitions.asp
Catalogs/Catalog Editor	Catalogs\Editor\List_catalogs.asp
Catalogs/Catalog Sets	Catalogsets\Catalogsets_list.asp
Orders/Basket Manager	Orders\Basket_list.asp
Orders/Data Codes	Application\Datacodes_list.asp
Orders/Order Status	Orders\Orderstatus_list.asp
Orders/Publish Transactions	Productionrefresh\refresh.asp
Orders/Shipping Methods	Shipping\Shipping_list.asp
Orders/Tax Rates	Tax\Regionaltax.asp
Users/Users	Users\Registered.asp
Users/Organizations	Organizations\Orgs.asp
Users/Profile Designer	Profiles\Profileselector.asp
Users/Site Terms Editor	Profiles\Profileeditor.asp
Users/Publish Profiles	Profiles\Refreshprofilesvcall.asp

If an individual user and the Authenticated Users group have access to a Business Desk module, and you take permission away from the individual user, restart the client computer in order to redraw the navigation pane, so that the modules the user has permissions to use are refreshed in the navigation pane.

If you include an ACE for the Administrator account, you must also grant permissions to the Everyone group. The exact set of permissions is not significant, but the Everyone group must be present in the list of users and groups. If the Everyone group does not have permissions to a Business Desk module, an administrator will not be able to access that module.

If you secure one of the following modules, all three of them are secured by default: Publish Profiles, Publish Campaigns, and Publish Transactions.

Securing Business Desk User Access to Catalogs

You cannot use Authfilter to authenticate users that are accessing the Business Desk to, for example, set access control on the administration tasks.

If you have one site with multiple customers, each of whom needs to update only their own catalog on that same site, you can customize the Catalog Editor module and restrict users to their own catalogs (that is, application level security) by not allowing them to select any other catalog. You do this by creating a filter that displays only their catalogs.

Securing Commerce Server Databases

This section provides the following information about securing your Commerce Server databases:

• Protecting SQL Server passwords

• Setting up Data Warehouse permissions

• Limiting access to the Administration database

• Securing log files

• Using the "sa" login name for SQL Server administrative login

• Differentiating access to resources

• Changing the Data Warehouse password

Protecting SQL Server Passwords

When a Web server connects to a SQL Server, the SQL password travels in clear text. To protect a SQL Server connection from intruders, use the multi-protocol network driver in SQL Server, which allows encryption of session connections. If you use Windows NT Authentication, this password will be protected, except in Commerce Server Setup or if you choose the Quick Unpack option in Site Packager.

Setting Up Data Warehouse Permissions

One way to give Business Desk users the ability to read and modify objects in the Data Warehouse is to give them a Windows Administrator account. However, you may want some Business Desk users to be able only to read reports. You can do this by assigning specific SQL Server database roles to different users. The db_datareader role allows users to see all data from all tables in a database. The db_datawriter role allows users to add, change, or delete data from tables in the database.

Limiting Access to the Administration Database

It is important to lock down the server that hosts the Administration database for your site. When you run Commerce Server Setup, you give users of that computer full control of the Administration database. Although the SQL password for the Administration database login is encrypted in the Windows registry, it is possible for users to gain access to it by using a script that accesses one of these programming objects: SiteConfigReadOnly, SiteConfig, or GlobalConfig. Make sure users cannot gain access to the computer or run scripts on it after you complete Setup. Disable the Guest account and disallow access to everyone without administrative privileges.

You can restrict use of the SiteConfig and GlobalConfig objects by modifying the ACLs on the registry keys for these object classes. To restrict access to these objects, change the permissions on these objects through the Windows Registry Editor.

The SiteConfigReadOnly object must be accessible by all user accounts that will access Commerce Server applications. If you want to allow anonymous access, the object must be available to the anonymous account, named IUSR_<computer name>. The key for the SiteConfigReadOnly object is D1AA04A4-B00D-4D30-88AA-E3070DAE8040.

Securing Log Files

It is a good idea to move your log files from your Web servers to a more secure location. When you move these files, do it in a secure way. One way to achieve security is to use separate network lines that run directly from your staging environment to your production environment. This separate line is a good way to update content and to move log files to secure servers. Another way to safely move log files is through SSL over HTTP or FTP.

If you use pipeline logging to debug a pipeline, be aware that sensitive information may appear in clear text in the log files. Make sure you secure the folder that contains these pipeline log files (by default, the \Pipeline\Logfiles folder in the application).

Using the "sa" Login Name for SQL Server Administrative Login

It is recommended that you do not use the "sa" login name that SQL Server creates by default. You should specify a different administrative login name for your database servers. If you do use the "sa" login name, do not use a blank password for it. Doing so increases security risks for your site.

Differentiating Access to Resources

Commerce Server resources have single connection strings to each database. Therefore, you cannot specify different access privileges for different Commerce Server site users.

Changing the Data Warehouse Password

If you change the password for your SQL Server computer, you must also change the password in the Data Warehouse and the connection strings for all resources.

Limiting Access to Commerce Server Services

During Commerce Server Setup, in the Services Account dialog box, you specify the Windows user name and password for the following Commerce Server services: List Manager, Direct Mailer, and Predictor. Setup automatically grants these Windows accounts the "Log On as a Service" permission.

Also in the Services Account dialog box, you specify an account under which Event Logging will be performed. This last account is used in the Commerce Event Logging COM+ package that is created by Setup.

Make sure you specify the proper account for each service. For List Manager, your Business Desk users must be able to read folders from which they import lists and write to folders onto which they export lists. The List Manager service account must have appropriate NTFS permissions on the folders from which users will import and export lists.

Setup does not permit you to set up these services to use the Local System account. Although it is possible to do this manually after Setup, it is not a good idea because doing so might give the services more permissions than they require.

Providing Access to Commerce Server Resources

Business Desk users and administrators must have sufficient permissions to access the SQL Server database that corresponds to the resource in order to access those resources, such as the Product Catalog. A user should have a SQL Server login name that is linked to a SQL Server user that has the db_owner database role. Or, to allocate more specific roles, you can assign the user to the db_ddladmin, db_datareader, and db_datawriter roles.

Commerce Server and Outlook Web Access (OWA) Integration

Outlook Web Access (OWA) for Microsoft Exchange Server 2000 secures access to its site by leveraging the IIS Basic Authentication mechanism. As part of this authentication method, a server variable accessible from within ASP pages named AUTH_USER is populated with the user name. OWA uses the AUTH_USER variable to determine which Exchange 2000 mailbox to open for the session.

AuthFilter intercepts the normal mechanism of IIS authentication by trapping an access-denied event. AuthFilter provides an HTML Forms login page instead of the usual Web browser login dialog box, and allows the session to proceed with the same security context as provided by normal IIS Basic Authentication.

Active Directory and Anonymous Users on the Supplier Site

The Supplier Solution Site, which uses Active Directory, does not allow anonymous users. The Supplier site is designed for a business-to-business scenario, which typically requires that all users are registered.

If you want to use Active Directory in this scenario, you can create a separate SQL Server profile store for your anonymous users, and then use Windows Authentication mode. Windows Authentication is ACL-driven, so your resources must be enabled for anonymous users. For more information, see "Enabling AuthFilter for the Supplier Solution Site" in the "Managing the CS Authentication Resource" section of Commerce Server 2000 Help.

Adding Products to a Basket Without an Account

You can enable users who do not have an account to add products to a basket. However, the cookie that identifies the anonymous basket and profile should expire when the user closes the browser. You do not want other users to be able to view the contents of the anonymous basket (for example, in a school or an Internet cafe setting).

To have Commerce Server distribute the MSCSProfile ticket as a non-persistent cookie, simply turn ASP buffering on (default) and at the end of the page (or after you've called the SetProfileTicket method) modify the expiration date of the MSCSProfile ticket.

ASP buffering allows you to modify HTTP headers (for example, changing the cookie) even after you've written other information to the buffer already. If you reach the maximum buffer size limit and then try to write headers, the modification will not work.

Security and Authentication Scenarios

This section provides information about implementing security and authentication for static and dynamic content.

Protecting Static Content

You can use Authfilter to protect static content on a Web site. The following two modes of AuthFilter do this:

• Windows Authentication uses Active Directory. You set permissions on static files.

• Custom Authentication uses SQL Server. It protects all content at the virtual directory level of the site. This means that you can't implement discretionary access: it's "all or nothing" from the virtual directory level.

Protecting Dynamic Content

In Site Server 3.0, Personalization & Membership, you were able to secure content on a file system using Windows NT Groups. You might want to secure content the same way in Commerce Server, using Custom Authentication instead of Windows Authentication, especially if your site content is predominantly dynamic content.

To protect dynamic content, use AuthFilter with proxy accounts (add the proxy accounts to security groups). Use AuthFilter in Windows Authentication mode, but validate credentials against a SQL store (that is, store your users in a SQL profile store) and protect your static files with ACLs.

During login, AuthFilter traps access denied to files protected with ACLs and redirects to a login page, where you accept the user ID and password, validating the user against the profile data in the SQL Server database. If the information is validated, then it chooses an Active Directory account to use as a proxy and provides the Active Directory user ID and password as credentials on the redirect from the Login.asp file to the original request page.

Site Security Deployment Notes

The following deployment notes pertain to site security.

Auditing Site Deletions

You can identify the account that was used to delete a site from Commerce Server Manager (not the service account used to remove the entries, but the account that was used to start the delete process). Check to see which accounts have access to modify data in the Administration database. After Commerce Server is installed, the ID used for Commerce Server doesn't require privileges to create tables, databases, and so on.

Put a trigger on the site table that creates a record when another record is deleted. While there are other tables in use on the site, you cannot delete them from the site table if these tables contain data.

A record is created if the Administration database is edited manually or the SiteAdmin or the GlobalConfig component is modified.

Using Windows Authentication against Windows NT 4.0 Domain Accounts

In an intranet, you can use Windows Authentication to authenticate users against their Windows NT 4.0 domain accounts. To do this, you must create an Active Directory domain and set it to trust the Windows NT Server 4.0 domain.

For information about configuring Windows Authentication for this scenario, see the Microsoft Windows 2000 Server Resource Kit.

Testing Your Environment

After you deploy your site, perform the following tests:

• Measure recovery time on the hardware. Take your hardware offline and measure how long it takes the hardware to recover. Is the time acceptable to you? If your target is 99.9 percent uptime, you can calculate how many minutes of downtime you can allow.

• Test your ASP availability code. Just as you test for functionality, test that the code you have to handle downtime or system failure works. If you have code to handle certain scenarios, implement the scenarios to make sure the code works.

• Verify that your backup services are running.

• Pull the plug on the network cards to test whether the failover configuration works.

• Test the distribution of the load on each computer to determine whether every computer is being used equally.

• Take down a server preemptively to test what happens. Are the appropriate people notified?

In addition, you should hire third parties to perform security analysis, and capacity and reliability analysis. For more information about testing your site, see Chapter 16, "Testing Your Site."

Implementing Initial Operational Procedures

When your site is ready to go live, there are several operations to perform on your site before you deploy it. Some of these procedures you perform only once before the site goes into production. Others, like backing up your site, you perform for the first time at this stage and many times afterward, during the Management phase of your site.

Final Steps Before Production

After you test your deployment, you are ready to put it in production. Consider the following production issues:

• If you have extra logging to track intermediate phases for debugging purposes, remove it now. Consult with the development team to determine whether some of it should be on for the first two weeks.

• A week before going live, set the MSCSEnv variable in the Global.asa file to the PRODUCTION server-side constant.

• Perform a final audit of the hardware to verify it is calibrated as specified. Update your hardware configuration documents.

• Perform a final audit of the software to verify it is calibrated as specified. Update your software configuration documents.

• Set up the performance monitoring and event monitoring service on your production computers.

• Determine which reports you need to monitor after the site is in production.

• Determine the process for resolving problems and assign members of your team to monitor for specific problems.

After Your Site Is in Production

During the first month that your new site is in production, you should perform the following steps:

• Keep the development and test teams available for at least the first two weeks.

• Hold daily meetings with the development, test, and deployment teams to make sure the site is behaving as expected.

• Track administrator logins for security purposes.

• Revisit the usage profile. How are people actually using your site?

• Review the size of your Web log files to verify they don't become too large for the disk, and that your strategy for Web log management will keep up with the rate of growth.

• Observe the growth of your databases to ensure they are in line with expectations. Make sure the rate of growth of the Data Warehouse, Transactions database, and Web log files is the rate you were planning.

  If, for example, the rate at which your database is growing outpaces the number of users visiting your site, you might have a bug in your system.

• Analyze the site to make sure there are no bottlenecks in the hardware architecture.

• Verify that third-party components are working in the production environment. Are you getting the right types of confirmation?

• Verify that the business processes are working.

As you modify your system to resolve these issues, you must update your site architecture and configuration documents. For additional ongoing maintenance tasks, see Chapter 17, "Managing Your Site."

Backing Up Your Site

To ensure recovery from a disaster, you must back up all the information needed to recreate your production environment. You should use a backup service that can back up the following:

• Server configuration

• System state

• File system

• Application data and open files

• Network configuration

Gathering Server Configuration Data

Always keep a current record of your configuration data. If you have to reconfigure any part of your system due to a disaster, this record will be a critical resource.

At a minimum, you must back up the following data:

• A list of the data that is stored on each computer

• Hardware configuration

• Disk size/configuration

• Operating system and service patches

• Key software installations

• Identification

• Server name

• Network configuration/addressing

• System role

• Services running

• Other configuration information

• Wide area network (WAN) diagram

• Local area network (LAN) diagram

• Service description

There are many automated methods of gathering this type of information, including technologies offered by Microsoft. Most of this information can be detected using Windows Management Instrumentation (WMI), a management technology within Windows 2000.

System State Backup

As part of any backup and recovery application for Windows 2000, the backup service should back up the Windows 2000 system state.

The system state consists of:

• Boot files, including the system files and all the files protected by Windows File Protection (WFP)

• Active Directory (on a domain controller only)

• Sysvol (on a domain controller only)

• Certificate Services (on certification authority only)

• Cluster database (on a cluster node only)

• The registry

• Performance counter configuration information

• Component Services Class registration database

All Windows 2000 backup applications back up this data as part of the backup process. To ensure full recovery of the system, the backup service you use must include backing up the system state.

File System Backup

A file system backup must include a back up of the file data and file attributes. If the file system is NTFS, the attributes consist of normal attributes and file permissions. If you backed up files without their attributes and permissions in an e-business environment, you would have to set them manually when you restored the data.

In Windows 2000, NTFS file permissions, share permissions, and file attributes limit access to NTFS files. To back up or restore NTFS files to which you do not have access rights, you must:

• Belong to the permissions group of administrators, backup operators, or restore operators.

• Have user rights to back up files and directories (if you are backing up) and restore files and directories (if you are restoring).

Neither the FAT16 nor the FAT32 file systems provide file permissions.

After the data file side of the file system backup service has been designed, the next decision concerns the type of backup the service will use. There are three types:

• Normal backup. Copies all selected files and marks each as having been backed up. With normal backups, you need only the most recent copy of the backup file to restore all of the files.

• Incremental backup. Backs up only those files created or changed since the last normal or incremental backup. It marks files as having been backed up. If you use a combination of normal and incremental backups, you need the last normal backup set as well as all of the incremental backups to restore your data.

• Differential backup. Backs up files created or changed since the last normal backup. It does not mark files as having been backed up. If you are doing normal and differential backups, you must have the last normal and last differential backup sets to restore your data.

Consider the following factors when you decide what type of backup to use:

• The normal backup type provides a baseline for the other backup types. It is best to use when a large amount of data changes between backups.

• The incremental backup type works well to record the progression of frequently changed data.

• The differential backup type simplifies the process for restoring files.

To provide for long-term storage with fewer media, you can use a combination of a normal backup plus either incremental or differential backups.

Some backup types use backup markers, also known as archive attributes, to track when a file has been backed up. When the file changes, Windows 2000 marks the file to be backed up again. Files or directories that have been moved to a new location are not marked for backup. An incremental backup allows you to choose to back up only files with this marker set, and to choose whether or not to mark files as having been backed up.

Application Data Backup

If your Commerce Server site is small, the easiest way to back it up is to repackage it using Site Packager. The new package will save many of the configuration settings specific to your current site. However, Site Packager does not package properties that are specific to the computer you are on. For example, Web server properties and some application properties that are set in Commerce Server Manager are not packaged. For a list of the data that is packaged for each resource, see "Site Packager Reference Information" in the "Deploying Your Site" section of Commerce Server 2000 Help.

If your site is large, creating a package file for it may not be practical. In this case, you need to back up each component (each application and database, for example) using the appropriate method for that component.

The following table lists appropriate backup tools for each Commerce Server component type.

To back up this component type	Use this
Application files, Windows registry, and IIS 5.0 metabase	Windows 2000 Backup Wizard or Application Center
Commerce Server site	Site Packager
SQL Server databases	SQL Server Enterprise Manager
Domain information	Active Directory replication between multiple domain controllers

Network Configuration Backup

The configuration of routers or firewalls in the modern e-business environment can be complex. As part of any contingency plan, the network equipment configuration should be backed up periodically. This information then becomes part of the offsite backup data.