Security and Authentication in Content Management Server

  • Article
On This Page

Introduction Introduction
System Architecture System Architecture
Authenticating Users Authenticating Users
Security Settings Security Settings
Resource URL Encryption Resource URL Encryption
Site Configuration Site Configuration
For More Information For More Information

Introduction

Microsoft® Content Management Server 2001 (MSCMS) is an enterprise Web content management system that enables companies to build, deploy, and maintain Internet, intranet, and extranet Web environments. One essential component of the Web development process is the planning and implementation of a security policy for the site. Businesses must provide adequate protection for the confidentiality, privacy, integrity, and availability of information on their Web sites.

Because there are multiple variables to consider, securing an MSCMS Web environment requires careful planning. Administrators must determine a preferred user authentication model, establish rights or permissions for specific user accounts, and determine security settings for the content, files, and directories of the Web site, among other things.

This paper describes some of the security options available in MSCMS and recommends some best practices for configuring a secure MSCMS Web site. The following issues are discussed in detail:

  • Assigning user permissions

  • Authenticating users

  • Securing content, files, and directories

  • Encrypting Resource URLs

  • Configuring a secure MSCMS Web site

Please note that this paper is not intended as a planning guide. Although this paper may recommend specific security policies, it does not provide detailed information about security planning, risk analysis, and security policies. You can find this information on the Microsoft Web site at https://www.microsoft.com/security/. For specific references, see For More Information at the end of this paper.

System Architecture

Before assessing the different security options available in MSCMS, it is important to understand the components of an MSCMS Web environment and the tools an administrator can use to implement security on a Web site.

Content Management Server 2001 is a distributed network application built on an industry-standard database and featuring an object-based Publishing API. MSCMS uses Microsoft Windows® 2000 Internet Information Services (IIS) as its Web server. This means that in addition to internal MSCMS security mechanisms, the MSCMS Web environment utilizes Windows File Security and IIS Security.

The Web environment is comprised of Web page content and resources (for example, graphics, documents, and videos) that are combined with template layouts at run time to produce Web site content. The different components of the Web site are stored in Containers. Container is the term used to describe virtual storage areas in the MSCMS 2001. Each of the following items is a container in MSCMS:

  • Channels where postings are stored

  • Folders where authors and editors create and edit pages

  • Template Galleries where designers create and store page and navigation templates

  • Resource Galleries where resources (images, video, text) are created and stored.

Web Administrators use Content Management Server Site Builder to define user access to Containers. Site Builder is a desktop application that runs on Windows platforms and requires Microsoft Internet Explorer. In addition to setting user permissions, administrators can use Site Builder to build the application framework. Site Builder can also be used in combination with any HTML editor to build Web templates.

The other tool administrators use to secure an MSCMS Web environment is Microsoft Content Management Server Configuration Application (SCA). This stand-alone application enables administrators to configure local and global security properties in the Web environment. For example, administrators can turn guest access on or off and determine the Web point entries using SCA. To protect the Web environment from hostile interventions, it is advisable to run SCA over a Secure Sockets Layer (SSL) connection.

For more information about Site Builder, SCA, and other components of MSCMS, see the "Setup Guide" at https://www.microsoft.com/CMServer/techinfo/.

Establishing User Rights

When setting up an MSCMS virtual workspace, one responsibility of the Web Administrator is to determine each user's right to access and modify data on the Web. These rights are determined by a combination of the rights groups to which a user belongs and the roles assigned to each rights group.

There are seven different roles in MSCMS, and each role is associated with certain rights:

  • Subscriber can browse to MSCMS 2001 pages.

  • Author can create and modify the pages they have ownership over (or pages that are owned by everybody), submit these pages for approval, and post them to Channel containers. The author also has the right to use page templates and resources.

  • Editor can approve, decline, create and delete pages, modify postings, and submit postings to channels. The editor also has rights to use page templates and resources.

  • Moderator can modify posting schedules and approve and decline postings. Although the moderator role may be useful for dealing with first publications, it may be easier to omit it from the general Web page workflow.

  • Resource Manager can add, remove, and replace content in a resource gallery.

  • Template Designer can design page and navigation templates and use resources.

  • Administrator can assign users to one or more roles, determine user rights, assign rights in all containers, create hierarchies, and maintain an archive of content revisions.

When determining user rights, the administrator first creates rights groups under one of the seven publishing roles available in MSCMS. The rights group determines the containers to which a group has access. For example, the administrator may create a Sales editor rights group and a Marketing editor rights group. Each of those groups has the rights associated with the Editor role, but each group may only be able to exercise those rights within certain containers on the site.

