Published: February 28, 2008

Introduction

As a result of reading the companion document, Choosing an External Collaboration Solution, of the External Collaboration Toolkit for SharePoint (ECTS) you may have decided that an internally hosted collaboration solution based on Microsoft® SharePoint® Products and Technologies is the best fit for your small or mid-sized organization.

This document walks you through the planning process to help you deploy the solution in your environment. It describes the decisions that you can make in advance of deployment and explains the other planning activities that such a deployment entails.

Determine Scale of SharePoint Deployment

Extranet SharePoint deployments are no different from other SharePoint deployments in terms of how you plan for availability and responsiveness of the collaboration sites. For more information, see the Plan for availability documentation on the Microsoft Office SharePoint Server site.

Plan Your Network Infrastructure

Before you deploy the external collaboration solution, you need to plan your network infrastructure. For more information about planning your network infrastructure, see the Design extranet farm topology documentation on the Office SharePoint Server site.

Plan for Security

Because the information that you share externally might be of high value, you should give special consideration to ensure the security of the entire collaboration environment. For more information about this important planning step, see the following documentation:

·         If you will deploy Windows SharePoint Services 3.0, see Plan for and design security (Windows SharePoint Services).

·         If you will deploy Office SharePoint Server 2007, see Plan for and design security (Office SharePoint Server).

·         Because the SharePoint server will be accessible from the Internet, it is important that it be protected by a firewall. For more information about the firewall offering from Microsoft, see Microsoft Internet Security and Acceleration Server 2006.

·         Because the collaboration site will store files, it is important that you protect it against malware. Microsoft Forefront™ Security for SharePoint provides this capability, as well as file-type and keyword filtering.

·         For enhanced security, Microsoft Intelligent Application Gateway 2007 is a comprehensive remote access solution that can easily publish SharePoint and a variety of other applications for employees, partners and customers.

Plan for Isolation of Workspaces

Many collaborative projects are somewhat sensitive in that you might not want the documents and information that you share with one company to be visible or readable by people from another company. Sometimes the collaboration is so sensitive that you’ll want to ensure that your external collaborators do not even know that you have collaborative projects with other companies.

Isolation between collaborative efforts is something that most solutions should include as a key characteristic. Best practices for isolation include to:

• Use different site collections for each collaborative effort. Collaborative sites that are peer sites in the same site collection can easily be misconfigured such that permissions are granted to users of multiple sites—including sites to which they shouldn’t have permissions. Also, Office SharePoint Server features such as Search are generally cross-site but will not provide results across different site collections.
• Decide which users can search for other users. In some cases you might not want to let your external users search to see whether people from other organizations are collaborating with your organization. Because the SharePoint people picker will generally search the entire account store, it might be a good idea to limit the ability of external users to view the Set Permissions page in SharePoint.

Plan for External User Management

As you plan for your external collaboration solution based on SharePoint, an important consideration is how users outside your organization will be provisioned and managed in an account store and how they will authenticate to your collaboration Web site.

Choose an Authentication Mechanism

SharePoint sites can be extended to different zones that support different authentication mechanisms than the Integrated Windows authentication that is typically used for intranet SharePoint sites. For external collaboration, the SharePoint administrator will typically extend the collaboration site to an extranet zone and then configure authentication that is appropriate for external users. There is general consensus that forms-based authentication offers the best user experience for Internet users. The rest of this planning guide assumes that you use forms-based authentication for your collaboration site.

When the extranet zone is configured to use forms-based authentication, the next step is to select a membership provider. SharePoint is based on the .NET membership provider framework, which allows for an abstraction between the API that is used to validate the credentials entered into the forms interface and the account store that holds the details of the user, including their user name and password. For more information about the membership providers included with Microsoft Windows Server® 2003 R2 and Office SharePoint Server 2007, see Authentication samples on the Microsoft Office System site.

Integrating with the 2007 Microsoft Office System

Users of Office SharePoint Server 2007 and Windows® SharePoint Services 3.0 who also have the 2007 Microsoft Office system installed enjoy a high level of integration between the 2007 Office system and SharePoint Products and Technologies. Many of those integration features, however, depend on Windows authentication and do not function correctly with forms-based authentication. With forms-based authentication, some integration points do not work, and others change considerably.

If the external users that your organization will collaborate with are familiar with the integration features, some documentation, training, or education about the lack of integration features with forms-based authentication might be necessary. For more information about using the integration features and forms-based authentication, see Forms Authentication in SharePoint Products and Technologies: Forms Authentication vs. Windows Authentication.

Account Store Options

Given that the ECTS uses forms-based authentication, you still need to decide what kind of repository to use to store the account objects that represent the external users. One option that avoids the overhead of account management is to use the relatively new federated identity technologies included with Windows Server 2003 R2. Using federated identity means you don’t have to have an account store for external users at all because all account management happens in the external user’s organization.

