SharePoint Security - NETWORKOLOGIST Security Overview.pdf · based on Security Assertion Markup...

SharePoint Security

This document is provided "as-is". Information and views expressed in this document, including URL and other Internet Web site references, may change without

notice. This document does not provide you with any legal rights to any intellectual property in any Microsoft product or product name. You may copy and use

this document for your internal, reference purposes. You may modify this document for your internal, reference purposes.© 2013 Microsoft. All rights reserved.Terms of Use (http://technet.microsoft.com/cc300389.aspx) | Trademarks (http://www.microsoft.com/library/toolbar/3.0/trademarks/en-us.mspx)

Table Of ContentsChapter 1

Authentication planning

Configure claims authentication

People Picker and claims provider planning

Security planning for sites and content

Security

Security hardening

Automatic password change planning

User permissions and permission levels

Business Connectivity Services security overview

http://technet.microsoft.com/en-us/library/ee782549(v=office.14).aspx


http://technet.microsoft.com/en-us/library/gg602063(v=office.14).aspx

http://technet.microsoft.com/en-us/library/cc288189(v=office.14).aspx

http://technet.microsoft.com/en-us/library/hh377939(v=office.14).aspx





Chapter 1

Plan authentication (SharePoint Foundation 2010)

Applies to: SharePoint Foundation 2010

Topic Last Modified: 2011-12-12

This section describes how to plan for authentication.

In this section:

Plan authentication methods (SharePoint Foundation 2010)

People Picker and claims provider planning (SharePoint Foundation 2010)

Plan for Kerberos authentication (SharePoint Foundation 2010)

Forefront UAG integration (SharePoint Foundation 2010)

Claims-based authentication with Microsoft UAG 2010 (SharePoint Foundation 2010)

Plan for claims-based authentication or classic-mode authentication (SharePoint Foundation 2010)

© 2014 Microsoft



http://technet.microsoft.com/en-us/library/ff607695(v=office.14).aspx




http://privacy.microsoft.com/en-us/default.mspx

Plan authentication methods (SharePoint Foundation 2010)



This article describes the authentication methods and authentication modes that are supported by Microsoft SharePoint Foundation 2010.

Authentication is the process of validating a user's identity. An authentication method is a specific exchange of account credentials and other attributes that assert that

identity. After a user's identity is validated, the authorization process determines which sites, content, and other features the user can access.

In this article:

Supported authentication methods

Authentication modes — classic or claims‐based

Implementing Windows authentication methods

Implementing forms-based authentication

Implementing SAML token-based authentication

Choosing authentication for LDAP environments

Planning zones for Web applications

Architecture for SAML token-based providers

Supported authentication methods

SharePoint Foundation 2010 supports authentication methods that were included in previous versions and also introduces support for token-based authentication that is

based on Security Assertion Markup Language (SAML). The following table lists the supported authentication methods.

Method category Authentication methods Notes

Windows authenticationNTLM

Kerberos

Anonymous

Basic

Digest

Forms-based authenticationLightweight Directory Access

Protocol (LDAP)

Microsoft SQL Server database or

other database

Custom or third-party

membership and role providers

SAML token-based authentication (new with

SharePoint Foundation 2010) Active Directory Federation

Services (AD FS) 2.0

Third-party identity provider

Lightweight Directory Access

Protocol (LDAP)

Supported only with SAML 1.1 that uses the WS-Federation Passive

Requestor Profile (WS-F PRP).

Client certificate authentication is possible through integration with AD

FS 2.0.

For additional information, see Configure Client Certificate

Authentication (SharePoint Foundation 2010).

Authentication modes — classic or claims‐based

Authentication modes determine how client computers authenticate with SharePoint Foundation 2010 resources. SharePoint Foundation 2010 introduces support for a

claims-based authentication mode. You can use any of the supported authentication methods with the claims-based authentication mode or you can use classic mode

authentication, which supports only Windows authentication.

User identity in Active Directory Domain Services (AD DS) is based on a user account. For successful authentication, the user provides the account name and proof of

knowledge of the password. To determine access to resources, applications might need to query AD DS for account attributes and other information, such as group

membership or role on the network. While this works well for Windows environments, it does not scale to third-party authentication protocols and directory providers

and multi-vendor environments that support Internet, partner, or cloud-based computing models.

Claims-based identity is based on the user obtaining a security token that is digitally signed by a commonly trusted identity provider and contains a set of claims. Each


claim represents a specific item of data about the user such as his or her name, group memberships, and role on the network. Claims-based authentication is user

authentication that utilizes claims-based identity technologies and infrastructure. Applications that support claims-based authentication obtain the security token from the

user and use the information within the claims to determine access to resources. No separate query to a directory service like AD DS is needed.

Claims-based authentication in Windows is built on Windows Identity Foundation (WIF), which is a set of .NET Framework classes that is used to implement claims-based

identity. Claims-based authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as SAML.

For more information about claims-based authentication, see the following resources:

Claims-based Identity for Windows (white paper) (http://go.microsoft.com/fwlink/p/?LinkId=198942)

Windows Identity Foundation home page (http://go.microsoft.com/fwlink/p/?LinkId=198943)

For new deployments of SharePoint Foundation 2010, we recommend claims-based authentication. If you use claims-based authentication, all supported authentication

methods are available for your Web applications.

When you create a Web application, you select one of the two authentication modes to use with the Web application, either claims-based or classic-mode.

If you select Classic-Mode Authentication, you can configure the Web application to use Windows authentication and the user accounts are treated by SharePoint

Foundation 2010 as Active Directory Domain Services (AD DS) accounts.

If you select Claims-Based Authentication, SharePoint Foundation 2010 automatically changes all user accounts to claims identities, resulting in a claims token for each

user. The claims token contains the claims pertaining to the user. Windows accounts are converted into Windows claims. Forms-based membership users are

transformed into forms-based authentication claims. Claims that are included in SAML-based tokens can be used by SharePoint Foundation 2010. Additionally,

SharePoint developers and administrators can augment user tokens with additional claims. For example, Windows user accounts and forms-based accounts can be

augmented with additional claims that are used by SharePoint Foundation 2010.

A SharePoint Foundation 2010 farm can include a mix of Web applications that use both modes. Some services do not differentiate between user accounts that are

traditional Windows accounts and Windows claims accounts. For example, a user who belongs to sites that are configured to use a mix of authentication modes may

receive search results that include results from all the sites that the user has access to, regardless of the authentication mode that is configured for Web applications. In

this scenario, the user is not interpreted as multiple user accounts. This is because services and service applications use claims identities for inter-farm communication

regardless of the mode that is selected for Web applications and users. However, users who belong to more than one user repository that is recognized by SharePoint

Foundation Web applications are treated as separate user accounts, depending on which identity they use to log in.

You do not have to be a claims architect to use claims-based authentication in SharePoint Foundation 2010. However, implementing SAML token-based authentication

requires coordination with administrators of your claims‐based environment, as described in the “Implementing SAML token‐based authentication” section of this article.

Implementing Windows authentication methods

The process of implementing Windows authentication methods is similar for both authentication modes (classic or claims-based). Choosing claims-based authentication

for a Web application does not increase the complexity of implementing Windows authentication methods. This section summarizes the process for each method.

Kerberos and NTLM

Both the Kerberos protocol and NTLM are Integrated Windows authentication methods, which let users seamlessly authenticate without being prompted for credentials.

Users who access SharePoint sites from Internet Explorer will authenticate by using the credentials the Internet Explorer process is running under. By default, these

credentials are the credentials that the user used to log on to the computer. Services or applications that access SharePoint Server resources using Integrated Windows

authentication methods will attempt to authenticate by using the credentials of the running thread, which by default is the identity of the process.

NTLM is the simplest form of Windows authentication to implement. Simply select this option when you are creating a Web application.

Kerberos is a secure protocol that supports ticketing authentication. Use of the Kerberos protocol requires additional configuration of the environment. To enable

Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). Configuring the Kerberos

protocol involves setting up service principal names (SPNs) in AD DS before you install SharePoint Foundation 2010.

The following steps summarize the process of configuring Kerberos authentication:

1. Configure Kerberos authentication for SQL Server communications by creating SPNs in AD DS for the SQL Server service account.

2. Create SPNs for Web applications that will use Kerberos authentication.

3. Install the SharePoint Foundation 2010 farm.

4. Configure specific services within the farm to use specific accounts.

5. Create the Web applications that will use Kerberos authentication.

For more information, see Plan for Kerberos authentication (SharePoint Foundation 2010).

http://go.microsoft.com/fwlink/p/?LinkId=198942



Additionally, for claims-authentication Web applications, the Claims to Windows Token Service (C2WTS) must be configured for constrained delegation. Constrained

delegation is required to convert claims to Windows tokens.

Note

The C2WTS does not support crossing domain boundaries between forests.

Kerberos authentication allows delegation of client credentials to access back-end data systems, which requires additional configuration depending on the scenario. The

following table provides examples.

Scenario Additional configuration required

Delegating a client's identity to a back-end server.

Displaying RSS feeds to authenticated content.

Configure Kerberos constrained delegation for computers and service accounts.

Identity delegation for Microsoft SQL Server Reporting Services (SSRS) Configure SPNs for SQL Server Reporting Services accounts.

Configure delegation for SQL Server Reporting Services.

Identity delegation for Excel Services in SharePoint Configure constrained delegation for servers that run Excel Services.

Configure constrained delegation for the Excel Services service account.

For more information about how to configure Kerberos authentication, including configuration steps for common scenarios, see Configuring Kerberos Authentication for

Microsoft SharePoint 2010 Products and Technologies (white paper) (http://go.microsoft.com/fwlink/p/?LinkID=197178).

Digest and Basic

Implementing Digest and Basic authentication requires configuring these authentication methods directly in Internet Information Services (IIS).

Implementing forms-based authentication

Forms-based authentication is an identity management system that is based on ASP.NET membership and role provider authentication. In SharePoint Foundation 2010,

forms-based authentication is available only when you use claims-based authentication.

Forms-based authentication can be used against credentials stored in AD DS, in a database such as a SQL Server database, or in an LDAP data store such as Novell

eDirectory, Novell Directory Services (NDS), or Sun ONE. Forms-based authentication enables user authentication based on validation of credential input from a logon

form. Unauthenticated requests are redirected to a logon page, where the user must provide valid credentials and submit the form. If the request can be authenticated,

the system issues a cookie that contains a key for reestablishing the identity for subsequent requests.

To use forms-based authentication to authenticate users against an identity management system that is not based on Windows or that is external, you must register the

membership provider and role manager in the Web.config file. Registering the role manager is a new requirement for SharePoint Foundation 2010. In the previous

version, this was optional. SharePoint Foundation 2010 uses the standard ASP.NET role manager interface to gather group information about the current user. Each

ASP.NET role is treated as a domain group by the authorization process in SharePoint Foundation 2010. You register role managers in the Web.config file the same way

that you register membership providers for authentication.

If you want to manage membership users or roles from the SharePoint Central Administration Web site, you must register the membership provider and the role

manager in the Web.config file for the Central Administration Web site. You must also register the membership provider and the role manager in the Web.config file for

the Web application that hosts the content.

For detailed steps to configure forms-based authentication, see Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010)

For additional information about forms-based authentication, see the following resources:

MSDN blog article: Claims-based authentication "Cheat Sheet" Part 1 (http://go.microsoft.com/fwlink/p/?LinkId=198944)

MSDN article: Forms Authentication in SharePoint Products and Technologies (Part 2): Membership and Role Provider Samples (http://go.microsoft.com/fwlink/p/?

LinkId=198945)

For information about features that do not work with forms-based authentication or features that require additional configuration in order to work with forms-based

authentication, see Plan for claims-based authentication or classic-mode authentication (SharePoint Foundation 2010).

Implementing SAML token-based authentication

SAML token-based authentication requires coordination with administrators of a claims-based environment, whether it is your own internal environment or a partner

environment. AD FS 2.0 is an example of a claims-based environment.

A claims-based environment includes an identity provider security token service (IP-STS). The IP-STS issues SAML tokens on behalf of users who are included in the

associated user directory. Tokens can include any number of claims about a user, such as a user name and groups the user belongs to.

SharePoint Foundation 2010 takes advantage of claims that are included in tokens provided by an IP-STS to authorize users. In claims environments, an application that

accepts SAML tokens is known as a relying party STS (RP-STS). A relying party application receives the SAML token and uses the claims inside to decide whether to grant

the client access to the requested resource. In SharePoint Foundation 2010, each Web application that is configured to use a SAML provider is added to the IP-STS

server as a separate RP-STS entry. A SharePoint farm can include multiple RP-STS entries.

http://go.microsoft.com/fwlink/p/?LinkID=197178





Implementing SAML token-based authentication with SharePoint Foundation 2010 involves the following processes that require planning in advance:

1. Export the token-signing certificate from the IP-STS. This certificate is known as the ImportTrustCertificate. Copy the certificate to a server in the SharePoint

Foundation 2010 farm.

2. Define the claim that will be used as the unique identifier of the user. This is known as the identity claim. Many examples of this process use the user e-mail name

as the user identifier. Coordinate with the administrator of the IP-STS to determine the correct identifier because only the owner of the IP-STS knows the value in

the token that will always be unique per user. Identifying the unique identifier for the user is part of the claims-mapping process. Claims mappings are created by

using Windows PowerShell.

3. Define additional claims mappings. Define the additional claims from the incoming token that will be used by the SharePoint Foundation 2010 farm. User roles are

an example of a claim that can be used to assign permissions to resources in the SharePoint Foundation 2010 farm. All claims from an incoming token that do not

have a mapping will be discarded.

4. Create a new authentication provider by using Windows PowerShell to import the token-signing certificate. This process creates the SPTrustedIdentityTokenIssuer.

During this process, you specify the identity claim and additional claims that you have mapped. You must also create and specify a realm that is associated with

the first SharePoint Web applications that you are configuring for SAML token-based authentication. After the SPTrustedIdentityTokenIssuer is created, you can

create and add more realms for additional SharePoint Web applications. This is how you configure multiple Web applications to use the same

SPTrustedIdentityTokenIssuer.

5. For each realm that is added to the SPTrustedIdentityTokenIssuer, you must create an RP-STS entry on the IP-STS. This can be done before the SharePoint Web

application is created. Regardless, you must plan the URL before you create the Web applications.

6. Create a new SharePoint Web application and configure it to use the newly created authentication provider. The authentication provider will appear as an option

in Central Administration when claims mode is selected for the Web application.

You can configure multiple SAML token-based authentication providers. However, you can only use a token-signing certificate once in a farm. All providers that are

configured will appear as options in Central Administration. Claims from different trusted STS environments will not conflict.

If you are implementing SAML token-based authentication with a partner company and your own environment includes an IP-STS, we recommend that you work with the

administrator of your internal claims environment to establish a trust relationship from your internal IP-STS to the partner STS. This approach does not require adding an

additional authentication provider to your SharePoint Foundation 2010 farm. It also allows your claims administrators to manage the whole claims environment.

Important

You need to set network load balancing to single affinity when using claims-based authentication. If you use SAML token-based authentication with AD FS on a

SharePoint Foundation 2010 farm that has multiple Web servers in a load-balanced configuration, there will be an effect on the performance and functionality of client

Web-page views. When AD FS provides the authentication token to the client, that token is submitted to SharePoint Foundation 2010 for each permission-restricted

page element. If the load-balanced solution is not using affinity, each secured element is authenticated to more than one SharePoint Foundation 2010 server, which

will result in rejection of the token. After the token is rejected, SharePoint Foundation 2010 redirects the client to authenticate again back to the AD FS server. After this

occurs, an AD FS server will reject multiple requests that are made in a short time period. This behavior is by design, to protect against a denial of service attack. If

performance is adversely affected or pages do not load completely, set network load balancing to single affinity. This isolates the requests for SAML tokens to a

single Web server.

For information about configuring Active Directory Federation Services (AD FS) 2.0 in SharePoint Foundation 2010, see How to configure AD FS v 2.0 in SharePoint

Foundation 2010.

Note

When a Web application is configured to use SAML token-based authentication, the SPTrustedClaimProvider class does not provide search functionality to the People

Picker control. Any text entered in the People Picker control will automatically be displayed as if it had been resolved, regardless of whether it is a valid user, group,

or claim. If your SharePoint Foundation solution will use SAML token-based authentication, you should plan to create a custom claims provider that implements

custom search and name resolution.

For more information, see Custom claims providers for People Picker (SharePoint Foundation 2010).

For detailed steps to configure SAML token-based authentication, see Configure authentication using a SAML security token (SharePoint Foundation 2010).

For additional information about SAML token-based authentication, see the following resources:

MSDN blog article: Claims-based authentication "Cheat Sheet" Part 2 (http://go.microsoft.com/fwlink/p/?LinkId=198946)

TechNet blog article: Planning Considerations for Claims Based Authentication in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=198947)

TechNet blog article: Creating both an Identity and Role Claim for a SharePoint 2010 Claims Auth Application (http://go.microsoft.com/fwlink/p/?LinkId=198948)

TechNet blog article: How to Create Multiple Claims Auth Web Apps in a Single SharePoint 2010 Farm (http://go.microsoft.com/fwlink/p/?LinkId=198949)

For information about features that do not work with SAML security tokens or features that require additional configuration in order to work with SAML security tokens,

see Plan for claims-based authentication or classic-mode authentication (SharePoint Foundation 2010).

Choosing authentication for LDAP environments

LDAP environments can be implemented by using either forms-based authentication or SAML token-based authentication. We recommend that you use forms-based

authentication because it is less complex. However, if the environment supports WS-Federation 1.1 and SAML Token 1.1, then SAML is recommended.

Planning zones for Web applications

Zones represent different logical paths for gaining access to the same sites in a Web application. Each Web application can include as many as five zones. When a Web









application is created, the default zone is created. Additional zones are created by extending the Web application and selecting one of the remaining zone names:

intranet, extranet, Internet, or custom.

In previous versions of SharePoint Foundation, zones are used to implement different types of authentication for users coming from different networks or authentication

providers. In the current version, claims authentication allows multiple types of authentication to be implemented on the same zone.

Your plan for zones will depend on which of the following authentication modes you select for a Web application:

Classic mode — Similar to previous versions, only one type of authentication can be implemented per zone. However, in SharePoint Foundation 2010, onlyWindows authentication can be implemented when classic mode is selected. Consequently, multiple zones can be used only to implement multiple types of

Windows authentication, or to implement the same type of Windows authentication against different Active Directory stores.

Claims‐based authentication — Multiple authentication providers can be implemented on a single zone. Multiple zones can also be used.

Implementing more than one type of authentication on a single zone

If you are using claims authentication and implementing more than one authentication method, we recommend that you implement multiple authentication methods on

the default zone. This results in the same URL for all users.

When you are implementing multiple authentication methods on the same zone, the following restrictions apply:

Only one instance of forms-based authentication can be implemented on a zone.

Central Administration allows you to use both an Integrated Windows method and Basic at the same time. Otherwise, more than one type of Windows

authentication cannot be implemented on a zone.

If multiple SAML token-based authentication providers are configured for a farm, these will all appear as options when you create a Web application or a new zone.

Multiple SAML providers can be configured on the same zone.

The following diagram illustrates multiple types of authentication implemented on the default zone for a partner collaboration site.

In the diagram, users from different directory stores access the partner Web site by using the same URL. A dashed box surrounding partner companies shows the

relationship between the user directory and the authentication type that is configured in the default zone. For more information about this design example, see Design

sample: Corporate deployment (SharePoint Server 2010).

Planning for crawling content

The crawl component requires access to content using NTLM. At least one zone must be configured to use NTLM authentication. If NTLM authentication is not

configured on the default zone, the crawl component can use a different zone that is configured to use NTLM authentication.

Implementing more than one zone

If you plan to implement more than one zone for Web applications, use the following guidelines:

Use the default zone to implement your most secure authentication settings. If a request cannot be associated with a specific zone, the authentication settings and

other security policies of the default zone are applied. The default zone is the zone that is created when you initially create a Web application. Typically, the most

secure authentication settings are designed for end-user access. Consequently, end users are likely to access the default zone.

Use the minimum number of zones that are required to provide access to users. Each zone is associated with a new IIS site and domain for accessing the Web

application. Only add new access points when these are required.


Ensure that at least one zone is configured to use NTLM authentication for the crawl component. Do not create a dedicated zone for the index component unless

it is necessary.

The following diagram illustrates multiple zones that are implemented to accommodate different authentication types for a partner collaboration site.

In the diagram, the default zone is used for remote employees. Each zone has a different URL associated with it. Employees use a different zone depending on whether

they are working in the office or are working remotely. For more information about this design example, see Design sample: Corporate deployment (SharePoint Server

2010).

Architecture for SAML token-based providers

The architecture for implementing SAML token-based providers includes the following components:

SharePoint security token service This service creates the SAML tokens that are used by the farm. The service is automatically created and started on all servers in a

server farm. The service is used for inter-farm communication because all inter-farm communication uses claims authentication. This service is also used for

authentication methods that are implemented for Web applications that use claims authentication, including Windows authentication, forms-based authentication, and

SAML token-based authentication. You must configure the security token service during the deployment process.

For more information, see Configure the security token service (SharePoint Foundation 2010).

Token-signing certificate (ImportTrustCertificate) This is the certificate that is exported from an IP-STS. The certificate is copied to one server in the farm. Once you

use this certificate to create an SPTrustedIdentityTokenIssuer, you cannot use it again to create another one. If you want to use the certificate to create a different

SPTrustedIdentityTokenIssuer, you must delete the existing one first. Before you delete an existing one, you must disassociate it from any Web applications that may be

using it.

Identity claim The identity claim is the claim from a SAML token that is the unique identifier of the user. Only the owner of the IP-STS knows which value in the token

will always be unique for each user. The identity claim is created as a regular claims mapping during the process of mapping all desired claims. The claim that serves as

the identity claim is declared when the SPTrustedIdentityTokenIssuer is created.

Other claims These claims consist of additional claims from a SAML ticket that describe users. These can include user roles, user groups, or other kinds of claims such

as age. All claims mappings are created as objects that are replicated across the servers in a SharePoint Foundation farm.

Realm In the SharePoint claims architecture, the URI or URL that is associated with a SharePoint Web application that is configured to use a SAML token-based

provider represents a realm. When you create a SAML-based authentication provider on the farm, you specify the realms, or Web application URLs, that you want the IP-

STS to recognize, one at a time. The first realm is specified when you create the SPTrustedIdentityTokenIssuer. Additional realms can be added after the

SPTrustedIdentityTokenIssuer is created. Realms are specified by using syntax similar to the following: $realm = "urn:sharepoint:mysites". After you add the realm to the

SPTrustedIdentityTokenIssuer, you must create an RP-STS trust with the realm on the IP-STS server. This process involves specifying the URL for the Web application.

SPTrustedIdentityTokenIssuer This is the object that is created on the SharePoint farm that includes the values necessary to communicate with and receive tokens

from the IP-STS. When you create the SPTrustedIdentityTokenIssuer, you specify which token-signing certificate to use, the first realm, the claim that represents the

identity claim, and any additional claims. You can only associate a token-signing certificate from an STS with one SPTrustedIdentityTokenIssuer. However, after you create

the SPTrustedIdentityTokenIssuer, you can add more realms for additional Web applications. After a realm is added to the SPTrustedIdentityTokenIssuer, it must also be

added to the IP-STS as a relying party. The SPTrustedIdentityTokenIssuer object is replicated across servers in the SharePoint Foundation farm.

Relying party security token service (RP-STS) In SharePoint Foundation 2010, each Web application that is configured to use a SAML provider is added to the IP-STS

server as an RP-STS entry. A SharePoint Foundation farm can include multiple RP-STS entries.

Identity provider security token service (IP-STS) This is the secure token service in the claims environment that issues SAML tokens on behalf of users who are

included in the associated user directory.

The following diagram illustrates the SharePoint 2010 Products claims architecture.



The SPTrustedIdentityTokenIssuer object is created by using several parameters. The following diagram illustrates the key parameters.

As the diagram illustrates, an SPTrustedIdentityTokenIssuer can include only one identity claim, one SignInURL parameter, and one Wreply parameter. However, it can

include multiple realms and multiple claims mappings. The SignInURL parameter specifies the URL to redirect a user request to in order to authenticate to the IP-STS.

Some IP-STS servers require the Wreply parameter, which is set to either true or false and is false by default. Only use the Wreply parameter if it is required by the IP-

STS.

See Also

Other ResourcesResource Center: Security and Authentication for SharePoint Foundation 2010

© 2014 Microsoft


People Picker and claims provider planning (SharePointFoundation 2010)



People Picker is a Web control used to find and select users, groups, and claims to grant permission to items such as lists, libraries, or sites in Microsoft SharePoint

Foundation 2010. When a Web application uses claims authentication mode, the People Picker control uses a claims provider to list, resolve, search, and determine the

"friendly" display of users, groups, and claims. A claims provider in SharePoint Foundation 2010 issues claims, which SharePoint Foundation 2010 then packages into

security tokens for users. Although People Picker is used by site, list, and library owners to assign permissions to sites and content in SharePoint Foundation 2010, its

behavior is heavily dependent on how authentication has been configured for the whole Web application. It is important to plan for People Picker and claims providers

when you plan authentication methods for your SharePoint Foundation 2010 solution.

The articles in this section are designed to help you understand and plan for using People Picker and custom claims providers in SharePoint Foundation 2010:

People Picker overview (SharePoint Foundation 2010)

This article describes the People Picker control and how it works, its relationship to authentication and claims providers, and includes considerations for planning for

People Picker.

Custom claims providers for People Picker (SharePoint Foundation 2010)

This article describes the use and benefits of claims providers, their architecture, special considerations for custom claims providers, and considerations for

planning for them.

See Also

ConceptsPlan authentication (SharePoint Foundation 2010)

Configure People Picker (SharePoint Foundation 2010)

© 2014 Microsoft








The People Picker control is used to find and select people, groups, and claims when a site, list, or library owner assigns permissions in Microsoft SharePoint Foundation

2010. This article describes the People Picker control and how it works, its relationship to authentication and claims providers, and how to plan for People Picker. For

information about how to configure People Picker, see Configure People Picker (SharePoint Foundation 2010).

Before reading this article, you should understand the concepts described in Plan authentication methods (SharePoint Foundation 2010)and in The Role of Claims

(http://go.microsoft.com/fwlink/p/?LinkID=208326). For additional information about claims-based authentication, see SharePoint Claims-Based Identity

(http://go.microsoft.com/fwlink/p/?LinkID=196647).

In this article:

Uses and benefits

Architecture

About the People Picker control

People Picker and authentication

People Picker and claims providers

Configuring People Picker

Using People Picker with multiple forests or domains

Considerations for People Picker

Uses and benefits

The People Picker control is used to select users, groups, and claims to grant permission to items such as lists, libraries, and sites. For example, your site has a

document library that you want to restrict to a certain list of users. When you use the library permissions page to give users permission levels for the library, you use the

People Picker control either to type user names and verify that the user accounts are valid, or to search for a name or partial string and return a list of users, groups, or

claims that match the value you entered. For more information about permissions, see Plan site permissions (SharePoint Foundation 2010).

Architecture

The People Picker control is a central component of SharePoint Foundation 2010. The control provides basic functionality for finding and selecting users, groups, and

claims to assign permissions in a site. The exact sources of those users, groups, and claims depend on the authentication method used by the Web application that

contains the site collection. For more information about authentication methods, see People Picker and authentication later in this article.

People Picker is configured at the zone level for a farm by using the Stsadm setproperty operation. By configuring the settings for the control, you can filter and restrict

the results that are displayed when a user searches for a user, group, or claim. Those settings will apply to every site within a specific site collection. For more

information about configuring People Picker, see Configure People Picker (SharePoint Foundation 2010).

Note

There are no Windows PowerShell commands to configure People Picker.

When a Web application is configured to use claims-based authentication, People Picker uses claims providers to resolve and display users, groups, and claims in the

Select People and Groups dialog box. The information that is displayed in the Select People and Groups dialog box depends on the claims provider used by the

authentication method that was configured for the Web application. For more information about claims providers, see Custom claims providers for People Picker

(SharePoint Foundation 2010).


The People Picker control consists of a text box and two buttons: the Check Names button and the Browse button. The following illustration shows an example of the

People Picker control.

The user types a user name, group name, or claim (such as an e-mail address) into the text box, and then clicks the Check Names button to resolve the search item

exactly as it was entered. If People Picker is able to resolve the search item, the name is replaced with a resolved identity. If the search item cannot be resolved exactly as

entered, People Picker performs a search. If no match is found, or if more than one match is found, a red underline is displayed under the search item and the following

error message appears: No exact match found. Click the item(s) that did not resolve for more options. When the item is clicked, a pop-up menu displays a list of

available users, groups, or claims that match the query, if applicable. The menu also contains a Remove button to remove the resolved user, group, or claim from the

text box, and a More Names button, which opens the Select People and Groups dialog box.








If the user clicks the Browse button, the Select People and Groups dialog box is displayed. The user types a full or partial user name, group name, or claim into the text

box, and then presses Enter. The results of the query are displayed in the dialog box. The claims providers that People Picker interacts with determine the query results

and the way those results are displayed in the dialog box. The user selects a resolved identity, clicks Add, and then clicks OK. The selected user, group, or claim is then

added to the text box in the People Picker control.

When a Web application is configured to use Windows authentication, you can limit the results that are displayed to users in the Select People and Groups dialog box

by using the Stsadm setproperty operation to change the settings for the People Picker control. For example, you can configure People Picker to return only users,

groups, and claims that belong to a certain Active Directory domain or are members of a specific site collection. For more information about configuring the People

Picker control, see Configure People Picker (SharePoint Foundation 2010).


People Picker relies on the authentication method used by the Web application that contains the site collection from which it is queried to determine what results to

display to a user. If the Web application is configured to use Windows authentication in classic mode, SharePoint Foundation 2010 treats user accounts as Active

Directory Domain Services (AD DS) accounts. If the Web application is configured to use claims-based authentication, you can specify whether to use Windows

authentication, forms-based authentication (FBA), or Security Assertion Markup Language (SAML) token-based authentication. In claims mode, People Picker searches

and resolves queries based on the claims provider that is specified for the authentication method used by the Web application and zone. The following sections

describe People Picker behavior for both classic-mode authentication and claims-based authentication. For more information about zones and authentication, see Plan

authentication methods (SharePoint Foundation 2010).

Classic-mode authentication

When Windows classic-mode authentication is used, the People Picker control queries Active Directory to retrieve a list of users, groups, or claims that match the

search item typed in the text box. You can configure People Picker to query Active Directory by using Lightweight Directory Access Protocol (LDAP) queries, which

enables you to apply custom Active Directory filters, limit the scope of search queries, and search across forests and domains.

By default, when the Browse button is clicked, the Select People and Groups dialog box displays the following fields:

Display Name

Title

Department

E-mail

Mobile Number

Account Name

The following image shows the Select People and Groups dialog box when Windows authentication is used in classic mode for the Web application.

For more information about classic-mode authentication, see Plan authentication methods (SharePoint Foundation 2010). For information about how to create a Web

application that uses classic-mode authentication, see Create a Web application that uses Windows-classic authentication (SharePoint Foundation 2010).

Claims-based authentication

When claims-based authentication is used, People Picker uses the claims provider that is specified for the authentication method used by the Web application and

zone to retrieve a list of users, groups, or claims that match the search item typed in the text box. For more information about claims mode authentication and zones,

see Plan authentication methods (SharePoint Foundation 2010).

By default, when the Browse button is clicked, the Select People and Groups dialog box displays a tree view on the left that lists the claims providers that People






Picker will query. The right side of the dialog box is where query results are displayed. When claims-based authentication is used, the results are displayed in one of

two views: Detailed View or List View. By default, Detailed View is displayed.

The following illustration shows the Select People and Groups dialog box when Windows authentication is used in claims mode for a Web application.

In Detailed View, the query results are grouped by the sources where the query results were found. For example, if a search item is found in a SharePoint group and

in Active Directory, the results are organized into a list of SharePoint groups followed by a list of Active Directory users and groups.

In List View, the query results are returned in a list that contains the following fields:

Display Name

E-mail Address

Title

Department

Presence

Work Phone

Location

You can write a custom claims provider to control what information is displayed and what results are returned in response to a query from the People Picker control.

When a custom claims provider is registered on the server, you can also configure it for use in a specific Web application and zone. This means that a custom claims

provider that is configured for only one zone will only be displayed in the Select People and Groups dialog box for Web sites in that zone. For more information

about custom claims providers, see Custom claims providers for People Picker (SharePoint Foundation 2010).

Note

In the Central Administration Web site, People Picker will return users, groups, and claims from all claims providers used in all Web applications in the farm,

regardless of the Web application or zone in which the claims providers are configured.

By default, when you use SAML token-based authentication, all queries entered in the text box are automatically displayed as if they had been resolved, regardless of

whether they are valid users or groups. If your SharePoint Foundation 2010 solution will use SAML token-based authentication, you should plan to create a custom

claims provider that will implement custom search, name resolution, and list features. For more information about custom claims providers, see Custom claims

providers for People Picker (SharePoint Foundation 2010).

For information about how to create a Web application that uses claims-mode authentication, see Create a Web application that uses Windows-claims authentication

(SharePoint Foundation 2010). For information about configuring claims-based authentication for Web applications, see Configure claims authentication (SharePoint

Foundation 2010).


A claims provider lists, resolves, searches, and determines the "friendly" display of users, groups, and claims in the People Picker when claims-based authentication is

used. If your Web application uses claims-based authentication, you must decide whether to use one of the default claims providers or create a custom claims provider

that will meet the business needs of your organization.

For more information about how claims providers are related to the People Picker control, see Custom claims providers for People Picker (SharePoint Foundation 2010).







The information in this section applies only to Web applications that use Windows authentication in either classic mode or claims mode.

You can configure People Picker to filter query results and to restrict the directories that People Picker uses as a source of those results by using property names for the

Stsadm setproperty operation. To see what property settings have been configured, use the Stsadm getproperty operation. For more information, see Peoplepicker:

Stsadm properties (Office SharePoint Server 2007). The settings for People Picker are applied to each URL zone for a Web application.

Note


The following table describes the properties that can be used to configure People Picker.

Property name Description

Peoplepicker-activedirectorysearchtimeout Configures the timeout when a query is issued to Active Directory. The default timeout value is 30 seconds.

For more information, see Peoplepicker-activedirectorysearchtimeout.

Peoplepicker-distributionlistsearchdomains Restricts the search of a distribution list to a specific subset of domains. For more information, see

Peoplepicker-distributionlistsearchdomains.

Peoplepicker-

nowindowsaccountsfornonwindowsauthenticationmode

Specifies not to search Active Directory when the current port is using forms-based authentication. For more

information, see Peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode.

Peoplepicker-onlysearchwithinsitecollection Displays only users who are members of the site collection when the Select People and Groups dialog box

is used. For more information, see Peoplepicker-onlysearchwithinsitecollection.

Peoplepicker-

peopleeditoronlyresolvewithinsitecollection

Displays only users who are members of the current site collection when the Check Names button is clicked.

For more information, see. Peoplepicker-peopleeditoronlyresolvewithinsitecollection: Stsadm property


Peoplepicker-searchadcustomfilter Enables a farm administrator to specify a unique search query. For more information, see Peoplepicker-

searchadcustomfilter.

Peoplepicker-searchadcustomquery Permits the administrator to set the custom query that is sent to Active Directory. For more information, see

Peoplepicker-searchadcustomquery.

Peoplepicker-searchadforests Permits a user to search from a second one-way trusted forest or domain. For more information, see

Peoplepicker-searchadforests.

Peoplepicker-serviceaccountdirectorypaths Enables a farm administrator to manage the site collection that has a specific organizational unit (OU)

setting as defined in the Setsiteuseraccountdirectorypath setting. For more information, see Peoplepicker-

serviceaccountdirectorypaths.

For more information about configuring People Picker, see Configure People Picker (SharePoint Foundation 2010).


By default, People Picker will only return users, groups, and claims from the domain on which SharePoint Foundation 2010 is installed. If you want People Picker to return

query results from more than one forest or domain, you must either have a two-way trust between the forests or domains, or you must configure People Picker to use

an encrypted account and password for a one-way trust between forests and domains. For more information about trusts, see Managing Trusts

(http://go.microsoft.com/fwlink/p/?LinkId=207573).

To configure People Picker for a one-way trust, you must first use the Stsadm setapppassword operation to set the password for use on the trusted forest or domain,

and then use the Peoplepicker-searchadforests property for the setproperty operation to specify the forest or domain to search. Remember that the settings for

People Picker are configured per zone for a Web application, so if you have more than one forest or domain in your farm, you must combine the accounts and

passwords into a single command for the setproperty operation. For more information, see Peoplepicker-searchadforests: Stsadm property (Office SharePoint Server).


Planning for People Picker largely depends on what forests and domains you want users to be able to query, and what users, groups, and claims you want to display in

query results. As you plan for the forests and domains you want users to query, consider the following questions:

Do users need to query across a forest or a domain?

What is the DNS name for each forest or domain you want users to query?

Will your forest or domain have a one-way or two-way trust with other forests or domains?

If you will be using a one-way trust, what credentials will be used to query the other farms or domains

Planning for the users, groups, and claims you want to display in the query results in People Picker will help you determine how to configure People Picker to return and

display results from claims providers. As you plan for the users, groups, and claims you want to display in query results, consider the following questions:

http://technet.microsoft.com/en-us/library/d8372668-ba43-4bcb-b341-50ade06f810f(office.12).aspx

http://technet.microsoft.com/en-us/library/fb1b23f4-30e4-40ae-a7a2-7cc654a4e7ad(office.12).aspx

http://technet.microsoft.com/en-us/library/c95da957-8eeb-4312-b039-7ac5c0f89a7e(office.12).aspx

http://technet.microsoft.com/en-us/library/cac79eec-e313-4f48-839a-902538d8b9be(office.12).aspx

http://technet.microsoft.com/en-us/library/1b96ad41-c43e-43dc-b59b-5a8f4a48fd6f(office.12).aspx


http://technet.microsoft.com/en-us/library/f1d7a0d5-1f32-4d26-8ccf-cf090a44d93c(office.12).aspx

http://technet.microsoft.com/en-us/library/911b5f5a-bd1d-42fd-b816-8cd5a770b4b9(office.12).aspx

http://technet.microsoft.com/en-us/library/f3988343-c57a-4f92-b523-682b7a5e9aa8(office.12).aspx

http://technet.microsoft.com/en-us/library/da6a65b4-6cb6-481d-b58b-5551b8d5d390(office.12).aspx

http://technet.microsoft.com/en-us/library/9538ed2e-507f-4af9-aa31-da971a69f66b(office.12).aspx




Are there certain LDAP filters you want to apply to query results?

Do you want to restrict the query results to users, groups, or claims in a specific site collection?

Do you want to restrict the query results to users, groups, or claims in a certain Active Directory organizational unit (OU)

See Also

ConceptsPlan authentication methods (SharePoint Foundation 2010)




© 2014 Microsoft





Custom claims providers for People Picker (SharePoint Foundation2010)



A claim consists of information about the identity of a user, such as a name, e-mail address, or group membership. A claims provider in Microsoft SharePoint Foundation

2010 issues claims, which SharePoint Foundation 2010 then packages into security tokens for users. When a user signs in to SharePoint Foundation 2010, the user's token is

validated and then used to sign in to SharePoint Foundation 2010. Claims providers are displayed in the user interface of the Select People and Groups dialog box in the

People Picker control. They provide the functionality used to find and select users, groups, and claims when permissions are assigned to items such as lists, libraries, and

sites in SharePoint Foundation 2010. For information about the People Picker control, see People Picker overview (SharePoint Foundation 2010).

This article describes the use and benefits of claims providers, their architecture, special considerations for custom claims providers, and how to plan for them. It does not

explain how to create or configure custom claims providers. For information about how to create a custom claims provider, see Claims How Tos

(http://go.microsoft.com/fwlink/p/?LinkId=207578) and Creating Custom Claims Providers in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=211324).

Before reading this article, you should understand the concepts described in Plan authentication methods (SharePoint Foundation 2010) and The Role of Claims


(http://go.microsoft.com/fwlink/p/?LinkID=196647) and A Guide to Claims-based Identity and Access Control (http://go.microsoft.com/fwlink/p/?LinkID=187911).

In this article:

Uses and benefits

Architecture

About custom claims providers

Deploying and configuring custom claims providers

Using custom claims on more than one farm

Considerations for custom claims providers

Uses and benefits

A claims provider in SharePoint Foundation 2010 is used primarily for two reasons:

To augment claims

To provide name resolution

In the augmentation role, a claims provider augments a user token with additional claims during sign-in. For more information about claims augmentation, see Claims

Provider (http://go.microsoft.com/fwlink/p/?LinkID=207579).

In the picking role, a claims provider lists, resolves, searches, and determines the "friendly" display of users, groups, and claims in the People Picker. Claims picking

enables an application to surface claims in the People Picker, for example when configuring the security of a SharePoint site or SharePoint service. For more information

about People Picker, see People Picker overview (SharePoint Foundation 2010).

You can use the claims providers that are included with SharePoint Foundation 2010, or you can create your own custom claims providers to provide additional claims in

the security token for a user or to connect to additional sources of claims. For example, if you have a CRM application that contains roles that are not found in the user

repository in Active Directory, you can create a custom claims provider to connect to that database and add CRM role data to a user's original claims token. For more

information about claims provider usage scenarios, see Claims Provider (http://go.microsoft.com/fwlink/p/?LinkID=207579).

Architecture

When a Web application is configured to use claims-based authentication, SharePoint Foundation 2010 automatically uses two default claims providers:

The SPSystemClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210011) class provides claims information related to the server farm where SharePoint

Foundation 2010 is installed.

The SPAllUserClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210012) class provides an All Users claim that is displayed in the Select People and

Groups dialog box for People Picker.

Depending on the authentication method selected for a zone of a Web application, SharePoint Foundation 2010 also uses one or more of the default claims providers

listed in the following table.

Authentication method Claims provider

Windows authentication SPActiveDirectoryClaimProvider (http://go.microsoft.com/fwlink/p/?LinkID=208325)















Forms-based authentication SPFormsClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210013)

Security Assertion Markup Language (SAML) token-based authentication SPTrustedClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210014)

These claims providers are displayed in the Select People and Groups dialog box for People Picker. You can see a list of claims providers for a farm by using the Get-

SPClaimProvider Windows PowerShell cmdlet.

Note



or claim. If your SharePoint Foundation 2010 solution will use SAML token-based authentication, you should plan to create a custom claims provider to implement


Claims providers are registered on a server farm as features that are deployed to the farm. They are scoped at the farm level. Each claims provider object uses the

SPClaimProviderDefinition class to include information about the claims provider, such as display name, description, assembly, and type. Two important properties of the

SPClaimProviderDefinition class are IsEnabled and IsUsedByDefault. These properties determine whether a registered claims provider is enabled for use in the farm, and

whether the claims provider is used by default in a particular zone. By default, all claims providers are enabled when they are deployed to a server farm. For information

about the SPClaimProviderDefinition class, see SPClaimProviderDefinition Class (http://go.microsoft.com/fwlink/p/?LinkId=207595).

For more information about zones and authentication, see Plan authentication methods (SharePoint Foundation 2010).

For information about how to write a custom claims provider, see Creating Custom Claims Providers in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?

LinkID=211324) and Claims Walkthrough: Writing Claims Providers for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207589). For information about how to

override the default claims provider, see How to Override the Default Name Resolution and Claims Provider for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?

LinkId=207591).


By default, the information that is resolved in People Picker when a query is performed depends on the information supplied by the claims provider. You cannot change

what information is supplied and how it is displayed when you use an out-of-box claims provider. To do this, you must have a developer create a custom claims

provider that will meet the needs of your solution for finding and selecting users, groups, and claims when a user assigns permissions to items such as a site, list, or

library.

For example, if your Web application uses SAML authentication and you also want to resolve users from Active Directory, you will need to create a custom claims

provider. For additional examples of claims provider use scenarios, see Claims Provider (http://go.microsoft.com/fwlink/p/?LinkID=207579).

When you create a custom claims provider, you can control what information is displayed and what results are returned in response to a query from the People Picker

control. By default, you configure the Web application to use claims authentication, and then register the claims provider on the server.

Note

You cannot control the order in which claims providers are displayed in the Select People and Groups dialog box in People Picker.

For information about how to write a custom claims provider, see How to: Create a Claims Provider (http://go.microsoft.com/fwlink/p/?LinkId=207588) and Claims

Walkthrough: Writing Claims Providers for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207589). For information about how to override the default claims

provider, see How to Override the Default Name Resolution and Claims Provider for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207591).


By default, when you register a custom claims provider on the farm, the IsEnabled and IsUsedByDefault properties are both set to True. Unless the IsUsedByDefault

property is set to False, the custom claims provider is displayed in the Select People and Groups dialog box in People Picker for all zones. Depending on the number of

zones needed for your SharePoint Foundation 2010 solution, the authentication methods used by each zone, and the users for each zone, you may want to limit the

zones in which your custom claims provider is displayed in People Picker.

Because claims providers are scoped at the farm level and enabled at the zone level, you must carefully plan the zones in which you want the custom claims provider to

be displayed. In general, you should make sure that the IsUsedByDefault property is set to False, and then configure the SPIisSettings class for each zone in which you

want to use the custom claims provider. To configure a custom claims provider for select zones, you can create a Windows PowerShell script that sets the claims

provider for a zone by using the SPIisSettings.ClaimsProviders property, or you can create a custom application to allow you to enable a custom claims provider for

select zones. For information about the SPIisSettings.ClaimsProvider property, see SPIisSettings.ClaimsProvider Property (http://go.microsoft.com/fwlink/p/?

LinkId=207597). For information about how to create a custom application to configure claims providers for select zones, see the TechNet blog post, Configuring a

Custom Claims Provider to be Used only on Select Zones in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207592).

For example, consider a scenario where there are two Web applications: The first Web application, PartnerWeb, has two zones — one intranet that uses Windowsclaims‐based authentication and one extranet that uses forms‐based authentication — and is used for collaboration among employees and partners. The second Webapplication, PublishingWeb, has only one zone that uses forms-based authentication and is an Internet publishing site for employees, business partners, and customer

partners. Now, suppose that for the extranet zone on PartnerWeb, you want employees to be able to collaborate with business partners but not customer partners. To

do this, you write a custom claims provider that determines whether the current user is a business partner or customer partner, based on the user's identity. In this

example, users from fabrikam.com are business partners, while users from contoso.com are customer partners. When a user who is a business partner is authenticated

in the PartnerWeb Web application, a claim for a role called BusinessPartner is added to the claim token; when a customer partner is authenticated, a claim for a role

called CustomerPartner is added to the claim token. To make sure that customer partners are never added to the extranet collaboration site, you add a Web application

policy on the PartnerWeb Web application for the extranet zone that explicitly denies access to any user who has a claim for a role called CustomerPartner. The custom

claims provider would also need to implement search and type-in support for the Web application policy to resolve the CustomerPartner role claim so it can be added

to the Web application policy. Finally, to enable this functionality on the extranet zone, you configure the SPIisSettings class for that zone to use the custom claims

provider. The following diagram illustrates the authentication methods and claims provider settings for each Web application and zone.















Note

On the Central Administration Web site, all claims providers are displayed in the Select People and Groups dialog box in People Picker, regardless of whether the

IsUsedByDefault property is set to True.

You can set the IsUsedByDefault property by configuring it in a feature receiver that you create for your custom claims provider. For information about how to use a

feature receiver to deploy a custom claims provider, see Sample: Feature Receiver to Deploy a Claims Provider (http://go.microsoft.com/fwlink/p/?LinkId=207590).

You can also override the settings of the IsEnabled and IsUsedByDefault properties by using the Set-SPClaimProvider Windows PowerShell cmdlet.

Important

Changing the IsEnabled property to False will disable the claims provider for the entire server farm. This can be useful if you need to troubleshoot issues that might

be caused by a custom claims provider. However, in general, the IsEnabled property should be set to True.


Claim values are a combination of the claim itself, the claims provider name, and the order in which the claims provider was installed on the server. Therefore, if you

want to use a claim across multiple farms or environments, you must install the claims providers in the same order on each farm in which you want to use the claim. Use

the following steps when you have installed a custom claims provider on a farm and you want to use the same claim on additional farms.

1. Register the claims providers on the additional farms in the same order that they were registered on the first farm.

2. Perform a backup of the first farm. For information about how to back up a farm, see Back up a farm (SharePoint Foundation 2010).

3. Use the back up from the first farm to restore the other farms. For information about how to restore a farm, see Restore a farm (SharePoint Foundation 2010).


As you plan custom claims providers for use with People Picker in your SharePoint solution, consider the following questions:

What zones does your Web application have, and what authentication methods are used in each zone?

Are there any custom claims that should be added to users to enable more advanced security scenarios?

Will you be using SAML authentication with a trusted identity provider?

What will be the source of the values for the users and roles that will be displayed in People Picker query results?

What claim data do you want to resolve in the Select People and Groups dialog box?

The SharePoint Foundation 2010 Content Publishing team would like to thank Steve Peschka for contributing to this article. His blog can be found here


See Also


© 2014 Microsoft







Plan for Kerberos authentication (SharePoint Foundation 2010)



Microsoft SharePoint Foundation 2010 supports several methods of authentication. Deployments that require secure authentication, client identity delegation, and low

network traffic can choose Kerberos authentication. For more information, see Plan authentication methods (SharePoint Foundation 2010).

In this article:

Kerberos authentication and SharePoint 2010

Kerberos authentication and claims-based authentication

Kerberos authentication and Microsoft SharePoint Foundation 2010

Why you should consider Kerberos authentication Why Kerberos authentication might not be appropriate for a deployment scenario

Kerberos is the most secure Integrated Windows authentication

protocol, and supports advanced security features including Advanced

Encryption Standard (AES) encryption and mutual authentication.

Kerberos authentication requires additional configuration of infrastructure and

environment to function properly. In many cases, domain administrator permission is

required to configure Kerberos. Kerberos authentication can be difficult to set up and

manage. Misconfiguring Kerberos can prevent successful authentication to your sites.

Kerberos enables delegation of client credentials. Kerberos authentication requires client computer connectivity to a Key Distribution Center

(KDC), and client computer connectivity to an Active Directory Domain Services (AD DS)

domain controller. In a Windows deployment, the KDC is an AD DS domain controller.

While this is a common network configuration in a corporate environment, Internet-facing

deployments are typically not configured this way.

Kerberos supports mutual authentication of clients and servers.

Of the available secure authentication methods, Kerberos requires the

least amount of network traffic to domain controllers. Kerberos can

reduce page latency in certain scenarios, or increase the number of

pages that a front-end Web server can serve in certain scenarios.

Kerberos can also reduce the load on domain controllers.

Kerberos is an open protocol that is supported by many platforms and

vendors.

Kerberos is a secure protocol that supports an authentication method that uses tickets provided by a trusted source. Kerberos tickets represent the network credentials

of a user who is associated with a client computer. The Kerberos protocol defines the way in which users interact with a network authentication service to gain access to

network resources. The Kerberos KDC issues a ticket to a client computer on behalf of a user. After a client computer establishes a network connection to a server, the

client computer requests network access by presenting the Kerberos authentication ticket to the server. If the request contains acceptable user credentials, the KDC

grants the request. For service applications, the authentication ticket must also contain an acceptable Service Principal Name (SPN). To enable Kerberos authentication,

the client and server computers must already have a trusted connection to the KDC. The client and server computers must also be able to access Active Directory

Domain Services (AD DS).

Kerberos delegation

Kerberos authentication supports the delegation of client identity. This means that a service can impersonate an authenticated client’s identity. Impersonation enables aservice to pass the authenticated identity to other network services on behalf of the client. Claims-based authentication can also be used to delegate client credentials,

but it requires the backend application to be claims-aware. Several important services are not currently claims-aware.

Used in conjunction with Microsoft SharePoint Foundation 2010, Kerberos delegation enables a front‐end service to authenticate a client and then use the client’s identityto authenticate to a backend system. The backend system then performs its own authentication. When a client uses Kerberos authentication to authenticate with a front-

end service, Kerberos delegation can be used to pass a client's identity to a backend system. The Kerberos protocol supports two types of delegation:

Basic Kerberos delegation (unconstrained)

Kerberos constrained delegation

Basic Kerberos delegation and Kerberos constrained delegation

Although basic Kerberos delegation can cross domain boundaries within the same forest, basic Kerberos delegation cannot cross a forest boundary. Kerberos

constrained delegation cannot cross domain boundaries or forest boundaries. Depending on the service applications that are part of a SharePoint Foundation 2010

deployment, implementing Kerberos authentications with SharePoint Foundation 2010 can require the use of Kerberos constrained delegation. Therefore, to deploy

Kerberos authentication with any of the following service applications, SharePoint Foundation 2010 and all external data sources must reside in the same Windows

domain:

Excel Services

PerformancePoint Services


InfoPath Forms Services

Visio Services

To deploy Kerberos authentication with any of the following service applications, SharePoint Foundation 2010 can use either basic Kerberos delegation or Kerberos

constrained delegation:

Business Data Connectivity service and Microsoft Business Connectivity Services

Access Services

Microsoft SQL Server Reporting Services (SSRS)

Microsoft Project Server 2010

Services that are enabled for Kerberos authentication can delegate identity multiple times. As an identity travels from service to service, the delegation method can

change from basic Kerberos to Kerberos constrained. However, the reverse is not possible. The delegation method cannot change from Kerberos constrained to basic

Kerberos. Therefore, it is important to anticipate and plan for whether or not a backend service will require basic Kerberos delegation. This can impact the planning and

design of domain boundaries.

A Kerberos enabled service can use protocol transition to convert a non-Kerberos identity to a Kerberos identity that can be delegated to other Kerberos enabled

services. This capability can be used, for example, to delegate a non-Kerberos identity from a front-end service to a Kerberos identity on a backend service.

Important

Protocol transition requires Kerberos constrained delegation. Therefore, protocol transitioned identities cannot cross domain boundaries.

Claims‐based authentication can be used as an alternative to Kerberos delegation. Claims‐based authentication enables a client’s authentication claim to be passedbetween two different services if the services meet all of the following criteria:

There must be a trust relationship between the services.

Both services must be claims-aware.

For more information about Kerberos authentication, see the following resources:

How the Kerberos Version 5 Authentication Protocol Works (http://go.microsoft.com/fwlink/p/?LinkID=196644)

Microsoft Kerberos (http://go.microsoft.com/fwlink/p/?LinkID=125740)

Kerberos Explained

Kerberos authentication and claims-based authentication

SharePoint Foundation 2010 supports claims-based authentication. Claims-based authentication is built on Windows Identity Foundation (WIF), which is a set of .NET

Framework classes that are used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation and WS-Trust. For more

information about claims-based authentication, see the following resources:

Claims-based Identity for Windows: An Introduction to Active Directory Federation Services 2.0, Windows CardSpace 2.0, and Windows Identity Foundation (white

paper) (http://go.microsoft.com/fwlink/p/?LinkId=198942)

Windows Identity Foundation home page (http://go.microsoft.com/fwlink/p/?LinkId=198943)

An Introduction to Claims (http://go.microsoft.com/fwlink/p/?LinkId=217399)

SharePoint Claims-Based Identity (http://go.microsoft.com/fwlink/p/?LinkID=196647)

When you create a SharePoint Foundation 2010 Web application, you have the option of selecting either of two authentication modes: claims-based or classic-mode. For

new implementations of SharePoint Foundation 2010, you should consider using claims-based authentication. By using claims-based authentication, all supported

authentication types are available for your Web applications.

The following service applications require the translation of claims-based credentials to Windows credentials. This process of translation uses the Claims to Windows

Token Service (C2WTS):

Excel Services

PerformancePoint Services


Visio Services

The service applications that require the C2WTS must use Kerberos constrained delegation. This is because the C2WTS requires protocol transition, and protocol

transition is only supported by Kerberos constrained delegation. For the service applications in the preceding list, the C2WTS translates claims within the farm to

Windows credentials for outbound authentication. It is important to understand that these service applications can leverage the C2WTS only if the incoming

authentication method is either claims-based or classic-mode. Service applications that are accessed through Web applications and that use SAML claims or forms-



http://technet.microsoft.com/en-us/library/bb742516.aspx





based authentication claims do not use the C2WTS, and, therefore, cannot translate claims to Windows credentials.

For comprehensive guidance for configuring Kerberos in nine specific scenarios, including core deployment, three Microsoft SQL Server solutions, and scenarios that

use Excel Services, PowerPivot for SharePoint, Visio Services, PerformancePoint Services, and Business Connectivity Services, see Configuring Kerberos authentication for

SharePoint 2010 Products (http://go.microsoft.com/fwlink/p/?LinkId=197178).

© 2014 Microsoft


Forefront UAG integration (SharePoint Foundation 2010)



Information technology (IT) professionals who manage websites that use Microsoft SharePoint Foundation 2010 may want to make them available to users who are outside

of their corporate network. This concept is referred to as publishing, and this is made possible by using edge protection software such as Microsoft Forefront Unified

Access Gateway 2010 (UAG).

Publishing SharePoint Sites with UAG

The following articles contain procedures that are required to publish SharePoint websites through Forefront UAG.

SharePoint publishing solution guide (http://go.microsoft.com/fwlink/p/?LinkId=206256)

Intended for system administrators who are responsible for publishing SharePoint websites for extranet users.

Publishing SharePoint Workspace Mobile on Forefront UAG (http://go.microsoft.com/fwlink/p/?LinkId=206257)

Describes how to publish the SharePoint 2010 mobile workspace for extranet users.

© 2014 Microsoft




Claims-based authentication with Microsoft UAG 2010 (SharePointFoundation 2010)



Microsoft Unified Access Gateway (UAG) 2010 with Service Pack 1 (SP1) adds support for Active Directory Federated Services Version 2.0 (ADFS 2.0), and UAG is a claims-

aware relying party that now supports publishing Microsoft SharePoint Foundation 2010 applications with claims-based authentication. (Partner access using single sign-on

to applications or to servers running SharePoint Foundation 2010 and that are not claims-aware is still supported.)

The following steps detail the process flow for authenticating users from a partner organization through a server that is running UAG to a server that is running SharePoint

Foundation 2010:

1. The partner users attempt to access the published SharePoint Foundation application using claims-based authentication in one of two ways: by accessing the

Forefront UAG portal and then clicking the published SharePoint Foundation application or by accessing the published SharePoint Foundation application directly

using the SharePoint Foundation alternate access mapping name.

2. Forefront UAG redirects the web browser request to the Resource Federation server to authenticate the user.

3. The Resource Federation server shows the home realm discovery page to users on which they must choose the organization to which they belong; in this case, the

partner organization.

4. The Resource Federation server redirects the web browser to the Account Federation server where users authenticate using their own credentials, after which they

receive a security token. Some authentication schemes prompt for credentials.

5. Users are silently redirected several times and automatically authenticated using the security token created by the Account Federation server to the Resource

Federation server and then to Forefront UAG. If they attempted to access the published SharePoint Foundation application directly, they are silently redirected to the

SharePoint Foundation site, after which the SharePoint Foundation site appears. If they first accessed the Forefront UAG portal, they must click the SharePoint

Foundation application to view the SharePoint Foundation site.

6. After the first successful connection to the SharePoint Foundation site, the Resource Federation server stores a cookie on the user’s computer. The cookie is storedby default for 30 days; the duration is configurable in the web.config file on the Resource Federation server. During this time, users are not required to answer

identification questions on the home realm discovery page; that is, choosing the organization to which they belong.

Warning

Office integration will fail in this scenario if a remote client’s session expires on the UAG server.

Note

For more information about remote user access using claims and Microsoft UAG, see Plan employee access using claims.

UAG with SP1 also adds claims‐based authorization. For example: If a user has a role claim, UAG can allow or deny the user’s access based on the value of the claim. Theserules are set through policy in UAG and are mapped to roles in ADFS.

Note

These claims-based authorization rules can only be used when UAG is a relying party of ADFS.

UAG with SP1 also adds single sign-out functionality; users who sign out are also signed out from all applications that rely on the authenticating federation server. There

are a few ways that a client can sign out (or be signed out):

A user can sign out from the UAG portal.

A timed interval of inactivity can sign out a user.

http://technet.microsoft.com/en-us/library/gg274299.aspx

Scheduled sign-out times of UAG can sign out a user.

For more information about single sign-out, see Overview of AD FS 2.0 with Forefront UAG (http://go.microsoft.com/fwlink/p/?LinkId=207207).

UAG can still provide single sign-on (SSO) access if an application uses NTLM or Kerberos authentication, and UAG performs Kerberos translation for clients. For more

information, see Configuring single sign-on with Kerberos constrained delegation to non-claims-aware applications (http://go.microsoft.com/fwlink/p/?LinkId=207208).

See Also

Other ResourcesPlan employee access using claims

Overview of AD FS 2.0 with Forefront UAG (http://go.microsoft.com/fwlink/p/?LinkId=207207)

Configuring single sign-on with Kerberos constrained delegation to non-claims-aware applications (http://go.microsoft.com/fwlink/p/?LinkId=207208)

© 2014 Microsoft



http://technet.microsoft.com/en-us/library/gg274299.aspx



Plan for claims-based authentication or classic-modeauthentication (SharePoint Foundation 2010)



In Microsoft SharePoint Foundation 2010, you can choose between claims-based authentication and classic-mode authentication when you create a Web application.

For more information about these two authentication modes, see Plan authentication methods (SharePoint Foundation 2010).

Choosing classic-mode or claims-based authentication

Choosing between classic-mode and claims-based authentication should be based on business needs. For example, if you need to support user accounts in identity

providers that are not based on Active Directory Domain Services (AD DS), and you implement forms-based authentication, you must use forms-based authentication

with claims-based authentication in SharePoint Foundation 2010. We recommend that you use claims-based authentication whenever possible.

The following chart summarizes the support for authentication types by each authentication mode.

Type Classic-mode authentication Claims-based authentication

Windows authentication methods

NTLM

Kerberos

Anonymous

Basic

Digest

Yes Yes

Forms-based authentication methods

LDAP

SQL Server database or other database

Custom or third-party membership and role providers

No Yes

SAML token-based authentication methods

AD FS 2.0

Third-party identity provider

LDAP

N/A Yes

Upgrading to SharePoint Foundation 2010

If you are upgrading from Windows SharePoint Services 3.0 to SharePoint Foundation 2010, you should consider the following information:

If you are upgrading an earlier version solution to SharePoint Foundation 2010 and the solution includes only Windows accounts, you can use either mode of

Windows authentication: Windows Claims or Windows Classic. We recommend that you use claims-based authentication whenever possible. For more information

about using claims-based authentication, see Implementing Claims-Based Authentication with SharePoint Server 2010 (whitepaper).

If you are upgrading a solution that requires forms-based authentication, the only option is to upgrade to claims-based authentication.

Custom code that uses Windows identities might have to be updated. If you have custom code that uses Windows identities, you can use classic-mode

authentication until your code is updated and tested. For example, if you wrote a custom Web part for Windows SharePoint Services 3.0 that retrieved the current

user identity and you are upgrading to SharePoint Foundation 2010, you should use SPWeb.CurrentUser() instead of HttpContext.Current.User.Identity() in

order to retrieve the identity.

The migration time will vary, depending on the number of users that are listed in the UserInfo table in the content database. When you change a Web application

from Windows classic mode to Windows claims, you must use Windows PowerShell to convert Windows identities to Windows claims identities. Be sure to allow

for enough time during the upgrade process to complete this task.

You can search and list names in people picker when you are using SAML token-based authentication, but they cannot be checked for validity unless you write a

custom claims provider.

For more information about how to write a customer claim provider, see Custom claims providers for People Picker (SharePoint Foundation 2010).

If you are using the Outlook social connector, you must use either Windows classic-mode authentication or Windows claims authentication.

The following table illustrates several compatibility considerations when you migrate from Windows SharePoint Services 3.0 to SharePoint Foundation 2010.




To SharePoint Foundation

2010

Windows classic mode

authentication


2010

Windows claims

authentication methods


2010

forms-based


To SharePoint Foundation 2010

SAML token-based


From Windows SharePoint

Services 3.0

Windows authentication

methods

Supported Supported Not supported Not supported


Services 3.0

forms-based authentication

methods

Not supported Not supported Supported1 Supported2


Services 3.0

Web single sign-on

Not supported Not supported Not supported3 Not supported3

Notes for the previous table of compatibility considerations:

1. This upgrade path is supported by migrating to claims authentication.

2. This upgrade path is supported, but it requires additional configuration in order to complete the migration.

3. This upgrade path is not supported, but the same level of functionality is provided through SAML token-based authentication.

For additional information about migrating, see the following topics:

Upgrading to SharePoint Foundation 2010

Migrate from forms-based authentication to claims-based authentication (SharePoint Foundation 2010)

Migrate from classic-mode to claims-based authentication (SharePoint Foundation 2010)

Features that do not work with forms-based authentication or SAML security tokens

The following SharePoint Foundation 2010 features do not work when you switch to a claims-based Web application that uses forms-based authentication or Security

Assertion Markup Language (SAML) security tokens. These features do not work because claims-based authentication does not generate a Windows security token,

which is necessary for these features.

Search Alerts

SharePoint Foundation 2010 Explorer View

Claims to Windows Token Service (C2WTS)


Search crawling

Note

If you are using forms-based authentication or SAML token-based authentication, you will still need a separate zone that supports Windows authentication to

enable Microsoft Search Server 2010 to crawl your content.

Certificate Authentication

Note

Certificate authentication is not supported in SharePoint Foundation 2010, but you can configure Unified Access Gateway (UAG) as a front-end to SharePoint

Foundation 2010 to enable certificate authentication by integrating with Active Directory Federated Services (AD FS) and SAML token-based authentication.

For more information about configuring SharePoint Foundation 2010 with UAG, see Forefront UAG integration (SharePoint Foundation 2010).

Features that require additional configuration in order to work with forms-based authentication or

SAML security tokens

There are several SharePoint Foundation 2010 features that require additional configuration to work with forms-based authentication or SAML security tokens.

Business Intelligence (BI)





BI clients must either use Windows Claims authentication, Windows Classic authentication, or the Secure Store Service. When you are using the Secure Store

Service, SAML claims are not translated to Windows tokens, so other services will not detect the SAML identity; the identity will be the service account, an

anonymous account, or an unattended account.

Information Rights Management (IRM)

A hotfix that enables basic IRM functionality with claims and SAML is available from Microsoft. For more information, see Microsoft Knowledge Base article

Description of the SharePoint Foundation 2010 hotfix package: June 30, 2011(http://go.microsoft.com/fwlink/?LinkId=236873).

© 2014 Microsoft

http://go.microsoft.com/fwlink/?LinkId=236873

Configure claims authentication (SharePoint Server 2010)

Applies to: SharePoint Server 2010, SharePoint Foundation 2010


In this section:

Create claims-based web applications in SharePoint 2010

Configure anonymous access for a claims-based Web application (SharePoint Server 2010)

Configure forms-based authentication for a claims-based Web application (SharePoint Server 2010)

Configure Kerberos authentication for the claims to Windows token service (SharePoint Server 2010)

Configure authentication using a SAML security token (SharePoint Server 2010)

Configure claims-based authentication using Windows Live ID (SharePoint Server 2010)

Configure Digest authentication for a claims-based Web application (SharePoint Server 2010)

Configure Basic authentication for a claims-based Web application (SharePoint Server 2010)

Configure Client Certificate Authentication (SharePoint Server 2010)

See Also

Other ResourcesResource Center: Installation and Deployment for SharePoint Server 2010

© 2014 Microsoft










http://go.microsoft.com/fwlink/p/?LinkId=220214&clcid=0x409


Configure anonymous access for a claims-based Web application(SharePoint Server 2010)



Administrators can configure anonymous access, which is not enabled by default, for a claims-based Web application.

This article is obsolete.

For information about how to configure anonymous access for a claims-based Web application, see Create claims-based web applications in SharePoint 2010.

See Also

ConceptsPlan authentication methods (SharePoint Server 2010)

Choose security groups (SharePoint Server 2010)

© 2014 Microsoft





Configure forms-based authentication for a claims-based Webapplication (SharePoint Server 2010)



Procedures in this article illustrate how to configure a forms-based Web application to use an LDAP provider.

The procedures in this article provide guidance to enable you to configure forms-based authentication for a Microsoft SharePoint Server 2010 claims-based Web

application. If you need to migrate an existing Microsoft Office SharePoint Server 2007 Web application from forms-based authentication to claims-based authentication in

SharePoint Server 2010, see Migrate from forms-based authentication to claims-based authentication (SharePoint Server 2010).

Configure a forms-based Web application to use an LDAP provider by using Central Administration

Configure the LDAP Web.Config files

Configure a forms-based Web application to use an LDAP provider by using Windows PowerShell

Configure a forms-based Web application to use an LDAP provider by using Central Administration

Perform the steps in the following procedure to use Central Administration to configure forms-based authentication for a claims-based Web application.

To configure forms-based authentication for a claims-based Web application by using Central Administration

1. Verify that the user account that is performing this procedure is a site collection administrator.

2. In Central Administration, in the Application Management section, click Manage web applications.

3. In the Contribute group of the ribbon, click New.

4. In the Authentication section of the Create New Web Application dialog box, click Claims Based Authentication.

5. In the Claims Authentication Types section, select Enable Forms Based Authentication (FBA).

6. Type a membership provider name and a role manager name. In the example Web.Config file depicted in this article, the name of the membership provider is

membership, and the name of the role manager is rolemanager.

7. Click OK to create the Web application.

Configure the LDAP Web.Config files

After you have successfully created the Web application (described in the preceding procedure), modify the following Web.Config files:

The Central Administration Web application Web.Config file

The Security Token Service Web.Config file

The forms-based authentication claims-based Web application Web.Config file

To configure the Central Administration Web.Config file

1. Start IIS Manager by typing INETMGR at a command prompt.

2. Go to the SharePoint Central Administration site in IIS.

3. Right-click SharePoint Central Administration and then click Explore.

4. Open the Web.Config file.

5. Find the <Configuration> <system.web> section and add the following entry:

<membership defaultProvider="AspNetSqlMembershipProvider">

<providers>

<add name="membership"

type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

server="yourserver.com"

port="389"

useSSL="false"

userDNAttribute="distinguishedName"

userNameAttribute="sAMAccountName"

userContainer="OU=UserAccounts,DC=internal,DC=yourcompany,DC= distinguishedName (of your userContainer)"


Important

After you have added the preceding entry, save and close the Web.Config file.

To configure the Security Token Service Web.Config file


2. Go to the SharePoint Web Services site.

3. Go to the SecurityTokenServiceApplication sub-site.

4. Right-click SecurityTokenServiceApplication and then click Explore.


6. Find the <Configuration> <system.web> section and add the following entry:

Important

userObjectClass="person"

userFilter="(ObjectClass=person)"

scope="Subtree"

otherRequiredUserAttributes="sn,givenname,cn" />

</providers>

</membership>

<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider" >

<providers>

<add name="roleManager"

type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"


port="389"

useSSL="false"

groupContainer="DC=internal,DC=yourcompany,DC= distinguishedName (of your groupContainer)"

groupNameAttribute="cn"

groupNameAlternateSearchAttribute="samAccountName"

groupMemberAttribute="member"


dnAttribute="distinguishedName"

groupFilter="((ObjectClass=group)"

userFilter="((ObjectClass=person)"

scope="Subtree" />

</providers>

</roleManager>

<membership>

<providers>




port="389"

useSSL="false"



userContainer="OU=UserAccounts,DC=internal,DC=yourcompany,DC=com"


userFilter="(&(ObjectClass=person))"

scope="Subtree"


</providers>

</membership>

<roleManager enabled="true" >

<providers>

<add name="rolemanager"



port="389"

useSSL="false"

groupContainer="DC=internal,DC=yourcompany,DC=com"






groupFilter="(&(ObjectClass=group))"


scope="Subtree" />

</providers>

</roleManager>


To configure the forms-based authentication claims-based Web application Web.Config file


2. Go to the Claims Forms site.

3. Right-click Claims Forms and then click Explore.


5. Find the <Configuration> <system.web> section.

6. Find the <membership defaultProvider="i"> section and add the following entry:

Find the <roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false"> section and add the following entry:

Important


Warning

Do not overwrite any existing entries in this Web.Config file.

Configure a forms-based Web application to use an LDAP provider by using Windows PowerShell

Perform the steps in the following procedure to use Windows PowerShell to configure forms-based authentication for a claims-based Web application.

To configure a forms-based Web application to use an LDAP provider by using Windows PowerShell

1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

2. On the Start menu, click All Programs.

3. Click Microsoft SharePoint 2010 Products.

4. Click SharePoint 2010 Management Shell.

5. From the Windows PowerShell command prompt, type the following:




port="389"

useSSL="false"



userContainer="OU=UserAccounts,DC=internal, DC=yourcompany,DC=com"



scope="Subtree"


<add name="roleManager"



port="389"

useSSL="false"

groupContainer="DC=internal,DC=yourcompany,DC=com"






groupFilter="(&(ObjectClass=group))"


scope="Subtree" />

$ap = New-SPAuthenticationProvider -Name "ClaimsForms" -ASPNETMembershipProvider "membership" -ASPNETRoleProviderName "rolemanager"

$wa = New-SPWebApplication -Name "Claims Windows Web App" -ApplicationPool "Claims App Pool" -ApplicationPoolAccount "internal\appool"


Note

The value of the ApplicationPoolAccount parameter must be a managed account on the farm.

6. After you have successfully created an authentication provider and a Web application, modify the following Web.Config files by using the sample entries provided

in the Configure the LDAP Web.Config files section of this article:

The Central Administration Web application Web.Config file

The Security Token Service Web.Config file

The forms-based authentication claims-based Web application Web.Config file

7. After you have modified the Web.Config files, create a SPClaimsPrincipal and a site collection, as shown in the following example:

For more information, see New-SPClaimsPrincipal.

Note

We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is

included to support compatibility with previous product versions.

See Also

ConceptsMigrate from forms-based authentication to claims-based authentication (SharePoint Server 2010)

Other ResourcesResource Center: Security and Authentication for SharePoint Server 2010

© 2014 Microsoft

-Url http://servername -Port 80 -AuthenticationProvider $ap

$cp = New-SPClaimsPrincipal -Identity "membership:SiteOwner" -IdentityType FormsUser

$sp = New-SPSite http://servername:port -OwnerAlias $cp.Encode() -Template "STS#0"




Configure Kerberos authentication for the claims to Windowstoken service (SharePoint Server 2010)



This article is obsolete.

For information about how to configure Kerberos authentication, see Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products and Technologies (white

paper). (http://go.microsoft.com/fwlink/p/?LinkID=197178) white paper.

See Also

ConceptsPlan authentication methods (SharePoint Server 2010)

Other ResourcesResource Center: Installation and Deployment for SharePoint Server 2010

© 2014 Microsoft





Configure authentication using a SAML security token (SharePointServer 2010)



The procedures in this article explain how to configure authentication using a Security Assertion Markup Language (SAML) security token for a Microsoft SharePoint Server

2010 claims-based Web application.

SAML sign-in is typically used in enterprise federation scenarios, for example, to provide access to a business partner. SAML sign-in is also deployed to provide access to

internal users whose accounts reside in a domain that is not part of the forest that contains SharePoint Server 2010.

Before you configure authentication using a SAML security token for a SharePoint Server 2010 claims-based Web application, you must configure an identity provider that

supports WS-Federation, such as Active Directory Federation Services (AD FS) 2.0. For information about configuring a server to run AD FS 2.0, see the AD FS 2.0

Deployment Guide (http://go.microsoft.com/fwlink/p/?LinkId=191723).

In this article:

Configure an Identity Provider STS (IP-STS) Web application by using Windows PowerShell

Configure a Relying Party STS (RP-STS) Web application

Establish a trust relationship between the IP-STS and the RP-STS by using Windows PowerShell

Export the trusted IP-STS certificate by using Windows PowerShell

Define a unique identifier for claims mapping by using Windows PowerShell

Create a new SharePoint Web application and configure it to use SAML sign-in

Enable replay protection

Configure an Identity Provider STS (IP-STS) Web application by using Windows PowerShell

Perform the following procedures to use Windows PowerShell to configure a SharePoint claims-based Web application.

To configure an Identity Provider STS (IP-STS) Web application by using Windows PowerShell





5. From the Windows PowerShell command prompt, create an x509Certificate2 object, as shown in the following example:

6. Create a claim type mapping to use in your trusted authentication provider, as shown in the following example:

7. Create a trusted login provider by first creating a value for the realm parameter, as shown in the following example:

8. Create a value for the signinurl parameter that points to the Security Token Service Web application, as shown in the following example:

9. Create the trusted login provider, using the same IdentifierClaim value as in a claim mapping ($map1.InputClaimType), as shown in the following

example:

$cert = New-Object

System.Security.Cryptography.X509Certificates.X509Certificate2("path to cert file")

New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

-IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

$realm = "urn:" + $env:ComputerName + ":domain-int"

$signinurl = "https://test-2/FederationPassive/"



10. Create a Web application by first creating a value for the application pool account (for the current user), as shown in the following example:

Note

The application pool account must be a managed account. To create a managed account, use New-SPManagedAccount.

11. Create a value for the Web application URL ($webappurl = "https://" + $env:ComputerName), as shown in the following example:

12. Create a site by first creating a claim object, as shown in the following example:

13. Create a site, as shown in the following example:

Configure a Relying Party STS (RP-STS) Web application

Use the procedure in this section to configure a relying-party STS Web application.

To configure a Relying Party STS (RP-STS) Web application

1. Open the Active Directory Federation Services (AD FS) 2.0 Management console.

2. In the left pane, expand Policy, and select Relying Parties.

3. In the right pane, click Add Relying Party. This opens the Active Directory Federation Services (AD FS) 2.0 configuration wizard.

4. On the first page of the wizard, click Start.

5. Select Enter relying party configuration manually, and click Next.

6. Type a relying party name and click Next.

7. Make sure Active Directory Federation Services (AD FS) 2.0 Server Profile is selected, and click Next.

8. Do not use an encryption certificate. Click Next.

9. Select Enable support for Web-browser-based identity federation.

10. Type the name of the Web application URL, and append /_trust/ (for example: https://servername/_trust/). Click Next.

11. Type the name of an identifier (for example: urn:COMPUTERNAME:Geneva), and click Add. Click Next.

12. On the Summary page, click Next and then click Close. This opens the Rules Editor Management console. Use this console to configure the mapping of claims

from an LDAP Web application to SharePoint.

13. In the left pane, expand New Rule, and select Predefined Rule.

14. Select Create Claims from LDAP Attribute Store.

15. In the right pane, from the Attribute Store drop-down list, select Enterprise Active Directory User Account Store.

16. Under LDAP Attribute, select sAMAccountName.

$ap = New-SPTrustedIdentityTokenIssuer -Name

"WIF" ‐Description "Windows® Identity Foundation" ‐Realm$realm -ImportTrustCertificate $cert

-ClaimsMappings $map1[,$map2..] -SignInUrl

$signinurl -IdentifierClaim $map1.InputClaimType

$account = "DOMAIN\" + $env:UserName

$wa = New-SPWebApplication -name "Claims WIF"

-SecureSocketsLayer -ApplicationPool "SharePoint SSL"

-ApplicationPoolAccount $account -Url $webappurl -Port 443

-AuthenticationProvider $ap

$claim = New-SPClaimsPrincipal

-TrustedIdentityTokenIssuerr $ap -Identity

$env:UserName

$site = New-SPSite $webappurl -OwnerAlias

$claim.ToEncodedString() -template "STS#0"

17. Under Outgoing Claim Type, select E-Mail Address.

18. In the left pane, click Save.

Establish a trust relationship with an Identity Provider STS (IP-STS) by using Windows PowerShell

Use the procedure in this section to establish a trust relationship with an IP-STS.

To establish a trust relationship with an IP-STS by using Windows PowerShell





5. From the Windows PowerShell command prompt, establish a trust relationship, as shown in the following example:

Export the trusted IP-STS certificate by using Windows PowerShell

Use the procedure in this section to export the certificate of the IP-STS with which you want to establish a trust relationship, and then copy the certificate to a location

that Microsoft SharePoint Server 2010 can access.

To export the trusted IP-STS certificate by using Windows PowerShell





5. From the Windows PowerShell command prompt, export the trusted IP-STS certificate, as shown in the following example:

Define a unique identifier for claims mapping by using Windows PowerShell

Use the procedure in this section to define an e-mail address that will serve as a unique identifier for claims mapping. Typically, the administrator of the trusted STS will

have to provide this information because only the owner of the STS knows which value in the token will be always unique for each user. Note that the administrator of the

trusted STS can create a URI to represent the e-mail address.

To define a unique identifier for claims mapping by using Windows PowerShell





5. From the Windows PowerShell command prompt, create a mapping, as shown in the following example:

Create a new authentication provider

Use the procedure in this section to create a new authentication provider that the Web application will use.

To create a new authentication provider by using Windows PowerShell


$waurl = "https://" + $env:ComputerName

$title = "SAML-Claims"

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\geneva.cer")

$map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming








5. From the Windows PowerShell command prompt, create a new authentication provider, as shown in the following example. Note that the realm is the parameter

used by the trusted STS to identify a specific SharePoint farm.

Create a new SharePoint Web application and configure it to use SAML sign-in

In this step, you create and configure the Web application.

To create a new SharePoint Web application and configure it to use SAML sign-in by using Windows PowerShell





5. From the Windows PowerShell command prompt, create a new SharePoint Web application and configure it to use SAML sign-in. Note that you must replace

"WebAppUrl" and "domain\admin" with the valid values.

Note

You are enabling SSL, because with SAML sign-in, cookies are used as the single sign-on ticket for the user. This allows administrators to grant access to the

SharePoint resources for the duration of the token without the need of re-authenticate the user. Without SSL, these cookies can be easily hijacked by a

malicious user and be used to impersonate the original user.

When you have completed these procedures, create a SharePoint site and assign an owner. For information about creating a SharePoint site, see Create a site collection

(SharePoint Server 2010).

Enable token replay protection

To provide additional security for UNRESOLVED_TOKEN_VAL(1st_OSS_14) web applications that use SAML-based claims authentication, you can use the

UNRESOLVED_TOKEN_VAL(IDFX_O15_supported_1st) token replay detection feature. Token replay protection can prevent an attacker from trying to intercept and use a

user’s security token. For more information, see Replay Detection.

Use the procedure in this section to enable replay detection on a UNRESOLVED_TOKEN_VAL(1st_OSS_14) web application that is configured for SAML claims

authentication.

To enable replay protection

1. On the server running UNRESOLVED_TOKEN_VAL(1st_OSS_14), open the Internet Information Services (IIS) Manager snap-in.

2. In the console tree of Internet Information Services (IIS) Manager, right-click the site that corresponds to the name of the web application, and then click Explore.

3. In the folder window, double-click the Web.Config file.

4. In the <Configuration> section, find the <microsoft.identityModel> section.

5. Add the following as a new section to the <microsoft.identityModel> section:

in which:

<NumberOfTokensToBeCached> is the number of tokens to store in the token replay detection cache.

<TokenCacheExpiration> is the time after which a token in the replay detection cache is removed, in <hours>:<minutes>:<seconds> format.

$realm = "urn:" + $env:ComputerName + ":Geneva"

$ap = New-SPTrustedIdentityTokenIssuer -Name "Geneva" -Description "Geneva" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https:// test-2/FederationPassive/" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

$wa = New-SPWebApplication -Name "SAML Sign-In" -SecureSocketsLayer -ApplicationPool "SAML Sign-In" -ApplicationPoolAccount "domain\admin" -

Url "WebAppUrl" -Port 443 -AuthenticationProvider $ap

<service>

<tokenReplayDetection enabled="true" capacity="<NumberOfTokensToBeCached>" expirationPeriod="<TokenCacheExpiration>">

</service>



http://technet.microsoft.com/en-us/library/ee517257.aspx

6. Save your changes to the Web.Config file.

For important considerations about enabling token replay protection in a load-balanced environment, see ACS Security Guidelines.

See Also

Other ResourcesResource Center: Security and Authentication for SharePoint Server 2010

© 2014 Microsoft



Configure claims-based authentication using Windows Live ID(SharePoint Server 2010)



Claims-based authentication in Microsoft SharePoint Server 2010 can delegate authentication to the Windows Live ID Security Token Service (STS). This is important if you

want to implement a scenario in which you use Windows Live ID for password management. The Windows Live ID service is configured as the identity provider for

SharePoint Server 2010. A one-way, certificate-based trust relationship is established between SharePoint Server 2010 and the Windows Live ID service. When a user

provides Windows Live ID credentials, the Windows Live ID service returns a Passport Unique Identity (PUID) and e-mail information encapsulated in a Security Assertion

Markup Language (SAML) version 1.1 claims token. The Windows Live ID public key, which is part of Windows Live ID Metadata XML, encrypts this claims token.

For more information about Windows Live ID, refer to the following resources:

Introduction to Windows Live ID (http://go.microsoft.com/fwlink/?LinkId=201477)

Microsoft Federation Gateway (http://go.microsoft.com/fwlink/?LinkId=150843)

Windows Live Developer Center (http://go.microsoft.com/fwlink/?LinkId=191075)

The Windows Live ID cookie is cached on the client computer and sent to SharePoint Server 2010 by way of a POST response to a successful authentication request.

SharePoint Server 2010 converts the Windows Live ID SAML token to a SharePoint Server 2010 SAML token. The PUID for the user is generated based on the user principal

name (UPN) claim returned in the SAML token. This value is used throughout SharePoint Server 2010 to uniquely identify the user and perform access control. SharePoint

Server 2010 can augment user tokens with additional claims by using a custom claims provider, which is configured in the SharePoint Server 2010 Web application. The

SharePoint Server 2010 cookie is also returned to the client computer and cached for subsequent requests. When the Windows Live ID or SharePoint Server 2010 cookie

expires, the user is redirected to a Windows Live ID server.

In this article:

Configure the Windows Live ID Security Token Service

Configure SharePoint for Windows Live ID authentication

Convert a Windows Live ID internal environment to a production environment

Create different types of SharePoint claims-based Web applications

Grant permissions to all Windows Live ID authenticated users

Configure the Windows Live ID Security Token Service

The WS-Federation protocol is implemented by the Windows Live ID service, and provides the infrastructure of the Live ID STS that is designated as a trusted identity

provider. You can extract a Windows Live ID public certificate from a metadata XML X509Certificate node and save it to an Internet security certificate with a .cer

file extension. If the metadata XML contains multiple X509Certificate nodes, you can use any of them. Provide read access to the SharePoint Server 2010 farm

application pool account in Internet security certificate (.cer file).

Configure the Microsoft Services Manager (MSM) using the following values:

Value Description

Domain Name The domain name for which authentication requests to the Live ID STS will be generated. Use a Fully Qualified Domain Name (FQDN).

Default Return

URL

The URL that the Windows Live ID STS will redirect a user to after successful authentication, for example:

https://username.global.corp.contoso.com/_trust/default.aspx.

DNS Name The unique identifier provided in an authentication request to the Windows Live ID STS. This unique identifier enables look-up functionality for the

Default Return URL. The DNS Name must correspond to the realm value specified in Windows Live ID authentication request.

WRealm

Parameter

The WRealm parameter must match the DNS field in the MSM Site configuration. The WRealm parameter must be created by using one of the

following formats: sub.domain.top or Urn:domain:name.

Override

Authentication

Policy

Configure the Override Authentication Policy by using the following value: MBI_FED_SSL.

Configure SharePoint for Windows Live ID authentication

Use the procedures in this section to configure SharePoint Server 2010 for Windows Live ID authentication.





To configure SharePoint for Windows Live ID authentication by using Windows PowerShell





5. From the Windows PowerShell command prompt (that is, PS C:\>), define the realm value to match the DNS Name value specified in the Microsoft Services

Manager. The realm value in Windows Live ID integration should correspond to the correct DNS name, as shown in the following example:

6. Get the PUID value of the account that you will use as the Farm Administrator account by first signing in to following Web site: Windows Live

ID(https://accountservices.passport-int.net/?ru=https://accountservices.passport-int.net/Credentials.srf%3Fvv%3D750%26mkt%3DEN-

US%26lc%3D1033&vv=750&mkt=EN-US&lc=1033&id=10), and then locating the Unique ID field on the Credentials page.

7. Specify the PUID value using the following format: [email protected].

8. Locate one of the <X509Certificate> nodes in the following source: Metadata XML URL (https://nexus.passport-int.com/federationmetadata2/2007-

06/federationmetadata.xml).

9. Copy the contents of either of the two X509Certificate nodes, as shown in the following example:

10. Paste the contents of either X509Certificate node into a new Notepad file and save the Notepad file with the following file name: LiveID-INT.cer.

11. Configure the Windows Live ID certificate (extracted from metadata XML), as shown in the following example:

12. Define a new trusted root authority in SharePoint Server 2010, as shown in the following example:

13. Create an object with a Windows Live ID certificate, as shown in the following example:

14. Define the claim you will use as the unique identifier of the user. Map the UPN claim to the reserved claim name Identifier. The e-mail Address claim can also be

mapped, as shown in the following example:

15. Create a new SharePoint Server 2010 authentication provider for a new Web application, as shown in the following example:

$realm = "urn:" + $env:ComputerName + ":ServerName"

MIICWzCCAcSgAwIBAgIJAJEzHoaEodSoMA0GCSqGSIb3DQEBBQUAMCkxJzAlBgNV

BAMTHkxpdmUgSUQgU1RTIFNpZ25pbmcgUHVibGljIEtleTAeFw0wODEwMzAyMjA5

MjNaFw0xMzEwMjkyMjA5MjNaMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25p

bmcgUHVibGljIEtleTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArz97XPae

GNAC4UnKl5zReyhgk3Bzf08U+CgD0R9+GZOahmpakJXFpI213gQWiHrUGaMN9nsK

4kzSfDPiquAMsV6vBYyWuPLZ0XrMzTAOV/WHSK3bCsYWWQZeH9Xn8G1Hkz+gQSC/

92lBbq9oBCZfLv3OlkobOmT8d+ldRKGU4pUCAwEAAaOBijCBhzAdBgNVHQ4EFgQU

VbJyIcGL0AjB4/Wm4DqUZux6uUkwWQYDVR0jBFIwUIAUVbJyIcGL0AjB4/Wm4DqU

Zux6uUmhLaQrMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25pbmcgUHVibGlj

IEtleYIJAJEzHoaEodSoMAsGA1UdDwQEAwIBxjANBgkqhkiG9w0BAQUFAAOBgQAO

/5vGfu+Vg1TKBuxsAIMqjqKXX7aRrANNZM/5ACdwAUtMDG/n8INoXgOKr851fbF6

4yBesmFjg2TbR8y0/ITAD+d+iyEpR7IO3/is9rWAj4ggbw8yqaDWn26eh3bAdoa+

p38qtqJHkUGF5vApeHiu6zO573bKs+nXcKVM8mNbjA==

$certloc = "C:\LiveIDWithSAML\LiveID-INT.cer"

$rootcert = Get-PfxCertificate $certloc

New-SPTrustedRootAuthority "NewRootAuthority" -Certificate $rootcert | Out-Null

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)

$map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/claims/EmailAddress" -IncomingClaimTypeDisplayName "http://schemas.xmlsoap.org/claims/EmailAddress" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

$apSAML = New-SPTrustedIdentityTokenIssuer -Name "LiveID" -Description "LiveID" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2 -SignInUrl "https://login.live-int.com/login.srf" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"


https://accountservices.passport-int.net/?ru=https://accountservices.passport-int.net/Credentials.srf?vv=750&mkt=EN-US&lc=1033&vv=750&mkt=EN-US&lc=1033&id=10

https://nexus.passport-int.com/federationmetadata2/2007-06/federationmetadata.xml

16. Create a new SharePoint Server 2010 Web application to use with the authentication provider created in the previous step, as shown in the following example:


18. Go to the Claims Web Application site in IIS.

19. In the left pane, right-click Claims Web Application, and select Edit Bindings.

20. Select https and click Edit.

21. Under SSL Certificate, select any listed certificate. Consider using a self-signed certificate.

22. Import the Windows Live ID public certificate to the Local computer, SharePoint Server 2010, and Trusted People folders.

Convert a Windows Live ID internal environment to a production environment

Use the procedures in this section to convert a Windows Live ID internal environment to a production environment.

To convert a Windows Live ID internal environment to a production environment

1. Make sure the site is migrated to a production environment in MSM, and that compliance is complete. A compliance review is not required if the Windows Live ID

environment in MSM is internal.

2. Make sure that the authentication policy of the Windows Live ID production environment is configured with the following value: MBI_FED_SSL.

3. Make sure that the Windows Live ID production environment uses HTTPS-based URLs because the production environment authentication policy is configured for

SSL transport. The production environment sites send POST requests over SSL to https://login.live.com. In the SPTrustedIdentityTokenIssuer there is a

Provider URI that should be the live login URI. Make sure the live logon URI is HTTPS-based.

4. If the Windows Live ID claims provider is configured to use an e-mail address instead of a PUID, the production environment site should be in the Microsoft policy

group. Be aware that this policy group is auto-approved for internal partners, and explicit approval is required for external partners.

Create different types of SharePoint claims-based Web applications

Use the procedures in this section to run a Windows PowerShell script to create different types of SharePoint Server 2010 claims-based Web applications.

To create different types of SharePoint claims-based Web applications by using Windows PowerShell





5. From the Windows PowerShell command prompt, run the DeployLiveIdWithSAML script, as shown in the following example:

$waurl = https://" + $env:ComputerName - You might use FQDN url of your site here.

$title = "Site Title"

$waexe = New-SPWebApplication -Name $title -ApplicationPool $title -ApplicationPoolAccount $owner -Url $waurl -AuthenticationProvider

$scexe = New-SPSite $siteurl -Name $title -Description $title -Template 'STS#1' -OwnerAlias

#.SYNOPSIS

# Script for creating different types of claims web applications from the Windows PowerShell command line.

#.DESCRIPTION

# Script will create ANON, WIN, FBA, MULTI, MIXED, SAML and combinations of these web applications.

#.NOTES

# Script: ClaimsWA.ps1

# Remark: The script will load/unload additional snap-ins depending on where it's being executed from.

# Update: 1/15/2010 (v2.0)

#.PARAMETER type

# Indicates the type of claims web app to create (see examples for full list of valid supported types)

#If not specified, this will default to ALL and each of the supported types of claims web apps will be created

#.PARAMETER port

# Indicates the port number to create the web app on (See reserved ports at http://support.microsoft.com/kb/832017)

#If not specified, this will default to port 201 and will be incremented in sequence for multiple web apps

#.PARAMETER owner

# Indicates the domain account that will be used for App Pool (should be registered as a SharePoint Server managed account)

#If not specified, this will default to logged on user and will use USERDOMAIN & USERNAME environment values

#.EXAMPLE

# claimswa.ps1 WIN (create WIN-claims web app at port# 201 and use logged on user for app pool account)

#

# Here are some more examples of HOWTO use the script:

# claimswa.ps1 ANON (create ANON web app at port# 201)

# claimswa.ps1 ANON/FBA 701 (create ANON/FBA web app at port# 701)

# claimswa.ps1 FBA (create FBA web app at port# 201 using LDAP provider; default is REDMOND instance)


# claimswa.ps1 FBA/IBM (create FBA web app at port# 201 using LDAP provider pointing to the IBM instance)

# claimswa.ps1 FBA/SQL 851 (create forms-based authentication web app at port# 851 using SQL provider)

# claimswa.ps1 WIN/FBA/MIXED 501 (create Windows/forms-based authentication mixed-mode web apps at port# 501)

# claimswa.ps1 WIN/SAML/MULTI 901 (create Windows/SAML multi-auth web apps at port# 901)

#

# Here is the full list of all the support TYPEs (combine options delimited with slash for your config):

#

# Basic auth types:

# WIN : create Windows claims web application on the port# specified on command line

# FBA : create forms-based authentication claims web apps with the specified membership provider (SQL Server/LDAP listed below)

# SAML : create SAML-claims web application on the default HTTPS port# 443

# ANON : indicator switch for creating the web application to allow ANON mode

# Complex auth types:

# MULTI : create claims web application with multiple auth types using a single URL to access

# MIXED : create claims web application with multiple auth types using multiple URLs to access

# FBA membership/rolemanager providers

# RED : use the REDMOND domain LDAP provider; this is the default setting if a provider is not specified

# SQL : use the SQL Server provider for connecting to forms-based authentication web apps (connects to the ASPNETDB instance on ZADANG)

# PPL : use the PEOPLEDC domain LDAP provider that is a private domain used for testing PEOPLE features

# SUN : use the SUNOne LDAP provider in the PEOPLEDC domain which is used for profile import/sync testing

# IBM : use the IBM LDAP provider in the PEOPLEDC domain which is used for profile import/sync testing

# NVL : use the Novell LDAP provider in the PEOPLEDC domain which is used for profile import/sync testing

# TODO (no specific ETA for these updates):

# 1. Set the default IIS cert bindings for SAML web

# 2. Use IIS CMDlets instead of updating XML object

# 3. We should be able to define MixedMode base auth

# 4. Use the domain for logged on user for LDAP string

# 5. Do not attempt to write to CA/STS if running on WFE

# Define the args list that we will accept & work with

param ([string]$type, [int]$port, [string]$owner)

function main() {

# Valid options list

$auths = @("WIN", "FBA", "SAML", "ANON")

$extnd = @("MULTI", "MIXED")

$provs = @("SQL", "RED", "PPL", "SUN", "IBM", "NVL")

$optns = @("APP", "FIX")

$typeOK = $true

# Do we have the minimum args data before we can proceed

# I'm not doing extensive validation but at least minimum

foreach ($arg in $type.split("/")) {

if (($auths+$extnd+$optns+$provs) -notcontains $arg) {

write-host -Fore Red "`nInvalid TYPE argument was specified; execution aborted!`nTo see a list of valid TYPEs, execute with -examples option`n"

$typeOK=$false; break

}

}

if ($typeOK) {

$type = @($type.toupper().split("/") | Sort | Get-Unique)

switch ($type.count) {

1 {

foreach ($arg in $type) {

if (($auths+$extnd+$optns) -notcontains $arg) {

write-host -Fore Red "`nInvalid AUTH argument was specified; execution aborted!`nTo see a list of valid AUTHs, execute with -examples option`n"


}

}

if (($type -eq "MULTI") -or ($type -eq "MIXED")) {

$type += @("WIN", "FBA"); write-host -Fore Yellow "MULTI/MIXED auth combo not specified; defaulting to $type"

}

if ($type -eq "ANON") {

$type += @("WIN"); write-host -Fore Yellow "ANON auth combo not specified; defaulting to $type"

}

}

2 {

if ($type -contains "ANON") {


if ($auths -notcontains $arg) {

write-host -Fore Red "`nInvalid ANON combo was specified; execution aborted!`nTo see a list of valid PROVIDERs, execute with -examples option`n"


}

}

}

else {

$multiOK=$true


if ($auth -notcontains $arg) {

$multiOK=$false; break

}

}

if ($multiOK) {$type += @("MULTI"); write-host -Fore Yellow "Multiple auth types specified; defaulting to $type"}

}

}

}

if (($type -contains "MULTI") -or ($type -contains "MIXED") -and ($type.count -lt 3)) {

write-host -Fore Red "`nMULTI/MIXED option requires 2 base auth types be specified!`nTo see a list of valid TYPEs, execute with -examples option`n"

$typeOK=$false

}

}

if ($typeOK) {

# We seem to have the TYPE argument, let's check the others

if (-not $port) {

if ($type -contains "SAML") {$port=443} else {$port=201}

write-host -Fore Yellow "PORT not specified; defaulting to $port"

}

if (-not $owner) {

$owner = $env:UserDomain + "\" + $env:UserName.tolower()

write-host -Fore Yellow "OWNER not specified; defaulting to $owner"

}

#In case somebody attempts to execute this script in the regular PS/ISE console,

#let's load the IIS/SP snap-in to ensure we have everything we need to work with

Manage-SnapIns (1)

# check what flavor of SERVER we're running

$product = Get-SPProduct | Where-Object {$_.ProductName.contains("SharePoint Server 2010")};

if ($product.ProductName.contains("Debug")) {$flavor="DEBUG"} else {$flavor="SHIP"}

write-host -Fore Green "Detected $flavor flavor of MOSS installed on this farm!"

if ($type -contains "APP") {

Write-WEBConfigs 0 "APP"

}

elseif ($type -contains "FIX") {

Fix-Environment

}

else {

Create-WebApp $type $port

}

# We're done with the snap-ins, so let's unload them

Manage-SnapIns (0)

}

}

function Fix-Environment {

# This is just a series of steps to clean up

# Not recommended to use unless you know why!

Remove-SPTrustedRootAuthority NewRootAuthority

Remove-SPTrustedIdentityTokenIssuer ServerName

# I need to add the other clean up stuff here...

}

# This is the core script block that creates the different web apps

function Create-WebApp ([string]$type, [int]$port) {

$waurl = http://" + $env:ComputerName

if ($type.contains("SAML")) { $waurl = $waurl.replace("http", "https") }

$siteurl = $waurl + ":" + $port

$title = "ClaimsWA-$port-" + $type.replace(" ","-")

# Let's construct the WA/SC CMDlet call that we'll invoke later

$waexe = "New-SPWebApplication -Name $title -ApplicationPool $title -ApplicationPoolAccount $owner -Url $waurl -AuthenticationProvider"

$scexe = "New-SPSite $siteurl -Name $title -Description $title -Template 'STS#1' -OwnerAlias"

write-host -Fore Cyan "`nSetting up $title on port $port now:"

if ($type.contains("WIN")) {

$apWIN = New-SPAuthenticationProvider -DisableKerberos:$true

$cpWIN = New-SPClaimsPrincipal -Identity $owner -IdentityType 1

}

if ($type.contains("FBA")) {

if ($type.contains("SQL")) {

$membership="SQLms"; $rolemanager="SQLrm"; $identity = "sqlms:user1"

}

elseif ($type.contains("PPL")) {

$membership="PPLms"; $rolemanager="PPLrm"; $identity = "pplms:fbauser1"

}

elseif ($type.contains("SUN")) {

$membership="SUNms"; $rolemanager="SUNrm"; $identity = "sunms:fbauser1"

}

elseif ($type.contains("IBM")) {

$membership="IBMms"; $rolemanager="IBMrm"; $identity = "ibmms:fbauser1"

}

elseif ($type.contains("NVL")) {

$membership="NVLms"; $rolemanager="NVLrm"; $identity = "nvlms:fbauser1"

}

else {

$membership="REDms"; $rolemanager="REDrm"; $identity = ("redms:$env:UserName").tolower()

}

$apFBA = New-SPAuthenticationProvider -ASPNETMembershipProvider $membership -ASPNETRoleProviderName $rolemanager;

$cpFBA = New-SPClaimsPrincipal -Identity $identity -IdentityType 4

}

if ($type.contains("SAML")) {

$realm = "urn:" + $env:ComputerName + ":ServerName"

$user = "[email protected]"

$certloc = "C:\LiveIDWithSAML\LiveID-INT.cer"

$rootcert = Get-PfxCertificate $certloc

New-SPTrustedRootAuthority "NewRootAuthority" -Certificate $rootcert | Out-Null

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)

$map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/claims/EmailAddress" -IncomingClaimTypeDisplayName "http://schemas.xmlsoap.org/claims/EmailAddress" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

$apSAML = New-SPTrustedIdentityTokenIssuer -Name "LiveID" -Description "LiveID" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2 -SignInUrl "https://login.live-int.com/login.srf" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"

$cpSAML = New-SPClaimsPrincipal -TrustedIdentityTokenIssuer $apSAML -Identity $user.tolower()

}


$waexe += " `$apWIN"; $scexe += " `$cpWIN.ToEncodedString()"

}

elseif ($type.contains("FBA")) {

$waexe += " `$apFBA"; $scexe += " `$cpFBA.ToEncodedString()"

}

else {

$waexe += " `$apSAML -SecureSocketsLayer"; $scexe += " `$cpSAML.ToEncodedString()"

}

if ($type.contains("MULTI")) {


if ($type.contains("FBA")) {

$waexe += ",`$apFBA"; $scexe += " -SecondaryOwnerAlias `$cpFBA.ToEncodedString()"

}

if ($type.contains("SAML")) {

$waexe += ",`$apSAML -SecureSocketsLayer"; if (!$scexe.contains("Secondary")) { $scexe += " -SecondaryOwnerAlias `$cpSAML.ToEncodedString()" }

}

}

else {

$waexe += ",`$apSAML -SecureSocketsLayer"; $scexe += " -SecondaryOwnerAlias `$cpSAML.ToEncodedString()"

}

}

# Check if we're creating the ANON web apps

if ($type.contains("ANON")) { $waexe += " -AllowAnonymousAccess" }

$waexe += " -Port $port | Out-Null"; $scexe += " | Out-Null"

write-host -Fore Cyan "Deploying app..." -noNewLine

Invoke-Expression $waexe

# We could do this with a simple if/else but there may be other auth types too

if ($type.contains("WIN")) { Create-UserPolicy $siteurl $cpWIN.ToEncodedString() }

if ($type.contains("FBA")) { Create-UserPolicy $siteurl $cpFBA.ToEncodedString() }

if ($type.contains("SAML")) { Create-UserPolicy $siteurl $cpSAML.ToEncodedString() }

write-host -Fore Cyan "Creating site..." -noNewLine

Invoke-Expression $scexe

# If this is the ANON web app, then set the root site access to entire web

if ($type.contains("ANON")) { $web = Get-SPWeb $siteurl; $web.AnonymousState="On"; $web.Update() }

# At this time, let's also check if it's going to be a MixedMode web app

if ($type.contains("MIXED")) {

# If it's a Mixed-Mode web app we need to extend the base app to another auth type too

$port++; write-host -Fore Cyan "Extending port $port..." -noNewLine

$waurl = $waurl.replace("https", "http")

$waexe = "Get-SPWebApplication $siteurl | New-SPWebApplicationExtension -Name $title-Ext -Zone `"Intranet`" -URL $waurl -Port $port -AuthenticationProvider"


if ($type.contains("FBA")) { $waexe += " `$apFBA" } else { $waexe += " `$apSAML" }

}

else {

$waexe += " `$apSAML"

}

Invoke-Expression $waexe

}

# If we've created a FBA web app, then it's time to update the CA/STS/FBA web.config files

if ($type.contains("FBA")) { Write-WEBConfigs 0 $port.tostring() }; write-host -Fore Cyan "done!"

}

function Create-UserPolicy ([string]$weburl, [string]$encodeduser) {

$webapp = Get-SPWebApplication $weburl

$policy = $webapp.Policies.Add($encodeduser, "ClaimsWA.ps1 User")

$role = $webapp.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl)

$policy.PolicyRoleBindings.Add($role)

$webapp.Update()

}

function Write-WEBConfigs ([int]$begin, [string]$vroot) {

# For now I'm using the XML object to load/save the config files

# Eventually we should use the IIS:CMDlets from WebAdministration

write-host -Fore Cyan "Writing WEBConfig..." -noNewLine

#$filei = "\\back\scratch\suntoshs\backup\webconfigs.xml"

$filei = "\\back\scratch\suntoshs\scripts\oobinstall\webconfigs.xml"

$xmli = [xml](get-content $filei)

$root = $xmli.get_DocumentElement()

for ($j=$begin; $j -le 2; $j++) {

if ($j -eq 0) {

[void][reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint")

$fileo = [Microsoft.SharePoint.Administration.SPAdministrationWebApplication]::Local.IisSettings.get_Item(0).Path.FullName + "\web.config"

}

elseif ($j -eq 1) {

$fileo = $env:CommonProgramFiles + "\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken\web.config"

if ($flavor -eq "DEBUG") { $fileo = $fileo.replace("Shared", "Shared Debug") }

}

else {

if ($vroot -ne "APP") { $fileo = $env:HomeDrive + "\inetpub\wwwroot\wss\VirtualDirectories\$vroot\web.config" }

}

$xmlo = [xml](get-content $fileo)

$perf = $xmlo.CreateElement("clear")

if ($flavor -eq "DEBUG") {

$ship = $root.config[1].tokens.token[0].value

$debug = $root.config[1].tokens.token[1].value

$token = $root.config[0]["system.web"].membership.providers.add[0].type

$root.config[0]["system.web"].membership.providers.add[0].SetAttribute("type", $token.replace($ship,$debug)) | Out-Null

$token = $root.config[0]["system.web"].rolemanager.providers.add[0].type

$root.config[0]["system.web"].rolemanager.providers.add[0].SetAttribute("type", $token.replace($ship,$debug)) | Out-Null

}

if ($j -eq 0) {

# Update the CA web config

if (-not $xmlo.SelectSingleNode("/configuration/connectionStrings")) {

$xmlo.configuration["system.web"].membership.ParentNode.RemoveChild($xmlo.configuration["system.web"].membership) | Out-Null

$xmlo.configuration["system.web"].roleManager.ParentNode.RemoveChild($xmlo.configuration["system.web"].roleManager) | Out-Null

$xmlo.SelectSingleNode("/configuration").AppendChild($xmlo.ImportNode($root.config[0]["connectionStrings"], $true)) | Out-Null

$xmlo.SelectSingleNode("/configuration/system.web").AppendChild($xmlo.ImportNode($root.config[0]["system.web"].membership, $true)) | Out-Null

$xmlo.SelectSingleNode("/configuration/system.web/membership/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null

$xmlo.SelectSingleNode("/configuration/system.web").AppendChild($xmlo.ImportNode($root.config[0]["system.web"].rolemanager, $true)) | Out-Null

$xmlo.SelectSingleNode("/configuration/system.web/roleManager/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null

}

}

elseif ($j -eq 1) {

# Update the STS web config

if (-not $xmlo.SelectSingleNode("/configuration/system.web")) {


$xmlo.SelectSingleNode("/configuration").AppendChild($xmlo.ImportNode($root.config[0]["system.web"], $true)) | Out-Null

}

}

else {

# Update the FBA web config

if ($vroot -ne "APP") {

if ($type.contains("PPL")) {$provider=1} elseif ($type.contains("SUN")) {$provider=2} elseif ($type.contains("IBM")) {$provider=3} elseif ($type.contains("NVL")) {$provider=4} elseif ($type.contains("SQL")) {$provider=5} else {$provider=0}


$xmlo.SelectSingleNode("/configuration/system.web/membership/providers").PrependChild($xmlo.ImportNode($root.config[0]["system.web"].membership.providers.add[$provider], $true)) | Out-Null

$xmlo.SelectSingleNode("/configuration/system.web/membership/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null

$xmlo.SelectSingleNode("/configuration/system.web/roleManager/providers").PrependChild($xmlo.ImportNode($root.config[0]["system.web"].rolemanager.providers.add[$provider], $true)) | Out-Null

$xmlo.SelectSingleNode("/configuration/system.web/roleManager/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null

}

}

$xmlo.Save($fileo)

}

}

function Manage-SnapIns ([int]$action) {

#The OWSTimer process always causes an update conflict (known bug) while

#creating multiple web apps; let's temporarily shut it down until we're done

if ($action -eq 1) { Stop-Service "SPTimerV4" }

# We need to do this only if we're running on ISE so check it

if ($host.name.contains("ISE")) {

if ($action -eq 1) {

write-host -Fore Yellow "Detecting host and loading dependent snap-ins..."

# Add-PSSnapIn WebAdministration (later!)


7. Go to the Claims Web Application site in IIS.

8. In the left pane, right-click Claims Web Application, and select Edit Bindings.

9. Select https and click Edit.

10. Under SSL Certificate, select any listed certificate. Consider using a self-signed certificate.

11. Import the Windows Live ID public certificate to the Local computer, SharePoint Server 2010, and Trusted People folders.

12. Perform IIS reset and browse the site URL.

Grant permissions to all Windows Live ID authenticated users

Use the procedures in this section to grant permissions to all Windows Live Id authenticated users.

To grant permissions to all Windows Live ID authenticated users

1. Browse to the SharePoint Server 2010 site that you created and log on using the administrator account.

2. On the Site Actions menu click Site Settings.

3. In the Users and Permissions section, click Site Permissions.

4. Click Site Name Visitors group, where Site Name is the name of the site.

5. Click New, and then click Add Users.

6. In the Grant Permissions window, click the browse icon.

7. In the Select People and Groups window, click All Users, and then click All Users (LiveIDSTS) in the right pane.

8. Click Add.

9. Click OK.

10. Verify that All Users (LiveIDSTS) is now part of the visitor’s group. You should now be able to log on to the SharePoint Server 2010 site with any other Live IDuser’s credentials.

About the author

Birendra Acharya is a Senior Software Design Engineer for MSIT at Microsoft.

See Also

Other ResourcesUnderstanding WS-Federation (http://go.microsoft.com/fwlink/p/?LinkId=192377)

© 2014 Microsoft

Add-PSSnapIn Microsoft.Sharepoint.PowerShell

}

else {

write-host -Fore Yellow "Unloading dependent snap-ins loaded earlier on..."

# Remove-PSSnapIn WebAdministration (later!)

Remove-PSSnapIn Microsoft.Sharepoint.PowerShell

}

}

if ($action -eq 0) {Start-Service "SPTimerV4"; write-host -Fore Yellow "`nAll done; if there were errors please research PS database for known issues!`n"}

}

main


Configure Client Certificate Authentication (SharePoint Server2010)



Client Certificate Authentication enables Web-based clients to establish their identity to a server and provides an additional layer of security for your network.

Note

For more information about Client Certificate Authentication, see Certificate-based Authentication Protocols (http://go.microsoft.com/fwlink/p/?LinkId=212507).

Microsoft SharePoint Server 2010 does not provide built-in support for Client Certificate Authentication, but Client Certificate Authentication is available through integration

with Active Directory Federation Services (AD FS) 2.0, or any third-party identity management system that supports standard security protocols such as claims-based

authentication, WS-Trust, WS-Federation, and SAML 1.1.

Note

For more information about SharePoint Server 2010 protocol requirements, see SharePoint Front-End Protocols (http://go.microsoft.com/fwlink/p/?LinkId=212509).

SharePoint Server 2010 makes it possible to use a variety of Security Token Services (STS) through claims-based authentication. If you use claims-based authentication and

you configure AD FS 2.0 as your STS, SharePoint Server 2010 can support any Identity Provider that is trusted by AD FS 2.0, including Client Certificate Authentication.

Note

For more information about AD FS 2.0, see Active Directory Federation Services Overview (http://go.microsoft.com/fwlink/p/?LinkId=212512).

In the following model, an administrator needs to configure SharePoint Server 2010 as a relying partner for an Identity Provider STS. (This example uses AD FS 2.0 for the

STS, but you can also use a third-party STS.) AD FS 2.0 can authenticate user accounts via several different types of authentication methods: forms-based authentication,

Active Directory Domain Services (AD DS), client certificates, and smart cards. When you configure SharePoint Server 2010 as a relying partner for an STS, SharePoint Server

2010 trusts the accounts that the STS validates, which is how SharePoint Server 2010 supports Client Certificate Authentication.

Configure Client Certificate Authentication

The following topics explain how to configure SharePoint Server 2010 with Client Certificate authentication or Smart Card authentication by using AD FS 2.0 as your STS.

Note

The required steps will be similar for a third-party STS.

Configure AD FS 2.0 or third-party STS to support CBA, and thereby Client Certificate authentication or Smart Card authentication.

For information on making these configuration changes, see AD FS 2.0 - How to change the local authentication type (http://go.microsoft.com/fwlink/p/?

LinkId=212513).

Configure SharePoint Server 2010 as relying party in AD FS 2.0 or third-party STS.







For information on making these configuration changes using AD FS 2.0, see Configuring SharePoint 2010 and AD FS v2 End to End


Configure the Identity Provider STS, for example AD FS 2.0, inside SharePoint Server 2010 as a trusted identity provider.

For information on making these configuration changes using AD FS 2.0, see Configure authentication using a SAML security token (SharePoint Server 2010).

Create a Web application that uses Claims-Based Authentication with a SAML security token, and thereby Client Certificate authentication or Smart Card

authentication.

For information on creating a Web application that uses SAML security tokens, see Configure authentication using a SAML security token (SharePoint Server 2010).

See Also

ConceptsConfigure the security token service (SharePoint Server 2010)

Configure authentication using a SAML security token (SharePoint Server 2010)

Other ResourcesPlanning and Architecture: AD FS 2.0 (http://go.microsoft.com/fwlink/p/?LinkId=212521)

AD FS 2.0 Deployment Guide (http://go.microsoft.com/fwlink/p/?LinkId=212520)

Using Active Directory Federation Services 2.0 in Identity Solutions (http://go.microsoft.com/fwlink/p/?LinkID=209776)

Configure SharePoint as relying party in ADFS 2.0 or third-party STS (http://go.microsoft.com/fwlink/?LinkID=207629)

© 2014 Microsoft










Configure Digest authentication for a claims-based Webapplication (SharePoint Server 2010)



This article describes how to configure digest authentication for one or more zones within a Microsoft SharePoint Server 2010 claims-based Web application. A Web

application is an IIS Web site thatSharePoint Server 2010 creates and uses. Zones represent different logical paths for gaining access to the same Web application. Within

each Web application, you can create up to five zones. A different Web site in IIS represents each zone. Use zones to enforce different access and policy conditions for

large groups of users. To configure digest authentication for one or more zones in a SharePoint Server 2010 Web application, use the IIS Management Console to directly

configure IIS.

Although digest authentication provides the same functionality as basic authentication, digest authentication encrypts user credentials to increase security. User credentials

are sent as an MD5 message digest in which the original user name and password cannot be deciphered. Digest authentication uses a challenge/response protocol that

requires the authentication requestor to present valid credentials in response to a challenge from the server. To authenticate against the server, the client has to supply an

MD5 message digest in a response that contains a shared secret password string. The MD5 Message-Digest Algorithm is described in detail in RFC 1321. For access to

RFC 1321, see The Internet Engineering Task Force (http://go.microsoft.com/fwlink/p/?LinkId=159913).

To use digest authentication, note the following requirements:

The user and IIS server must be members of, or trusted by, the same domain.

Users must have a valid Windows user account stored in Active Directory Domain Services (AD DS) on the domain controller.

The domain must use a Microsoft Windows Server 2008 domain controller.

Configure IIS to enable digest authentication

Use the IIS Management Console to configure IIS to enable digest authentication for one or more of the following zones for a claims-based Web application:

Note

The Default zone is the zone that is first created when a Web application is created. The other zones are created by extending a Web application.

Default

Intranet

Extranet

To configure IIS to enable digest authentication

1. Verify that you have one of the following administrative credentials:

You must be a member of the Administrators group on the server on which you are configuring IIS.

2. On the Start menu, point to All Programs, click Administrative Tools , and then click Internet Information Services (IIS) Manager to start the IIS Management

Console.

3. Expand Sites on the console tree, right-click the IIS Web site that corresponds to the Web application zone on which you want to configure digest authentication.

4. In Features View, double-click Authentication.

5. On the Authentication page, select Digest Authentication.

6. In the Actions pane, click Enable to use Digest authentication with the default settings.

7. In the Actions pane, click Edit to enter a realm name.

8. In the Edit Digest Authentication Settings dialog box, in the Realm text box, type the appropriate realm and click OK.

At this point, the Web site is configured to use digest authentication.

See Also

Other ResourcesWhat is Digest Authentication? (http://go.microsoft.com/fwlink/p/?LinkId=209085)

© 2014 Microsoft



Configure Basic authentication for a claims-based Web application(SharePoint Server 2010)



This article describes how to configure basic authentication for one or more zones within a Microsoft SharePoint Server 2010 claims-based Web application. A Web

application is an Internet Information Services (IIS) Web site that SharePoint Server 2010 creates and uses. Zones represent different logical paths for gaining access to the

network services that are available within the same Web application. Within each Web application, you can create up to five zones. A different Web site in IIS represents

each zone. Use zones to enforce different access and policy conditions for large groups of users. To configure basic authentication for one or more zones in a SharePoint

Server 2010 Web application, use the IIS Management Console to directly configure IIS.

Basic authentication requires previously assigned Windows account credentials for user access. Basic authentication enables a Web browser to provide credentials when

the browser makes a request during an HTTP transaction. Because user credentials are not encrypted for network transmission but are sent over the network in plaintext,

we do not recommend using basic authentication over an unsecured HTTP connection. To use basic authentication, you should enable Secure Sockets Layer (SSL)

encryption.

Configure IIS to enable basic authentication

Use the IIS Management Console to configure IIS to enable basic authentication for one or more of the following zones for a claims-based Web application:

Note

The Default zone is the zone that is first created when a Web application is created. The other zones are created by extending a Web application.

Default

Intranet

Extranet

To configure IIS to enable basic authentication

1. Verify that you have one of the following administrative credentials:

You must be a member of the Administrators group on the server on which you are configuring IIS.

2. On the Start menu, point to All Programs, click Administrative Tools , and then click Internet Information Services (IIS) Manager to start the IIS Management

Console.

3. Expand Sites on the console tree, right-click the IIS Web site that corresponds to the Web application zone on which you want to configure Basic authentication.

4. In Features View, double-click Authentication.

5. On the Authentication page, select Basic Authentication.

6. In the Actions pane, click Enable to use Basic authentication with the default settings.

7. In the Actions pane, click Edit to enter a realm name.

8. In the Edit Basic Authentication Settings dialog box, in the Realm text box, type the appropriate realm and click OK.

At this point, the Web site is configured to use basic authentication.

For information about creating a claims-based Web application in SharePoint Server 2010, see Create claims-based web applications in SharePoint 2010.

If you want credentials of users to be sent over a network in a form that is not encrypted, select Basic authentication (password is sent in clear text).

Security Note

You can select basic authentication or integrated Windows authentication, or both. If you select both, SharePoint Server 2010 will offer both authentication types to

the client Web browser. The client Web browser then determines the type of authentication to use. If you only select basic authentication, ensure that SSL is enabled;

otherwise, the credentials can be intercepted by a malicious user.

© 2014 Microsoft



People Picker and claims provider planning (SharePointFoundation 2010)



People Picker is a Web control used to find and select users, groups, and claims to grant permission to items such as lists, libraries, or sites in Microsoft SharePoint

Foundation 2010. When a Web application uses claims authentication mode, the People Picker control uses a claims provider to list, resolve, search, and determine the

"friendly" display of users, groups, and claims. A claims provider in SharePoint Foundation 2010 issues claims, which SharePoint Foundation 2010 then packages into

security tokens for users. Although People Picker is used by site, list, and library owners to assign permissions to sites and content in SharePoint Foundation 2010, its

behavior is heavily dependent on how authentication has been configured for the whole Web application. It is important to plan for People Picker and claims providers

when you plan authentication methods for your SharePoint Foundation 2010 solution.

The articles in this section are designed to help you understand and plan for using People Picker and custom claims providers in SharePoint Foundation 2010:


This article describes the People Picker control and how it works, its relationship to authentication and claims providers, and includes considerations for planning for

People Picker.


This article describes the use and benefits of claims providers, their architecture, special considerations for custom claims providers, and considerations for

planning for them.

See Also

ConceptsPlan authentication (SharePoint Foundation 2010)


© 2014 Microsoft









The People Picker control is used to find and select people, groups, and claims when a site, list, or library owner assigns permissions in Microsoft SharePoint Foundation

2010. This article describes the People Picker control and how it works, its relationship to authentication and claims providers, and how to plan for People Picker. For

information about how to configure People Picker, see Configure People Picker (SharePoint Foundation 2010).

Before reading this article, you should understand the concepts described in Plan authentication methods (SharePoint Foundation 2010)and in The Role of Claims



In this article:

Uses and benefits

Architecture







Uses and benefits

The People Picker control is used to select users, groups, and claims to grant permission to items such as lists, libraries, and sites. For example, your site has a

document library that you want to restrict to a certain list of users. When you use the library permissions page to give users permission levels for the library, you use the

People Picker control either to type user names and verify that the user accounts are valid, or to search for a name or partial string and return a list of users, groups, or

claims that match the value you entered. For more information about permissions, see Plan site permissions (SharePoint Foundation 2010).

Architecture

The People Picker control is a central component of SharePoint Foundation 2010. The control provides basic functionality for finding and selecting users, groups, and

claims to assign permissions in a site. The exact sources of those users, groups, and claims depend on the authentication method used by the Web application that

contains the site collection. For more information about authentication methods, see People Picker and authentication later in this article.

People Picker is configured at the zone level for a farm by using the Stsadm setproperty operation. By configuring the settings for the control, you can filter and restrict

the results that are displayed when a user searches for a user, group, or claim. Those settings will apply to every site within a specific site collection. For more

information about configuring People Picker, see Configure People Picker (SharePoint Foundation 2010).

Note


When a Web application is configured to use claims-based authentication, People Picker uses claims providers to resolve and display users, groups, and claims in the

Select People and Groups dialog box. The information that is displayed in the Select People and Groups dialog box depends on the claims provider used by the

authentication method that was configured for the Web application. For more information about claims providers, see Custom claims providers for People Picker



The People Picker control consists of a text box and two buttons: the Check Names button and the Browse button. The following illustration shows an example of the

People Picker control.

The user types a user name, group name, or claim (such as an e-mail address) into the text box, and then clicks the Check Names button to resolve the search item

exactly as it was entered. If People Picker is able to resolve the search item, the name is replaced with a resolved identity. If the search item cannot be resolved exactly as

entered, People Picker performs a search. If no match is found, or if more than one match is found, a red underline is displayed under the search item and the following

error message appears: No exact match found. Click the item(s) that did not resolve for more options. When the item is clicked, a pop-up menu displays a list of

available users, groups, or claims that match the query, if applicable. The menu also contains a Remove button to remove the resolved user, group, or claim from the

text box, and a More Names button, which opens the Select People and Groups dialog box.








If the user clicks the Browse button, the Select People and Groups dialog box is displayed. The user types a full or partial user name, group name, or claim into the text

box, and then presses Enter. The results of the query are displayed in the dialog box. The claims providers that People Picker interacts with determine the query results

and the way those results are displayed in the dialog box. The user selects a resolved identity, clicks Add, and then clicks OK. The selected user, group, or claim is then

added to the text box in the People Picker control.

When a Web application is configured to use Windows authentication, you can limit the results that are displayed to users in the Select People and Groups dialog box

by using the Stsadm setproperty operation to change the settings for the People Picker control. For example, you can configure People Picker to return only users,

groups, and claims that belong to a certain Active Directory domain or are members of a specific site collection. For more information about configuring the People

Picker control, see Configure People Picker (SharePoint Foundation 2010).


People Picker relies on the authentication method used by the Web application that contains the site collection from which it is queried to determine what results to

display to a user. If the Web application is configured to use Windows authentication in classic mode, SharePoint Foundation 2010 treats user accounts as Active

Directory Domain Services (AD DS) accounts. If the Web application is configured to use claims-based authentication, you can specify whether to use Windows

authentication, forms-based authentication (FBA), or Security Assertion Markup Language (SAML) token-based authentication. In claims mode, People Picker searches

and resolves queries based on the claims provider that is specified for the authentication method used by the Web application and zone. The following sections

describe People Picker behavior for both classic-mode authentication and claims-based authentication. For more information about zones and authentication, see Plan

authentication methods (SharePoint Foundation 2010).

Classic-mode authentication

When Windows classic-mode authentication is used, the People Picker control queries Active Directory to retrieve a list of users, groups, or claims that match the

search item typed in the text box. You can configure People Picker to query Active Directory by using Lightweight Directory Access Protocol (LDAP) queries, which

enables you to apply custom Active Directory filters, limit the scope of search queries, and search across forests and domains.

By default, when the Browse button is clicked, the Select People and Groups dialog box displays the following fields:

Display Name

Title

Department

E-mail

Mobile Number

Account Name

The following image shows the Select People and Groups dialog box when Windows authentication is used in classic mode for the Web application.

For more information about classic-mode authentication, see Plan authentication methods (SharePoint Foundation 2010). For information about how to create a Web

application that uses classic-mode authentication, see Create a Web application that uses Windows-classic authentication (SharePoint Foundation 2010).

Claims-based authentication

When claims-based authentication is used, People Picker uses the claims provider that is specified for the authentication method used by the Web application and

zone to retrieve a list of users, groups, or claims that match the search item typed in the text box. For more information about claims mode authentication and zones,

see Plan authentication methods (SharePoint Foundation 2010).

By default, when the Browse button is clicked, the Select People and Groups dialog box displays a tree view on the left that lists the claims providers that People






Picker will query. The right side of the dialog box is where query results are displayed. When claims-based authentication is used, the results are displayed in one of

two views: Detailed View or List View. By default, Detailed View is displayed.

The following illustration shows the Select People and Groups dialog box when Windows authentication is used in claims mode for a Web application.

In Detailed View, the query results are grouped by the sources where the query results were found. For example, if a search item is found in a SharePoint group and

in Active Directory, the results are organized into a list of SharePoint groups followed by a list of Active Directory users and groups.

In List View, the query results are returned in a list that contains the following fields:

Display Name

E-mail Address

Title

Department

Presence

Work Phone

Location

You can write a custom claims provider to control what information is displayed and what results are returned in response to a query from the People Picker control.

When a custom claims provider is registered on the server, you can also configure it for use in a specific Web application and zone. This means that a custom claims

provider that is configured for only one zone will only be displayed in the Select People and Groups dialog box for Web sites in that zone. For more information

about custom claims providers, see Custom claims providers for People Picker (SharePoint Foundation 2010).

Note

In the Central Administration Web site, People Picker will return users, groups, and claims from all claims providers used in all Web applications in the farm,

regardless of the Web application or zone in which the claims providers are configured.

By default, when you use SAML token-based authentication, all queries entered in the text box are automatically displayed as if they had been resolved, regardless of

whether they are valid users or groups. If your SharePoint Foundation 2010 solution will use SAML token-based authentication, you should plan to create a custom

claims provider that will implement custom search, name resolution, and list features. For more information about custom claims providers, see Custom claims

providers for People Picker (SharePoint Foundation 2010).

For information about how to create a Web application that uses claims-mode authentication, see Create a Web application that uses Windows-claims authentication

(SharePoint Foundation 2010). For information about configuring claims-based authentication for Web applications, see Configure claims authentication (SharePoint

Foundation 2010).


A claims provider lists, resolves, searches, and determines the "friendly" display of users, groups, and claims in the People Picker when claims-based authentication is

used. If your Web application uses claims-based authentication, you must decide whether to use one of the default claims providers or create a custom claims provider

that will meet the business needs of your organization.

For more information about how claims providers are related to the People Picker control, see Custom claims providers for People Picker (SharePoint Foundation 2010).







The information in this section applies only to Web applications that use Windows authentication in either classic mode or claims mode.

You can configure People Picker to filter query results and to restrict the directories that People Picker uses as a source of those results by using property names for the

Stsadm setproperty operation. To see what property settings have been configured, use the Stsadm getproperty operation. For more information, see Peoplepicker:

Stsadm properties (Office SharePoint Server 2007). The settings for People Picker are applied to each URL zone for a Web application.

Note


The following table describes the properties that can be used to configure People Picker.

Property name Description

Peoplepicker-activedirectorysearchtimeout Configures the timeout when a query is issued to Active Directory. The default timeout value is 30 seconds.

For more information, see Peoplepicker-activedirectorysearchtimeout.

Peoplepicker-distributionlistsearchdomains Restricts the search of a distribution list to a specific subset of domains. For more information, see

Peoplepicker-distributionlistsearchdomains.

Peoplepicker-

nowindowsaccountsfornonwindowsauthenticationmode

Specifies not to search Active Directory when the current port is using forms-based authentication. For more

information, see Peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode.

Peoplepicker-onlysearchwithinsitecollection Displays only users who are members of the site collection when the Select People and Groups dialog box

is used. For more information, see Peoplepicker-onlysearchwithinsitecollection.

Peoplepicker-

peopleeditoronlyresolvewithinsitecollection

Displays only users who are members of the current site collection when the Check Names button is clicked.

For more information, see. Peoplepicker-peopleeditoronlyresolvewithinsitecollection: Stsadm property


Peoplepicker-searchadcustomfilter Enables a farm administrator to specify a unique search query. For more information, see Peoplepicker-

searchadcustomfilter.

Peoplepicker-searchadcustomquery Permits the administrator to set the custom query that is sent to Active Directory. For more information, see

Peoplepicker-searchadcustomquery.

Peoplepicker-searchadforests Permits a user to search from a second one-way trusted forest or domain. For more information, see

Peoplepicker-searchadforests.

Peoplepicker-serviceaccountdirectorypaths Enables a farm administrator to manage the site collection that has a specific organizational unit (OU)

setting as defined in the Setsiteuseraccountdirectorypath setting. For more information, see Peoplepicker-

serviceaccountdirectorypaths.

For more information about configuring People Picker, see Configure People Picker (SharePoint Foundation 2010).


By default, People Picker will only return users, groups, and claims from the domain on which SharePoint Foundation 2010 is installed. If you want People Picker to return

query results from more than one forest or domain, you must either have a two-way trust between the forests or domains, or you must configure People Picker to use

an encrypted account and password for a one-way trust between forests and domains. For more information about trusts, see Managing Trusts


To configure People Picker for a one-way trust, you must first use the Stsadm setapppassword operation to set the password for use on the trusted forest or domain,

and then use the Peoplepicker-searchadforests property for the setproperty operation to specify the forest or domain to search. Remember that the settings for

People Picker are configured per zone for a Web application, so if you have more than one forest or domain in your farm, you must combine the accounts and

passwords into a single command for the setproperty operation. For more information, see Peoplepicker-searchadforests: Stsadm property (Office SharePoint Server).


Planning for People Picker largely depends on what forests and domains you want users to be able to query, and what users, groups, and claims you want to display in

query results. As you plan for the forests and domains you want users to query, consider the following questions:

Do users need to query across a forest or a domain?

What is the DNS name for each forest or domain you want users to query?

Will your forest or domain have a one-way or two-way trust with other forests or domains?

If you will be using a one-way trust, what credentials will be used to query the other farms or domains

Planning for the users, groups, and claims you want to display in the query results in People Picker will help you determine how to configure People Picker to return and

display results from claims providers. As you plan for the users, groups, and claims you want to display in query results, consider the following questions:

http://technet.microsoft.com/en-us/library/d8372668-ba43-4bcb-b341-50ade06f810f(office.12).aspx

http://technet.microsoft.com/en-us/library/fb1b23f4-30e4-40ae-a7a2-7cc654a4e7ad(office.12).aspx

http://technet.microsoft.com/en-us/library/c95da957-8eeb-4312-b039-7ac5c0f89a7e(office.12).aspx

http://technet.microsoft.com/en-us/library/cac79eec-e313-4f48-839a-902538d8b9be(office.12).aspx

http://technet.microsoft.com/en-us/library/1b96ad41-c43e-43dc-b59b-5a8f4a48fd6f(office.12).aspx


http://technet.microsoft.com/en-us/library/f1d7a0d5-1f32-4d26-8ccf-cf090a44d93c(office.12).aspx

http://technet.microsoft.com/en-us/library/911b5f5a-bd1d-42fd-b816-8cd5a770b4b9(office.12).aspx


http://technet.microsoft.com/en-us/library/da6a65b4-6cb6-481d-b58b-5551b8d5d390(office.12).aspx

http://technet.microsoft.com/en-us/library/9538ed2e-507f-4af9-aa31-da971a69f66b(office.12).aspx




Are there certain LDAP filters you want to apply to query results?

Do you want to restrict the query results to users, groups, or claims in a specific site collection?

Do you want to restrict the query results to users, groups, or claims in a certain Active Directory organizational unit (OU)

See Also





© 2014 Microsoft





Custom claims providers for People Picker (SharePoint Foundation2010)



A claim consists of information about the identity of a user, such as a name, e-mail address, or group membership. A claims provider in Microsoft SharePoint Foundation

2010 issues claims, which SharePoint Foundation 2010 then packages into security tokens for users. When a user signs in to SharePoint Foundation 2010, the user's token is

validated and then used to sign in to SharePoint Foundation 2010. Claims providers are displayed in the user interface of the Select People and Groups dialog box in the

People Picker control. They provide the functionality used to find and select users, groups, and claims when permissions are assigned to items such as lists, libraries, and

sites in SharePoint Foundation 2010. For information about the People Picker control, see People Picker overview (SharePoint Foundation 2010).

This article describes the use and benefits of claims providers, their architecture, special considerations for custom claims providers, and how to plan for them. It does not

explain how to create or configure custom claims providers. For information about how to create a custom claims provider, see Claims How Tos

(http://go.microsoft.com/fwlink/p/?LinkId=207578) and Creating Custom Claims Providers in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=211324).

Before reading this article, you should understand the concepts described in Plan authentication methods (SharePoint Foundation 2010) and The Role of Claims


(http://go.microsoft.com/fwlink/p/?LinkID=196647) and A Guide to Claims-based Identity and Access Control (http://go.microsoft.com/fwlink/p/?LinkID=187911).

In this article:

Uses and benefits

Architecture





Uses and benefits

A claims provider in SharePoint Foundation 2010 is used primarily for two reasons:

To augment claims

To provide name resolution

In the augmentation role, a claims provider augments a user token with additional claims during sign-in. For more information about claims augmentation, see Claims

Provider (http://go.microsoft.com/fwlink/p/?LinkID=207579).

In the picking role, a claims provider lists, resolves, searches, and determines the "friendly" display of users, groups, and claims in the People Picker. Claims picking

enables an application to surface claims in the People Picker, for example when configuring the security of a SharePoint site or SharePoint service. For more information

about People Picker, see People Picker overview (SharePoint Foundation 2010).

You can use the claims providers that are included with SharePoint Foundation 2010, or you can create your own custom claims providers to provide additional claims in

the security token for a user or to connect to additional sources of claims. For example, if you have a CRM application that contains roles that are not found in the user

repository in Active Directory, you can create a custom claims provider to connect to that database and add CRM role data to a user's original claims token. For more

information about claims provider usage scenarios, see Claims Provider (http://go.microsoft.com/fwlink/p/?LinkID=207579).

Architecture

When a Web application is configured to use claims-based authentication, SharePoint Foundation 2010 automatically uses two default claims providers:

The SPSystemClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210011) class provides claims information related to the server farm where SharePoint

Foundation 2010 is installed.

The SPAllUserClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210012) class provides an All Users claim that is displayed in the Select People and

Groups dialog box for People Picker.

Depending on the authentication method selected for a zone of a Web application, SharePoint Foundation 2010 also uses one or more of the default claims providers

listed in the following table.

Authentication method Claims provider

Windows authentication SPActiveDirectoryClaimProvider (http://go.microsoft.com/fwlink/p/?LinkID=208325)
















Forms-based authentication SPFormsClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210013)

Security Assertion Markup Language (SAML) token-based authentication SPTrustedClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210014)

These claims providers are displayed in the Select People and Groups dialog box for People Picker. You can see a list of claims providers for a farm by using the Get-

SPClaimProvider Windows PowerShell cmdlet.

Note



or claim. If your SharePoint Foundation 2010 solution will use SAML token-based authentication, you should plan to create a custom claims provider to implement


Claims providers are registered on a server farm as features that are deployed to the farm. They are scoped at the farm level. Each claims provider object uses the

SPClaimProviderDefinition class to include information about the claims provider, such as display name, description, assembly, and type. Two important properties of the

SPClaimProviderDefinition class are IsEnabled and IsUsedByDefault. These properties determine whether a registered claims provider is enabled for use in the farm, and

whether the claims provider is used by default in a particular zone. By default, all claims providers are enabled when they are deployed to a server farm. For information

about the SPClaimProviderDefinition class, see SPClaimProviderDefinition Class (http://go.microsoft.com/fwlink/p/?LinkId=207595).

For more information about zones and authentication, see Plan authentication methods (SharePoint Foundation 2010).

For information about how to write a custom claims provider, see Creating Custom Claims Providers in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?

LinkID=211324) and Claims Walkthrough: Writing Claims Providers for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207589). For information about how to

override the default claims provider, see How to Override the Default Name Resolution and Claims Provider for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?

LinkId=207591).


By default, the information that is resolved in People Picker when a query is performed depends on the information supplied by the claims provider. You cannot change

what information is supplied and how it is displayed when you use an out-of-box claims provider. To do this, you must have a developer create a custom claims

provider that will meet the needs of your solution for finding and selecting users, groups, and claims when a user assigns permissions to items such as a site, list, or

library.

For example, if your Web application uses SAML authentication and you also want to resolve users from Active Directory, you will need to create a custom claims

provider. For additional examples of claims provider use scenarios, see Claims Provider (http://go.microsoft.com/fwlink/p/?LinkID=207579).

When you create a custom claims provider, you can control what information is displayed and what results are returned in response to a query from the People Picker

control. By default, you configure the Web application to use claims authentication, and then register the claims provider on the server.

Note

You cannot control the order in which claims providers are displayed in the Select People and Groups dialog box in People Picker.

For information about how to write a custom claims provider, see How to: Create a Claims Provider (http://go.microsoft.com/fwlink/p/?LinkId=207588) and Claims

Walkthrough: Writing Claims Providers for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207589). For information about how to override the default claims

provider, see How to Override the Default Name Resolution and Claims Provider for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207591).


By default, when you register a custom claims provider on the farm, the IsEnabled and IsUsedByDefault properties are both set to True. Unless the IsUsedByDefault

property is set to False, the custom claims provider is displayed in the Select People and Groups dialog box in People Picker for all zones. Depending on the number of

zones needed for your SharePoint Foundation 2010 solution, the authentication methods used by each zone, and the users for each zone, you may want to limit the

zones in which your custom claims provider is displayed in People Picker.

Because claims providers are scoped at the farm level and enabled at the zone level, you must carefully plan the zones in which you want the custom claims provider to

be displayed. In general, you should make sure that the IsUsedByDefault property is set to False, and then configure the SPIisSettings class for each zone in which you

want to use the custom claims provider. To configure a custom claims provider for select zones, you can create a Windows PowerShell script that sets the claims

provider for a zone by using the SPIisSettings.ClaimsProviders property, or you can create a custom application to allow you to enable a custom claims provider for

select zones. For information about the SPIisSettings.ClaimsProvider property, see SPIisSettings.ClaimsProvider Property (http://go.microsoft.com/fwlink/p/?

LinkId=207597). For information about how to create a custom application to configure claims providers for select zones, see the TechNet blog post, Configuring a

Custom Claims Provider to be Used only on Select Zones in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207592).

For example, consider a scenario where there are two Web applications: The first Web application, PartnerWeb, has two zones — one intranet that uses Windowsclaims‐based authentication and one extranet that uses forms‐based authentication — and is used for collaboration among employees and partners. The second Webapplication, PublishingWeb, has only one zone that uses forms-based authentication and is an Internet publishing site for employees, business partners, and customer

partners. Now, suppose that for the extranet zone on PartnerWeb, you want employees to be able to collaborate with business partners but not customer partners. To

do this, you write a custom claims provider that determines whether the current user is a business partner or customer partner, based on the user's identity. In this

example, users from fabrikam.com are business partners, while users from contoso.com are customer partners. When a user who is a business partner is authenticated

in the PartnerWeb Web application, a claim for a role called BusinessPartner is added to the claim token; when a customer partner is authenticated, a claim for a role

called CustomerPartner is added to the claim token. To make sure that customer partners are never added to the extranet collaboration site, you add a Web application

policy on the PartnerWeb Web application for the extranet zone that explicitly denies access to any user who has a claim for a role called CustomerPartner. The custom

claims provider would also need to implement search and type-in support for the Web application policy to resolve the CustomerPartner role claim so it can be added

to the Web application policy. Finally, to enable this functionality on the extranet zone, you configure the SPIisSettings class for that zone to use the custom claims

provider. The following diagram illustrates the authentication methods and claims provider settings for each Web application and zone.















Note

On the Central Administration Web site, all claims providers are displayed in the Select People and Groups dialog box in People Picker, regardless of whether the

IsUsedByDefault property is set to True.

You can set the IsUsedByDefault property by configuring it in a feature receiver that you create for your custom claims provider. For information about how to use a

feature receiver to deploy a custom claims provider, see Sample: Feature Receiver to Deploy a Claims Provider (http://go.microsoft.com/fwlink/p/?LinkId=207590).

You can also override the settings of the IsEnabled and IsUsedByDefault properties by using the Set-SPClaimProvider Windows PowerShell cmdlet.

Important

Changing the IsEnabled property to False will disable the claims provider for the entire server farm. This can be useful if you need to troubleshoot issues that might

be caused by a custom claims provider. However, in general, the IsEnabled property should be set to True.


Claim values are a combination of the claim itself, the claims provider name, and the order in which the claims provider was installed on the server. Therefore, if you

want to use a claim across multiple farms or environments, you must install the claims providers in the same order on each farm in which you want to use the claim. Use

the following steps when you have installed a custom claims provider on a farm and you want to use the same claim on additional farms.

1. Register the claims providers on the additional farms in the same order that they were registered on the first farm.

2. Perform a backup of the first farm. For information about how to back up a farm, see Back up a farm (SharePoint Foundation 2010).

3. Use the back up from the first farm to restore the other farms. For information about how to restore a farm, see Restore a farm (SharePoint Foundation 2010).


As you plan custom claims providers for use with People Picker in your SharePoint solution, consider the following questions:

What zones does your Web application have, and what authentication methods are used in each zone?

Are there any custom claims that should be added to users to enable more advanced security scenarios?

Will you be using SAML authentication with a trusted identity provider?

What will be the source of the values for the users and roles that will be displayed in People Picker query results?

What claim data do you want to resolve in the Select People and Groups dialog box?

The SharePoint Foundation 2010 Content Publishing team would like to thank Steve Peschka for contributing to this article. His blog can be found here


See Also


© 2014 Microsoft







Security planning for sites and content (SharePoint Foundation2010)



Some of the sites in your enterprise probably contain content that should not be available to all users. For example, proprietary technical information should be accessible

only on a need-to-know basis. An intranet portal for employee benefits should be available only to full-time employees, whereas the home page of an Internet Web site is

accessible by anonymous clients.

Permissions control access to your sites and site content. You can manage permissions by using Microsoft SharePoint Foundation 2010 groups, which control membership,

and fine-grained permissions, which help to secure content at the item and document level. This section describes permissions for sites and site content and provides

considerations for choosing permissions.

In this section:

Plan site permissions (SharePoint Foundation 2010) helps you understand how permissions are assigned and helps you choose the appropriate permissions to use

in your site collection or subsite.

Determine permission levels and groups (SharePoint Foundation 2010) reviews the available permission levels and groups, and helps you determine whether you

need additional permission levels or groups.

Choose security groups (SharePoint Foundation 2010) helps you determine which Microsoft Windows security groups and user accounts to use to grant access to

sites, decide whether to use the Authenticated Users group, and decide whether to allow anonymous access.

Choose administrators and owners for the administration hierarchy (SharePoint Foundation 2010) defines the levels of administration from the server level to the

subsite level and helps you choose administrators for each level.

Best practices for using fine-grained permissions (white paper) (SharePoint Foundation 2010)

Provides guidance about how to use fine-grained permissions in Microsoft SharePoint 2010 Products.

Contribute permission level overview (SharePoint Foundation 2010)

Provides information about the Contribute permission level and the tasks that you can complete if you have these permissions.

Security Note

SharePoint Foundation 2010 does not currently comply with Federal Information Processing Standard (FIPS) 140-2 - Security Requirements for Cryptographic Modules. FIPS

140-2 defines security standards which the United States and Canadian governments use to validate security levels for products that implement cryptography.

For more information about FIPS 140-2, see the following references:

FIPS 140 Evaluation

FIPS Publications

© 2014 Microsoft







http://technet.microsoft.com/en-us/library/cc750357.aspx

http://csrc.nist.gov/publications/PubsFIPS.html


Plan site permissions (SharePoint Foundation 2010)



This article helps you plan access control at the site collection, site, subsite, and site content (list or library, folder, item or document) levels. This article also describes the

concepts about permission inheritance and fine-grained permissions.

This article does not address planning the security of your entire server or server farm. For more information about planning other aspects of security, such as

authentication methods and authentication modes, see Plan authentication methods (SharePoint Foundation 2010).

In this article:

About site permissions

About permission inheritance

Plan for site permissions

Plan for permission inheritance

Worksheet

Introduction

You can control access to site and site content by assigning permissions to users or groups for a specific site or site content at the following levels within a site

collection:

Site

Library or list

Folder

Document or item

Before developing your plan for site and content access, you should consider the following questions:

To what granularity do you want to control permissions for the site or site content? For example, you might want to control access at the site level, or you might

need more restrictive security settings for a specific list, folder, or item.

How do you want to categorize and manage your users by using SharePoint groups? Groups do not have any permission until they are assigned a permission

level for a specific site or for specific site content. When you assign permission levels to SharePoint groups at the site collection level, by default, all sites and site

content inherit those permission levels.

For more information about using groups to help manage permissions, see Choose security groups (SharePoint Foundation 2010)).

About site permissions

You should understand the following concepts before designing your permissions plan.

Permissions Permissions grant a user the ability to perform specific actions. For example, the View Items permission allows a user to view items in a list or

folder, but not to add or remove items. Permissions can be granted to individual users at site or site content levels.

For information about available permissions, see User permissions and permission levels (SharePoint Foundation 2010).

Fine-grained permissions Fine-grained permissions are unique permissions on securable objects that are at a lower level in a site hierarchy, such as

permissions on a list or library, folder, or item or document. Fine-grained permissions allow for greater granularity and customization of user permissions in a

site collection.

Permission level Permission levels are collections of permissions that allow users to perform a set of related tasks. For example, the Read permission level

includes the View Items, Open Items, View Pages, and View Versions permissions (among others), all of which are needed to view pages, documents, and items in

a SharePoint site. Permissions can be included in more than one permission level.

Permission levels are defined at the site collection level and can be customized by any user or group whose permission level includes the Manage Permissions

permission. For more information about customizing permission levels, see Configure custom permissions (SharePoint Foundation 2010).

The default permission levels are Limited Access, Read, Contribute, Design, and Full Control. For information about default permission levels and the permissions

included in each level, see User permissions and permission levels (SharePoint Foundation 2010).

SharePoint group A SharePoint group is a group of users that are defined at site collection level for easy management of permissions. Each SharePoint group

is assigned a default permission level. For example, the default SharePoint groups are Owners, Visitors, and Members, with Full Control, Read, and Contribute as

their default permission levels respectively. Anyone with Full Control permission can create custom groups.






User A user can be a person with a user account from any authentication provider supported by the Web application. We recommend that you assign

permissions to groups rather than users, although you can directly grant individual users permissions to a site or specific content. Because it is inefficient to

maintain individual user accounts, you should assign permissions on a per-user basis only as an exception.

Securable object A securable object is a site, list, library, folder, document, or item for which permissions levels can be assigned to users or groups. By default,

all lists and libraries within a site inherit permissions from the site. You can use list-level, folder-level, and item-level permissions to further control which users can

view or interact with site content. You must first break the permission inheritance before you change or assign permissions for that securable object. You can

resume inheriting permissions from the parent list or site at any time.

You can assign a user or group permissions for a specific securable object. Individual users or groups can have different permissions for different securable objects.

The following diagram illustrates the relationships among permissions, users and groups, and securable objects.

About permission inheritance

Permissions on securable objects within a site are inherited from the parent object by default. You can break inheritance and use fine‐grained permissions — uniquepermissions on the list or library, folder, or item or document level — to gain more control of the actions users can take on your site. For more information about thebest practices for using fine-grained permissions, see Best practices for using fine-grained permissions

Stopping inheriting permissions copies the groups, users, and permission levels from the parent object to the child object, and then breaks the inheritance. When

permission inheritance is broken, all permissions are explicit and any changes to parent object do not affect the child object. If you restore inherited permissions, the

child object will inherit its users, groups, and permission levels from the parent again, and you will lose any users, groups, or permission levels that were unique to the

child object.

For ease of management, use permission inheritance wherever possible.

Tip

If you choose to break inheritance and use fine-grained permissions, you should use groups to avoid having to track individual users. Because people move in and

out of teams and change responsibilities frequently, tracking those changes and updating the permissions for uniquely secured objects would be time-consuming

and error-prone.

Plan for site permissions

When you create permissions, you must balance the ease of administration and performance against the need to control access to individual items. If you use fine-

grained permissions extensively, you will spend more time managing the permissions, and users may experience slower performance when they try to access site

content.

Use the following guidelines to plan site permissions:

1. Follow the principle of least privilege: Users should have only the permission levels or individual permissions they need to perform their assigned tasks.

2. Use standard groups (such as Members, Visitors, and Owners) and control permissions at the site level.

Make most users members of the Members or Visitors groups. By default, users in the Members group can contribute to the site by adding or removing

items or documents, but cannot change the structure, site settings, or appearance of the site. The Visitors group has read-only access to the site, which

means that they can see pages and items, and open items and documents, but cannot add or remove pages, items, or documents.

Limit the number of people in the Owners group. Only those users you trust to change the structure, settings, or appearance of the site should be in the

Owners group.


3. Use permission levels rather than assign individual permissions.

Note

1. You can create additional SharePoint groups and permission levels if you need more control over the actions that your users can take. For example, if you do

not want the Read permission level on a specific subsite to include the Create Alerts permission, break the inheritance and customize the Read permission level

for that subsite.

2. Microsoft SharePoint Foundation 2010 and SharePoint Server 2010 use Check Permissions to determine a user or group’s permissions on all resources withina site collection. You can now find both the user's directly assigned permissions and the permissions assigned to any groups of which the user is a member by

checking permissions for a specific site or site content.

Plan for permission inheritance

It is much easier to manage permissions when there is a clear hierarchy of permissions and inherited permissions. It becomes more difficult when some lists within a site

have fine-grained permissions applied, and when some sites have subsites with unique permissions and others with inherited permissions.

For example, it's much easier to manage a site that has permission inheritance as described in the following table.

Securable object Description Unique or inherited permissions

SiteA Group home page Unique

SiteA/SubsiteA Sensitive group Unique

SiteA/SubsiteA/ListA Sensitive data Unique

SiteA/SubsiteA/LibraryA Sensitive documents Unique

SiteA/SubsiteB Group shared project information Inherited

SiteA/SubsiteB/ListB Non-sensitive data Inherited

SiteA/SubsiteB/LibraryB Non-sensitive documents Inherited

However, it is not as easy to manage a site that has permission inheritance as shown in the following table.

Securable object Description Unique or inherited permissions

SiteA Group home page Unique

SiteA/SubsiteA Sensitive group Unique

SiteA/SubsiteA/ListA Non-sensitive data Unique, but same permissions as SiteA

SiteA/SubsiteA/LibraryA Non-sensitive documents, but with one or two sensitive documents Inherited, with unique permissions at the document level

SiteA/SubsiteB Group shared project information Inherited

SiteA/SubsiteB/ListB Non-sensitive data, but with one or two sensitive items Inherited, with unique permissions at the item level

SiteA/SubsiteB/LibraryB Non-sensitive documents, but with a special folder containing sensitive

documents

Inherited, with unique permissions at the folder and

document level

Worksheet

Use the following worksheet to fill in your site hierarchy, and then list the permissions needed at each level of the hierarchy and any permission inheritance:

Site and content security worksheet (http://go.microsoft.com/fwlink/p/?LinkID=213967&clcid=0x409)

See Also


http://go.microsoft.com/fwlink/p/?LinkID=213967&clcid=0x409


Determine permission levels and groups (SharePoint Foundation2010)



A SharePoint group is a set of users that can be managed together. A permission level is a set of permissions that can be assigned to a specific group for a specific

securable object. SharePoint groups and permission levels are defined at the site collection level and are inherited from the parent object by default. This article describes

default groups and permission levels and helps you decide whether to use them as they are, customize them, or create different groups and permission levels.

In this article:

Review available default groups

Review available permission levels

Determine whether you need custom permission levels or groups

Worksheet

The most important decision about your site and content security in Microsoft SharePoint Foundation 2010 is how to group your users and which permission levels to

assign.

Review available default groups

SharePoint groups enable you to manage sets of users instead of individual users. These groups can contain many individual users, or they can include the contents of

any corporate identity system, including Active Directory Domain Services (AD DS), LDAPv3-based directories, application-specific databases and new user-centric

identity models, such as Windows Live ID. SharePoint groups do not confer specific rights to the site; they are a way to designate a set of users. You can organize your

users into any number of groups, depending on the size and complexity of your organization or Web site. SharePoint groups cannot be nested.

The following table displays default groups that are created by using team site templates in SharePoint Foundation 2010. Each default group is assigned a default

permission level.

Group name Default permission level Description

Visitors Read Use this group to grant people Read permissions to the SharePoint site.

Members Contribute Use this group to grant people Contribute permissions to the SharePoint site.

Owners Full Control Use this group to grant people Full Control permissions to the SharePoint site.

Make most users members of the Visitors or Members groups. By default, users in the Members group can contribute to the site by adding or removing items or

documents, but cannot change the structure, site settings, or appearance of the site. The Visitors group has read-only access to the site, which means that they can see

pages and items, and open items and documents, but cannot add or remove pages, items, or documents.

If the default groups do not map to the exact user groups in your organization, you can create custom groups. For more information about how to determine whether

you need additional groups, see Determine whether you need additional permission levels or groups.

Besides the above SharePoint groups, there are also administrator groups for higher-level administration tasks. They are Windows administrators, SharePoint farm

administrators, and site collection administrators.

For more information, see Choose administrators and owners for the administration hierarchy (SharePoint Foundation 2010).

Review available permission levels

The ability to view, change, or manage a site is determined by the permission level that you assign to a user or group. This permission level controls all permissions for

the site and the child objects that inherit the site’s permissions. Without the appropriate permission levels, your users might be unable to perform their tasks, or theymight be able to perform tasks that you did not want them to perform.

By default, the following permission levels are available:

Limited Access Includes permissions that enable users to view specific lists, document libraries, list items, folders, or documents, without giving users access to

all the elements of a site. You cannot edit this permission level directly.

Note

If this permission level is removed, group members might be unable to navigate the site to access items, even if they have the correct permissions for an item

within the site.


Read Includes permissions that enable users to view items on the site pages.

Contribute Includes permissions that enable users to add or change items on the site pages or in lists and document libraries.

Design Includes permissions that enable users to change the layout of site pages by using the browser or Microsoft SharePoint Designer 2010.

Full Control Includes all permissions.

For more information about permissions that are included in the default permission levels, see User permissions and permission levels (SharePoint Foundation 2010).

Determine whether you need custom permission levels or groups

The default groups and permission levels provide a general framework for permissions, covering many different organization types and roles within those organizations.

However, they might not map exactly to how your users are organized or to the many different tasks that your users perform on your sites. If the default groups and

permission levels do not suit your organization, you can create custom groups, change the permissions included in specific permission levels, or create custom

permission levels.

Do you need custom groups?

The decision to create custom groups is fairly straightforward and has little effect on your site's security. You should create custom groups instead of using the

default groups if either of the following situations applies:

You have more (or fewer) user roles within your organization than are apparent in the default groups. For example, if in addition to Designers, you have a set

of people who are tasked with publishing content to the site, you might want to create a Publishers group.

There are well-known names for unique roles within your organization that perform very different tasks in the sites. For example, if you are creating a public

site to sell your organization's products, you might want to create a Customers group that replaces Visitors or Viewers.

You want to preserve a one-to-one relationship between Windows security groups and the SharePoint groups. For example, if your organization has a security

group called Web Site Managers, you might want to use that name as a group name for easy identification when managing the site.

You prefer other group names.

Do you need custom permission levels?

The decision to customize permission levels is less straightforward than the decision to customize SharePoint groups. If you customize the permissions assigned to a

permission level, you must keep track of that change, verify that it works for all groups and sites affected by the change, and ensure that the change does not

negatively affect your security or your server capacity or performance.

For example, if you customize the Contribute permission level to include the Create Subsites permission that is typically part of the Full Control permission level,

Contributors can create and own subsites, and can potentially invite malicious users to their subsites or post unapproved content. If you change the Read permission

level to include the Create Alerts permission that is typically part of the Contribute permission level, all members of the Visitors group can create alerts, which might

cause performance issues.

You should customize the default permission levels if either of the following situations applies:

A default permission level includes all permissions except one that your users need to do their jobs, and you want to add that permission.

A default permission level includes a permission that your users do not need.

Note

Do not customize the default permission levels if your organization has security or other concerns about a specific permission that is part of the permission

level. If you want to make that permission unavailable for all users assigned to the permission level or levels that include that permission, turn off the

permission for all Web applications in your server farm, rather than change all of the permission levels. To manage permissions for a Web application, see

Manage permissions for a Web application (SharePoint Foundation 2010).

If you need to make several changes to a permission level, create a custom permission level that includes all of the permissions you need.

You might want to create additional permission levels if either of the following conditions applies:

You want to exclude several permissions from a specific permission level.

You want to define a unique set of permissions for a new permission level.

To create a permission level, you can create a permission level and then select the permissions that you want to include.

For more information about how to configure custom permissions, see Configure custom permissions (SharePoint Foundation 2010).

Note

Some permissions depend on other permissions. If you clear a permission that another permission depends on, the other permission is also cleared.




Worksheet

Use the following worksheet to determine permission levels and groups to use:

Custom permission levels and groups worksheet (http://go.microsoft.com/fwlink/p/?LinkID=213966&clcid=0x409)

© 2014 Microsoft


Choose security groups (SharePoint Foundation 2010)



This article describes the security and distribution groups that comprise the Active Directory® Domain Services ﴾ADDS﴿. This article also provides recommendations forusing those groups to organize the users of your SharePoint sites.

In this article:

Decide whether to add security groups

Determine which security groups to use for granting access to sites

Decide whether to allow access to all authenticated users

Decide whether to allow access to anonymous users

Worksheet

Introduction

Managing users of SharePoint sites is easier if you assign permission levels to groups rather than to individual users. SharePoint group is a set of individual users and

can also include Active Directory groups. In Active Directory Domain Services (ADDS), the following groups are commonly used to organize users:

Distribution group A group that is used only for e-mail distribution and that is not security-enabled. Distribution groups cannot be listed in discretionary

access control lists (DACLs), which are used to define permissions on resources and objects.

Security group A group that can be listed in DACLs. A security group can also be used as an e-mail entity.

You can use security groups to control permissions for your site by adding security groups to SharePoint groups and granting permissions to the SharePoint groups.

You cannot add distribution groups to SharePoint groups, but you can expand a distribution group and add the individual members to a SharePoint group. If you use

this method, you must manually keep the SharePoint group synchronized with the distribution group. If you use security groups, you do not need to manage the

individual users in the SharePoint application. Because you included the security group instead of the individual members of the group, ADDS manages the users for you.

Note

For ease of security management, the following items are not recommended in managing Active Directory groups.

Assign permission levels directly to Active Directory groups.

Adding security groups that contain nested security groups, contacts, or distribution lists.

Decide whether to add security groups

Adding security groups to SharePoint groups provides centralized management of groups and security. The security group is the only place where you manage

individual users. Once you add the security group to a SharePoint group, you do not have to manage security group members in that SharePoint group. If a user is

removed from the security group, the user will be automatically removed from the SharePoint group.

However, using security groups in SharePoint sites does not provide full visibility of what is happening. For example, when a security group is added to a SharePoint

group for a specific site, the site will not appear in the users’ My Sites. The User Information List will not show individual users until they have contributed to the site. Inaddition, security groups with deep nested structure might break SharePoint sites.

Considering the previous advantages and disadvantages, here are the recommendations:

For intranet sites that are broadly accessed by your users, use security groups because you do not care about the individual users who accessed the intranet site

home page.

For collaboration sites that are accessed by a small group of users, add users directly to SharePoint groups. In this case, there is more of a need to know who is

a member so the group members know each other’s e‐mail addresses and how to contact each other.

Determine which security groups to use for granting access to sites

Each organization sets up its security groups differently. For easier permission management, security groups should be:

Large and stable enough that you are not continually adding additional security groups to your SharePoint sites.

Small enough that you can assign appropriate permissions.


For example, a security group called "all users in building 2" is probably not small enough to assign permissions, unless all users in building 2 have the same job

function, such as accounts receivable clerks. This is rarely the case, so you should look for a smaller, more specific set of users, such as “Accounts Receivable”.

Decide whether to allow access for all authenticated users

If you want all users within your domain to be able to view content on your site, consider granting access to all authenticated users (the Domain Users Windows security

group). This special group allows all members of your domain to access a Web site (at the permission level you choose), without your having to enable anonymous

access.

Decide whether to allow access for anonymous users

You can enable anonymous access to allow users to view pages anonymously. Most Internet Web sites allow anonymous viewing of a site, but might ask for

authentication when someone wants to edit the site or buy an item on a shopping site. Anonymous access is disabled by default and must be granted at the Web

application level at the time that the Web application is created.

If anonymous access is allowed for the Web application, site administrators can decide whether to grant anonymous access to a site or any of the content on that site.

Anonymous access relies on the anonymous user account on the Web server. This account is created and maintained by Microsoft Internet Information Services (IIS), not

by your SharePoint site. By default in IIS, the anonymous user account is IUSR. When you enable anonymous access, you are in effect granting that account access to the

SharePoint site. Allowing access to a site, or to lists and libraries, grants the View Items permission to the anonymous user account. Even with the View Items permission,

however, there are restrictions to what anonymous users can do. Anonymous users cannot:

Open sites for editing in Microsoft Office SharePoint Designer.

View sites in My Network Places.

Upload or edit documents in document libraries, including wiki libraries.

Important

To improve security for sites, lists, or libraries, do not enable anonymous access. Enabling anonymous access allows users to contribute to lists, discussions,

and surveys, which will possibly use up server disk space and other resources. Anonymous access also allows anonymous users to discover site information,

including user e-mail addresses and any content posted to lists, and libraries, and discussions.

Permission policies provide a centralized way to configure and manage a set of permissions that applies to only a subset of users or groups in a Web application. You

can manage permission policy for anonymous users by enabling or disabling anonymous access for a Web application. If you enable anonymous access for a Web

application, site administrators can then grant or deny anonymous access at the site collection, site, or item level. If anonymous access is disabled for a Web application,

no sites within that Web application can be accessed by anonymous users.

None No policy. This is the default option. No additional permission restrictions or additions are applied to site anonymous users.

Deny Write Anonymous users cannot write content, even if the site administrator specifically attempts to grant the anonymous user account that permission.

Deny All Anonymous users cannot have any access, even if site administrators specifically attempt to grant the anonymous user account access to their sites.

For more information about permission policies, see Manage permission policies for a Web application (SharePoint Foundation 2010).

Worksheet

Use the following worksheet to list the security groups that you will use and the permission levels that the groups will need at each level of your site hierarchy.

Site and content security worksheet (http://go.microsoft.com/fwlink/p/?LinkID=213967&clcid=0x409)

© 2014 Microsoft



Choose administrators and owners for the administration hierarchy(SharePoint Foundation 2010)



This article describes the administrator roles that correspond to the Microsoft SharePoint Foundation 2010 server and site hierarchy. Many people can be involved in

managing SharePoint Foundation 2010. Administration of Microsoft SharePoint Foundation occurs at the following levels:

Windows server or SharePoint server farm

Shared services

Web application

Sites

Document library or list

Individual items

In this article:

Levels of administration

Worksheet

Levels of administration

Most levels of the server and site hierarchy have a corresponding administration group. The administration groups who have administrative permissions at different

levels are described in the following list:

Windows server or server farm level

Farm Administrators group Members of the Farm Administrators group have permissions to and responsibility for all servers in the server farm.

Members can perform all administrative tasks in Central Administration for the server or server farm. They can assign administrators to manage service

applications, which are instances of shared services. This group does not have access to individual sites or their content by default. However, they can

grant themselves access if need be.

Windows Administrators group Members of the Windows Administrators group on the local server can perform all farm administrator actions.

Administrators on the local server can perform additional tasks, such as installing new products or applications, deploying Web Parts and new features to

the global assembly cache, creating new Web applications and new Internet Information Services (IIS) Web sites, and starting services. Like farm

administrators, members of this group on the local server have no access to site content by default.

Note

Farm administrators and members of the local Administrators group can take ownership of specific site collections if necessary. For example, if a site

administrator leaves the organization and a new administrator must be added, the farm administrator or a member of the local Administrators group

can take ownership of the site collection to make the change. To take ownership, they can add themselves as the site collection administrator on the

Application Management page.

Shared services level

Service application administrators These administrators are designated by the farm administrator. They can configure settings for a specific service

application within a farm. However, these administrators cannot create service applications, access any other service applications in the farm, or perform

any farm-level operations, including topology changes. For example, the service application administrator for a Search service application in a farm can

configure settings for that Search service application only.

Feature administrators A feature administrator is associated with a specific feature or features of a service application. These administrators can

manage a subset of service application settings, but not the entire service application. For example, a Feature administrator might manage the Audiences

feature of the User Profile service application.

Web application level

The Web application level does not have a unique administrator group, but farm administrators have control over the Web applications within their scope.

Members of the Farm Administrators group and members of the Administrators group on the local server can define a policy to grant individual users

permissions at the Web application level. For more information about policy, see "Policy for Web applications" in the Logical architecture components

(SharePoint Server 2010) article.

Site level

Site collection administrators These administrators have the Full Control permission level on all Web sites within a site collection. They have Full Control

access to all site content in that site collection, even if they do not have explicit permissions on that site. They can audit all site content and receive any



administrative alert. A primary and a secondary site collection administrator can be specified during the creation of a site collection.

Site owners By default, members of the Owners group for a site have the Full Control permission level on that site. They can perform administrative tasks

on the site, and on any list or library within that site. They receive e-mail notifications for events, such as the pending automatic deletion of inactive sites

and requests for site access.

Worksheet

Use the following worksheet to choose administrators and owners for the administration hierarchy:

Administrators and owners worksheet (http://go.microsoft.com/fwlink/p/?LinkID=213965&clcid=0x409)

© 2014 Microsoft


Best practices for using fine-grained permissions (white paper)(SharePoint Foundation 2010)



This white paper describes best practices for fine-grained permissions (FGP) and how to use them within your organization when implementing Microsoft SharePoint

Foundation 2010.

Download the white paper from the following link: http://go.microsoft.com/fwlink/p/?LinkId=201596

© 2014 Microsoft


Contribute permission level overview (SharePoint Foundation 2010)



Permissions for the Contribute permission level in Windows SharePoint Services 3.0 and Microsoft SharePoint Foundation 2010 are the same. However, the Contribute

permission level in SharePoint Foundation 2010 allows users to complete a more limited set of tasks.

For example, the default Contribute permissions in Windows SharePoint Services 3.0 allow users to edit scriptable Web files and Web Parts. Although the permissions are

identical in SharePoint Foundation 2010, users who have the default Contribute permissions cannot edit scriptable Web files and Web Parts. The ability to edit scriptable

Web files and Web Parts in SharePoint Foundation 2010 requires the Add and Customize Pages permission. The absence of this permission in the default Contribute

permission level of SharePoint Foundation 2010 prevents users from editing scriptable Web files and Web Parts. Despite the absence of the same permission in the default

Contribute permission level of Windows SharePoint Services 3.0, users who have the default Contribute permissions in Windows SharePoint Services 3.0 can edit scriptable

Web files and Web Parts.

This article describes the Contribute permission level in SharePoint Foundation 2010 and does not describe how to enable users with the Contribute permission level to edit

scriptable Web Parts. For more information, see Allow or prevent Contributors ability to edit scriptable Web Parts (SharePoint Foundation 2010).

In this article:

About updating Web files

About editing Web Parts

About updating Web files

Web files are a set of special files that provide a full range of customization of a Web page. These files can contain scripts (such as JavaScript) that can call Web services

and interoperate with data on a site. Web files are stored as a modifiable list based on their file extensions. The default list of file extensions is as follows:

.ascx

.aspx

.asmx

.master

.jar

.swf

.xap

.xsf

.xsn

Note

A member of the Farm Administrators group can use Windows PowerShell cmdlets to modify the above list.

Although users with the default Contribute permission level in Windows SharePoint Services 3.0 can complete the following tasks, users with the default Contribute

permission level in SharePoint 2010 Products cannot complete these tasks:

Update the content of a Web file

Move a Web file

Upload a Web file

Rename a Web file

Publish, migrate, import and export a Web file

Note

In SharePoint 2010 Products, a user must have the Add and Customize Pages permission to complete the above tasks.

Users with the default Contribute permission level in Windows SharePoint Services 3.0 and SharePoint 2010 Products can complete the following tasks:

Check in, check out, or revert a Web file

Revert a version from version history for a Web file

Delete a Web file



Recycle a deleted Web file

About editing Web Parts

Users who have the default Contribute permission level in Windows SharePoint Services 3.0 can add or edit Web Parts that developers have marked as unsafe for

editing. However, users who have the default Contribute permission level in SharePoint 2010 Products cannot add or edit the same Web Parts.

Note

To add or edit Web Parts that developers have marked as unsafe for editing, users in SharePoint 2010 Products must have the Add and Customize Pages permission.

The following Web Parts are marked as safe for editing by default and can be added or edited by users who have the default Contribute permission level:

Basic Chart Web Part

Image Web part

Page Viewer Web Part

Picture Slideshow Web Part

Relevant Documents Web Part

Site Users Web Part

Title Bar Web Part

User Tasks Web Part

A member of the Farm Administrators group can update permissions to allow users with the default Contribute permission level to add or edit Web Parts that are

marked as unsafe for editing. For more information, see Allow or prevent Contributors ability to edit scriptable Web Parts (SharePoint Foundation 2010).

See Also

ConceptsAllow or prevent Contributors ability to edit scriptable Web Parts (SharePoint Foundation 2010)

© 2014 Microsoft



Security planning for server farms (SharePoint Foundation 2010)



This section contains security articles designed to help you to plan server farms environments and configurations.

In this section:

Plan administrative tasks in a least-privilege environment (SharePoint Foundation 2010)

Plan for administrative and service accounts (SharePoint Foundation 2010)

© 2014 Microsoft



Plan administrative tasks in a least-privilege environment(SharePoint Foundation 2010)



This article describes how to configure and maintain a Microsoft SharePoint Foundation 2010 farm by using least-privileged administration.

Overview

The concept of least-privileged administration assigns users the minimum permissions that are required for users to complete authorized tasks. The goal of least-

privileged administration is to configure and help maintain secure control of an environment. The result is that each service is granted access to only the resources that

are absolutely necessary. Implementing least-privileged administration can result in increased operational costs because additional resources might be required to

maintain this level of administration. Moreover, the ability to troubleshoot security problems can also be diminished.

Security Note

Organizations implement least-privileged administration to achieve better security than would be typically recommended. Only a small percentage of organizations

require this heightened level of security because of the resource costs of maintaining least-privileged administration. However, some deployments that might require

this heightened level of security include governmental agencies, security organizations, and organizations in the financial services industry. The implementation of a

least-privileged environment should not be confused with best practices. In a least-privileged environment, administrators implement best practices together with

additional heightened levels of security is performed.

Least-privileged environment for accounts and services

To plan for least-privileged administration, you must consider several accounts, roles, and services. Some apply to SQL Server and some apply to SharePoint 2010

Products. As administrators lock down additional accounts and services, daily operational costs are likely to increase.

Microsoft SQL Server roles

In a least-privileged administration environment, we recommend that you remove the following two SQL Server server-level roles from accounts that are not

SharePoint service accounts, but are used for SharePoint administration:

dbcreator- Members of the dbcreator fixed server role can create, alter, drop, and restore any database.

securityadmin- Members of the securityadmin fixed server role manage logins and their properties. They can GRANT, DENY, and REVOKE server-level

permissions. They can also GRANT, DENY, and REVOKE database-level permissions if they have access to a database. Additionally, they can reset passwords

for SQL Server logins.

Security Note

The ability to grant access to the Database Engine and to configure user permissions allows the security admin to assign most server permissions. The

securityadmin role should be treated as equal to the sysadmin role.

For additional information about SQL Server server-level roles, see Server Level Roles (http://go.microsoft.com/fwlink/p/?LinkId=213450)

The removal of one or more of these SQL Server roles might cause “Unexpected” error messages that will be displayed in the Central Administration Web site. Inaddition, you may receive the following message in the Unified Logging Service (ULS) log file:

System.Data.SqlClient.SqlException… <operation type> permission denied in database <database>. Table <table>

Along with an error message that may be displayed, the user may be unable to perform any of the following tasks:

Restore a backup of a farm due to the inability to write to a database

Provision a service instance or Web application

Configure managed accounts

Change managed accounts for Web applications

Any database, managed account, or services operation that requires the use of the Central Administration Web site

In certain situations, database administrators (DBAs) may want to operate independently from SharePoint administrators and create and manage all the databases.

For information about how DBAs create and manage all databases, see Deploy by using DBA-created databases (SharePoint Foundation 2010).

SharePoint Foundation 2010 roles and services

In general, the ability to create new databases should be removed from SharePoint service accounts. No SharePoint service account should have the sysadmin role on



the Microsoft SQL Serverinstance and no SharePoint service account should be a local Administrator on the server that runs Microsoft SQL Server.

However, you could lock down several other SharePoint Foundation 2010 services and accounts:

SharePoint_Shell_Access role

When this Microsoft SQL Server role is removed, the ability to write entries to the configuration and content database is removed. For additional information

about this role, see Add-SPShellAdmin.

SharePoint Timer service (SPTimerV4)

By default, this service is installed and maintains configuration cache information. If the service type is set to disabled the following behavior may occur:

No timer jobs will run

Health analyzer rules will not run

Maintenance and farm configuration will be out of date

SharePoint Administration service (SPAdminV4)

This service performs automated changes that require local administrator permission on the server. When the service is not running, you must manually

process server-level administrative changes. If the service type is set to disabled, the following behavior may occur:

Administrative timer jobs will not run

Web configuration files will not be updated

Security and local groups will not be updated

Registry values and keys will not be written

Services may be unable to be started or restarted

Provisioning of services may be unable to be completed

SPUserCodeV4 Service

This service lets a site collection administrator upload sandboxed solutions to the Solutions gallery. For additional information about sandboxed solutions, see

Sandboxed solutions overview (SharePoint Foundation 2010).

For more information services, see SharePoint Administration service is disabled (SharePoint 2010 Products).

Depending on an organization's business requirements, if any SharePoint Foundation 2010 services or roles are implemented, the behavior to the following features

may occur:

Backup and restore

The ability to perform a restore from a backup may fail if database permissions have been removed.

Upgrade

The upgrade process will start correctly, but then fail as you do not have suitable permissions to databases. If your organization is already in a least-privileged

environment, the workaround is move to a best practices environment to complete the upgrade, and then move back to a least-privileged environment.

Update

The ability to apply a software update to a farm will succeed for the schema of the configuration database, but fail on the content database and services.

Additional requirements to consider

In addition to the preceding considerations, you might have to consider more operations. The following list is not complete. Selectively use the items at your own

discretion:

Setup user administrator account- This account is used to set up each server in a farm. The account must be a member of the Administrators group on each

server in the Microsoft SharePoint Server 2010 farm. For additional information about this account, see Administrative accounts

My Site host application pool account- This is the account under which the My Site application pool runs. To configure this account, you need to be a

member in the Farms Administrators group.

Built-in user group- Removing the built-in user security group or changing the permissions may have unanticipated consequences.

Group permissions-By default the WSS_ADMIN_WPG SharePoint group has read and write access to local resources. The following WSS_ADMIN_WPG file

system locations, %WINDIR%\System32\drivers\etc\HOSTS and %WINDIR%\Tasks are needed for Microsoft SharePoint Foundation to work properly. If other

services or applications are running on a server, you may consider how they access the Tasks or HOSTS folder locations. For additional information about

account settings, see Account permissions and security settings (SharePoint Server 2010)

Change permission of a service- A change of a permission of a service may have unanticipated consequences. For example, if the following registry key,

HKLM\System\CurrentControlSet\Services\PerfProc\Performance\Disable Performance Counters, has the value of 0, the User Code Host service would be

disabled which would cause sandboxed solutions to stop working. For additional information about the User Code service not working, see The SharePoint

2010 User Code Host service fails to start (http://go.microsoft.com/fwlink/p/?LinkId=225642)




http://technet.microsoft.com/en-us/library/55b99d80-3fa7-49f0-bdf4-adb5aa959019(v=office.14)#Section2



Plan for administrative and service accounts (SharePointFoundation 2010)



This article describes the accounts that that you must plan for and describes the deployment scenarios that affect account requirements.

In this article:

About administrative and service accounts

Single server standard requirements

Server farm standard requirements

Use this article with the following deployment article: Initial deployment administrative and service accounts (SharePoint Foundation 2010)

The initial deployment administrative and service accounts article describes the specific account and permissions that you need to grant prior to running Setup.

This article does not describe security roles and permissions required to administer in Microsoft SharePoint Foundation 2010.

About administrative and service accounts

This section lists and describes the accounts that you must plan for. The accounts are grouped according to scope.

After you complete installation and configuration of accounts, ensure that you do not use the Local System account to perform administration tasks or to browse sites.

Server farm-level accounts

The following table describes the accounts that are used to configure Microsoft SQL Server database software and to install SharePoint Foundation 2010.

Account Purpose

SQL Server service

account

SQL Server prompts for this account during SQL Server Setup. This account is used as the service account for the following SQL Server

services:

MSSQLSERVER

SQLSERVERAGENT

If you are not using the default instance, these services will be shown as:

MSSQL$InstanceName

SQLAgent$InstanceName

Setup user account The user account that is used to run:

If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for

the database.

Setup on each server computer

SharePoint Products Configuration Wizard

The Psconfig command-line tool

The Stsadm command-line tool

Server farm account This account is also referred to as the database access account.

This account is:

The application pool identity for the SharePoint Central Administration Web site.

The process account for the Windows SharePoint Services Timer service.

Service application accounts


The following table describes the accounts that are used to set up and configure a service application. Plan one set of an application pool and proxy group for each

service application you plan to implement.

For additional information about service application endpoints, see Using Service Endpoints (http://go.microsoft.com/fwlink/p/?LinkId=227293).

Account Service Purpose Requirements

Service

Application

Endpoint

Business Data

Connectivity Service

Search Service

Usage and Health

Data Collection Service

Used as the identity for the service application endpoint application pool. Unless

there are specific isolation requirements, the application pool can be used to host

multiple service application endpoints.

Must be a member of the Farm

Administrators group.

Application Discovery

and Load Balancer

Service Application

Used as the identity for the service application endpoint application pool. This

account must be the Farm Account and the application pool is created automatically

by the SharePoint Products Configuration Wizard.

Must be a member of the Farm

Administrators group.

Default

Content

Access

Search Service The default account when crawling content. Note that additional accounts can be

specified per crawl rule.

Must have Read Access to the

content being crawled.

Full Read permissions must be

granted explicitly to content that is

outside the local farm.

Full Read permissions are

automatically configured for

content databases in the local

farm.

Search

Service

Search Service This is the Windows Service account for the SharePoint Server Search Service. This

setting affects all Search service applications in the farm.

Must be a domain user account.

Microsoft SharePoint Foundation 2010 search service accounts

The following table describes the accounts that are used for the SharePoint Foundation 2010 search service account.

SharePoint Foundation 2010 uses these accounts only for searching Help content in response to user search queries. There is only one instance of the SharePoint

Foundation 2010 Search service in a farm.

Account Purpose

SharePoint Foundation 2010 Search

Service

Used as the service account for the SharePoint Foundation 2010 Search Service. This account cannot be a built-in account,

such as Local Service or Network Service.

SharePoint Foundation 2010 Search

Content Access

Used to crawl Help content. For proper search functionality and information security, do not use an administrator account

or an account that can modify content.

Used to crawl Help content. For proper search functionality and information security, do not use an administrator account

or an account that can modify content.

Additional application pool identity accounts

If you create additional application pools to host sites, plan for additional application pool identity accounts. The following table describes the application pool

identity account. Plan one application pool account for each application pool you plan to implement.

Account Purpose

Application

pool identity

The user account that the worker processes that service the application pool use as their process identity. This account is used to access content

databases associated with the Web applications that reside in the application pool.


If you are deploying to a single server computer, account requirements are greatly reduced. In an evaluation environment, you can use a single account for all of the

account purposes. In a production environment, ensure that the accounts you create have the appropriate permissions for their purposes.



For a list of account permissions for single server environments, see Initial deployment administrative and service accounts (SharePoint Foundation 2010).

Server farm requirements

If you are deploying to more than one server computer, use the server farm standard requirements to ensure that accounts have the appropriate permissions to

perform their processes across multiple computers. The server farm standard requirements detail the minimum configuration that is necessary to operate in a server

farm environment.

For a more secure environment, see Plan administrative tasks in a least-privilege environment (SharePoint Foundation 2010)

For a list of standard requirements for server farm environments see the requirements listed in the Technical reference: Account requirements by scenario section of this

article.

For some accounts, additional permissions or access to databases are configured when you run Setup. These are noted in the accounts planning tool. An important

configuration for database administrators to be aware of is the addition of the WSS_Content_Application_Pools database role. Setup adds this role to the following

databases:

SharePoint_Config database (configuration database)

SharePoint_AdminContent database

Members of the WSS_Content_Application_Pools database role are granted the Execute permission to a subset of the stored procedures for the database.

Additionally, members of this role are granted the Select permission to the Versions table (dbo.Versions) in the SharePoint_AdminContent database.

For other databases, the accounts planning tool indicates that access to read from these databases is automatically configured. In some cases, limited access to write to

a database is also automatically configured. To provide this access, permissions to stored procedures are configured. For the SharePoint_Config database, for example,

access to the following stored procedures is automatically configured:

proc_dropEmailEnabledList

proc_dropEmailEnabledListsByWeb

proc_dropSiteMap

proc_markForDeletionEmailEnabledList

proc_markForDeletionEmailEnabledListsBySite

proc_markForDeletionEmailEnabledListsByWeb

proc_putDistributionListToDelete

proc_putEmailEnabledList

proc_putSiteMap

Technical reference: Account requirements by scenario

This section lists account requirements by scenario:





Account Requirements

SQL Server service Local System account (default)

Setup user Member of the Administrators group on the local computer

Server farm Network Service (default)

No manual configuration is necessary.

Microsoft SharePoint Foundation 2010 Search service accounts




SharePoint Foundation 2010

Search Service

Must not be a built-in account, such as Local Service or Network Service.

SharePoint Foundation 2010

Search Service Content Access

For proper search functionality and information security, do not use an administrator account or an account that can modify

content. This account is automatically added to the Full Read policy, giving it read-only access to all Help content.



Application pool identity No manual configuration is necessary.

The Network Service account is used for the default Web site that is created during Setup and configuration.




SQL

Server

service

account

Use either a Local System account or a domain user account.

If a domain user account is used, this account uses Kerberos authentication by default, which requires additional configuration in your network

environment. If SQL Server uses a service principal name (SPN) that is not valid (that is, that does not exist in the Active Directory service

environment), Kerberos authentication fails, and then NTLM is used. If SQL Server uses an SPN that is valid but is not assigned to the appropriate

container in Active Directory, authentication fails. Authentication will always try to use the first SPN it finds, so ensure that there are no SPNs assigned

to inappropriate containers in Active Directory.

If you plan to back up to or restore from an external resource, permissions to the external resource must be granted to the appropriate account. If

you use a domain user account for the SQL Server service account, grant permissions to that domain user account. However, if you use the Network

Service or the Local System account, grant permissions to the external resource to the machine account (domain_name\SQL_hostname$).

Setup

user

account

Domain user account.

Member of the Administrators group on each server on which Setup is run.

SQL Server login on the computer running SQL Server.

Member of the following SQL Server security roles:

securityadmin fixed server role

dbcreator fixed server role

If you run Stsadm commands that affect a database, this account must be a member of the db_owner fixed database role for the database.

Server

farm

account

Domain user account.

If the server farm is a child farm with Web applications that consume shared services from a parent farm, this account must be a member of

the db_owner fixed database role on the configuration database of the parent farm.

Additional permissions are automatically granted for this account on Web servers and application servers that are joined to a server farm.

This account is automatically added as a SQL Server login on the computer running SQL Server and added to the following SQL Server security roles:

dbcreator fixed server role

securityadmin fixed server role

db_owner fixed database role for all databases in the server farm

Note if you configure the Secure Store Service, the server farm account will not automatically be given db_owner access to the Secure Store Service

database.

Microsoft SharePoint Foundation 2010 Search accounts


Microsoft SharePoint Foundation 2010 Search service accountMust be a domain user account.

Must not be a member of the Farm Administrators group.

The following are automatically configured:

Access to read from the configuration database and the SharePoint_Admin content

database.

Membership in the db_owner role for the WSS_ Search database.

Microsoft SharePoint Foundation 2010 Search content access

account Same requirements as the SharePoint Foundation Search Service account.

Automatically added to the Web application Full Read policy for the farm.



Application pool identity No manual configuration is necessary.

The following are automatically configured:

Membership in the db_owner role for content databases and search databases associated with the Web application.

Membership in specific application pool roles for the configuration and the SharePoint_AdminContent databases.

Additional permissions for this account to front-end Web servers and application servers are automatically granted.

© 2014 Microsoft

Plan security hardening (SharePoint Foundation 2010)



This article describes security hardening for Microsoft SharePoint Foundation 2010 Web server, application server, and database server roles, and gives detailed guidance

about the specific hardening requirements for ports, protocols, and services in Microsoft SharePoint 2010 Products.

In this article:

Secure server snapshots

Specific port, protocol, and service guidance

Secure server snapshots

In a server farm environment, individual servers play specific roles. Security hardening recommendations for these servers depend on the role each server plays. This

article contains secure snapshots for two categories of server roles:

Web server and application server roles

Database server role

The snapshots are divided into common configuration categories. The characteristics defined for each category represent the optimal hardened state for Microsoft

SharePoint 2010 Products. This article does not include hardening guidance for other software in the environment.

Web server and application server roles

This section identifies hardening characteristics for Web servers and application servers. Some of the guidance applies to specific service applications; in these cases,

the corresponding characteristics need to be applied only on the servers that are running the services associated with the specified service applications.

Category Characteristic

Services listed

in the Services

MMC snap-in

Enable the following services:

File and Printer Sharing

World Wide Web Publishing Service

Ensure that these services are not disabled:

Claims to Windows Token Service

SharePoint 2010 Administration

SharePoint 2010 Timer

SharePoint 2010 Tracing

SharePoint 2010 VSS Writer

Ensure that these services are not disabled on the servers that host the corresponding roles:

SharePoint 2010 User Code Host

SharePoint Foundation Search V4

Ports and

protocols TCP 80, TCP 443 (SSL)

File and Printer Sharing service —either of the following, used by search roles:

Direct‐hosted SMB ﴾TCP/UDP 445﴿ — this is the recommended portNetBIOS over TCP/IP ﴾NetBT﴿ ﴾TCP/UDP ports 137, 138, 139﴿ — disable this port if you do not use it

Ports required for communication between Web servers and service applications (the default is HTTP):

HTTP binding: 32843

HTTPS binding: 32844

net.tcp binding: 32845 (only if a third party has implemented this option for a service application)

UDP port 1434 and TCP port 1433 — default ports for SQL Server communication. If these ports are blocked on the SQL Servercomputer (recommended) and databases are installed on a named instance, configure a SQL Server client alias for connecting to the

named instance.

TCP/IP 32846 for the Microsoft SharePoint Foundation User Code Service ﴾for sandbox solutions﴿ — This port must be open foroutbound connections on all Web servers. This port must be open for inbound connections on Web servers or application servers where

this service is turned on.

Ensure that ports remain open for Web applications that are accessible to users.

Block external access to the port that is used for the Central Administration site.

TCP/25 (SMTP for e-mail integration)

Registry No additional guidance

Auditing and

logging

If log files are relocated, ensure that the log file locations are updated to match. Update directory access control lists (ACLs) also.

Code access

security

Ensure that you have a minimal set of code access security permissions enabled for your Web application. The <trust> element in the

Web.config file for each Web application should be set to WSS_Minimal (where WSS_Minimal has its low defaults as defined in

14\config\wss_minimaltrust.config or by your own custom policy file, which is minimally set.)

Web.config Follow these recommendations for each Web.config file that is created after you run Setup:

Do not allow compilation or scripting of database pages via the PageParserPaths elements.

Ensure <SafeMode> CallStack=""false"" and AllowPageLevelTrace=""false"".

Ensure that the Web Part limits around maximum controls per zone is set low.

Ensure that the SafeControls list is set to the minimum set of controls needed for your sites.

Ensure that your Workflow SafeTypes list is set to the minimum level of SafeTypes needed.

Ensure that customErrors is turned on (<customErrors mode=""On""/>).

Consider your Web proxy settings as needed (<system.net>/<defaultProxy>).

Set the Upload.aspx limit to the highest size you reasonably expect users to upload (default is 2 GB). Performance can be affected by

uploads that exceed 100 MB.

Database server role

The primary recommendation forSharePoint 2010 Products is to secure inter-farm communication by blocking the default ports used for Microsoft SQL Server

communication and establishing custom ports for this communication instead. For more information about how to configure ports for SQL Server communication, see

Blocking the standard SQL Server ports, later in this article.

Category Characteristic

PortsBlock UDP port 1434.

Consider blocking TCP port 1433.

This article does not describe how to secure SQL Server. For more information about how to secure SQL Server, see Securing SQL Server


Specific port, protocol, and service guidance

The rest of this article describes in greater detail the specific hardening requirements for SharePoint 2010 Products.

In this section:

Blocking the standard SQL Server ports

Service application communication

File and Printer Sharing service requirements

Service requirements for e-mail integration

SharePoint 2010 Products services

Web.config file

Blocking the standard SQL Server ports

The specific ports used to connect to SQL Server are affected by whether databases are installed on a default instance of SQL Server or a named instance of SQL

Server. The default instance of SQL Server listens for client requests on TCP port 1433. A named instance of SQL Server listens on a randomly assigned port number.

Additionally, the port number for a named instance can be reassigned if the instance is restarted (depending on whether the previously assigned port number is

available).

By default, client computers that connect to SQL Server first connect by using TCP port 1433. If this communication is unsuccessful, the client computers query the SQL

Server Resolution Service that is listening on UDP port 1434 to determine the port on which the database instance is listening.

The default port-communication behavior of SQL Server introduces several issues that affect server hardening. First, the ports used by SQL Server are well-publicized

ports and the SQL Server Resolution Service has been the target of buffer overrun attacks and denial-of-service attacks, including the "Slammer" worm virus. Even if

SQL Server is updated to mitigate security issues in the SQL Server Resolution Service, the well-publicized ports remain a target. Second, if databases are installed on


a named instance of SQL Server, the corresponding communication port is randomly assigned and can change. This behavior can potentially prevent server-to-server

communication in a hardened environment. The ability to control which TCP ports are open or blocked is essential to securing your environment.

Consequently, the recommendation for a server farm is to assign static port numbers to named instances of SQL Server and to block UDP port 1434 to prevent

potential attackers from accessing the SQL Server Resolution Service. Additionally, consider reassigning the port used by the default instance and blocking TCP port

1433.

There are several methods you can use to block ports. You can block these ports by using a firewall. However, unless you can be sure that there are no other routes

into the network segment and that there are no malicious users that have access to the network segment, the recommendation is to block these ports directly on the

server that hosts SQL Server. This can be accomplished by using Windows Firewall in Control Panel.

Configuring SQL Server database instances to listen on a nonstandard port

SQL Server provides the ability to reassign the ports that are used by the default instance and any named instances. In SQL Server 2005 and SQL Server 2008, you

reassign ports by using SQL Server Configuration Manager.

Configuring SQL Server client aliases

In a server farm, all front-end Web servers and application servers are SQL Server client computers. If you block UDP port 1434 on the SQL Server computer, or

you change the default port for the default instance, you must configure a SQL Server client alias on all servers that connect to the SQL Server computer.

To connect to an instance of SQL Server 2005 or SQL Server 2008, you install SQL Server client components on the target computer and then configure the SQL

Server client alias by using SQL Server Configuration Manager. To install SQL Server client components, run Setup and select only the following client components

to install:

Connectivity Components

Management Tools (includes SQL Server Configuration Manager)

For specific hardening steps for blocking the standard SQL ports, see Harden SQL Server for SharePoint environments (SharePoint Foundation 2010).

Service application communication

By default, communication between Web servers and service applications within a farm takes place by using HTTP with a binding to port 32843. When you publish a

service application, you can select either HTTP or HTTPS with the following bindings:

HTTP binding: port 32843

HTTPS binding: port 32844

Additionally, third parties that develop service applications can implement a third choice:

net.tcp binding: port 32845

You can change the protocol and port binding for each service application. On the Service Applications page in Central Administration, select the service application,

and then click Publish.

Communication between service applications and SQL Server takes place over the standard SQL Server ports or the ports that you configure for SQL Server

communication.

File and Printer Sharing service requirements

Several core features depend on the File and Printer Sharing service and the corresponding protocols and ports. These include, but are not limited to, the following:

Search queries All search queries require the File and Printer Sharing service.

Crawling and indexing content To crawl content, servers that include crawl components send requests through the front-end Web server. The front-end

Web server communicates with content databases directly and sends results back to the servers that include crawl components. This communication requires

the File and Printer Sharing service.

The File and Printer Sharing service requires the use of named pipes. Named pipes can communicate by using either direct-hosted SMB or NetBT protocols. For a

secure environment, direct-hosted SMB is recommended instead of NetBT. The hardening recommendations provided in this article assume that SMB is used.

The following table describes the hardening requirements that are introduced by the dependency on the File and Printer Sharing service.

Category Requirements Notes

Services File and Printer Sharing Requires the use of named pipes.


Protocols Named pipes that use direct-hosted SMB

Disable NetBT

Named pipes can use NetBT instead of direct-hosted SMB. However, NetBT is not considered as

secure as direct-hosted SMB.

Ports Either of the following:

Direct‐hosted SMB ﴾TCP/UDP 445﴿ —recommended

NetBT (TCP/UDP ports 137, 138, 139)

Disable NetBT (ports 137, 138, and 139) if it is not being used

For more information about how to disable NetBT, see the Microsoft Knowledge Base article 204279, Direct hosting of SMB over TCP/IP


Service requirements for e-mail integration

E-mail integration requires the use of two services:

SMTP service

Microsoft SharePoint Directory Management service

SMTP service

E-mail integration requires the use of the Simple Mail Transfer Protocol (SMTP) service on at least one of the front-end Web servers in the server farm. The SMTP

service is required for incoming e-mail. For outgoing e-mail, you can either use the SMTP service or route outgoing email through a dedicated e-mail server in your

organization, such as a Microsoft Exchange Server computer.

Microsoft SharePoint Directory Management service

SharePoint 2010 Products include an internal service, the Microsoft SharePoint Directory Management Service, for creating e-mail distribution groups. When you

configure e-mail integration, you have the option to enable the Directory Management Service feature, which lets users create distribution lists. When users create a

SharePoint group and they select the option to create a distribution list, the Microsoft SharePoint Directory Management Service creates the corresponding Active

Directory distribution list in the Active Directory environment.

In security-hardened environments, the recommendation is to restrict access to the Microsoft SharePoint Directory Management Service by securing the file

associated with this service, which is SharePointEmailws.asmx. For example, you might allow access to this file by the server farm account only.

Additionally, this service requires permissions in the Active Directory environment to create Active Directory distribution list objects. The recommendation is to set

up a separate organizational unit (OU) in Active Directory for SharePoint 2010 Products objects. Only this OU should allow write access to the account that is used

by the Microsoft SharePoint Directory Management Service.

SharePoint 2010 Products services

Do not disable services that are installed by SharePoint 2010 Products (listed in the snapshot previously).

If your environment disallows services that run as a local system, you can consider disabling the SharePoint 2010 Administration service only if you are aware of the

consequences and can work around them. This service is a Win32 service that runs as a local system.

This service is used by the SharePoint 2010 Timer service to perform actions that require administrative permissions on the server, such as creating Internet

Information Services (IIS) Web sites, deploying code, and stopping and starting services. If you disable this service, you cannot complete deployment-related tasks

from the Central Administration site. You must use Windows PowerShell to run the Start-SPAdminJob cmdlet (or use the Stsadm.exe command-line tool to run the

execadmsvcjobs operation) to complete multiple-server deployments for SharePoint 2010 Products and to run other deployment-related tasks.

Web.config file

The .NET Framework, and ASP.NET in particular, use XML-formatted configuration files to configure applications. The .NET Framework relies on configuration files to

define configuration options. The configuration files are text-based XML files. Multiple configuration files can, and typically do, exist on a single system.

System-wide configuration settings for the .NET Framework are defined in the Machine.config file. The Machine.config file is located in the

%SystemRoot%\Microsoft.NET\Framework\%VersionNumber%\CONFIG\ folder. The default settings that are contained in the Machine.config file can be modified to

affect the behavior of applications that use the .NET Framework on the whole system.

You can change the ASP.NET configuration settings for a single application if you create a Web.config file in the root folder of the application. When you do this, the

settings in the Web.config file override the settings in the Machine.config file.

When you extend a Web application by using Central Administration, SharePoint 2010 Products automatically create a Web.config file for the Web application.

The Web server and application server snapshot presented earlier in this article lists recommendations for configuring Web.config files. These recommendations are

intended to be applied to each Web.config file that is created, including the Web.config file for the Central Administration site.

For more information about ASP.NET configuration files and editing a Web.config file, see ASP.NET Configuration (http://go.microsoft.com/fwlink/p/?LinkID=73257).




SharePoint Security - NETWORKOLOGIST Security Overview.pdf · based on Security Assertion Markup...

Documents

Transcript of SharePoint Security - NETWORKOLOGIST Security Overview.pdf · based on Security Assertion Markup...