Next, the administrator assigns each user to one or more rights groups. The permissions a user has within a container are determined by a combination of the user's role and group. So, for example, a user assigned to the Sales editor group has all the rights of an Editor, but that user can only exercise those rights in Containers to which the Sales Editors group has been given permission.

Note: There is only one rights group associated with the administrator role, and it applies to the entire system. No additional rights groups can be created for the administrator role.

Although the containers to which a group has permission and a user's membership in a particular role can change, the rights associated with a role cannot be modified.

When assigning roles and rights groups, administrators should keep the following information in mind:

  1. Roles are not system-wide. For example, Dave may be an author in the Sales folder and the Company News folder, but he is not an author in any other folders.

  2. A user can have more than one role. For example, Ann may be an author in the Sales folder and an editor in the Marketing folder.

  3. Some roles overlap others. For instance, Fred can be both an author and an editor in one folder.

  4. Users only see parts of MSCMS 2001 based on their assigned roles. For example, a user assigned to the Resource Manager role only will only see the channels in the Resource Gallery.

  5. After users have authenticated on a site, they cannot use guest access to view pages, so authors and editors who do not have rights to modify content in the whole site need to be added to a subscriber group that does have rights to view the entire site.

For detailed information about assigning users to a role or assigning permissions within a container, see the "Site Administrator's Guide" at https://www.microsoft.com/CMServer/techinfo/.

Authenticating Users

In MSCMS 2001, every user is associated with a user account. This account may be a Windows 2000 account, a Site Server Lightweight Directory Access Protocol (LDAP) account, or an Active Directory® directory service account. Through authentication, a user's identity is verified so the user can exercise the rights associated with his or her account.

To authenticate, the user typically provides credentials, including user name, password, and domain, during the login process. The system uses these credentials to determine the data that the user can access and the operations that the user can perform on the Web site. When a user assigned to the Editor role is authenticated on the site, for example, she can add and delete pages in the Containers to which she has permissions.

There are a number of options for authenticating users on an MSCMS Web site. Administrators may choose to use one of the authentication options provided by Internet Information Services, or the forms-based manual login provided with Microsoft Content Management Server, or some combination of these methods. It is also possible to enable Guest Access on the Web site so that anonymous users may browse some or all of the pages on a Web site.

An overview of the different authentication options is provided in Figure 1.

Figure 1: MSCMS Authentication Process

The authentication method an administrator chooses to use is dependent on the site requirements and the risks the administrator is willing to assume. Integrated Windows Authentication, for example, works best in an Internet Explorer only environment, whereas forms-based login is a better alternative in a multi-browser environment. In an environment where there are proxy servers and multi-browsers, Basic Authentication with SSL encryption is best.

Details on each of the authentication options, including Guest Access, are provided in the sections that follow.

Using MSCMS Forms-Based Authentication

Within Microsoft Content Management Server, the AESecurity Service authenticates users. In this forms-based authentication system, users trying to access a secure Web page are redirected to a login form (an Active Server Pages [ASP] script called ManualLogin.asp) where they must enter a user name and password. After the user enters credentials, the ASP script does an HTML post of the login credentials to an ASP script called ManualLoginSubmit.asp, which communicates the data to the server.

Note: Site programmers can customize the ManualLogin.asp so that it maintains the look and feel of the Web site. They can also add it to one of their page templates if it is guest accessible.

If user authentication succeeds, MSCMS saves a session cookie with an encrypted token in the Web browser. The token is comprised of the user identity, the time of login, and the login IP address; it is encrypted in the cookie with the Server Security Key. Each time the user requests a new page, MSCMS validates the token and grants or denies access accordingly. When the user logs off, the token is removed from the Web browser, and when the browser is closed, the session cookie is destroyed.

If a server does not have the Server Security key, it cannot decrypt the token, in which case the server denies access to the user. The Server Security Key, therefore, must be consistent across all servers in a cluster. Also, if the Server Security Key changes, all tokens previously generated will be invalid.

To configure MSCMS forms-based manual login

  1. Browse to c:\\Program Files\Microsoft Content Management Server\Server\IIS_NR\System\Access, and then open the IISAuthentication.inc file.

  2. Ensure that the value of the constant CF_IIS_Security_Context_Login is set to false (false is the default setting).

  3. Go to the IIS NR virtual directory and enable Anonymous access. Anonymous access is required to access include files and files in the cache. If anonymous access is not enabled, then the user will have to complete IIS authentication in addition to the forms-based login to access these files. If the file caches are located in an alternate location, special file permission must be granted to the anonymous account to access this location.

  4. Enable SSL encryption of the Login page, if not for the entire site.