The following options are all possibilities to consider as account stores for external users:

• Federated identity
• Active Directory® Domain Services (AD DS)
• Active Directory Application Mode (ADAM)
• Microsoft SQL Server®
• Lightweight Directory Access Protocol (LDAP)

Note   Regardless of where your organization stores information about external users, you should ensure that you adhere to your organization’s privacy policies, because some of the information that your solution will store in order to identify users is, by definition, personally identifiable information (PII).

Federated Identity

Using the federated identity capabilities included with Windows Server 2003 R2 for user account management and authentication may be the most elegant solution because the partner organization manages their own accounts and you, as a resource provider, don’t have to manage accounts at all. For more information about federation technologies and how they can be used with SharePoint for extranet collaboration, see Configure Web SSO authentication by using ADFS (Office SharePoint Server).

Using Active Directory Federation Services (AD FS) might be a great solution for external collaboration, but it does require that your collaboration partners deploy federation technologies of their own. This may only be feasible when two companies have a stable long-term collaborative effort and the business benefit of collaborating efficiently makes infrastructure investment worthwhile. Ad hoc collaboration efforts are more prevalent in most organizations so your organization may need to provide a solution that does not rely on federation.

Without federation, you will need to design a solution that includes an account store where the external user accounts will reside.

Active Directory Domain Services

Active Directory Domain Services (AD DS) is the LDAP directory where user accounts that represent employees of your own organization are located. It is certainly possible to add external user accounts to your internal Active Directory infrastructure. In fact, this is probably the simplest possible solution because if you take this approach, SharePoint will work in your external collaboration scenario almost immediately.

The problem with this approach is that creating external user accounts in the internal Active Directory forest typically gives those external users capabilities that you probably do not want them to have. For example if the external user has an account in your Active Directory forest, they could probably log on to most of the desktop computers in your organization if they could gain physical access to them. It is possible to create accounts in AD DS that are not capable of doing much on the internal network, but it requires a level of administrative effort that most organizations would not want to undertake.

Another option is to set up a completely separate Active Directory forest to house the accounts for the external users. Although this approach works and avoids the problems associated with placing the users in the intranet Active Directory forest, there is a somewhat simpler solution using Active Directory Application Mode.

Active Directory Application Mode

As an account store for external users, Active Directory Application Mode (ADAM) provides many advantageous features. Based on Active Directory technology, ADAM is robust and scales well to very large numbers of user objects. Because ADAM is architecturally similar to Active Directory, management tools that work on Active Directory typically work on ADAM, or, if necessary, can be modified to do so relatively easily.

SQL Server

SQL Server works perfectly well as an account store for external users. Organizations that have personnel who have existing expertise in SQL Server and little or no experience with LDAP-based directories often choose to use SQL Server. Such organizations can usually create account management tools or scripts quite easily by borrowing components from similar applications.

Lightweight Directory Access Protocol (LDAP)

LDAP servers other then ADAM could be used as an account store for external users, but there may be other considerations. For example, the LDAP membership provider is included with Office SharePoint Server 2007 but not with Windows Server 2003 R2 and Windows SharePoint Services. If your requirements are such that an LDAP server will be the basis for your external user account store, you should consider using Office SharePoint Server.

Planning for External User Management Processes

An important part of the planning process for external collaboration is designing management processes for managing the accounts used by people external to your organization. The most critical processes to consider are:

• Account provisioning
• Granting permissions
• Password reset
• Active Directory and ADAM Password Policies

Account Provisioning

Getting an account set up in the chosen user account store is a process that can be implemented in a couple of different ways. Some organizations require that internal people, such as the Project Manager for the collaboration project, initiate account setup requests for external collaborators. In some organizations such requests can be approved automatically, whereas organizations that want more control might require administrator approval for each request.

The act of making the account setup request could be a manual process or could achieve a level of automation using e-mail, a separate Web application, or possibly an interface presented within SharePoint. Similarly the administrator approval process could be completely manual or streamlined through specialized interfaces. A manual process could include an administrator creating an account in Active Directory using the Active Directory Users and Computers MMC snap-in, creating an account in ADAM using ADSI Edit, or using specially designed interfaces with built-in workflow capabilities such as those that the ECTS provides.

At the very minimum, the solution designer should walk through the process they imagine using to ensure that their targeted user population can understand and efficiently interact with whatever interfaces the organization would like to use.

Another item to consider and address in the planning process is to understand how external user accounts will be named. Although it is possible to use the same type of naming scheme that you use for internal user accounts, you should consider using the external user’s full e-mail address as their account name. E-mail addresses are guaranteed to be unique, are easily remembered by both internal users and the external user, and might provide information about the organization to which the external user belongs.

