Although you can specifically control the availability of each of the individual SharePoint rights, you will never directly assign one of these rights to a user. Instead, SharePoint gives you a way to collect rights into permission levels and levels into SharePoint groups. You then assign a user to a group, which assigns all of the contained rights from the associated permission levels.

Levels and groups are defined and assigned by an administrator directly within the SharePoint site. If you have appropriate permissions within the site to perform administrative tasks, you will see the Site Actions menu on the page. Clicking this item causes a drop-down menu to appear with available administrative options. The Site Actions menu, along with just about everything else in SharePoint, is security-trimmed. This means that users will only see options and menus that are valid for their permission set. This is a big improvement over the previous version of SharePoint, which allowed users to click any menu item only to be denied access later when the system discovered they had insufficient rights.

Although there are several specific items on the drop-down menu, the easiest way to get started with site administration is to open the Site Settings page. The Site Settings page gives you access to a broad range of settings grouped together by category. In order to access the Site Settings page through the MOSS site you created in Chapter 2, click the Site Actions menu and select Site Settings

Figure 3.1. Accessing site administration functions

When you create a site collection within a web application, SharePoint provides you with several predefined permission levels and groups that you can use immediately to assign rights to users. From the Site Settings page, you can see the predefined groups by clicking the link titled Advanced Permissions under the Users and Permissions section. From the list, select Add

When you look at the list of available groups, you'll notice that they are associated with permission levels that have unfamiliar names. For example, the Hierarchy Managers group is associated with the permission levels Limited Access and Manage Hierarchy. When you first set up SharePoint, it can be difficult to know exactly what rights are being assigned to a user in these groups. Fortunately, you can access the definition for the permission levels by selecting Settings

Before you can configure a site to allow anonymous access, the associated web application must first have anonymous access enabled through Central Administration. If the web application is set through Central Administration to allow anonymous access, you can control what parts of your site are visible to anonymous users. If the central administrator has not enabled anonymous access for the web application, the functionality will not be visible.

Follow these steps to enable anonymous access for the web application:

Once the web application is configured for anonymous access, you can return to the Permissions page. From the Permissions page, you can select Settings

Along with assigning rights to end users, you can also establish broader security policies for a web application. On the Application Management tab of the Central Administration site, you can click the link titled Policy for Web Application to set security policies. Using the Policy for Web Application page, you can change the policy for anonymous access, grant full control, or deny all access. These security policies override the rights that have been assigned through the Site Settings page so they should only be used when you want to grant a high-level of permission to an administrator or completely deny access to a set of users. You used this functionality in Chapter 2 to grant access rights to the administrator in the development environment. Additionally, these policies are set for a given zone, which determines whether they apply to users inside the firewall or outside. Zones are discussed in detail later in the section titled "Understanding Authentication Options."

A site collection in SharePoint contains one or more sites. Sites within a site collection represent a security boundary and a way to group teams and functionality for a business purpose. When you create a site collection, SharePoint will define some initial sites based on the template that you selected. The sites that SharePoint creates are designed to support the audience for which the template was designed. In the case of the MOSS site collection you created in Chapter 2, SharePoint defined sites named Document Center, News, Reports, Search, and Sites. If you created a site collection in WSS, you'll only see a home page with no additional sites defined.

The Document Center site in MOSS is designed to act as a central repository for documents throughout the organization. This site seems to be an acknowledgement that many customers simply want to use SharePoint as a document management system without necessarily taking advantage of its many other features. In previous versions of SharePoint, it was difficult to create such a document management system because of limitations in the library metadata and available document templates. SharePoint 2007 has largely overcome these limitations; I discuss the document management features in detail in Chapter 6.

The News site is designed to support the creation and publishing of news articles for the organization. This site makes use of special article templates, content management, and publishing features that allow the creation and approval of content directly within SharePoint. Content management is a major area of new functionality within SharePoint 2007 that I cover in Chapter 5.

The Reports site is a site designed to function as a report center for all business intelligence information within an organization. Using this site, you may define data connections to external sources such as SQL databases, and utilize that data to create reports and dashboards. These reports and dashboards can be presented in a number of ways, including scorecards, Excel spreadsheets, and SQL Reporting Services reports. Business intelligence is another major area of functionality that I cover in detail in Chapter 8.