The forms-based manual login works with all types of Web browsers provided that cookies are enabled in the browser. If an individual disables cookies in the browser, the user will have to re-authenticate on every page. One workaround to this problem is to store the information in the URL, but this requires special system configuration, including code changes to some of the out-of-the-box scripts shipped with MSCMS.

It is important to note that the forms-based system passes authentication information in clear text over the network. Because a sniffer could intercept this data and use it to impersonate the user, the login page should be SSL encrypted. For information about using SSL on an MSCMS site, see Enabling SSL Encryption on an MSCMS Web site. Administrators can also use IP checking and cookie time-out to decrease the probability of an intruder using a stolen identity to access the Web site. When a session token exceeds the timeframe, the user must re-authenticate to access secure pages. For information about these settings, see IP Checking and Cookie Time-out.

Using IIS Authentication

Internet Information Service can authenticate users on an MSCMS Web site through IIS Security Context. Three types of IIS Security Context authentication are supported in MSCMS:

  • Basic Authentication sends user name and password over the network in clear text.

  • Integrated Windows Authentication uses hashing technology to identify the user. Instead of sending user information over the network, credentials are exchanged in a cryptographic manner.

  • Anonymous Authentication is required for CMS Guest Access to work. Guest Access allows visitors, who are not necessarily Microsoft Windows NT® or ADS users, to request the site without providing login credentials. In an NTFS system, Anonymous authentication ensures that anonymous users have permission to all files under IIS_NR. Anonymous access should be used in conjunction with other forms of authentication to ensure that users have read access to these files.

Note: IIS digest authentication is not supported in Content Management Server 2001.

Basic Authentication and Integrated Windows Authentication are discussed in the following sections, including some general recommendations regarding when an administrator may want to use one method versus the other.

Basic Authentication

Basic authentication is similar to the MSCMS forms-based authentication in that it is part of the HTTP specification and is supported by most browsers. Users enter their assigned Windows 2000 account user name, password, and domain into a dialog box. Administrators may also specify a default domain.

Basic authentication is recommended in environments where one or more of the following conditions are true:

  1. Users are authenticating from multiple browsers and the MSCMS forms-based authentication is not an option.

  2. The IP address of the browsing machine is behind a proxy server so that Integrated Windows Authentication will not work.

  3. The administrator wants to identify access to the site, that is, the unique number of users, but is not concerned with authenticated access.

Like forms-based authentication, Basic Authentication sends user information over the network in clear text at the initial request of the user; in addition, Basic authentication sends user information with every subsequent request. Because it is passed over the network every time a user requests a new page, the user information is particularly vulnerable to being intercepted. For this reason, Basic authentication is not recommended unless the connection between the user and the Web server is absolutely secure, through a dedicated line, for example. In addition, SSL encryption should be used for any parts of the Web site that rely on Basic authentication.

Integrated Windows Authentication

Like Basic Authentication, Integrated Windows Authentication (formerly called NTLM or Windows NT Challenge/Response authentication) utilizes the user's Windows logon information. Instead of prompting the user to re-enter this information into a dialog box, however, the browser attempts to retrieve this information automatically. This process is referred to as automatic login. It is enabled by default in an intranet environment, but administrators can disable it in IIS. For automatic login to work in an intranet environment, the user must authenticate against the same domain as the server, or a one-way trust relationship must exist between the user's domain and the server domain.

Note: If a perimeter network (also known as DMZ, demilitarized zone, and screened subnet) protects the Web environment, setting up a trust from the perimeter network to an internal network is not recommended. If the appropriate ports are open, a domain outside the firewall may be used.

After the browser retrieves the Windows authentication information, it passes the data to the Web server through a one-way process referred to as hashing. The resulting message digest, or "hash," cannot be decrypted. In the event that the authentication exchange initially fails to identify the user, the browser will prompt the user for an account name, password, and domain.

Although integrated Windows authentication is the most secure authentication option, it does have some limitations:

  • It does not work if the IP address of the browsing machine is sheltered by a firewall or proxy server.

  • It does not work over HTTP proxy connections.

  • The dialog box that prompts the user for logon information is not customizable.

  • It only works with Internet Explorer browsers.