Granting Permissions

Granting permissions in the SharePoint environment means being able to type a user account name into the SharePoint people picker, having it resolve against an identity store, and then selecting which permission to grant. This process reinforces the idea that using e-mail addresses as external user names is a good idea because the external user’s e-mail address is one of the more readily remembered pieces of information about the external user.

When planning an external collaboration solution based on SharePoint, special consideration should be given to whether to grant permissions using cross-site groups or explicitly. Cross-site groups are useful in that they can grant permissions across many sites at once, but this might not be advantageous in an external collaboration solution. Consider a cross-site group named Document Viewers. If this group has permissions across sites that are used to collaborate with different companies, some of which compete with each other, users could navigate to their competitor’s site and might be able to read documents there. Clearly, this is not the best outcome!

A better solution is to create groups that have permissions only within a particular site or to assign user permissions directly. The ECTS includes components that create groups in the correct scope and a user interface that helps guide the owner of the collaboration project site down the right path as they grant permissions to external users.

Password Reset

Password reset functionality for forgotten passwords is an important consideration when dealing with external users. If your site will be used infrequently by some or all of the external collaborators, forgotten passwords are inevitable. You should design a solution that includes provisions for self-service password reset and pay particular attention to the security of the mechanisms you provide for doing so.

One option is to allow external users to request a password reset by clicking a button on the forms-based logon page. When they click the button, a newly generated password could be sent directly to the user by e-mail or delivered to some previously designated internal contact (either help desk, the site administrator, or possibly the internal collaboration coordinator) for delivery to the external user by some other mechanism such as a phone call. The mechanism you select for your organization will need to balance administrative overhead and security.

Active Directory and ADAM Password Policies

If your account store plan is either to host external users in your organization’s Active Directory domain or in a domain-joined instance of ADAM, special planning is required.

In such a situation you might encounter complicating factors. For example, the domain may have strict password policies that enforce complex passwords or expire passwords on a relatively short interval such as 45 days. These same password policies will apply to external users in the Active Directory domain or the domain-joined ADAM. In this scenario, ADAM inherits the domain policies for password complexity and expiration by default.

The most important planning task related to password complexity and expiration is to document the current domain policies and understand how they will impact external users. External users who aren’t aware of password complexity rules could face a poor user experience if they are unable to create passwords of sufficient complexity. Similarly, a short password expiration cycle might not work for projects in which external users could go weeks or months between visits to the collaboration site. There are possible combinations of password expiration policy and site visitation patterns that could lead to the user having an expired password every time they visit your collaboration site!

Typically, a user with an expired password will require assistance from IT or help desk personnel in order to reset the expired password so they can log on. Because this would raise the relative cost of your collaboration solution, you should consider whether hosting users in the organization’s Active Directory domain is the best approach. For solutions that use domain-joined ADAM, you may want to consider overriding internal password policies. For more information on this topic, see the “Password policy settings and account lockouts” heading in the How Active Directory Application Mode Works documentation on Microsoft TechNet.

Plan for Administrative Roles

During an external collaboration project, certain administrative functions will be performed by designated personnel within your organization. Roles that must be filled include those who are involved in the management of SharePoint, which includes the setup and deactivation of site collections, Web Parts, and other optional components such as SharePoint lists. Additional roles to be filled include administrative responsibilities for the management of the accounts used by external users.

Planning for SharePoint Administrative Roles

As discussed previously in this document, your external collaboration solution will likely require that new site collections be created in SharePoint for each collaborative effort. You need to identify internal users who have the correct skill set and then establish processes for the performance of site administration.

Other administrative operations that should be assigned to specific personnel include:

• Monitoring of collaboration sites for proper use
• Backup and recovery of sites and documents
• Deactivation and archival of sites that no longer need to be kept in service

The ECTS provides components to streamline the administrative processes of creating new collaboration sites and includes additional functionality such as approval and workflow.

Planning for Account Administrative Roles

This document also discussed previously the requirements to create users in the chosen account store. Again, you need to identify internal users who have the correct skill set and then establish processes for the performance of site administration. Administrators can be given responsibilities to perform both SharePoint and Account administrative functions or the responsibilities can be shared among additional administrators.

Specific actions related to account management that must be assigned to an administrator include:

• Account creation
• Password reset
• Account profile updates
• Account deactivation and permission removal
• Permission problems

The ECTS provides components to streamline the administrative processes of account creation and maintenance and includes additional functionality such as approval and workflow.

Summary

This document described the planning process for deploying an internally hosted SharePoint-based collaboration solution in your small or mid-sized organization.

For more information about deploying the ECTS, see the companion Deployment and Operations Guide.