The Search site implements an enterprise search capability that allows you to search all of the content within MOSS as well as external content and even external databases. Search is greatly enhanced in this version of SharePoint, and the Search site has the ability to truly function across all enterprise systems. I cover search in Chapter 4.

The Sites site forms a site directory that lists and catalogs all of the sites within the collection. The Site Directory helps end users locate sites of interest and understand the structure of the collection. If you have appropriate permissions, you can also create a new site within the collection by clicking the Create Site link. The Create Site link is a shortcut to the site creation page, which can also be reached through the Site Settings page. Most administrators will use the Site Settings page for site creation because it is conveniently grouped with other administrative tasks and works the same in both MOSS and WSS.

To create a new site, follow these steps:

When you create sites in WSS or MOSS, you may see some different options for configuring how the site is displayed in the navigation system or how it is categorized in the Site Directory. If you are using MOSS in particular, you will notice that you have options to specify a division and a region with which to associate the site. These are the same options available in the previous version of SharePoint Portal Server. These options are configurable and can even be eliminated altogether (which is good because I don't know of any organization that uses the default values). The key to altering these options lies in modifying the columns associated with the Sites list.

Follow these steps to modify the division and region options in MOSS:

Lists represent a broad umbrella of functionality in SharePoint that encompasses everything from document management to scorecards. This is because at the lowest level, SharePoint manages groups of items as lists regardless of what the items are. For administrative purposes, however, SharePoint divides list functionality into four distinct categories: Libraries, Communications, Tracking, and Custom lists. The Libraries category contains list types for managing documents. The Communications category contains list types for communicating with other people. The Tracking category contains list types for managing tasks, plans, and issues. The Custom category allows you to create a custom list to meet your own needs. In this section, I provide an overview of each list type.

Using Document Libraries

In many ways, libraries are the central feature of SharePoint. Nearly all site users will be involved with creating, retrieving, and sharing documents. You can create document libraries at any level in the site hierarchy and assign different permissions at the item or library level. This makes libraries useful for facilitating collaboration among organizational teams. What's more, you'll see in Chapters 6, 7, and 9 that document libraries are fully integrated with Microsoft Office 2007.

When a new site is created it often comes with predefined libraries. The softball site you created earlier uses the Team Site template, which comes with a document library suitable for managing all kinds of documents including Office documents, text documents, PDF documents, and others. In WSS, you can also elect to create a picture library, a form library, or a wiki library for managing images, InfoPath forms, and wiki pages, respectively. In MOSS, you can create additional types of libraries for managing documents in multiple languages, reports, data connections, and slide libraries of PowerPoint presentations.

When new documents are added to any library, a document profile is created based on the content type of the new document. A content type is a set of characteristicssuch as a document template, workflow processes, and propertiesthat uniquely define a document. Content types allow you to manage multiple kinds of documents within a single library. This is a great improvement over the previous version of SharePoint, which was designed to support only a single document profile for every document in a library. I discuss content types in greater detail throughout the book.

Once documents are part of a library, users can take advantage of the document management features built into SharePoint. These document management features include check-in, checkout, version control, initiating workflows, editing properties, and publishing. You may restrict the ability of users to utilize the document management feature set based on their membership in a security group, as I described earlier in the section "Managing Users." In this version of SharePoint, you may control these permissions at the document level, whereas the previous version controls them at the library level. Access to the document management features of a library is accomplished through a drop-down list associated with each document. Figure 3-3 shows the drop-down list for a document in a library.

Figure 3.3. Accessing document management functions

You can check out documents directly from the document library using the drop-down list. When a document is checked out, it is still listed in the document library and visible to site users, but the username of the person who checked it out is visible in the list. For each library, you may control whether to require a checkout before a document can be edited. If you do not require a checkout, the document can be opened in a read-only mode by other users.

Follow these steps to require checkout for a document library:

Once changes are made to a document, it may be saved back to the library and checked in. Users can be granted the authority to cancel an existing checkout by another person. This action causes the document to be checked back in to the library immediately; however, all changes made to the document since it was checked out are lost. This feature is primarily used to recover a checked-out document when the holder is unavailable for some reason.

By default, the document library overwrites the old document version with the new version and does not keep any history. If you would like to keep version history, you must enable it from the Versioning Settings page. These settings allow you to specify whether you want to create major or minor versions and how many versions to retain. Once versioning is enabled, you can access the version history page from the drop-down menu associated with a document. This page will list all of the document versions and allow you to restore any of them as the current version.

Along with version control, you can also enable content approval for a document library. When document approval is enabled, new documents will not be visible to the general population of site users. Instead, the documents must be approved before they become generally available. Rejections and approvals are issued directly in the portal using the drop-down menu associated with each document.

Using Form Libraries

A form library can be thought of as a special document library. The purpose of the form library is to store XML-based forms created through Microsoft InfoPath. For example, you might create a form library in the human resources area of the site that contains a vacation request form, a 401(k) change form, or a health insurance change form. In this way, key forms are centralized and easily located.

Creating a form library can be done directly in the SharePoint site if you have appropriate permissions. Unlike document libraries, form libraries do not generally exist by default. When you create a form library, it is given a default form template for use with the library, but you will certainly want to modify it. As with any library, you can have multiple content types associated with the form library.

To create a form library, follow these steps:

Once the form library is created, you can create and upload forms. Forms in InfoPath may be designed based on an existing template or a database schema or from scratch. All of the forms created with InfoPath are interactive with complete control sets such as list boxes, options, and text fields. Once the form is created, you can publish it to the form library.

Take these steps to publish a default InfoPath form:

Using Picture Libraries

Like form libraries, picture libraries are a special type of document library. These libraries are specifically intended to manage digital photography and images such as corporate logos and web site images. Although images can be stored in any document library, picture libraries have special features to view and use graphical content.

Uploading pictures into the library is similar to uploading any document or form and can be done using the Upload menu on the library toolbar. Once the images are uploaded, however, they may be presented in special views available only in the picture library. The images may also be edited with Microsoft Picture Manager or sent directly to any Office application for inclusion in a document.

Using Announcements

An announcements list is used to create a list of announcements with a title and a rich-text body. Announcements are simple list types that typically display the title and a few lines of the body on the home page of a site. Additionally, each item can be given an expiration date so that they are automatically hidden after a period of time.

Using Contacts

A contact list is used to track contact information about people. You can either type contact information directly into the list, or import the information from an address book. SharePoint contact lists can also be synchronized with Outlook contact lists by selecting Actions

Using Discussion Boards

Discussion boards are lists that can be used to start threaded discussions. Threaded discussions allow users to post topics and responses in a tree structure that keeps them together. Discussion boards are superior to e-mail threads when you want to preserve the discussion postings for reference.

Using Links

Link list items are hyperlinks to web pages of interest to a team or an organization. A blank list of links typically appears on any new site added to the portal. When users add links to the list, they provide the target URL and a description.

Using Calendars

Calendars are events associated with meetings, seminars, parties, and so on. When you create a new site, a blank calendar list typically appears on the home page. Users may enter new events directly from the home page and can also associate a document with the event. This is useful for linking directions or agendas with events. Calendars can be synchronized with Outlook by selecting Actions

Using Tasks

Task items form a to-do list for a team. When a new site is created, a blank task list is available. When you create a new task in the list, you may assign it to a team member. The list may then be viewed in summary to track all items for the team. Task lists can be synchronized with Outlook by selecting Actions

Using Project Tasks

Project task items are similar to normal task items except that they show the task list using a Gantt chart format. This list type is useful for creating mini project plans and tracking progress. Project task lists can be synchronized with Outlook by selecting Actions

Figure 3.4. A Gantt chart display

Using Issues Tracking

Issue tracking lists are used to track problems for resolution. This list type is used like a simple help-desk application that assigns an identifier to each issue, a person to resolve it, and a due date. You can also associate other related issues together.

Using Surveys

Surveys provide a way to poll portal users for input on a subject. When a site is first created, it usually does not have a survey associated with it. Once created, surveys support a wide variety of response types from simple yes/no answers to free-form text. When the survey is filled out, you may display a number of simple reports to show the results. The list also supports branching logic for surveys, which allows you to present questions based on the response to previous questions.

Using Custom Lists

Custom lists in SharePoint allow you to create your own list with your own field definitions. You can create your custom list either in a standard list format or in a datasheet view. Additionally, you can import an existing Excel spreadsheet to create a custom list in SharePoint.

Along with using lists to manage documents and items, you can also configure them to receive e-mail. E-mail-enabled lists are given their own e-mail addresses. When they receive mail, the message can be stored and any attached documents can be saved. Configuring e-mail-enabled lists first requires that you set up the SMTP service on the server running MOSS.

Follow these steps to install and configure the SMTP service:

Once the SMTP service is set up, you need to configure the general incoming e-mail settings for the farm. This is done through the Central Administration site. When you configure these settings, you can choose to simply relay incoming mail to the targeted list with no other frills, or you can choose to enable the directory management service (DMS). DMS is used to create mailing lists that you can use through Exchange and Outlook. This makes it easy to find addresses for lists in the same way that you find them for people.

Follow these steps to configure incoming e-mail settings:

Once the incoming e-mail settings are configured for the farm, you can finally enable an individual list to receive mail. Enabling a list is done through the settings associated with the list. In these settings, you specify the address to use for the list and options regarding the handling of attachments and the original mail message.

Follow these steps to e-mail-enable a list:

When you first create a site, it is made up of only the home page. However, you can add additional pages to the site at any time by using the Create page. Although you can access the Create page from the Site Settings page, it is often easier to simply select Site Actions

Follow these steps to create a new page:

WSS and MOSS support a set of zones that allow you to establish different access methodologies to a single web application. Zones are an administrative category, which you use to specify a different URL for accessing the same web application. The value of this configuration is that you can establish different authentication methods for different zones while delivering the same content to each zone.

When you first create a new web application, it is always created in the Default zone. The Default zone is always set up to utilize Windows authentication either through NTLM or Kerberos as you specify. If your web application will only be accessed inside the firewall, you can simply use the Default zone and not worry about any further configuration. However, if you want to make the same content available outside the firewall or change the authentication method, you should extend the web application into another zone.

Extending a web application is done from the Central Administration pages on the Application Management tab. Under the SharePoint Web Application Management section, there is a link titled Create or Extend Web Application. Whenever you extend an existing web application, you can choose to associate it with a zone. Figure 3-8 shows part of the administration page where you can select to extend an existing web application into another zone.

Figure 3.8. Extending an existing web application into another zone

Forms authentication uses a web form to collect a username and password that is submitted for verification against a credential store. This is a common way to authenticate users who are not members of the domain. The nice thing about Forms authentication is that you can use a SQL Server database or another Lightweight Directory Access Protocol (LDAP) source to authenticate the user. The data source you use is dictated by an authentication provider that is capable of authenticating users against the desired store. While you can use any authentication provider with SharePoint, common ones include SqlMembershipProvider for use with a SQL Server database; ActiveDirectoryMembershipProvider for use with Active Directory; and LDAPMembershipProvider for use with other LDAP sources such as Lotus Notes.

When you want to use Forms authentication, you must add a connectionStrings and a membership section to the web.config file of the web application. Additionally, you must add the same sections to the SharePoint Central Administration application so that permissions can be managed centrally. The exact syntax of the new sections varies, and you may have to perform some additional steps depending on what data store you will use. I cover the configuration details for key providers in the next few sections.

Authentication with SqlMembershipProvider

One of the most common scenarios with Forms authentication employs a SQL Server database as the credential store. The SqlMembershipProvider is used to authenticate users against a SQL database when that database utilizes the same schema as a standard ASP.NET 2.0 application. When Visual Studio 2005 is installed, it automatically configures an instance of SQL Express to serve as a credential store for any ASP.NET 2.0 applications. If you want to use a SQL Server 2005 database instead, it must be configured with the appropriate schema. Creating a credential store in SQL Server 2005 that can be used with Forms authentication in SharePoint is done using the ASPNET_REGSQL.EXE utility.

Follow these steps to create a credential store in SQL Server 2005:

When using SQL Server 2005 as the credential store, you are not provided with a good interface for initially populating the database with usernames. If no names are initially in the database, no one can be designated as the site administrator for managing additional users. Therefore, you have to find a way to get at least one name into the database before enabling Forms authentication.

The best option for entering users is to simply use the web site configuration tools that ship with Visual Studio 2005. These tools are preconfigured to work with an instance of SQL Express installed alongside Visual Studio. The strategy is to create an ASP.NET project and add a web configuration file that refers to the database you created earlier. Then you can configure the database directly from Visual Studio.

Follow these steps to edit the credential database with Visual Studio:

Once the credential store is created, you can add the new sections to the web.config files of the SharePoint sites. Remember, you must add the section to both the application you want to access and the Central Administration site. The configuration files are all located in subfolders in the path InetpubwwwrootwssVirtualDirectories. Here you will find a subdirectory for each of the web applications you have created and the Central Administration site.

For each file, create a connectionStrings section immediately before the <system.web> tag and a membership section immediately following the <system.web> tag. The connectionStrings section defines a valid connection string to access the credential database. The membership section provides configuration information for the SqlMembershipProvider class to use the information in the credential store. Listing 3-1 shows example sections with the <system.web> tag visible between them. These entries are based on the database you created earlier.

<connectionStrings>
  <add name="DBService"
  connectionString="Server=VSSQL;Database=aspnetdb;Integrated Security=SSPI;"
  providerName="System.Data.SqlClient" />
</connectionStrings>
<system.web>
  <membership defaultProvider="DB">
    <providers>
      <add connectionStringName="DBService"
        enablePasswordRetrieval="false"
        enablePasswordReset="true"
        requiresQuestionAndAnswer="true"
        applicationName="/"
        requiresUniqueEmail="false"
        minRequiredPasswordLength="1"
        minRequiredNonalphanumericCharacters="0"
        passwordFormat="Clear"
        maxInvalidPasswordAttempts="5"
        passwordAttemptWindow="10"
        passwordStrengthRegularExpression=""
        name="DB"
        type="System.Web.Security.SqlMembershipProvider,

          System.Web, Version=2.0.0.0, Culture=neutral,

          PublicKeyToken=b03f5f7f11d50a3a" />
    </providers>
  </membership>

After the configuration files are updated, you are ready to enable Forms authentication. This is done through the Central Administration site. In the Central Administration site, you will switch the provider for the extended web application from Windows to Forms authentication.

Follow these steps to enable Forms authentication:

Once the initial user has been given rights to the site you can open the site in a browser. You should see a login page where you can type the credentials you entered into the database earlier. Because you granted full control to this user, you can now use the Site Settings from within the site to add new users and give them rights.

Authentication with ActiveDirectoryMembershipProvider

The ActiveDirectoryMembershipProvider is an authentication provider for use with Active Directory. Using this provider, you can set up Forms authentication for users who have accounts within the domain. This type of authentication is good for creating extranet solutions where you want to provide a login screen rather than just popping up the ugly gray Windows authentication box. Exercise 3.1 at the end of this chapter uses the ActiveDirectoryMembershipProvider to create an extranet, so I will not cover it in detail here.

Authentication with LDAPMembershipProvider

MOSS ships with an additional authentication provider called LDAPMembershipProvider. The LDAPMembershipProvider allows you to authenticate users against other LDAP sources such as Lotus Notes. This provider is most useful for environments that are not using Active Directoryalthough it certainly could be used with Active Directory, which is LDAP-compliant. Like all of the other providers, the LDAPMembershipProvider requires you to make connectionString and membership entries in the web configuration file. Listing 3-2 shows an example configuration for the provider for the Active Directory you set up in Chapter 2.

<membership defaultProvider="LDAP">
 <providers>
  <add name="LDAP"
    type="Microsoft.Office.Server.Security.LDAPMembershipProvider,

      Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral,

      PublicKeyToken=71E9BCE111E9429C"
    server="VSPDC" port="389"
    useSSL="false" userDNAttribute="distinguishedName"
    userNameAttribute="sAMAccountName"
    userContainer="CN=Users,DC=domain,DC=local"

userObjectClass="person"
    userFilter="(|(ObjectCategory=group)(ObjectClass=person))" scope="Subtree"
    otherRequiredUserAttributes="sn,givenname,cn" />
 </providers>
</membership>

In addition to the authentication providers already discussed, SharePoint also gives you the option to use a web single sign-on service for authentication. A web single sign-on service is a separate third-party service used to provide authentication across many disparate systems. Windows Live ID service is an example of a web single sign-on service. In addition to registering a provider in the web configuration file, these types of providers also require you to register an HTTP module with specific information about the provider. Web single sign-on providers are beyond the scope of this book.

The final authentication option available in SharePoint is a special account mode known as Active Directory Account Creation (ADAC). This mode is intended for use by Internet service providers (ISPs) who support large constituencies that are not members of the hosting domain. In ADAC mode, users can self-register using e-mail addresses instead of domain accounts. In this way, an ISP can host Internet users without having to specifically add them to a domain.

It's important to note that ADAC is incompatible with the normal domain account mode. During the installation of WSS, you select the mode in which the farm will operate. After you make the selection, you cannot alter it. Throughout this book, I assume that SharePoint Services are operating in domain account mode.

When you create a new web application in WSS or MOSS, it is configured by default to utilize internal server names and URLs. This means that a web application in the Default zone is not initially suitable for exposure outside the firewall. If you were to simply forward port 80 from your firewall to the internal IP address of the SharePoint server, you would discover that external users are redirected to the internal name of the server and access would fail. In order to make external access function correctly, you must provide an alternate access mapping that directs the incoming URL to the SharePoint web application. Incoming URLs are associated with a specific zone so you can limit the mapping to a given set of users.

Establishing alternate access maps is done through the Central Administration site on the Operations tab. Figure 3-9 shows a page from the Central Administration site with some mappings defined. Exercise 3.1 at the end of this chapter covers the steps necessary to create alternate mappings for an externally facing site.

Figure 3.9. Alternate access mappings

When you create or extend a web application, you will have the option to enable SSL. Enabling SSL provides an extra level of security based on certificates and encryption. In order to enable SSL for SharePoint, you must obtain and install a server certificate on any IIS web sites that will be accessed through SSL. Exercise 3.1 walks you through the process of creating a secure site with SSL enabled.

When you created your first web application in Chapter 2, it was created in the Default zone using Windows authentication. Generally speaking, it is a good idea to always use Windows authentication in conjunction with the Default zone so that users inside the firewall can access the web application. If you want to make the web application available outside the firewall, you should extend it into the Internet or Extranet zone. In this exercise, you will extend the existing web application into the Extranet zone in order to create a secure site.

Follow these steps to extend the existing web application into the Extranet zone:

Creating an alias for your web site is a simple matter of making a new record entry in the Domain Name Service for the network. Creating an alias will allow you to use a name such as sharepoint.domain.local when accessing a web application. Although you will create your alias solely for internal use, you can create an alias for external use and map it to an IP address that will expose the portal on the Internet.

Follow these steps to create an alias for the SharePoint server:

Server certificates can be purchased commercially from a trusted source such as VeriSign, or you can create your own using Microsoft Certificate Services. In our exercise, we will install and utilize Microsoft Certificate Services. Making your own certificates is fine for testing and limited production use, but if you are going to allow access to the portal to a wide audience, you should consider getting a certificate from a trusted provider.

Adding the Application Server Role

IIS is required in order to make certificates available for download and distribution. Therefore, you must install IIS before installing Certificate Services. Follow these steps to configure VSPDC:

Adding Certificate Services

Once IIS is installed, you may proceed to add Certificate Services to the server. This will allow you to issue your own trusted certificates to SharePoint servers. Follow these steps to install Certificate Server:

Creating a certificate begins by preparing a request using the virtual server that you want to secure. This server prepares a text file that may then be submitted to Certificate Services. In this exercise, you can create a request for either VSWSS or VSMOSS depending upon whether you installed WSS or MOSS in Chapter 2.

Follow these steps to prepare a request:

Once the request is prepared, you may use it to create a new certificate. Certificate Services uses the text file created under IIS to generate the certificate. The new certificate may then be installed on the SharePoint server.

Follow these steps to create the new server certificate:

Once the new certificate is created, you can install it on the SharePoint server. When using the Microsoft Certificate Services, you must install the certificate file with the P7B extension. This file will establish the appropriate trusts to ensure that you can view the web application.

To install the new certificate, do the following:

Forms authentication allows you to configure a SharePoint page as a login form instead of utilizing Windows authentication directly. SharePoint supports many different providers for authenticating users against other data stores such as SQL Server or an LDAP service. In this exercise, you will make use of the ActiveDirectoryMembershipProvider to configure Forms authentication against Active Directory. In this scenario, users will enter their Windows credentials into the login form to gain access to the secure site.

Follow these steps to set up Forms authentication:

Whenever you use an alias or external IP address to access a SharePoint site, you must set up alternate access mappings or else the authentication will fail. This is because SharePoint will deliver URLs that reference internal server names by default. In this exercise, you need to add a new incoming URL because the project site uses an alias.

Follow these steps to specify an incoming URL:

Once the certificate is installed on the SharePoint server, you are ready to utilize SSL. When users access the portal through SSL, they will initially see the certificate warning. They can subsequently install the certificate on their machines and trust your root authority. This will allow them to access the portal without acknowledging the certificate each time.

Follow these steps to test secure communications:

Figure 3.10. Forms authentication on a secure site