Integrated Windows authentication is best suited for an intranet environment, where both user and Web servers are in the same domain, and where administrators can ensure that all authenticated users use Internet Explorer.

To Configure IIS Security Context Login

  1. Browse to C:\\Program Files\Microsoft Content Management Server\Server\IIS_NR\System\Access, and then open the IISAuthentication.inc file.

  2. Set CF_IIS_Security_Context_Login to true. This enables IIS Security Context for the entire Web site.

  3. Go to the Internet Information Services snap-in for the MMC console, or Internet Service Management, open the IIS_NR virtual directory, and then click the Directory Security tab.

    scauth02

  4. Under Anonymous access and authentication control, click Edit, and then select the appropriate authentication method.

    scauth03

    Note: You can choose more than one authentication method, but this is not recommended. This means that the browser selects the method that it will use. If the browser selects Basic and SSL encryption is not enabled on the site, the user credentials may be intercepted.

  5. To enable automatic login, select Integrated Authentication and select the option you prefer for automatic login in the client browser.

    scauth04

For more information about Integrated Windows Authentication, see https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/maintain/featusability/authmeth.mspx

Using Site Server Login

Content Manager Server 2001 currently supports Microsoft Site Server 3.0 SP3, so it is possible to user Site Server's Membership Server to authenticate Lightweight Directory Access Protocol (LDAP) accounts.

Site Server provides a forms-based login. The two files in Content Management Server 2001 that facilitate authentication are NRSiteServerAccess.asp found in the virtual Web root and NRFormsLogin.asp found in IIS_NR/shared.

If you decide to use Site Server authentication, please note the following:

  • Site Server authentication does not provide generic LDAP support. For example, it will not work with a Novell system.

  • Site Server will not be supported in future releases of MSCMS; it is only available in MSCMS 2001.

  • Site Server is not supported in a server cluster environment.

To configure Site Server login

  1. Install Site Server on the CMS 2001 box.

  2. Open the Server Configuration Application, click the Access tab, and then click Configure Access.

  3. Enable Site Server authentication in Server Configuration Application, and then select the organizational units to include.

Guest Access

Guest access permits users to access some or all of the MSCMS Web pages without providing authentication credentials. The pages that the anonymous user can access depend on the permissions of the subscriber group to which the administrator assigns the guest account. The guest account must be added as an MSCMS 2001 subscriber by using Site Builder.

Guest access can be enabled in conjunction with IIS security context or forms-based authentication.

To Configure Guest Access

  1. Browse to the IIS_NR virtual directory and enable anonymous access.

  2. Open the Server Configuration Application, click the Security tab, and then click Configure.

  3. Designate a guest user by using a Windows NT user account.

    Note: You can use an Active Directory Service account, but it must be formatted as a Windows NT account.

  4. Add the Windows NT account to a subscriber group in CMS 2001. Users who log on using Guest Access will then inherit the permissions of that subscriber group.

Security Settings

There are three different layers of security settings on any MSCMS Web site. In addition to the security settings unique to MSCMS, some Web files inherit the security settings that apply to Windows or IIS, depending on where they are stored. Web Author scripts, authentication and external scripts, temporary resource data files, and ASP templates generated at run time are stored in the NTFS file system, not the MSCMS database, so NTFS provides security for these files. NTFS file permissions restricts access to files.

Note: MSCMS must be installed on an NTFS enabled partition. It will not install on a file allocation table [FAT] file system.

Likewise, Content Management Server creates several virtual directories during installation under the IIS virtual Web site and directory, and access to these virtual directories is restricted in IIS by default. It is not advisable to relax the default security settings within NTFS or IIS; you may, however, want to further restrict access to specific directories or computer names by IP address, for example.

Administrators manage the following security settings within Microsoft Content Management:

  • Control user access to each of the virtual Web sites in an IIS Web server.

  • Set MSCMS 2001 System Account information

  • Set Guest Access options

  • Establish Web cookie settings.

Because MSCMS SCA is used to configure these security settings, access to SCA should also be restricted, preferably to the local administrator. To minimize access, do not install SCA on the following Web site entry points:

  • Any site that allows anonymous access.

  • The MSCMS default Web site in IIS.

  • Sites that use port 80.

  • Sites that do not have file system security or IIS security enabled on the files.

If SCA is installed on one of these Web sites, warning messages will be generated during installation. Ideally, SCA should be installed on the most secure IIS-administered virtual Web site available.

Each of the MSCMS security settings is addressed in detail in the sections that follow, except Guest Access. For information on Guest Access, see Authenticating Users.

Controlling Access to virtual Web sites

Each virtual Web site on an MSCMS site represents a different point of entry to the Web server. Controlling access on these sites, therefore, is very important to server security.

Administrators can select from one of three different security settings for each virtual Web site:

  • MSCMS Authoring is allowed. This setting authorizes users to access and modify content on the Web site.

  • MSCMS Authoring is not allowed. The site is read-only when this setting is enabled. This means that no client with the ability to modify content can log in through this site. For example, Site Builder is not accessible on a site in which MSCMS Authoring is not allowed.

  • MSCMS is disabled. When a site is not supported by MSCMS, the virtual directory is unmapped or removed, so any page that is requested from this site will be reported as "Not Found."

For high-security sites, administrators may want to configure the system so that only one virtual Web site on one server allows authoring capabilities. The address of this virtual Web server can be hidden by the firewall or by IP access so that no external users can access or read it. In addition to providing high security, this configuration also can improve performance because MSCMS uses more efficient scripts to render the run-time Web pages.

The MSCMS 2001 System Account

MSCMS uses a System Account to access resources on the network and to connect to Active Directory if it is used. This account acts as an agent on behalf of all authenticated users, so that administrators do not have to grant access to protected resources to each individual authenticated user. The system account must have permission to enumerate or browse the organizational units, domains, containers, groups, and users that are supported in MSCMS.

When setting up a system account, please note the following:

  • It is not necessary to use a privileged Windows user account to establish the system account; a regular domain user account will work.

  • If Active Directory Service organizational units are used in MSCMS 2001, the system account must have permission to view the ADS tree.

  • The system account must have read/write permission on the Microsoft SQL Server™ database used by CMS 2001 if SQL trusted authentication is used. If SQL authentication is used, then the SQL account requires permissions on the database, not the system account.

  • Never make the system account a domain admin. The system account can be a local admin account, but this setup is not recommended.

  • Never set the IIS anonymous account to be the system account. This would grant anonymous permission to the CMS 2001 database.

To enable the System Account

  1. Open Server Configuration Application, click the Security tab, and then click Configure.

  2. Set the Windows NT User Account and Account Password for the System Account.

  3. If you choose to use SQL authentication, open the Database Configuration Application, select SQL Server 7/2000, and then click Next.

  4. Clear the Use Trusted Connection check box, and then supply the necessary credentials. If you are using SQL integrated security, define the database roles Public, DB_DATAREAD and DB_DATAWRITE.

IP checking and cookie time-out are designed to prevent unauthorized access to the Web site by hackers impersonating an authenticated user. These settings are particularly important for administrators who plan to use a forms-based manual login, because cookie time-out specifies the lifetime of the session token that identifies a user session and tokens are only issued for users accessing the site through a forms-based login. The default lifetime of a token is 720 minutes or 12 hours.

When IP checking is enabled, the session token generated by MSCMS when a user logs on is checked against the IP address of the header in an HTTP request. In theory, users maintain a consistent IP address while they are logged on to a Web site, so for every subsequent HTTP request, the IP address in the token should match the IP address of the user submitting the request. When it does not, access is denied. In some cases, however, users do not maintain a consistent IP address (for example, users whose requests will be passed through different proxy servers), so it is wise to analyze the user population likely to access a Web site before implementing IP checking. Note that IP checking is enabled by default, so administrators must disable it in the event that they foresee a problem for users of the Web site. For example, if authenticated users are continuously being prompted for manual login with the message "Session Timed Out," administrators may want to disable IP Checking.

To configure IP checking and Cookie time-out

  1. Open SCA, click the Security tab, and then click Configure.

  2. To change the cookie time-out, type a new number in the Cookie Lifetime box.

  3. To enable IP checking, make sure Yes appears in the Check Machine IP against Cookie box. To disable IP checking, select No from the drop-down menu.

Resource URL Encryption

Resource URLs refer to URLs embedded in MSCMS-generated Web pages as links to attachments, pictures, video files, and other gallery items. Without the proper authentication credentials, a user cannot access the Web page to view these resources. It is possible, however, for a subscriber to pass a resource URL in an MSCMS-generated Web page to a user without permissions to the resource, and this user would then be able to access current or subsequent versions of the resource.

To avoid this situation, resource URLs are always encrypted before they are made available outside MSCMS. The server key and the authenticated user identity are used in the encryption, so that the resulting URL is different for each authenticated user. If a user other than the person for whom the encrypted URL was generated tries to access the resource, the file is not found.

The server key must be the same on all Web servers in a cluster for URL encryption to be successful; otherwise, a user session routed to one server will be re-authenticated every time it is routed to a different server. Use the ManageKey.exe located at C:\Program Files\Microsoft Content Management Server\Server\bin to copy the server key to all servers in a cluster.

Note that if a person were to retrieve the real path to a resource, he or she could request the resource without proper authorization. The resource URLs encryption then becomes useless. For this reason, it is a good idea not to enable directory browsing of the resources generated dynamically by MSCMS in the file caches. NTF or IIS security will work for resources not managed by MSCMS.

It is important to be aware that indexing a site can pose problems if the proper precautions are not taken. If the Web Indexing software performs an authenticated crawl, it will include resource URLs in the search results. If the crawl is completed under an administrator, however, the links generated from the indexing are only accessible from accounts assigned to the administrator role. To avoid some of the problems associated with site indexing, do one of the following:

  • Make sure the crawl is performed using guest access, so that only URLs available to the guest account are accessible to all users.

  • If an authenticated search crawl is necessary, store the resource files outside of CMS on the file system or in a document repository where they will not be included in the index.

For more information about performing an authenticated search crawl, see "Integrating Microsoft SharePoint Portal Search into Microsoft Content Management Server."

Site Configuration

Proper deployment and configuration of the different components of a Web site are the first step to ensuring the security of a site. Figure 2 illustrates one way to configure the Web site.

Figure 2: Sample MSCMS Site Configuration

To protect the servers and database from disruption, the firewalls in Figure 2 minimize the number of computers that are accessible directly through the Internet. The production site is separated from the development and authoring environments to provide maximum protection from intruders on the internal network.

Figure 2 also indicates the specific firewall ports that must be open to enable data transfer in the MSCMS Web environment. Following is a brief summary of the ports that must be open for each type of traffic on the site:

  • Internet Originating Traffic. MSCMS Site Builder and the Internet Browser process traffic originating from the Internet. Each of these components supports HTTP or HTTPS connections for communicating with an MSCMS server. Port 80 and Port 443 must be open for this type of data transfer.

  • Perimeter Network Originating Traffic. This communication transpires between MSCMS and the SQL database, which is stored behind a firewall. The network administrator should configure the firewall to forward the IP address through the default port 1433 or through the TCP port configured for the SQL Server to receive data. The firewall should also be configured to forward requests for UDP port 1434 on the same IP address. SQL Server 2000 uses UDP port 1434 to establish communications links from applications.

  • Internal Network Traffic. When deploying to the MSCMS cluster, App Center requires that Port 4244 and 4243 be open for data transfer. MSCMS Site Deployment, which only supports HTTP connections, requires Port 80. For data transfer between MSCMS Site Stager and the MSCMS Server, an HTTP connection is also required, so Port 80 must be open.

To ensure proper security on the Web site, administrators should also take the proper precautions to secure IIS by using the IIS lockdown tool. For an MSCMS Web site to work properly after IIS lockdown has been implemented, certain settings must not be activated on the site. For more information about these settings, see https://www.microsoft.com/technet/security/tools/locktool.mspx

Enabling SSL Encryption on an MSCMS Web site

To increase security, Web administrators can configure Secure Sockets Layer connections on some or all parts of a MSCMS Web site. The security-related advantages of using SSL when connecting to a Content Management Server Web site are:

  • Clients and servers can authenticate each other, to ensure no other computers can read the contents of communications between the two machines.

  • All data sent from a client through an SSL connection is encrypted, so that malicious users cannot intercept passwords or data sent to a Content Management Server server.

It is possible to enforce the use of SSL connections for an entire Content Management Server Web site, or for select parts of the site. For example, on a site that uses the MSCMS forms-based login authentication method, SSL encryption can be used on just the login form. For Basic Authentication, SSL encryption must be enforced on the whole site.

Note: SSL mandates that the session stay with the same server during the authentication process, because the encryption requires that information be sent back and forth between the client and server in a challenge and response communication. This requirement may cause problems with load balancing on the site.

For more information about protecting a Web site with Secure Sockets Layers, see https://support.microsoft.com/directory/article.asp?ID=KB;EN-US;298805. To read about the server authentication process during the SSL handshake, see https://support.microsoft.com/default.aspx?scid=kb;EN-US;257587.

For More Information