Moss2010 Security

Planning, Administration, Configuration, Setup, Migration, and Upgrade
Environment Specification
All computers in the demonstration environment are virtualized running on Windows Server
2008 R2 Hyper-V. The computers are joined to a single Windows domain, “vmlab.local”, running
in Windows Server 2008 Forest and Domain function levels.
Client Computer
o Windows 7 Professional 64 bit
SharePoint Web Front Ends
o Windows 2008 R2 Enterprise 64 bit
o Services
 Web Application Service
o Load balanced with Windows NLB
SharePoint Application Server
o Windows Server 2008 R2 Enterprise 64 bit
o Microsoft SharePoint Server 2010 (RTM)
o Services
 WIF Claims to Windows Token Service
 Managed Metadata Service
 SharePoint Index
 SharePoint Query
 Excel Services
 Visio Graphics Service
 Business Connectivity Services
 Performance Point Services
SQL Services
o Windows Sever 2008 R2 Enterprise 64 bit
o Microsoft SQL Server 2008 R2 Enterprise 64 bit
o Active/Passive Configuration
o SQL Services
 SQL Data Engine
 SQL Analysis Services
 SQL Agent
 SQL Browser
SQL Reporting Server
o Windows Server 2008 R2 Enterprise 64 bit (RTM)
o Microsoft SQL 2008 R2 Enterprise 64 bit (RTM)
o Microsoft SharePoint Server 2010 (RTM)
o Windows NLB Load balanced
o Reporting Service SharePoint integrated mode
o Reporting Services Scaled out mode
Plan authentication methods (SharePoint Foundation 2010)
Supported authentication methods
SharePoint Foundation 2010 supports authentication methods that were included in previous
versions and also introduces token-based authentication that is based on Security Assertion
Markup Language (SAML) as an option. The following table lists the supported authentication
methods.
Method Examples Notes
Windows NTLM
Kerberos
Anonymous
Basic
Digest
Forms-based Lightweight Directory

authentication Access Protocol (LDAP)
Microsoft SQL Server

database or other
database
Custom or third-
party membership and
role providers
SAML token-based Active Directory Supported only with SAML 1.1 that
authentication Federation Services uses the WS-Federation Passive
profile.
(AD FS) 2.0 Client certificate authentication is
possible through integration with AD
Third-party identity FS 2.0.
provider For additional information, see
Configure Client Certificate
Authentication (SharePoint
Lightweight Directory Foundation 2010).
Access Protocol (LDAP)
Authentication modes — classic or claims-based
SharePoint Foundation 2010 introduces claims-based authentication, which is built on Windows

Identity Foundation (WIF). You can use any of the supported authentication methods with
claims-based authentication; or you can use classic-mode authentication, which supports
Windows authentication.
Claims-based authentication is built on 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, WS-Trust, and protocols such as SAML. 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/?LinkId=198942)
Windows Identity Foundation home page

For new implementations of SharePoint Foundation 2010, you should consider claims-based
authentication. By using claims-based authentication, all supported authentication types 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, you can implement 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, user Windows 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 later in this
article.
Implementing Windows authentication
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.
Integrated Windows authentication — Kerberos and NTLM
Both Kerberos protocol and NTLM are Integrated Windows authentication methods, which let
clients seamlessly authenticate without being prompted for credentials. Users who access
SharePoint sites from Windows 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 in
Integrated Windows authentication mode will attempt to authenticate by using the credentials
of the running thread, which is the identity of the process by default.
NTLM is the simplest form of Windows authentication to implement. Simply select this option
when you are creating a Web application.
Kerberos protocol 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 Configure Kerberos authentication (SharePoint Foundation 2010).
Additionally, for claims-authentication Web applications, the Claims to Windows Token Service
must be configured for constrained delegation. Constrained delegation is required to convert
claims to Windows tokens.
Note:
The Claims to Windows Token Service does not support crossing domain boundaries
between forests.
For more information about how to configure this service, see Configure Kerberos
authentication for the claims to Windows token service (SharePoint Foundation 2010).
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
Delegating a client's identity to a back-end Configure Kerberos constrained delegation for

server. computers and service accounts.
Displaying RSS feeds to authenticated
content.
Identity delegation for Microsoft SQL Configure SPNs for SQL Server Reporting
Server Reporting Services (SSRS) Services accounts.
Configure delegation for SQL Server Reporting
Services.
Identity delegation for Excel Services in Configure constrained delegation for servers
SharePoint 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/?LinkID=197178).
Digest authentication and Basic authentication
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 more information about how to configure forms-based authentication, see the following
resources:
TechNet article: Configure forms-based authentication for a claims-based Web

application (SharePoint Foundation 2010).
MSDN blog article: Claims-based authentication "Cheat Sheet" Part 1

MSDN article: Forms Authentication in SharePoint Products and Technologies (Part 2):
Membership and Role Provider Samples
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.
Implementing SAML token-based authentication with SharePoint Foundation 2010 involves the
following processes that require advance planning:
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.
Note:
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 might 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 might 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 might 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, consider setting network
load balancing to single affinity. This isolates the requests for SAML tokens to a single Web
server.
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 more information about how to configure SAML token-based authentication, see the
following resources:
TechNet article: Configure authentication using a SAML security token (SharePoint

Foundation 2010).
MSDN blog article: Claims-based authentication "Cheat Sheet" Part 2

TechNet blog article: Planning Considerations for Claims Based Authentication in
SharePoint 2010 (http://go.microsoft.com/fwlink/?LinkId=198947)
TechNet blog article: Creating both an Identity and Role Claim for a SharePoint 2010
Claims Auth Application (http://go.microsoft.com/fwlink/?LinkId=198948)
TechNet blog article: How to Create Multiple Claims Auth Web Apps in a Single
SharePoint 2010 Farm (http://go.microsoft.com/fwlink/?LinkId=198949)
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. Profile synchronization is not supported with LDAP providers
that are not associated with ADFS 2.0.
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, 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 modes is selected for a Web
application:
Classic mode — Similar to previous versions, only one type of authentication can be
implemented per zone. However, in the current version, only Windows 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 authentication — Multiple authentication providers can be implemented on a

single zone. Multiple zones can be used also.
Implementing more than one type of authentication on a single zone

If you are using claims authentication and implementing more than one type of authentication,
we recommend that you implement multiple types of authentication on the default zone. This
results in the same URL for all users.
When you are implementing multiple types of authentication 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.
Overview of the SharePoint 2010 Security Model

In SharePoint 2010, security has been implemented based upon user, groups and their ACL. Both
Active Directly Users and Active Directory groups are represented by SPUser objects in the
SharePoint object model. The reason for this goes back to the asp.net provider model, since the
actual implementation of the authentication and authorization mechanism is abstracted, it’s
necessary to have an abstract notion of the user that should be granted permissions on a
resource. This is done via the abstract SPPrincipal object and it’s descendants, SPUser and
SPGroup in SharePoint. The benefit of this abstraction is that SPUser object can represent Active
Directory users or groups or custom users authenticated via forms authentication and by
extension the SPGroup object which represents a collection of SPUser object can contain a
heterogeneous collection of SPUser objects, allowing permissions to be defined regardless of
the authentication mechanism.
Now that we’ve covered how users and user groups are represented in the SharePoint security
object model, the next thing to consider is access control. Many of the objects in a SharePoint
application can have access control lists (ACLs) attached to them. An ACL is a binary data
structure that contains details of the SPPrincipal objects that have permissions defined for the
object together with information on the permissions. Each principal/permission mapping is
represented by an SPRoleAssignment object. You’ll notice from the name, that a
SPRoleAssignment doesn’t actually map permissions to principals directly, in fact there’s a
further level of grouping that’s represented by the SPRoleDefinition object. An SPRoleDefintion
object is a collection of bits that represent the status of a number of pre-defined permission
flags. The individual flags are listed in the SPBasePermissions enumeration. While actual
permissions are hardcoded into the SharePoint platform, SPRoleDefinitions are user-defined and
the system-defined permissions are fine-grained enough to allow users to create roles that
encompass practically any security requirement.
SPRoleDefintions are stored at the SPWeb level and are accessible through the Roles property
of the SPWeb object.
The three main objects that can be secured in SharePoint implement the ISecurableObject
interface. These objects are:
· SPWeb, which represents an entire web site. Permissions defined at this level are inherited by
all lists contained within the web unless inheritance has been explicitly turned off. Sub-web’s
also inherit permissions defined here unless inheritance has been turned off.
· SPList, which represents all lists and document libraries within a web site. Permissions defined
at this level automatically apply to all items contained within the list or library unless inheritance
has been explicitly turned off.
· SPListItem, which represents the lowest level of access control available in SharePoint.
Permissions defined at this level apply to a single document or data item.
You’ll no doubt be aware that these are some of the most fundamental objects used when
building applications with SharePoint, so much so that many of the other objects that are
commonly used either inherit from these types or have methods that can return an associated
instance of these types. For example the SPFolder object has a ParentListId property that can be
used to get a reference to the containing list, or the SPFile object has an Item property that
returns an SPListItem object that represents the file. Since it is our aim to create a utility that
will allow declarative configuration of security in SharePoint, it is vital that we can manage ACL’s
on all objects that implement the ISecurableObject interface, particularly those described
above.
So to recap, the key objects and interfaces that will be required for our configuration utility are:
· SPPrincipal – an abstract class that provides the base for SPUser and SPGroup. This class allows
permissions to be set based on group membership or on a per-user basis (subject to the caveat
that an SPUser isn’t necessarily only a single user)
· SPUser – represents a discrete security entity in SharePoint. This can be a user, a local user
group or an Active Directory group.
· SPGroup – represents a group of SPUser objects
· SPRoleAssignment – represents an entry in the ACL for a particular role
· SPRoleDefintion – represents the combination of permissions that should be applied for a

particular user on a particular resource
· SPBasePermission – an enumeration that lists the system level permissions that can be used
when creating SPRoleDefinitions
· ISecurableObject – represents a resource that can be secured via an access control list
SharePoint security UI walkthrough
Let’s have a look at the SharePoint 2010 UI, Go to “Site Settings -> Site Permissions”, you will
able to see all the SharePoint Groups, Domain Groups and SharePoint users. This list also
provides the permission level of the groups and users which will one or move i.e. approve and
Read.
· Grant Permission to provide the access to user and groups. You will two ways to grant the
access:-
o Add users to SharePoint Group (recommended) to add your users/ domain groups to
SharePoint Groups. It automatically cascade the permission to the users.
o Grant Permission Directly gives you granular level permission which specifies the built-in
permissions available in SharePoint Foundation.
List
Permissions
Manage Lists - Create and delete lists, add or remove columns in a list,
and add or remove public views of a list.
Override Check Out - Discard or check in a document which is checked

out to another user.
Add Items - Add items to lists and add documents to document

libraries.
Edit Items - Edit items in lists, edit documents in document libraries,

and customize Web Part Pages in document libraries.
Delete Items - Delete items from a list and documents from a

document library.
View Items - View items in lists and documents in document libraries.
Approve Items - Approve a minor version of a list item or document.
Open Items - View the source of documents with server-side file

handlers.
View Versions - View past versions of a list item or document.
Delete Versions - Delete past versions of a list item or document.
Create Alerts - Create alerts.
View Application Pages - View forms, views, and application pages.

Enumerate lists.
Site
Permissions
Manage Permissions - Create and change permission levels on the Web

site and assign permissions to users and groups.
View Web Analytics Data - View reports on Web site usage.
Create Subsites - Create subsites such as team sites, Meeting

Workspace sites, and Document Workspace sites.
Manage Web Site - Grants the ability to perform all administration

tasks for the Web site as well as manage content.
Add and Customize Pages - Add, change, or delete HTML pages or Web
Part Pages, and edit the Web site using a Microsoft SharePoint
Foundation-compatible editor.
Apply Themes and Borders - Apply a theme or borders to the entire

Web site.
Apply Style Sheets - Apply a style sheet (.CSS file) to the Web site.
Create Groups - Create a group of users that can be used anywhere

within the site collection.
Browse Directories - Enumerate files and folders in a Web site using

SharePoint Designer and Web DAV interfaces.
Use Self-Service Site Creation - Create a Web site using Self-Service Site
Creation.
View Pages - View pages in a Web site.
Enumerate Permissions - Enumerate permissions on the Web site, list,

folder, document, or list item.
Browse User Information - View information about users of the Web

site.
Manage Alerts - Manage alerts for all users of the Web site.
Use Remote Interfaces - Use SOAP, Web DAV, the Client Object Model
or SharePoint Designer interfaces to access the Web site.
Use Client Integration Features - Use features which launch client

applications. Without this permission, users will have to work on
documents locally and upload their changes.
Open - Allows users to open a Web site, list, or folder in order to access
items inside that container.
Edit Personal User Information - Allows a user to change his or her own
user information, such as adding a picture.
Personal
Permissions
Manage Personal Views - Create, change, and delete personal views of

lists.
Add/Remove Personal Web Parts - Add or remove personal Web Parts

on a Web Part Page.
Update Personal Web Parts - Update Web Parts to display personalized

information.
· Create Group is to create more SharePoint Group.
· Edit User Permissions option is to change the permission of users and group in SharePoint.
· Remove User Permissions to remove all the permission from SPUser (Domain group,
SharePoint Group and users) from SharePoint site.
· Check Permissions to check user/group list, site and personal permissions.
· Permission level to role to describe to access of the user all over the site.
· Site Collection Administrators provides you the list of administrator of the site. If you have
implemented the Break Role Inheritance or unique permission on SPWeb, SPList and SPListItem,
then there will be a notification message i.e. “Site content on this site has unique permissions
which are not controlled from this page. And A link to the uniquely secured content”.
The following diagram shows an object hierarchy for a document library, in which all objects but
one inherits their scope from their parents. Each numbered gold hexagon represents a
permissions scope. All child objects within a container inherit from that parent scope unless they
have their own unique permissions scope.
If you have a sub-site and you go to Site Actions -> Site Permissions, you will be able to see the
parent users and groups with the notification “This Web site inherits permissions from its
parent. (Parent Website Name).
Implementation through SharePoint Object Model
Obviously, it is the SiteCollection which is the eventual security boundary. All SPWeb inherit the
users from SiteCollection, unless of course such inheritance has been broken. Similarly, there
are two properties representing groups, which are Groups and SiteGroups. You can probably
guess what these are: the groups are also inherited from parent to SPWeb. As before, both
Groups and SiteGroups represent collections of the SPGroup object.
Finally, there is also a property called Roles. This is a collection of type SPRole. However, as
mentioned earlier, that SPRole has been deprecated since SharePoint 2007. To replace these,
two new objects have been introduced, namely SPRoleDefinition and SPRoleAssignment, which
can be seen in the class diagram in Figure
· Get the SharePoint Groups from the SharePoint site
string url = http://URL:3500;
using (SPSite site = new SPSite(url)){
using (SPWeb web = site.OpenWeb(url.Replace(site.Url, string.Empty)))

{
foreach (SPGroup group in web.Groups)
Console.WriteLine(“Group Name :- ” +group.Name + ” Group Owner :- “+ group.Owner );
}
}
· Get the SharePoint Users from the SharePoint site

string url = “http://url:3500″;
using (SPSite site = new SPSite(url))

{

{
foreach (SPUser user in web.Users)
Console.WriteLine(“User Name :- ” + user.Name + ” User Login :- “+ user.LoginName );
· Get the All SharePoint Users from the SharePoint site it provides all the SPUsers(excluding
SharePoint Group) and Domain Groups

{
foreach (SPUser user in web.AllUsers)
Console.WriteLine(“User Name :- ” + user.Name + ” User Login :- “+ user.LoginName );

}
· Get the all the RoleAssignment in the SharePoint

SPRoleAssignmentCollection roleassigments = web.RoleAssignments;
foreach (SPRoleAssignment roleAssign in roleassigments)
Console.WriteLine(“RoleAssignment Name :- ” + roleAssign.Member + ” RoleAssignment Parent

:- ” + roleAssign.Parent);
· Get the all the RoleDefinition and its Base Permission in the SharePoint site
SPRoleDefinitionCollection roleDefinitions = web.RoleDefinitions;

foreach (SPRoleDefinition roleDef in roleDefinitions)
Console.WriteLine(“RoleDefinition Name :- ” + roleDef.Name + “Base Permission :- ” +

roleDef.BasePermissions);
· How to create a new RoleDefinition in the SharePoint site

SPRoleDefinition customPermissionLevel = new SPRoleDefinition();
customPermissionLevel.Name = “Manager”;
customPermissionLevel.Description = “Can view only view pages, list items, and documents.”;
customPermissionLevel.BasePermissions |= SPBasePermissions.ViewListItems
| SPBasePermissions.OpenItems
| SPBasePermissions.ViewVersions
| SPBasePermissions.ViewFormPages;
web.AllowUnsafeUpdates = true;
web.RoleDefinitions.Add(customPermissionLevel);
web.Update();
· How to add a new RoleAssignment to user or group in the SharePoint site

SPRoleDefinition customRoleDefinition = web.RoleDefinitions["Managers"];
SPUser user = web.Users["ASIAPACIFIC\madanna"];
SPRoleAssignment assignment = web.RoleAssignments.GetAssignmentByPrincipal(user);

assignment.RoleDefinitionBindings.Add(customRoleDefinition);
web.AllowUnsafeUpdates = true;
assignment.Update();
web.Update();
This section provides helpful conceptual and practical information related to general security
and claims-based identity model for Microsoft SharePoint Foundation 2010 and Microsoft
SharePoint Server 2010, for both new and veteran programmers.
The claims-based identity model for Microsoft SharePoint Foundation 2010 and Microsoft
SharePoint Server 2010 is built upon Windows Identity Foundation (WIF). Features of claims-
based identity include:
Authentication across users of Windows-based systems and systems that are not
Windows-based.
Multiple authentication types.
Stronger real-time authentication.
A wider set of principal types.
Delegation of user identity between applications.
When you build claims-aware applications, the user presents an identity to your application as a
set of claims. One claim could be the user’s name, another might be an e-mail address. The idea
is that an external identity system is configured to give your application all the information that
it needs about the user with each request, along with cryptographic assurance that the identity
data that your application receives comes from a trusted source. Under this model, single sign-
on is much easier to achieve.
Authorization, Users, and Groups

In Microsoft SharePoint Foundation, access to Web sites, lists, folders, and list items is
controlled through a role-based membership system by which users are assigned to roles that
authorize their access to SharePoint Foundation objects.
To give a user access to an object, you can add the user to a group that already has permissions
on the object, or you can create a role assignment object, set the user for the role assignment,
optionally bind the role assignment to the appropriate role definition with base permissions,
and then add the assignment to the collection of role assignments for the list item, folder, list, or
Web site. If you do not bind the role assignment to a role definition when assigning a user to a
role, the user has no permission.
Following are ways that SharePoint Foundation provides to control access to its objects:
Objects can use the same permissions as the parent Web site, list, or folder (inheriting
both the roles and users available on the parent object), or they can use unique
permissions.
Sites, lists, folders, and items each provide role assignment collections, enabling fine
management of user access to objects.
Groups consist of users and may or may not be assigned to roles. SharePoint Foundation
includes the following three groups by default:
owners (administrator)
members (contributor)
visitors (reader)
When you create a Web site with unique permissions through the user interface, you are
directed to a page where you can assign users to these groups as part of provisioning the site.
Anonymous access allows users to contribute anonymously to lists and surveys, or to

view pages anonymously. You can also grant access to "all authenticated users" to allow
all members of your domain to access a Web site without having to enable anonymous
access.
Site creation rights (CreateSSCSite and ManageSubwebs) control whether users can
create top-level Web sites, subsites, or workspaces.
Users become members of a SharePoint object indirectly through a group that has a role
assignment, or directly through a role assignment. Users also can be members of a Microsoft
Windows NT Domain Group that is added to a group or to a role. A role definition associates a
user or group with a single right or set of rights corresponding to values of the
Microsoft.SharePoint.SPBasePermissions enumeration. Each user or group has a unique
member ID.
You can use the object model to create or modify role assignments and definitions differently
than you can through the functionality of the addrole.aspx file and the editrole.aspx file. Unlike
these pages presented in the user interface, the object model does not enforce rights
dependency, so you can create a role definition with an arbitrary combination of rights.
However, plan carefully when using the object model to customize role definitions and
permissions, because a poorly conceived role definition and inappropriately assigned rights can
lead to an unpleasant user experience.
For more information about SharePoint Foundation rights, see SPBasePermissions.
Security Policy
A security policy provides a means to enforce uniform security throughout all site collections
within a Web application (virtual server). Through policy, you can assign a role, or collection of
rights, to individual SharePoint Foundation users, and to domain groups using Windows
authentication or pluggable authentication systems, but not to SharePoint groups. Each policy
entry specifies rights for a user or group in the Web application.
Policy is set at the logical Web application level or at the zone level. A user can have, for
example, different policies on http://Server and http://Server.extranet.microsoft.com, even if
the two Web applications have the same content.
Rights can be granted or denied through policy. Granting a right gives that right to the user or
group on all secured objects within the Web application, regardless of local permissions on the
object. Denying a right is given a higher priority than granting the right, actively blocking that
right for the user or group on all secured objects within the Web application. Denying all for a
user prevents that user from accessing any content, even if the user has explicit permissions on
specific content: policy overrides site-level permissions.
In policy roles, the users and groups are identified by both their security identifier (SID) and their
login or user name. Applying a policy role is similar to managing permissions for a Web site, list,
folder, or document: You add users or groups and assign them to one or more role definitions.
Each Web application has its own policy roles. Another difference between policy roles and
managing permissions is that central administrators can deny a right to a user throughout a Web
application.
Claims-based authentication enables systems and applications to authenticate a user without

requiring the user to disclose more personal information (such as social security number and
date of birth) than necessary. An example of claims-based authentication is someone claiming
to be over 18 years old or someone claiming to be in a company's marketing group. An external
system (relying party) needs only to trust the authentication authority that can validate those
claims to allow the user to be authenticated for specific functions.
Claims
The clearest way to think about claims is as a set of information about some subject. This
subject is most often a person, but it might also be an application, a computer, or something
else. When an identity is transmitted on the network, it is represented by some kind of token
(also known as a security token).
A claim is a piece of information about a subject that a claims provider asserts about that
subject. It is a statement about a subject (for example, a name) that is made by a subject about
itself or another subject. You can think of a claim as a bit of identity information, such as e-mail
address, name, age, or membership in the sales role. It is a unique identifier that represents a
specific user, application, computer, or other entity. It enables that entity to gain access to
multiple resources, such as applications and network resources, without entering credentials
multiple times. It also enables resources to validate requests from an entity.The more claims
that an application receives, the more you know about your user.
A claim is given one or more values and then packaged in security tokens that are issued by a
security token service (STS).
The word claim is used, instead of the word attributes that is more commonly used in the
enterprise directory world, because of the delivery method. In this model, your application does
not look up user attributes in a directory. Instead, the user delivers claims to your application.
Each claim is made by an issuer, and you trust the claim only as much as you trust the issuer. For
example, you trust a claim made by your company's domain controller more than a claim made
by the user. The claims API has an issuer property that enables you to find out who issued the
claim.
Tokens
A token is a set of bytes that expresses information about an identity. This information consists
of one or more claims, each of which contains some information about the subject to which this
token applies. The claims in a token commonly contain information such as the name of the user
who presents it. They can also contain many sorts of other information—claims are not limited
to, and do not even need to include, a subject's name. And, as the word claims suggests, an
application that receives a token does not automatically accept the information that it contains.
Instead, a received token is usually validated in some way before an application uses any claims
that it contains.
The key concept is that a claim is not just a unique identifier that identifies the resource,
application, or user. It is a set of claims (that is, values) that is used to describe the resource,
application, or user. The claims are also used to authorize access.
SharePoint 2010 offers permissions to manage its resources using different permission levels. It
provides more granular control on permissions starting from the entire farm to item level
security, as continued from SharePoint 2007. The permissions can be defined for users and
groups using the default permission levels available out-of-the-box or you can define custom
permission levels. The permissions for users and groups can be assigned from Active Directory
repository or external stores like SQL or other custom authentication providers.
Depending on the object level in the SharePoint hierarchy, permissions can be assigned by using
the default SharePoint classifications like Farm Administrators, Site Collection Administrators,
Site Owners, Site Members, Site Visitors, etc., which have pre-defined permissions configured in
them. SharePoint administrators can also manage SharePoint security by creating custom
permission levels, apart from using the SharePoint defaults.
With the Permissions Management in SharePoint 2010 more flexible, SharePoint administrators
/ owners / users can modify permissions of SharePoint objects at ease. Proper documentation of
the existing permissions setting and any change to permissions facilitates effective permission
management and is necessary for post-migration of SharePoint contents.
Create a Web application that uses Windows-claims authentication (SharePoint Server 2010)
Create a Web application that uses Windows-claims authentication (SharePoint Server
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)
Before you perform this procedure, confirm that:
Your system is running Microsoft SharePoint Server 2010.
You have your logical architecture design in place. For more information, see Logical
architecture components (SharePoint Server 2010).
You have planned authentication for your Web application. For more information, see
Plan authentication methods (SharePoint Server 2010), Configure Kerberos
authentication (SharePoint Server 2010) and Choose security groups (SharePoint Server
2010).
You have selected the service applications that you want to use for your Web
application. For more information, see Service application and service management
(SharePoint Server 2010).
If you use Secure Sockets Layer (SSL), you must associate the SSL certificate with the
Web application's IIS Web site after the IIS Web site has been created. For more
information about setting up SSL, see How to Setup SSL on IIS 7.0
(http://go.microsoft.com/fwlink/?LinkId=187887).
You have read about alternate access mappings.
If you have User Account Control (UAC) turned on in Windows, and you use Windows
PowerShell 2.0 to create a Web application, you must right-click the SharePoint 2010
Management Shell and select Run as administrator.
You can create a Web application by using the SharePoint Central Administration Web site or
Windows PowerShell. You typically use Central Administration to create a Web application. If
you want to automate the task of creating a Web application, which is common in enterprises,
use Windows PowerShell. After the procedure is complete, you can create one or several site
collections on the Web application that you have created.
To create a Web application with Windows-claims authentication by using Central
Administration
1. Verify that you have the following administrative credentials:
To create a Web application, you must be a member of the Farm Administrators

SharePoint group and a member of the local Administrators group on the
computer running Central Administration.
2. On the Central Administration Home page, in the Application Management section,

click Manage web applications.
3. On the ribbon, click New.
4. On the Create New Web Application page, in the Authentication section, click Claims
Based Authentication.
5. In the IIS Web Site section, you can configure the settings for your new Web application
by selecting one of the following two options:
Click Use an existing web site, and then select the Web site on which to install
your new Web application.
Click Create a new IIS web site, and then type the name of the Web site in the
Name box.
6. In the IIS Web Site section, in the Port box, type the port number you want to use to
access the Web application. If you are creating a new Web site, this field is populated
with a random port number. If you are using an existing Web site, this field is populated
with the current port number.
Note:
The default port number for HTTP access is 80, and the default port number for HTTPS
access is 443. If you want users to access the Web application without typing in a port
number, they should use the appropriate default port number.
7. Optional: In the IIS Web Site section, in the Host Header box, type the host name (for
example, www.contoso.com) you want to use to access the Web application.
Note:
In general, this field is not set unless you want to configure two or more IIS Web sites that
share the same port number on the same server, and DNS has been configured to route
requests to the same server.
8. In the IIS Web Site section, in the Path box, type the path to the IIS Web site home
directory on the server. If you are creating a new Web site, this field is populated with a
suggested path. If you are using an existing Web site, this field is populated with the
current path of that Web site.
9. In the Security Configuration section, choose whether or not to use allow anonymous
access and whether or not to use Secure Sockets Layer (SSL).
a. Under Allow Anonymous, click Yes or No. If you choose to allow anonymous access, this
enables anonymous access to the Web site by using the computer-specific anonymous access
account (that is, IIS_IUSRS).
Note:
If you want users to be able to access any site content anonymously, you must enable
anonymous access for the entire Web application zone before you enable anonymous access
at the SharePoint site level; later, site owners can configure how anonymous access is used
within their sites. If you do not enable anonymous access at the Web application level, you
cannot enable anonymous access later, at the site level. For more information, see Choose
security groups (SharePoint Server 2010).
b. Under Use Secure Sockets Layer (SSL), click Yes or No. If you choose to enable SSL for
the Web site, you must configure SSL by requesting and installing an SSL certificate. For more
information about setting up SSL, see How to Setup SSL on IIS 7.0
10. In the Claims Authentication Types section, select the authentication that you want to
use for the Web application.
. If you want to enable Windows authentication, select Enable Windows Authentication

and, in the drop-down menu, select Negotiate (Kerberos) or NTLM. For more information, see
Configure Kerberos authentication (SharePoint Server 2010).
If you do not want to use Integrated Windows authentication, clear Integrated Windows
authentication.
If you want users' credentials to be sent over a network in a nonencrypted form, select Basic
authentication (password is sent in clear text).
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 which 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.
a. If you want to enable forms-based authentication, select Enable Forms Based

Authentication (FBA), and then enter the membership provider name and the role manager
name in the boxes.
For more information, see Configure forms-based authentication for a claims-based Web
application (SharePoint Server 2010).
Note:
If you select this option, ensure that SSL is enabled; otherwise, the credentials can be
intercepted by a malicious user.
b. If you have set up Trusted Identity Provider authentication in Windows PowerShell, the
Trusted Identity provider check box is selected.
For more information, see Configure authentication using a SAML security token (SharePoint
Server 2010).
You can use one or more claims authentication types. For more information, see Plan
authentication methods (SharePoint Server 2010).
11. In the Sign In Page URL section, choose one of the following options to sign into
SharePoint Server 2010:
Select Default Sign In Page URL if you want users to be redirected to a default
sign-in Web site for claims-based authentication.
Select Custom Sign In page URL and then type the sign-in URL if you want users
to be redirected to a customized sign-in Web site for claims-based
authentication.
12. In the Public URL section, type the URL for the domain name for all sites that users will
access in this Web application. This URL will be used as the base URL in links shown on
pages within the Web application. The default URL is the current server name and port,
and is automatically updated to reflect the current SSL, host header, and port number
settings on the page. If you are deploying SharePoint Server 2010 behind a load balancer
or proxy server, then this URL may need to be different than the SSL, host header, and
port settings on this page.
The Zone value is automatically set to Default for a new Web application.
Note:
You can change the zone when you extend a Web application. For more information, see
Extend a Web application (SharePoint Server 2010).
13. In the Application Pool section, do one of the following:
Click Use existing application pool, and then select the application pool you
want to use from the drop-down menu.
Click Create a new application pool, and then type the name of the new
application pool or keep the default name.
For more information, see Logical architecture components (SharePoint Server 2010).
14. Under Select a security account for this application pool, do one of the following:
Click Predefined to use a predefined security account, and then select the
security account from the drop-down menu.
Click Configurable to specify a new security account to be used for an existing

application pool.
Note:
You can create a new account by clicking the Register new managed account link.
15. In the Database Name and Authentication section, choose the database server,
database name, and authentication method for your new Web application as described
in the following table.
Item Action
Database Server Type the name of the database server and Microsoft SQL Server instance
you want to use in the format <SERVERNAME\instance>. You can also
use the default entry.
Database Name Type the name of the database, or use the default entry.
Database Select the database authentication to use by doing one of the following:
Authentication
If you want to use Windows authentication, leave this
option selected. We recommend this option because Windows
authentication automatically encrypts the password when it
connects to SQL Server.
If you want to use SQL authentication, click SQL

authentication. In the Account box, type the name of the account
you want the Web application to use to authenticate to the SQL
Server database, and then type the password in the Password box.
Note:
SQL authentication sends the SQL authentication password to the

SQL Server unencrypted. We recommend that you only use SQL
authentication if you force protocol encryption to the SQL Server of
encrypt your network traffic by using IPsec.
16. If you use database mirroring, in the Failover Server section, in the Failover Database
Server box, type the name of a specific failover database server that you want to
associate with a content database.
17. In the Service Application Connections section, select the service application
connections that will be available to the Web application. In the drop-down menu, click
default or custom. You use the custom option to choose the services application
connections that you want to use for the Web application.
18. In the Customer Experience Improvement Program section, click Yes or No.
19. Click OK to create the new Web application.
To create a Web application that uses Windows-claims authentication by using Windows

PowerShell
1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. You
also need to be a member of the local Administrators group on the computer running
Windows PowerShell. In addition, some procedures require membership in the SQL
Server fixed server roles dbcreator and securityadmin.
2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2010 Products.
4. Click SharePoint 2010 Management Shell.

5. To create a Windows-claims authentication provider, at the Windows PowerShell
command prompt, type the following command:
$ap = New-SPAuthenticationProvider
To create a Web application that uses Windows-claims authentication, at the Windows
PowerShell command prompt, type the following command:
$wa = New-SPWebApplication -Name <ClaimsWindowsWebApplication> -

ApplicationPool <ClaimsApplicationPool> -ApplicationPoolAccount
<ClaimsApplicationPoolAccount> -URL <URL> -Port <Port> -AuthenticationProvider $ap
Note:
We recommend that the application pool account is a managed account on the server farm.
Where:
<Name> is the name of the new Web application that uses Windows claims
authentication.
<ApplicationPool> is the name of the application pool.
<ApplicationPoolAccount> is the user account that this application pool will run
as.
<URL> is the public URL for the Web application.
<Port> is the port on which the Web application will be created in IIS.
Example
$ap = New-SPAuthenticationProvider
$wa = New-SPWebApplication -Name "Contoso Internet Site" -ApplicationPool
"ContosoAppPool" -ApplicationPoolAccount (Get-SPManagedAccount "DOMAIN\jdoe") -URL
"http://www.contoso.com" -Port 80 -AuthenticationProvider $ap
Security planning for sites and content (SharePoint Foundation 2010)
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.
Plan site permissions (SharePoint Foundation 2010)
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 — unique permissions 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 the best 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 within a 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.
Unique or inherited
Securable object Description 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 Inherited

information
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.
Unique or inherited
Securable object Description 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 Inherited, with unique

with one or two sensitive permissions at the document
documents level
SiteA/SubsiteB Group shared project information Inherited
SiteA/SubsiteB/ListB Non-sensitive data, but with one Inherited, with unique

or two sensitive items permissions at the item level
SiteA/SubsiteB/LibraryB Non-sensitive documents, but Inherited, with unique

with a special folder containing permissions at the folder and
sensitive documents document level
Determine permission levels and groups (SharePoint Foundation 2010)
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.
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 Default permission

name 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 custom 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
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 they might 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.
Choose security groups (SharePoint Foundation 2010)
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. In addition, 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.
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.
Best practices for using fine-grained permissions

Contents ................................................................................................................. Error! Bookmark not defined.
Overview of using fine-grained permissions ...................................................................................................... 63
SharePoint permission system overview ........................................................................................................... 64
Permission levels.......................................................................................................................................... 64
SharePoint groups........................................................................................................................................ 64
Scope ............................................................................................................................................................ 64
Securable object .......................................................................................................................................... 65
Inheritance ................................................................................................................................................... 65
Limited access .............................................................................................................................................. 65
Binary ACL .................................................................................................................................................... 67

Best practices for avoiding common FGP limit issues ........................................................................................ 67
Too many scopes within a list ...................................................................................................................... 67
Too many members within a scope ............................................................................................................. 68
Very deep scope hierarchy .......................................................................................................................... 68

Recommended solutions for common FGP performance issues ....................................................................... 68
Solution 1: Remove FGP and use security enforcement only at Web level ................................................ 69
Environmental security cleanup ............................................................................................................ 69
Environmental security architecture redesign ...................................................................................... 70
Solution 2: Use fine-grained permissions by hierarchical structure changes .............................................. 71
Environment hierarchy redesign ........................................................................................................... 71
Solution 3: Use fine-grained permissions by scope structure changes (2010 only) .................................... 72
Dynamic security changing code redesign ............................................................................................ 72

Environment architecture example.................................................................................................................... 73
Environment overview ................................................................................................................................. 73
Workflow design .......................................................................................................................................... 74
Fine-grained permission issues .................................................................................................................... 75
Resolution of FGP issues .............................................................................................................................. 76

Summary............................................................................................................................................................. 78
Overview of using fine-grained permissions
This article describes the use of fine-grained permissions (FGP) for SharePoint® 2010 Products
(Microsoft® SharePoint® Server 2010 and Microsoft® SharePoint® Foundation 2010) and
SharePoint® Products and Technologies (Office SharePoint® Server 2007 and Windows
SharePoint® Services version 3.0); performance issues related to FGP; and best practices for
configuring solutions that include FGP.
Note: We recommend that you use FGP for only those business cases for which it is required.
FGP can be expensive in terms of both operational oversight and performance.
You can avoid the use of FGP by doing the following:
Break permission inheritance as infrequently as possible.
Use groups based on directory membership to assign permissions.
Note: We do not recommend that you use SharePoint groups to assign permissions to
sites, because when a SharePoint group is used to assign permissions, a full crawl of the
index occurs. Instead, we recommend Domain groups to be used.
Assign permissions at the highest possible level. As part of this strategy, consider the
following techniques:
o Segregate documents that require fine-grained permissions into document
libraries that are defined to support each group of permissions, and keep the
document libraries in a segregated site collection or site. For additional
information about hierarchical changes, see Solution 2: Use fine-grained
permissions by hierarchical structure changes.
Note: In this document, the terms Web and site equate to the SPWeb object,
and site collections equate to the SPSite object.
o Use different document publish levels to control access. Before a document is
published, the advanced permissions and versioning settings can be set for
users who can only approve items in the document library.
o For non-document libraries (lists), use the ReadSecurity and WriteSecurity
permission levels. When a list is created, the owners can set the Item-level
permissions to either Read access or Create and Edit access.
If you must use fine-grained permissions, consider the following recommended practices:
Ensure that you do not have too many items at the same level of hierarchy in the
document libraries, because the time necessary to process items in the views increases.
Use event handlers to control edit permission. You can have an event handler that
registers an event using the SPEventReceiverType.ItemUpdating and
SPEventReceiverType.ItemUpdated methods, and then use code to control whether the
update should be allowed. This is extremely powerful, because you can make security
decision based on any metadata of a list or item, without affecting the view rendering
performance. For additional information about event handlers, see Resolution of FGP
issues.
Use AddToCurrentScopeOnly method to assign Limited Access membership within a
SharePoint group. The key element in this principle is to redesign the architecture so
that scope membership does not cause ACL recalculation at the parent document library
and Web. For additional information about scope changes, Solution 3: Use fine-grained
permissions by scope structure changes (2010 only).
SharePoint permission system overview
This section describes the SharePoint permissions scope system. For more information about
planning site security, see:
Plan site permissions (SharePoint Server 2010) (http://technet.microsoft.com/en-
us/library/cc262778.aspx)
Plan site permissions (SharePoint Foundation 2010) (http://technet.microsoft.com/en-
us/library/cc287752.aspx)
Plan site security (Office SharePoint Server) (http://technet.microsoft.com/en-
us/library/cc262778(office.12).aspx)
Plan site security (Windows SharePoint Services) http://technet.microsoft.com/en-
us/library/cc287752(office.12).aspx (http://technet.microsoft.com/en-
Permission levels
A permission level contains a set of individual permissions, for example, View Items or Create
Alerts. Permission levels can be predefined or created by the user. The set of permissions can be
modified even within the predefined permission levels.
SharePoint groups
A SharePoint group is a site collection-wide object that can hold other security principals,
including Windows user accounts, non-Windows users (for example, forms-based accounts), and
Active Directory groups.
Scope
A scope is the security boundary for a securable object and any of its children that do not have a
separate security boundary defined. The scope contains an Access Control List (ACL), but unlike
NTFS ACLs, a scope can include SharePoint-specific security principals. The members of an ACL
for a scope can include Windows users, non-Windows users (such as forms-based accounts in
SharePoint Products and Technologies or claims-based accounts in SharePoint 2010 Products),
Active Directory groups, or SharePoint groups.
There is no maximum number of scopes that can be created within a parent scope. However, in
SharePoint Products and Technologies, after 1,000 scopes have been created, a code path that
requires additional Microsoft® SQL Server roundtrips to analyze the scopes before rendering a
view is used. When there 1,000 or fewer scopes, only one roundtrip is required. In SharePoint
2010 Products, the limit of number of scopes returned before switching to a different algorithm
is based on a query throttle limit, with a default value of 5,000; however this value even at
default can be large enough to significantly detract from performance.
In SharePoint 2010 Products, there is a new method called
SPRoleAssignmentCollection.AddToCurrentScopeOnly, by which role assignment can occur. For
additional inforamation about role assignments, see
SPRoleAssignmentCollection.AddToCurrentScopeOnly (http://msdn.microsoft.com/en-
us/library/microsoft.sharepoint.sproleassignmentcollection.addtocurrentscopeonly.aspx).
Securable object
A securable object is an object that can have an ACL assigned to it. In SharePoint Products and
Technologies, the ISecurableObject interface can be used, and in SharePoint 2010 Products, the
SPSecurableObject class should be used. For additional information about securable objects,
see ISecurableObject interface (http://msdn.microsoft.com/en-
us/library/microsoft.sharepoint.isecurableobject.aspx or SPSecurableObject class
(http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurableobject.aspx).
Inheritance
If a securable object does not have a unique scope, the object inherits the scope of its parent.
When an object inherits from its parent, no scope is created for the object. Instead, whenever a
security check is made, it verifies only against the parent object. In the simplest environment,
this scope is at the root Web of the site collection that contains the item. When an item or
container is changed to have unique membership, its inheritance is broken, which means that a
new scope is created for that item and, by default, for any of its children that inherit its
permission scopes.
The following diagram shows an object hierarchy for a document library, in which all objects but
one inherit their scope from their parents. Each numbered gold hexagon represents a
permissions scope. All child objects within a container inherit from that parent scope unless they
have their own unique permissions scope.
Site Collection Object
Web Object 1 Scope 1

User 1 (Contributor)
Web Object 1 User 2 (Reader)
User 3 (Limited Access)
Document Library Object 1 User 4 (Full Control)
User 4 (Limited Access)
Folder Object 1 User 5 (Reader)
AD Group X (Limited Access)
Item 1 Object 1
Item 2 Object 1
Scope 2
AD Group X (Reader)
Item 2 Object 5 User 3 (Contributor)
User 4 (Full Control)
Limited access
When a security principal is added to the scope of an item with unique permissions, the security
principal is immediately added with the Limited Access permission level to each unique
permission scope in the hierarchy above the item until a parent Web with unique permissions is
located.
The reason for adding the user to the scopes with Limited Access is to allow enough access to
the object hierarchically above the uniquely permissioned item so that the Object Model (OM),
master pages, and navigation can render when the user attempts to navigate to the item.
Without the Limited Access permissions at the parent scopes, the user would not be able to
successfully navigate to or open the item that has unique permissions.
The following diagram shows how the hierarchical depth of scopes can affect the amount of
work required to add Limited Access users to parent scopes. The larger the number of unique
scopes above the item, up to and including the uniquely permissioned Web, the larger the
number of additions that must occur. The diagram shows a simplified representation of a
physical structure that has unique scopes defined at every level from the Web down to
individual items. As in the previous diagram, each differently numbered gold hexagon
represents a unique permission scope, and all child objects within that container inherit from
that scope unless they have their own unique permissions scope. The chain of Limited Access
promotion is shown using red arrows.
Scope 1
User 2 (Reader)
+ AD Group X (Limited Access)
+ User 3 (Limited Access)
Web Object 1 + User 4 (Limited Access)
Document Library Object 1 + User 1 (Limited Access)
Folder Object 2
Scope 2
Item 1 Object 3
User 5 (Reader)
Item 2 Object 4
Scope 3
Item 3 Object 5
Scope 4
Scope 5
AD Group X (Reader)
The diagram also includes the set of unique scopes along with the Limited Access membership
additions that must occur on each parent scope, represented by separate boxes within the
scope. No additional programming is required to add unique scopes whenever a security
principal is added to an object scope with unique permissions that is below a Web with unique
permissions.
When a security principal with the Limited Access permission level is added to a parent scope,
no check is made to see whether the security principal is already in the parent scope. A security
principal that already has access to the parent scope is added again with Limited Access
permissions, regardless of its existing permissions on the parent scope.
When a security principal is removed from the Limited Access permission level at a parent
scope, each instance of that security principal within every child scope is removed from the
Limited Access permission level, regardless of whether the security principal has Limited Access
or a wider set of permissions at the child scopes.
Binary ACL
A binary ACL performs rapid comparisons of a user token to determine whether the user should
have access to the object covered by the scope. Whenever the membership of a scope changes,
a binary ACL is calculated, including when a new limited access member is added. The binary
ACL takes more time to calculate as the membership gets larger, and access to the objects will
be blocked until the ACL can be recalculated.
Although there is no explicit size limitation on a binary ACL other than the maximum size of an
image column in SQL Server, some services cannot accept an ACL that is larger than 64KB. In this
case, the number of security principals in the binary ACL may be able to grow very large, but
should be limited due to performance and interoperability considerations. For information
about limitations in image column sizes in SQL Server, see ntext, text, and image (Transact-SQL)
(http://msdn.microsoft.com/en-us/library/ms187993.aspx).
Best practices for avoiding common FGP limit issues
When working fine-grained permissions, it is easy to unintentionally encounter limits that

prevent permissions from resolving.
Too many scopes within a list

There is a built-in limit of 50,000 scopes per list or document library. After 50,000 scopes are
reached addition of new scopes within a given list or document library is prohibited.
In SharePoint 2010 Products, the built-in scope limit can be modified by using a Windows
PowerShell script.
To modify the built-in scope limit to less than 50,000 scopes
1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin
(http://technet.microsoft.com/en-us/library/ff607596.aspx).
5. At the Windows PowerShell command prompt, type the following syntax:
$webapp = Get-SPWebApplication http://serverName

$webapp.MaxUniquePermScopesPerList
$webapp.MaxUniquePermScopesPerList = <Number of scope limit>
Often, however, the effective limit is much smaller than 50,000 if many scopes exist at the same
hierarchical level. This is because display checks for items below that hierarchical level must be
checked against all scopes above them. This limitation can cause the effective number of scopes
allowed in a particular query to be reduced to 1,000 to 2,000.
Best practices:
Only set unique scopes on parent objects such as folders.
Do not create a system with many uniquely permissioned objects below an object that
has many scopes.
If your business requires that you more than 50,000 uniquely permissioned items in a list or
document library, then you must move some items to adifferent list or document library.
Too many members within a scope

As described earlier, a binary ACL is calculated whenever the membership of that scope
changes, including when a new limited access member is added. As the scope membership
number increases, the amount of time it takes to recalculate the binary ACL increases.
However, the problem can be made worse as the additions of users at a child objects unique
scope will cause its parent scopes to be updated with the new Limited Access members, even if
this ultimately results in no change to the parent scope membership. When this occurs, the
binary ACL for the parent scope(s) must also be recalculated, at the expense of more processing
time even if it ultimately results in the same ACL.
Best practice:
Rely on group membership instead of indivudal user membership in the scopes. For example, if
a single group can be used in place of 1,000 users, the scope will be 999 membership entries
smaller for the scope and any of its parent scopes which will be updated with Limited Access
rights for that single group instead of all 1,000 individual users with Limited Access rights. This
additionally helps increase the speed of Limited Access rights push and ACL recalculation at the
parent scope objects.
Important: Using a SharePoint group will cause a full crawl of the index. If possible, use a
domain group.
Very deep scope hierarchy

As indicated earlier, hierarchical depth of scopes can affect the amount of work required to add
Limited Access users to parent scopes. The larger the number of unique scopes above an item,
up to and including the uniquely permissioned Web, the larger the number of additions that
must occur. If a scope hierarchy is very deep, a scope membership change can take a very long
time to occur, as each membership change in the deepest scope item will have to iteratively
update parent scopes with a membership addition for the explicitly added user or group with
Limited Access rights. Additionally this will increase the number of binary ACLs that need to be
recalculated, with an according performance impact.
Best practice:
Reduce the numbers of uniquely permissioned parent objects, thereby reducing the numer of
scopes that need to be updated with Limited Access members whenever any child objects scope
changes.
Recommended solutions for common FGP performance issues

The following solutions can help mitigate performance issues that are specifically related to the
extensive use of fine-grained permissions. Each of the following covers changes to the
environment security, object hierarchy or custom code that is contributing tho the FGP related
performace issue. Each solution will start with the following example environment where a
single Web contains multiple document libraries each with a great many number of uniquely
permissioned child objects.
Web Object 1
Document Library 1 Object 2
Folder Object 3
Item 1 Object 4
Item 2 Object 5
Item 3 Object 6
…
x10,000+ Items
(10,000 max per level)
Solution 1: Remove FGP and use security enforcement only at Web level
To re-architect the environment so it no longer requires fine-grained permissions, an
environment cleanup process can be implemented, and then the number of scoped items can
be adjusted to improve the scalability of the environment over the longer term. The following
recommendations describe the environment cleanup and architectural security changes
required to accomplish this solution.
Environmental security cleanup
When a user is removed from the Web-level scope, the internal OM must remove the user from
every scope below the Web level. However, removing individual users in order to clean up
existing permissions is a time-consuming process. Instead, first remove each of the individual
item-level unique scopes so that the item is set to inherit permissions from its parent object.
This will take comparatively less time than attempting to remove users first, because it has to
act on only a single scope for the item.
Important: If the current Web is not at the root of the site collection, and if it is then set to
inherit its permissions from its parent Web, all the unique scopes under it will be removed, and
all the Limited Access memberships will be overwritten at once using in a single SQL Server
roundtrip.
Web Object 1
Scope 1 SPGroup Object FullGP
Document Library Object 1
+ FullControlGP (Full Control) + User 3
Folder Object 1 + ContributorGP (Contributor) + User 4
Item 1 Object 1 + ReaderGP (Reader)

SPGroup Object ContributeGP
Scope 2 + User 1
Item 2 Object 1 User 5 (Reader) + User 2
+ User 1 (Limited Access) SPGroup Object ReaderGP
+ User 5
Item 3 Object 1
Scope 3 + AD Group X
Scope 4
Scope 5
AD Group X (Reader)
After all item-level scopes have been removed, individual scope memberships at the Web-level
scope can be replaced with one or more group memberships to allow access.
Web Scope Web Scope
14,000+ unique entries (Limited Access) Access Group (Contributor)
Environmental security architecture redesign
After the existing fine-grained permissions and scopes are removed, the long-term architecture
plan should be to maintain a unique scope only at the Web level. The following diagram shows
how this could be structured so that only the Web-level scope remains. The core requirement in
the architecture is to not have too many items at the same level of hierarchy in the document
libraries, because the time necessary to process items in the views increases. As a best practice,
the maximum count of items or folders at any level in the hierarchy should be roughly 2,000
items.
Web Object 1
Document Library 1 Object 1
Folder Object 1
Item 1 Object 1
Item 2 Object 1
Item 3 Object 1
…
x10,000+ Items
(2,000 max per level)
If additional changes are needed to the architecture, consider moving document libraries to
different Webs or site collections. The number of document libraries could also be changed to
more closely support business needs and scaling recommendations that are based on the
taxonomy or audience of the stored content.
Solution 2: Use fine-grained permissions by hierarchical structure changes

To re-architect the environment so it still uses requires fine-grained permissions, but without
causing excessive updates to or or sizing of a single Web scope, consider moving differently
secured document libraries to different Webs.
Environment hierarchy redesign
In the following diagram, the physical architecture has been modified so that each document
library is in a uniquely permissioned Web. Additionally, when item-level FGP must be preserved,
as a best practice the cumulative number of security principals who will be granted access
should be limited to approximately 2,000, although this is not a fixed limit. As such, the effective
membership of each Web, including all Limited Access members users, should be no more than
approximately 2,000 users in order to keep each Web-level scope from growing too large.
Web 1 Object 1 Web 2 Object 7
Document Library 1 Object 2 Document Library 2 Object 8
Folder Object 3 Item 8 Object 9
Item 1 Object 4 Item 9 Object 10

… …
x5,000+ Items x5,000+ Items
(2,000 max per level) (2,000 max per level)
The number of uniquely scoped children is not a significant issue, and can scale to large
numbers, but the number of principles that will be added as limited access up the chain of
scopes to the first uniquely permissioned Web will be a limiting factor.
Lastly, althoiugh not specifically an FGP issue, the folder structure should ensure that no single
hierarchical level of the document library ever exceeds roughly 2,000 items. This limit can help
ensure good performance of views requested by users.
Solution 3: Use fine-grained permissions by scope structure changes (2010 only)

To re-architect the environment so it still uses requires fine-grained permissions, but without
causing excessive updates to or or sizing of a single Web scope, consider using a different
process of securing items. This is mainly applicable if the cause of the excessive number of
unique scopes was through an automated process such as an event handler or workflow that
dynamically modified object permissions. The recommendation in this case is to make a code
change to whatever process was creating the unique security scopes.
Dynamic security changing code redesign
In the following diagram, the scope architecture has been modified so that scope membership
does not cause ACL recalculation at the parent document library and Web. As mentioned earlier,
the effective membership of the Web, including all Limited Access members, should be no more
than approximately 2,000 in order to keep the Web-level scope from growing too large. In this
case, however, by implementing a new SharePoint group to hold all members who should have
Limited Access rights, the scope will not grow too large. When users are added to individual
scopes under the Web level, using the new SharePoint 2010 Products
SPRoleAssignmentCollection.AddToCurrentScopeOnly method, they can also then be added, by
additional code, to the new group that has already been established as having Limited Access
rights at the Web and document library level.
Scope 1
User 2 (Reader)
Web Object 1 User 6 (Contributor)
Document Library Object 1 + AccessGP1 (Limited Access)
Folder Object 2
Scope 2
Item 1 Object 3
User 5 (Reader)
Item 2 Object 4
SPGroup Object AccessGP1
Scope 3
+ User 5
Item 3 Object 5 + User 1
+ User 2
Scope 4
+ AD Group X
User 2 (Contributor) + User 3
+ User 4
Scope 5
AD Group X (Reader)
As mentioned earlier, when item-level FGP must be preserved, as a best practice the cumulative
number of security principals who will be granted access should be limited to approximately
2,000, although this is not a fixed limit. As such, when this number increases, the amount of
time it takes to recalculate the binary ACL increases. If the membership of a scope is changed,
the binary ACL must be recalculated. However, the additions of users at a child item unique
scope will cause parent scopes to be updated with the new Limited Access members, even if this
ultimately results in no change to the parent scope membership. When this occurs, the binary
ACL for the parent scope(s) must also be recalculated.
As in the previous solution, the number of uniquely scoped children is not a significant issue,
and can scale to large numbers, but the number of principles that will be added as limited access
up the chain of scopes to the first uniquely permissioned Web will be a limiting factor.
Environment architecture example
This section describes an example environment that was experiencing significant issues related
to a confluence of fine-grained permissions related issues, and covers the combination of
solutions used to fix the issue.
Environment overview
A knowledge management system based on SharePoint Server 2007 contained two site
collections each with a single Web, Contoso-Draft and Contoso-Production. Contoso-Draft was
where initial drafts were published and where workflows interacted with the documents.
Contoso-Production was the final destination of each approved document, and was the
repository for all approved content.
Documents could be assigned to one of multiple content types that convey the intended
purpose of the document (such as project plans or troubleshooting guides). Additionally the
documents were classified within technology domains (of which there couild be a hundred or
more of increasing specificity), and for various disciplines (such as project management or
operations). The draft publishing site collection contained one document library per discipline,
each with a hierarchy of increasingly specifc folders for each technology domain, and users were
expected to first select into a discipline library and specific technology domain folder when
creating a new document.
The following diagram shows a simplified representation of the original physical structure of the
Web, where each uniquely numbered gold hexagon represents a unique permissions scope, and
all child objects within that container inherit from that same scope unless they have their own
unique permissions scope.
Web Object 1
Document Library 1 Object 2 Document Library 2 Object 7 …

Folder Object 3 Item 8 Object 8 x20

… …
Each combination of content type, technology domain, and discipline could have a non-
overlapping reviewer assigned who was an expert in the technology domain or discipline. The
document library was expected to hold a large number of items while they were undergoing
workflow operations which dynamically changed the assigned reviewer and security of the item.
Once the document was final reviewed, it was then copied to a matching Contoso-Production
based location where it remained unmodified as a published version, and available to all
company employees.
For information about content type and workflow planning, see:
Content type and workflow planning (SharePoint Server 2010)
(http://technet.microsoft.com/en-us/library/cc262735.aspx)
Content types planning (SharePoint Foundation 2010)
(http://technet.microsoft.com/en-us/library/ff607870.aspx)
Plan content types (Office SharePoint Server) (http://technet.microsoft.com/en-
Plan content types (Windows SharePoint Services) (http://technet.microsoft.com/en-
Workflow design
When the workflow process began, the author of a document was blocked from accessing it so
others could review it without the author making changes at the same time. For each
succeeding step of the workflow, the users who previously had access to the document were
denied access and the reviewer(s) for the next stage of the workflow were given access.
The workflow process used both a coded workflow and a custom event handler, which worked
together. When an item was changed in a document library, it was initially acted upon by the
custom event handler which would change permissions and start a new workflow instance. Both
the workflow and the event handler changed the permissions for the specific file being updated,
so that each item was given a unique permissions scope. This permission change meant that
only a single user or small subset of users—that is, the reviewers for that step, had access to the
item at a time. The final step in the workflow, once the document was fully approved, was to
copy it to the equivalent Contoso-Production location as a new published version of the
document, with permissions inheriting from the parent Web.
Fine-grained permission issues

The environment and workflow design tested well during development, but is now experiencing
signficant issues in performance, with users experiencing delays from one to dozens of minutes
before tasks can be accomplished. The testing used only hundreds of test accounts, but once the
design was made available and and then announced as a mandatory knowledge capture tool for
the entire company, usage quickly grew to greater than 15,000 users cumulatively working on
over 30,000 documents. The performance issues reported prevented a large portion of the
company from being able to use the new knowledge management system which was expected
to support upwards of 60,000 users.
When the permission changes happened through the workflow, a permission scope was created
for each individual item. Following the requirements of the Limited Access permission level as
described previously, each unique security principal was added with Limited Access to the
various unique permission scopes in the hierarchy above the item until a uniquely permissioned
Web was located. Therefore, the more unique scopes that were above the uniquely
permissioned item but below the uniquely permissioned Web, the more scopes that the security
principal was added to with Limited Access.
Web Scope
15,000+ unique entries (Limited Access) Item Scope
Item Scope
Item Scope
AD Group X (Reader)
…
x30,000+ Scopes
x15,000+ Unique Users
A key thing to be aware of here is that the problem is not due to the sheer number of unique
scopes that have been created within the site collections root Web, but that the effective
number of unique security principals within that Web-level scope has grown to over 15,000
unique users. Each user added to any unique permissions scope below the Web was also added
to the Web’s own scope, which caused a binary ACL recalculation for each addition.
Due to the large size of the Web-level scope combined with the frequency of binary ACL
recalculation can cause blocking in several SQL Server stored procedures. Each time an item
with broken inheritance has its membership scope changed, it causes each member of the scope
to be added as a having Limited Access user membership at the Web-level scope. Additionally,
each each time the membership of the Web scope was updated with existing or new members,
including for Limited Access, it caused a recalculation of the Web-level scope binary ACL. Due to
the Web-level scope containing over 15,000 security principals, it took a long time to
recalculate. While it was recalculating, no access was available to that object, and end users
experienced intermittent login difficulties.
Resolution of FGP issues

The previously mentioned soltions were considered as part of the process of mitigating the
experienced FGP related performance issues, with both a short term and long term plan
enacted. The short term decision was to refactor the workflow to no longer set per item FGP,
and the environment structure was left hierarchically the same. The individual FGP scopes were
then removed, initially by attempting to remove each user from the Web scope or item level
scopes, but as the performance was unsatisfactory, a removal process for each item scope was
enacted by having the item inherit permissions from its parent. Additionally, some content
rebalancing was used to prevent too many items from displaying at a specific level of hierarchy.
The event handler was modified to enforce a form or read access for those not currently
assigned as reviewer by preventing modifications to documents or workflows. This approach did
not limit who could view items, because there is no way other than the use of scopes to securely
restrict viewing, but it could be used to prevent modifications to documents or workflows, such
as for example, mistakenly allowing the author to modify the document while it was in a review
cycle. Once individual item security scopes had been removed, and the updated workflow and
event handler were installed users were able to use the environment, minus the individual item
level security enforcement with no further performance issues.
The following diagram shows a simplified representation of the physical structure of the Web
after security scope removal, where each uniquely numbered gold hexagon represents a unique
permissions scope, and all child objects within that container inherit from that same scope
unless they have their own unique permissions scope.
Web Object 1


… …
A planned longer-term solution in SharePoint Products and Technologies would be to separate
content into different Webs, so that FGP could continue to be used, but with overall impact
limited to a much smaller set of changes.
The following diagram shows a simplified representation of the physical structure of the content
after separating to different Webs, where each uniquely numbered gold hexagon represents a
unique permissions scope, and all child objects within that container inherit from that same
scope unless they have their own unique permissions scope.
Web 1 Object 1 Web 2 Object 7


… …
The following diagram shows the logical scope design and highlights the limits of how many
unique security principals could be added to each Web's scope if FGP was reena bled after
moving to different Webs. Note that although a large number of uniquely permissioned items
still would remain, the key issue of excessive numbers of security principals in a scope is solved.
Web Scope
Maximum 2,000 entries (Limited Access) Item Scope
Item Scope
Item Scope
Group X (Reader)
…
x10,000+ Scopes
x2,000 Unique Users
Lastly some consideration was made for when an eventual switch to SharePoint 2010 Products
would bring new capabilities to the workflow design, specifically the ability to dynamically assign
FGP by using the SPRoleAssignmentCollection.AddToCurrentScopeOnly method to assign
membership only to each items individual scope, and then granting a SharePoint group,
containing the membership, Limited Access at the parent Web. This process would enable FGP
to be implemented via the workflow and/or event handler without impacting performance.
Summary
This paper describes best practices on how your organization can use fine-grained permissions
and what potential performance issues can occur. It additionally covers strategies and processes
to mitigate issues if an environment is currently experiencing issues due to improper use or
scale of fine-grained permissions. Lastly, it covers an example environment that was
experiencing issues from improper fine-grained permissions use, and the process used to fix the
issues found.
Custom claims providers for People Picker (SharePoint Foundation 2010)
Published: February 3, 2011
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/?LinkId=207578) and
Creating Custom Claims Providers in SharePoint 2010
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/?LinkID=208326). For additional information about claims-
based authentication, see SharePoint Claims-Based Identity
(http://go.microsoft.com/fwlink/?LinkID=196647) and A Guide to Claims-based Identity and
Access Control (http://go.microsoft.com/fwlink/?LinkID=187911).
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
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
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/?LinkId=210011) class

provides claims information related to the server farm where SharePoint Foundation
2010 is installed.
The SPAllUserClaimProvider (http://go.microsoft.com/fwlink/?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/?LinkID=208325)
Forms-based authentication SPFormsClaimProvider

Security Assertion Markup SPTrustedClaimProvider

Language (SAML) token-based (http://go.microsoft.com/fwlink/?LinkId=210014)
authentication
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-
SPClaimProviderWindows PowerShell cmdlet.
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 2010 solution will use SAML token-based authentication, you should plan to
create a custom claims provider to implement custom search and name resolution.
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/?LinkId=207595).
For more information about zones and authentication, see Plan authentication methods
For information about how to write a custom claims provider, see Creating Custom Claims
Providers in SharePoint 2010 (http://go.microsoft.com/fwlink/?LinkID=211324) and Claims
Walkthrough: Writing Claims Providers for SharePoint 2010
(http://go.microsoft.com/fwlink/?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/?LinkId=207591).
About custom claims providers
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
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/?LinkId=207588) and Claims Walkthrough: Writing
Claims Providers for SharePoint 2010 (http://go.microsoft.com/fwlink/?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
Deploying and configuring custom claims providers

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/?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
For example, consider a scenario where there are two Web applications: The first Web
application, PartnerWeb, has two zones — one intranet that uses Windows claims-based
authentication and one extranet that uses forms-based authentication — and is used for
collaboration among employees and partners. The second Web application, 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
You can also override the settings of the IsEnabled and IsUsedByDefault properties by using the
Set-SPClaimProviderWindows 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.
Using custom claims on more than one farm
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).
Considerations for custom claims providers

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
Security planning for sites and content (SharePoint Foundation 2010)

Published: May 12, 2010
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.
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 Enable the following services:

in the Services
MMC snap-in 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 TCP 80, TCP 443 (SSL)

protocols
File and Printer Sharing service —either of the following, used by
search roles:
Direct-hosted SMB (TCP/UDP 445) — this is the

recommended port
NetBIOS 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 Server
computer (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 for
outbound 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 If log files are relocated, ensure that the log file locations are updated to
logging match. Update directory access control lists (ACLs) also.
Code access Ensure that you have a minimal set of code access security permissions
security 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
Ports Block 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 (http://go.microsoft.com/fwlink/?LinkId=186828).
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- Named pipes can use NetBT instead of direct-
hosted SMB hosted SMB. However, NetBT is not considered
Disable NetBT as secure as direct-hosted SMB.
Ports Either of the following: Disable NetBT (ports 137, 138, and 139) if it is
not being used
Direct-hosted SMB
(TCP/UDP 445) —
recommended
NetBT (TCP/UDP
ports 137, 138, 139)
For more information about how to disable NetBT, see the Microsoft Knowledge Base article
204279, Direct hosting of SMB over TCP/IP (http://go.microsoft.com/fwlink/?LinkId=76143).
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/?LinkID=73257).
Plan sandboxed solutions (SharePoint Foundation 2010)

Updated: February 10, 2011
Sandboxed solutions restrict access to network and local resources to provide greater security
and stability. You can use sandboxed solutions for load balancing solutions, for solutions that
have not been fully tested, and for deploying user solutions in a hosted environment.
Sandboxed solutions run in a separate worker thread so that they cannot access resources that
belong to other solutions, and they have limited access to local and network resources.
When you plan sandboxed solutions, decide first whether to use sandboxed solutions at all. You
should determine whether your primary consideration is performance or security. A farm that
uses sandboxed solutions generates more worker and proxy processes than a farm that does
not use sandboxed solutions. Using sandboxed solutions provides more process isolation, which
enhances the security of your farm.
For more information about sandboxed solutions, see Sandboxed solutions overview
Determine when to use sandboxed solutions
Using sandboxed solutions is appropriate in scenarios where you want to load balance solutions
across multiple servers, or where you want to provide the ability to run code that has not been
fully tested or that your organization does not support. Sandboxed solutions can play a valuable
part of a scaled deployment path for developers in your organization, from their test
environment to a sandboxed solution in the production environment. Sandboxed solutions can
later be changed to full trust status by a farm administrator when the solution is shown to be
safe for full deployment.
It is especially appropriate to use sandboxed solutions in the following scenarios:
When you want to load balance solutions between multiple SharePoint Foundation
servers.
When an organization wants to run code for employees on a production SharePoint

Foundation site, and that code has not been stringently code reviewed and tested.
When an Internet hosting provider wants to let the owners of hosted SharePoint
Foundation sites upload and run custom code.
When you use sandboxed solutions, you must activate the SharePoint 2010 User Code Host
service on each server on which you want to run the sandboxed solutions.
Plan to load balance sandboxed solution code
You can select one of two load balancing schemes for sandboxed solutions. Based on the load
balancing scheme, Microsoft SharePoint Foundation 2010 determines which server to run the
solution on. In local load balancing, the solution runs on the same server that received the
request. If you choose remote load balancing, the server that the solution runs on is selected
based on solution affinity, and the sandboxed solution is run on a server where it is already
loaded and has already been run. This saves time in servicing the request for the solution. In
both cases, each server must be running the SharePoint Foundation Sandboxed Code Service.
Your load balancing choice determines the model that is used by the entire SharePoint
Foundation farm. You cannot use a mixture of local and remote load balancing, but instead you
must choose to implement one or the other. When you are deciding which mode to implement
consider the following:
Local mode requires less administration, but its scalability is limited by the resources of
the local server.
Remote mode is more scalable than local mode, but it requires administrative tasks to
be performed on more servers.
You obtain better performance by using the remote load balancing model in a SharePoint
Foundation farm where there are multiple servers on which to run sandboxed solutions. If you
are using sandboxed solutions as part of a development process, and you want to keep them
restricted to the server from which they are called, use the local mode load balancing.
For more information, see Sandboxed solutions overview (SharePoint Foundation 2010).
Determine where to deploy sandboxed solutions
Sandboxed solutions are deployed at the root of a site collection. Anyone who is a site collection
administrator can deploy a sandboxed solution. When it is deployed in a site collection, the
sandboxed solution can be used anywhere within that site collection.
You can choose to run sandboxed solutions only on certain servers within your SharePoint
Foundation farm or to all servers. To enable sandboxed solutions on a server, you must enable
the SharePoint Foundation Sandboxed Code Service. This service must be enabled on every
server on which you want to run sandboxed solutions.
Determine who can deploy sandboxed solutions
When you plan for the user roles that are involved in deploying sandboxed solutions, you must
determine who will be authorized to deploy the solutions and who will be authorized to
administer the solutions. Members of the site collection administrators group can deploy
sandboxed solutions.
You must be a member of the farm administrators group to perform administrative tasks such as
enabling or disabling the SharePoint Foundation Sandboxed Code Service, blocking or
unblocking a solution, and adjusting or resetting quotas.
Note:
It is not enough to be a site collection owner, to deploy and activate a sandboxed solution
you must be a site collection administrator for the site collection where you are deploying
the sandboxed solution.
Because farm administrators can change sandboxed solutions to fully trusted solutions that can
be deployed anywhere on the farm, you should be careful to limit the membership of the farm
administrators group to appropriate users. The same consideration applies to adding users to
the site collection administrators group if there is any concern over the security of the
sandboxed solutions being deployed.
Determine which site collections will run sandboxed solutions using quotas
Sandboxed solutions can be enabled or disabled on specific site collections by adjusting their
quotas. If you set the quota for sandboxed solutions to 0 on a specific site collection, sandboxed
solutions will not run on that site collection. In this way you can fine tune the use of sandboxed
solutions in your farm.
To plan where to deploy sandboxed solutions you should consider both which servers will run
the SharePoint Foundation Sandboxed Code Service, and which site collections will be able to
run sandboxed solutions. If you enable sandboxed solutions on some site collections you should
disable them on the remaining site collections by setting the quotas on those site collections to
0.
Plan resource usage quotas for sandboxed solutions

Sandboxed solutions are monitored for resource usage based on default resource quotas. If a
sandboxed solution exceeds any of the resource quotas, the solution is disabled for the
remainder of the day or until a farm administrator manually resets the solution. This helps
administrators to know when a particular sandboxed solution is making excessive demands on
shared resources or in some cases where a resource-intensive sandboxed solution requires an
increased quota.
The default quotas are satisfactory for most scenarios; however, you can adjust individual quota
limits to permit higher limits where appropriate.
If you determine that a sandboxed solution is consistently misusing server resources, you can
block that solution until the developer can correct the situation. For more information about
blocking and unblocking sandboxed solutions, see Block or unblock a sandboxed solution
The default values that are assigned to sandboxed solution quotas are listed in the following
table.
Resource Description Units Resources Absolute

per Point Limit
AbnormalProcessTerminationCount Abnormally occurrence 1 1

terminated
process
CPUExecutionTime CPU Execution seconds 3,600 60

Time for site
CriticalExceptionCount Critical events 10 3

Exception
Events
InvocationCount Solution events 100 100

Invocation
Events
PercentProcessorTime Percent CPU percentage 85 100

usage by
solution
ProcessCPUCycles Solution CPU cycles 1 x10^11 1 x10^11

cycles
ProcessHandleCount Windows items 10,000 1,000

handles count
ProcessIOBytes Windows items 0 1 x10^8

handles count
ProcessThreadCount Thread count instances 10,000 200

in overall
process
ProcessVirtualBytes Memory bytes 0 1.0x10^9

consumed
SharePointDatabaseQueryCount Number of instances 20 100

SharePoint
database
queries
SharePointDatabaseQueryTime Elapsed time seconds 120 60

to execute
query
UnhandledExceptionCount Number of instances 50 3

unhandled
exceptions
UnresponsiveProcessCount Number of instances 2 1

unresponsive
processes
Plan sandboxed solutions governance
While you are still planning for sandboxed solutions, you should consider your processes for
governance issues, including the following:
At what point will the farm administrator block or unblock a sandboxed solution?
Identifying the administrative policy for blocking and unblocking sandboxed solutions
will eliminate confusion if there is any doubt about the need to block a solution.
At what point will you transfer a sandboxed solution to the global catalog as a full trust
solution? This decision applies to solution code that is developed by your organization’s
developers. You should establish a policy for determining what level of testing is
required for a sandboxed solution to be considered ready for production use in your
organization.
When you are planning for who can deploy sandboxed solutions, will you choose to add
people to the site collection administrators group or establish a procedure for a limited
number of site collection administrators to deploy sandboxed solutions on behalf of
their users? Depending on the security concerns in your organization, you can decide to
add people directly to the site collection administrators group rather than requiring
them to ask permission to deploy the sandboxed solution.
Plan automatic password change (SharePoint Foundation 2010)

To simplify password management, the automatic password change feature enables you to
update and deploy passwords without having to perform manual password update tasks across
multiple accounts, services, and Web applications. You can configure the automatic password
change feature to determine if a password is about to expire and reset the password using a
long, cryptographically-strong random string. To implement the automatic password change
feature, you have to configure managed accounts.
In this article:
Configuring managed accounts
Resetting passwords automatically on a schedule
Detecting password expiration
Resetting the account password immediately
Synchronizing SharePoint Foundation account passwords with Active Directory Domain

Services
Resetting all passwords immediately

Credential change process
Configuring managed accounts

Microsoft SharePoint Foundation 2010 supports the creation of managed accounts to improve
security and ensure application isolation. Using managed accounts, you can configure the
automatic password change feature to deploy passwords across all services in the farm. You can
configure SharePoint Web applications and services, running on application servers in a
SharePoint farm, to use different domain accounts. You can create multiple accounts in Active
Directory Domain Services (AD DS), and then register each of these accounts in SharePoint
Foundation 2010. You can map managed accounts to various services and Web applications in
the farm.
Resetting passwords automatically on a schedule
Prior to the implementation of the automatic password change feature, updating passwords
required resetting each account password in AD DS and then manually updating account
passwords on all of the services running on all the computers in the farm. To do this, you had to
run the Stsadm command-line tool or use the SharePoint Central Administration Web
application. Using the automatic password change feature, you can now register managed
accounts and enable SharePoint Foundation 2010 to control account passwords. Users have to
be notified about planned password changes and related service interruptions, but the accounts
used by a SharePoint farm, Web applications, and various services can be automatically reset
and deployed within the farm as necessary, based on individually configured password reset
schedules.
Detecting password expiration

IT departments typically impose a policy requiring that all domain account passwords be reset
on a regular basis, for example, every 60 days. SharePoint Foundation 2010 can be configured to
detect imminent password expiration, and send an e-mail notification to a designated
administrator. Even without administrator intervention, SharePoint Foundation 2010 can be
configured to generate and reset passwords automatically. The automatic password reset
schedule is also configurable to ensure that the impact of possible service interruptions during a
password reset will be minimal.
Resetting the account password immediately
You can always override any automatic password reset schedule and force an immediate service
account password reset, using a specific password value. In this scenario, the password for the
service account can also be changed in AD DS by SharePoint Foundation 2010. The new
password is then immediately propagated to other servers in the farm.
Synchronizing SharePoint Foundation account passwords with Active Directory Domain

Services
If AD DS and SharePoint Foundation 2010 account passwords are not synchronized, services in
the SharePoint farm will not start. If an Active Directory administrator changes an Active
Directory account password without coordinating the password change with a SharePoint
administrator, there is a risk of service interruptions. In this scenario, a SharePoint administrator
can immediately reset the password from the Account Management page using the password
value that was changed in AD DS. The password is updated and immediately propagated to the
other servers in the SharePoint farm.
Resetting all passwords immediately

If an administrator suddenly leaves your organization, or if the service account passwords need
to be immediately reset for any other reason, you can quickly create a Windows PowerShell
script that calls the password change cmdlets. You can use the script to generate new random
passwords and deploy the new passwords immediately.
Credential change process
When SharePoint Foundation 2010 changes the credentials for a managed account, the
credential change process will occur on one server in the farm. Each server in the farm will be
notified that the credentials are about to change and servers can perform critical pre-change
actions, if necessary. If the account password has not yet been changed, then SharePoint
Foundation 2010 will attempt to change the password using either a manually entered
password, or a long, cryptographically-strong random string. The complexity settings will be
queried from the appropriate policy (network or local), and the generated password will be
equivalent to the detected settings. SharePoint Foundation 2010 will attempt to commit a
password change. If it is unable to commit the password change, it will retry, using a new
sequence, for a specified number of times. If the account password update process succeeds, it
will proceed to the next dependent service, where it will again attempt to commit a password
change. If it does not ultimately succeed, each dependent service will be notified that they can
resume normal activity. Either success in committing a password change or failure to commit
will result in the generation of an automated password change status notification that will be
sent by e-mail to farm administrators.
Security and permissions (SharePoint Foundation 2010)

Configure custom permissions (SharePoint Foundation 2010)
For more control over the level of access to a site, site collection, or site content, you can define
custom permission levels. For more information, see Determine permission levels and groups
(SharePoint Foundation 2010) and User permissions and permission levels (SharePoint
Foundation 2010).
In this procedure:
Customize an existing permission level
Copy an existing permission level
Create a permission level
Customize an existing permission level

If the custom permission level that you want is nearly identical to an existing default permission
level and you do not need to use the default permission level, you can customize the default
permission level.
To customize an existing permission level

1. Verify that you have one of the following administrative credentials:
You are a member of the Administrators group for the site collection.
You are a member of the Owners group for the site.
You have the Manage Permissions permission.
2. On the Site Settings page, under Users and Permissions, click Site permissions.
3. In the Manage section of the ribbon, click Permission Levels.
4. In the list of permission levels, click the name of the permission level you want to
customize.
5. In the list of permissions, select or clear the check boxes to add permissions to or
remove permissions from the permission level.
6. Click Submit.
Copy an existing permission level

If the custom permission level that you want is similar to an existing default permission level,
and you need to use both the default permission level and your custom permission level, you
can copy the default permission level, and then modify the copy and save it as a new permission
level.
To copy an existing permission level


4. In the list of permission levels, click the name of the permission level you want to copy.
5. At the bottom of the page, click Copy Permission Level.
6. On the Copy Permission Level page, in the Name field, type a name for the new
permission level.
7. In the Description field, type a description for the new permission level.
8. In the list of permissions, select or clear the check boxes to add permissions to or
remove permissions from the permission level.
9. Click Create.
Create a permission level
If there is no permission level similar to the one you need, you can create one.
To create a permission level

4. On the toolbar, click Add a Permission Level.
5. On the Add a Permission Level page, in the Name field, type a name for the new
permission level.
6. In the Description field, type a description of the new permission level.
7. In the list of permissions, select the check boxes to add permissions to the permission
level.
8. Click Create.
Change passwords used for administration accounts (SharePoint Foundation 2010)
Published: July 8, 2010
Certain Microsoft SharePoint Foundation services and features must be associated with a
Windows account in order to run. If the account has a password -- that is, if the account is
anything other than the Local System account, the Local Service account, or the Network Service
account -- then the password in SharePoint Foundation must be updated whenever the
account's password changes.
There are two ways to keep passwords synchronized between Windows and SharePoint
Foundation: automatically and manually. To synchronize passwords automatically you can
register managed accounts and configure SharePoint Foundation to change the managed
accounts' passwords according to a schedule. SharePoint Foundation automatically generates a
new password, updates the password in Active Directory Domain Services (AD DS), and
propagates the changes to other servers in the farm. For more information about managed
accounts, see Plan automatic password change (SharePoint Foundation 2010).
Warning:
Windows Server 2008 R2 includes managed accounts at the operating system level. Do not
use Windows Server 2008 R2 managed accounts. They are not compatible with SharePoint
Foundation managed accounts.
We recommend that you use SharePoint Foundation managed accounts when possible. You can
use managed accounts to control the passwords for the following things:
Central administration
Timer service
Service applications
Application pools
When managed accounts are unsuitable, you must change passwords in SharePoint Foundation
manually when the passwords change in AD DS. Passwords must be changed manually for the
following things:
SQL Server services
The default content access account

The articles in this section contain procedures for changing the passwords for accounts that
SharePoint Foundation uses. In this section:
Configure automatic password change (SharePoint Foundation 2010)

Change passwords for SQL Server services (SharePoint Foundation 2010)
Change the password for the default content access account (SharePoint Foundation
2010)
Configure People Picker (SharePoint Foundation 2010)

Published: February 3, 2011
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 the site collection.
The information in this article applies only to Web applications that use Windows authentication
in either classic mode or claims mode.
The People Picker control is used to find and select users, groups, and claims when a site, list, or
library owner assigns permissions in Microsoft SharePoint Foundation 2010. 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 the
site collection. For more information about the People Picker properties, see Peoplepicker:
Stsadm properties.
Note:
There are no Windows PowerShell commands to configure People Picker.

This article contains information about how to configure People Picker for specific scenarios. For
more information about the People Picker control and how it works, its relationship to
authentication and claim providers, and how to plan for People Picker, see People Picker
overview (SharePoint Foundation 2010).
Before you perform the procedures in this article, you must do the following:
Verify that the account you use to run Stsadm is a member of the local Administrators
group on the server on which SharePoint Foundation 2010 is installed.
Open the command prompt window as an administrator to perform the procedures in

this article.
In the command prompt on the driver where SharePoint Foundation 2010 is installed,
change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web
server extensions\14\Bin.
In this article:
Check the setting value for any property
Clear a property value from People Picker
Set an encryption key for use with a one-way trust
Enable cross-forest or cross-domain queries when using a one-way trust
Restrict People Picker to a certain group in Active Directory
Define the location of administrator accounts
Force People Picker to pick only from users in the site collection
Filter Active Directory accounts by using LDAP queries
Return only non-Active Directory user accounts
Check the setting value for any property
To check the setting for any People Picker property, type the following command:
stsadm.exe -o getproperty -pn <Property Name> -url <Web application URL>
For more information, see Peoplepicker: Stsadm properties (http://technet.microsoft.com/en-

us/library/cc263318(office.12).aspx).
Clear a property value from People Picker

You can remove the setting for a People Picker property by specifying the property name you
want to clear, and using empty quotation marks for the property value.
To remove a property setting from People Picker, type the following command:
stsadm.exe -o setproperty -pn <Property Name> -pv "" -url <Web application URL>
For more information, see Peoplepicker-searchadforests: Stsadm property

(http://technet.microsoft.com/en-us/library/cc263460(office.12).aspx).
Set an encryption key for use with a one-way trust
If the forest or domain on which SharePoint Foundation 2010 is installed has a one-way trust
with another forest or domain, you must first set the credentials for an account that is allowed
to authenticate with the forest or domain to be queried before you can use the Stsadm
peoplepicker-searchadforests property.
Note:
The encryption key must be set on every front-end Web server in the farm on which
SharePoint Foundation 2010 is installed.
To set an encryption key, type the following command:
stsadm.exe -o setapppassword -password <key>
For more information about querying additional forests or domains, see All you want to know
about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ) Part-2
Enable cross-forest or cross-domain queries when using a one-way trust
If the forest or domain on which SharePoint Foundation 2010 is installed has a one-way trust
with another forest or domain, you must specify the credentials to be used to query the forest
or domain, in addition to the names of the forests or domains to be queried. People Picker will
only query the forests or domains that you specify in the peoplepicker-searchadforests
property setting.
To specify the forests or domains to be queried along with the credentials, type the following
command:
stsadm.exe -o setproperty -pn peoplepicker-searchadforests -pv <Valid list of forests or

domains, Login name, Password> -url <Web application URL>
Note:
You do not need to include the encryption key password that you assigned to the account
when you use the peoplepicker-searchadforests property. However, if you have not already
set an encryption key for the account, en error message will be displayed.
The following example configures People Picker for use with a forest named Contoso.com and a
domain named Fabrikam.com, and includes the credentials for each:
STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv

"forest:Contoso.com,Contoso\User1,Password1;
domain:Fabrikam.com,Fabrikam\User2,Password2" -url http://ServerName
For more information, see Peoplepicker-searchadforests: Stsadm property
Restrict People Picker to a certain group in Active Directory
If a Web application is using Windows authentication and the site user directory path is not set,
the People Picker control searches the entire Active Directory to resolve users' names or find
users, instead of searching only users within a particular organizational unit (OU). The Stsadm
setsiteuseraccountdirectorypath operation allows the user's directory path to be set to a
specific OU in the same domain. After the directory path is set to a site collection, the People
Picker control will only search under that particular OU.
To restrict People Picker to a certain OU in Active Directory, type the following command:
stsadm -o setsiteuseraccountdirectorypath -path <Valid OU name> –url <Web application URL>
The following example configures People Picker to only return users and groups in the OU
named "Sales":
stsadm -o setsiteuseraccountdirectorypath -path "OU=Sales,DC=ContosoCorp,DC=local" –url

http://ServerName
Note:
Because this property specifies only one OU at a time, you should only run the Stsadm
setsiteuseraccountdirectorypath operation once per site collection. To set multiple OUs at
one time, use the Stsadm Peoplepicker-serviceaccountdirectorypaths property.
For more information, see Setsiteuseraccountdirectorypath: Stsadm operation
Define the location of administrator accounts

Administrative user accounts are often located in a different OU from regular site users. If you
have used the Stsadm setsiteuseraccountdirectorypath operation to force People Picker to only
return query results from a specific OU, you must also set the Stsadm peoplepicker-
serviceaccountdirectorypaths property so the administrator can manage the site collection.
Note:
Before the peoplepicker-serviceaccountdirectorypaths property will work, the

Setsiteuseraccountdirectorypath operation must be set and contain a value.
To define the location of administrator accounts, type the following command:
Stsadm -o setproperty -pn peoplepicker-serviceaccountdirectorypaths -pv <A list of OU

names> -url <Web application URL>
The following example configures People Picker to allow users that are in the OU "FarmAdmin":
stsadm -o setproperty -pn peoplepicker-serviceaccountdirectorypaths -pv

"OU=FarmAdmin,DC=Contoso,DC=local" -url http://ServerName
For more information, see Peoplepicker-serviceaccountdirectorypaths: Stsadm property
Force People Picker to pick only from users in the site collection
The People Picker control consists of a text box, and two buttons; the Check Names button and
the Browse button. The Check Names button is used to resolve a user name, group name or e-
mail address exactly as it was typed into the text box. The Browse button opens the Select
People and Groups dialog box, which can be used to submit a query for a full or partial string.
The important difference between the two is that the Check Names button only resolves exactly
what is in the text box, whereas the Select People and Groups dialog box searches for the query
string. You can force People Picker to only return users who have permissions in the site
collection by using either the PeoplePicker-Peopleeditoronlyresolvewithinsitecollection
property or the PeoplePicker-Onlysearchwithinsitecollection property. However, the property
you use to configure this restriction will depend on whether you want to set the restriction for
the text box (People editor) and Check Names button, or for the Select People and Groups
dialog box.
To force People Picker to only return users who have permissions in the site collection when the
Check Names button is clicked, type the following command:
stsadm -o setproperty –pn peoplepicker-Peopleeditoronlyresolvewithinsitecollection –pv yes

–url <Web application URL>
To force People Picker to only return users who have permissions in the site collection when the
Select People and Groups dialog box is used, type the following command:
stsadm -o setproperty –pn peoplepicker-onlysearchwithinsitecollection –pv yes –url <Web

application URL>
For more information, see Peoplepicker-onlysearchwithinsitecollection: Stsadm property

(http://technet.microsoft.com/en-us/library/cc261988(office.12).aspx) and Peoplepicker-
peopleeditoronlyresolvewithinsitecollection: Stsadm property (SharePoint Foundation 2010).
Filter Active Directory accounts by using LDAP queries
You can use a Lightweight Directory Access Protocol (LDAP) query to create a custom filter for
displaying query results. For more information about LDAP queries, see LDAP Query Basics
To use a custom LDAP query, type the following command:
Stsadm –o setproperty –pn peoplepicker-searchadcustomfilter -pv <LDAP query filter> -url

<Web application URL>
The following example filters out user accounts that do not have e-mail addresses, or that are
disabled. Because security groups do not always have e-mail addresses associated with them, an
OR statement is used to ensure that security groups are still included in the query results:
stsadm –o setproperty –pn peoplepicker-searchadcustomfilter -pv
"(|(&(mail=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))(objectcategory=group))" -url
http://ServerName
The following example only returns active users, and not groups:
stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv

"(&(objectCategory=person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2)
)" -url http://ServerName
For an explanation of the user account control string used in this query, see Search Filter Syntax
The following example returns a list of Active Directory users with the title "Manager":
stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv "((Title=Manager))" -url

http://ServerName
Important:
Remember that every time you run the setproperty command for a specific property, that
property's current values will be overwritten by the new values you specify. If you need to
filter query results based on multiple criteria, you will need to build a compound LDAP query
that includes all the values for which you want to filter.
For more information, see Peoplepicker-searchadcustomfilter: Stsadm property
Return only non-Active Directory user accounts
If your Web application uses forms-based authentication, you can prevent People Picker from
returning Active Directory accounts in the query results.
To return only non-Active Directory user accounts, type the following command:
stsadm -o setproperty -pn peoplepicker-

nowindowsaccountsfornonwindowsauthenticationmode -pv yes -url <Web application URL>
For more information, see Peoplepicker-

nowindowsaccountsfornonwindowsauthenticationmode: Stsadm property
User permissions and permission levels (SharePoint Foundation 2010)

Updated: January 7, 2011
This article describes the default permission levels as well as the user permissions in Microsoft
SharePoint Foundation 2010.
In this article:
Default permission levels
User permissions
Default permission levels
Permission levels are collections of permissions that allow users to perform a set of related
tasks. SharePoint Foundation 2010 includes five permission levels by default. You can customize
the permissions available in these permission levels (except for the Limited Access and Full
Control permission levels), or you can create customized permission levels that contain only the
permissions you need. For more information about how to customize permission levels, see
Configure custom permissions (SharePoint Foundation 2010).
Note:
Although you cannot directly edit the Limited Access and Full Control permission levels, you
can make individual permissions unavailable for the entire Web application, which removes
those permissions from the Limited Access and Full Control permission levels. For more
information about how to manage permissions for a Web application, see Manage
permissions for a Web application (SharePoint Foundation 2010).
The following table lists the default permission levels for team sites in SharePoint Foundation
2010.
Permission Permissions included by

level Description default
Limited Allows access to shared resources in the Web site View

Access so that the users can access an item within the site. Application Pages
Designed to be combined with fine-grained
permissions to give users access to a specific list,
document library, folder, list item, or document, Browse User
without giving them access to the entire site. Information
Cannot be customized or deleted.
Use Remote
Interfaces
Use Client
Integration
Features
Open
Read View pages, list items and download documents. Limited Access
permissions, plus:
View Items
Open Items
View Versions
Create Alerts
Use Self-
Service Site
Creation
View Pages
Contribute View, add, update, and delete items in the existing Read
lists and document libraries. permissions, plus:
Add Items
Edit Items
Delete Items
Delete
Versions
Browse
Directories
Edit Personal
User Information
Manage
Personal Views
Add/Remove
Personal Web Parts
Update
Personal Web Parts
Design View, add, update, delete, approve, and customize Approve

items or pages in the Web site. permissions, plus:
Manage Lists
Add and
Customize Pages
Apply Themes
and Borders
Apply Style
Sheets
Full Allows full control of the scope. All permissions

Control
User permissions
SharePoint Foundation 2010 includes 33 permissions, which are used in the five default
permission levels. You can change which permissions are included in a particular permission
level (except for the Limited Access and Full Control permission levels), or you can create a new
permission level to contain specific permissions.
Permissions are categorized as list permissions, site permissions, and personal permissions,
depending on the objects to which they can be applied. For example, site permissions apply to a
particular site, list permissions apply only to lists and libraries, and personal permissions apply
only to things such as personal views, private Web Parts, and more. The following tables
describe what each permission is used for, the dependent permissions, and the permission
levels in which it is included.
List permissions
Permission Description Dependent Included in these

permissions permission levels
by default
Manage Lists Create and delete lists, add or View Items, View Design, Full
remove columns in a list, and Pages, Open, Control
add or remove public views of a Manage Personal
list. Views
Override Discard or check in a document View Items, View Design, Full

Check Out that is checked out to another Pages, Open Control
user without saving the current
changes.
Add Items Add items to lists, and add View Items, View Contribute,
documents to document Pages, Open Design, Full
libraries. Control
Edit Items Edit items in lists, edit View Items, View Contribute,
documents in document Pages, Open Design, Full
libraries, and customize Web Control
Part Pages in document
libraries.
Delete Items Delete items from a list, and View Items, View Contribute,
documents from a document Pages, Open Design, Full
library. Control
View Items View items in lists, and View Pages, Open Read, Contribute,
documents in document Design, Full
libraries. Control
Approve Approve minor versions of list Edit Items, View Design, Full
Items items or documents. Items, View Pages, Control
Open
Open Items View the source of documents View Items, View Read, Contribute,
with server-side file handlers. Pages, Open Design, Full
Control
View View past versions of list items View Items, Open Read, Contribute,
Versions or documents. Items, View Pages, Design, Full
Open Control
Delete Delete past versions of list View Items, View Contribute,

Versions items or documents. Versions, View Design, Full
Pages, Open Control
Create Alerts Create e-mail alerts. View Items, View Read, Contribute,
Pages, Open Design, Full
Control
View View forms, views, and Open All

Application application pages. Enumerate
Pages lists.
Site permissions
Included in
these
permission
levels by
Permission Description Dependent permissions default
Manage Create and change View Items, Open Items, Full Control
Permissions permission levels on the View Versions, Browse
Web site and assign Directories, View Pages,
permissions to users and Enumerate Permissions,
groups. Browse User Information,
Open
View Usage View reports on Web site View Pages, Open Full Control
Data usage.
Create Create subsites such as team View Pages, Browse User Full Control
Subsites sites, Meeting Workspace Information, Open
sites, and Document
Workspace sites.
Manage Web Perform all administration View Items, Add and Full Control
Site tasks for the Web site, and Customize Pages, Browse
manage content. Directories, View Pages,
Enumerate Permissions,
Browse User Information,
Open
Add and Add, change, or delete HTML View Items, Browse Design, Full
Customize pages or Web Part pages, Directories, View Pages, Control
Pages and edit the Web site by Open
using a Windows SharePoint
Services-compatible editor.
Apply Themes Apply a theme or borders to View Pages, Open Design, Full
and Borders the entire Web site. Control
Apply Style Apply a style sheet (.css file) View Pages, Open Design, Full
Sheets to the Web site. Control
Create Create a group of users that View Pages, Browse User Full Control
Groups can be used anywhere Information, Open
within the site collection.
Browse Enumerate files and folders View Pages, Open Contribute,

Directories in a Web site by using Design, Full
Microsoft SharePoint Control
Designer 2010 and Web DAV
interfaces.
Use Self- Create a Web site by using View Pages, Browse User Read,
Service Site Self-Service Site Creation. Information, Open Contribute,
Creation Design, Full
Control
View Pages View pages in a Web site. Open Read,

Contribute,
Design, Full
Control
Enumerate Enumerate permissions on Browse Directories, View Full Control

Permissions the Web site, list, folder, Pages, Browse User
document, or list item. Information, Open
Browse User View information about Open All

Information users of the Web site.
Manage Manage alerts for all users of View Items, View Pages, Full Control
Alerts the Web site. Open
Use Remote Use SOAP, Web DAV, or Open All

Interfaces SharePoint Designer 2010
interfaces to access the Web
site.
Use Client Use features that start client Use Remote Interfaces, All
Integration applications. Without this Open
Features permission, users must work
on documents locally and
then upload their changes.
Open Open a Web site, list, or None All

folder to access items inside
that container.
Edit Personal Users can change their own Browse User Information, Contribute,
User user information, such as Open Design, Full
Information adding a picture. Control
Personal permissions
Included in these
Dependent permission levels by
Permission Description permissions default
Manage Personal Create, change, and View Items, View Contribute, Design,
Views delete personal views of Pages, Open Full Control
lists.
Add/Remove Add or remove personal View Items, View Contribute, Design,

Personal Web Web Parts on a Web Part Pages, Open Full Control
Parts page.
Update Personal Update Web Parts to View Items, View Contribute, Design,
Web Parts display personalized Pages. Open Full Control
information.
Business Connectivity Services security overview (SharePoint Foundation 2010)
Updated: September 9, 2010
This article describes the security architecture of the Microsoft Business Connectivity Services
server and client, the supported security environments, the authentication modes available to
connect external content types to external systems, the authorization options available on
stored objects, and the general techniques for configuring Microsoft Business Connectivity
Services security.
In this article:
About this article
Business Connectivity Services security architecture
Business Connectivity Services authentication overview
Business Connectivity Service permissions overview
Securing Business Connectivity Services
About this article
Microsoft Business Connectivity Services include security features for authenticating users to
access external systems and for configuring permissions on data from external systems.
Microsoft Business Connectivity Services are highly flexible and can accommodate a range of
security methods from within supported Microsoft Office 2010 applications and from the Web
browser.
Business Connectivity Services security architecture
This section describes the Microsoft Business Connectivity Services security architecture.
Security Note:
We recommend that you use Secure Sockets Layer (SSL) on all channels between client
computers and front end servers. Also we recommend using Secure Sockets Layer or
Internet Protocol Security (IPSec) between servers running Microsoft SharePoint Foundation
2010 and external systems. An exception is that you cannot use SSL when transmitting
messages to external systems using the SOAP 1.1 protocol or when connecting to a SQL
server database. However, in those cases you can use IPSec to protect the data exchange.
Accessing external data
When a user accesses external data from a Web browser, three systems are involved: the
logged on user’s client computer, the Web server farm, and the external system.
1. From Web browsers, users typically interact with external data in external lists or by
using Web Parts.
2. The BDC Server Runtime on front-end servers uses data from the Business Data
Connectivity service to connect to and execute operations on external systems.
3. The Secure Store Service securely stores credential sets for external systems and
associates those credential sets to individual or group identities.
Important:
The Secure Store Service is not included in SharePoint Foundation 2010. If you need a secure
store in SharePoint Foundation 2010, you must supply a custom secure store provider.
4. The Security Token Service is a Web service that responds to authentication requests by
issuing security tokens made up of identity claims that are based on user account
information.
5. Microsoft Business Connectivity Services can pass credentials to databases and Web
services that are configured to use claims-based authentication. For an overview of
claims-based authentication, see Plan authentication methods (SharePoint Foundation
2010).
Business Connectivity Services authentication overview
Microsoft Business Connectivity Services can be configured to pass authentication requests to

external systems by using the following types of methods:
Credentials These are typically in the form of name/password. Some external systems
may also require additional credentials such as a personal identification number (PIN)
value.
Claims Security Assertion Markup Language (SAML) tickets can be passed to claims-
aware services that supply external data.
Configuring Business Connectivity Services for credentials authentication

Microsoft Business Connectivity Services can use credentials that a user supplies to authenticate
requests for external data. The following methods by which users can supply credentials for
accessing external data are supported:
Windows authentication:
Windows Challenge/Response (NTLM)
Microsoft Negotiate
Authentication other than Windows
Forms-based
Digest
Basic
When configuring Microsoft Business Connectivity Services to pass credentials, the solution
designer adds authentication-mode information to external content types. The authentication
mode gives Microsoft Business Connectivity Services information about how to process an
incoming authentication request from a user and map that request to a set of credentials that
can be passed to the external content system. For example, an authentication mode could
specify that the user’s credentials be passed directly through to the external data system.
Alternatively, it could specify that the user’s credentials should be mapped to an account that is
stored in a Secure Store Service which should then be passed to the external system.
You associate an authentication mode with an external content type in the following ways:
When you create an external content type in Microsoft SharePoint Designer.
If the external system is a Web service, you can use the Microsoft Business Connectivity
Services administration pages to specify the authentication mode.
You can specify the authentication mode by directly editing the .XML file that defines
the external content type.
The following table describes the authentication modes of the Microsoft Business Connectivity
Services:
Authentication
mode Description
PassThrough Passes the credentials of the logged-on user to the external system.
This requires that the user’s credentials are known to the external
system.
Note:
If the Web application is not configured to authenticate with

Windows credentials, the NT Authority/Anonymous Logon
account is passed to the external system rather than the user's
credentials.
This mode is called User’s Identity in the Microsoft Business
Connectivity Services administration pages and in SharePoint
Designer 2010.
RevertToSelf When the user is accessing external data from a Web browser, this
mode ignores the user’s credentials and sends the application pool
identity account under which the BCS runtime is running on the Web
server to the external system. When the user is accessing external
data from an Office client application, this mode is equivalent to
PassThrough mode, because Microsoft Business Connectivity Services
running on the client will be running under the user’s credentials.
This mode is called BDC Identity in the Microsoft Business
Connectivity Services administration pages and in SharePoint
Designer 2010.
Note:
By default, RevertToSelf mode is not enabled. You must use

Windows PowerShell to enable RevertToSelf mode before you
can create or import models that use RevertToSelf. For more
information, see RevertToSelf authentication mode.
RevertToSelf mode is not supported in hosted environments.
WindowsCredentials For external Web services or databases, this mode uses a Secure
Store Service to map the user’s credentials to a set of Windows
credentials on the external system.
This mode is called Impersonate Windows Identity in the Microsoft
Business Connectivity Services administration pages and in
SharePoint Designer 2010.
Credentials For an external Web service, this mode uses a Secure Store Service to
map the user’s credentials to a set of credentials that are supplied by
a source other than Windows and that are used to access external
data. The Web service should use basic or digest authentication
when this mode is used.
Important:
To help preserve security in this mode, we recommend that the

connection between the Microsoft Business Connectivity
Services and the external system should be secured by using
Secure Sockets Layer (SSL) or Internet Protocol Security (IPSec).
This mode is called Impersonate Custom Identity in the Microsoft
Business Connectivity Services administration pages and in Office
SharePoint Designer.
RDBCredentials For an external database, this mode uses a Secure Store Service to
map the user’s credentials to a set of credentials that are supplied by
a source other than Windows. To help preserve security in this mode,
we recommend that the connection between the Microsoft Business
Connectivity Services and the external system should be secured by
using Secure Sockets Layer (SSL) or IPSec.
This mode is called Impersonate Custom Identity in the Microsoft
Business Connectivity Services administration pages and in Office
SharePoint Designer.
DigestCredentials For a WCF Web service, this mode uses a Secure Store Service to map
the user’s credentials to a set of credentials using Digest
authentication.
This mode is called Impersonate Custom Identity – Digest in the
Microsoft Business Connectivity Services administration pages and in
SharePoint Designer 2010.
The following illustration shows the Microsoft Business Connectivity Services authentication
modes when it uses credentials.
In PassThrough (User’s Identity) mode (A) the logged-on user’s credentials are passed
directly to the external system.
In RevertToSelf (BDC Identity) mode (B) the user’s logon credentials are replaced with
the credentials of the process account under which Microsoft Business Connectivity
Services is running, and those credentials are passed to the external system.
Three modes use the Secure Store Service: WindowsCredentials (Impersonate Windows
ID,) RdbCredentials (Impersonate Custom ID,) and Credentials. In those modes, the
user’s credentials are mapped to a set of credentials for the external system and
Microsoft Business Connectivity Services passes those credentials to the external
system. Solution administrators can either map each user’s credentials to a unique
account on the external system or they can map a set of authenticated users to a single
group account.
Configuring Business Connectivity Services for claims-based authentication

Microsoft Business Connectivity Services can provide access to external data based on an
incoming security tokens and it can pass security tokens to external systems. A security token is
made up of a set of identity claims about a user, and the use of security tokens for
authentication is called “claims-based authentication.” SharePoint Foundation includes a
Security Token Service that issues security tokens.
The following illustration shows how the Security Token Service and the Secure Store Service
work together in claims-based authentication:
1. A user tries an operation on an external list that is configured for claims authentication.
2. The client application requests a security token from the Secure Token Service.
3. Based on the requesting user’s identity, the Secure Token Service issues a security token
that contains a set of claims and a target application identifier. The Secure Token Service
returns the security token to the client application.
4. The client passes the security token to the Secure Store Service.
5. The Secure Store Service evaluates the security token and uses the target application
identifier to return a set of credentials that apply to the external system.
6. The client receives the credentials and passes them to the external system so that an
operation (such as retrieving or updating external data) can be performed.
Business Connectivity Service permissions overview
Permissions in Microsoft Business Connectivity Services associate an individual account, group

account, or claim with one or more permission levels on an object in a metadata store. By
correctly setting permissions on objects in Microsoft Business Connectivity Services, you help
enable solutions to securely incorporate external data. When planning a permissions strategy,
we recommend that you give specific permissions to each user or group that needs it, in such a
way that the credentials provide the least privilege needed to perform the needed tasks.
Caution:
Properly setting permissions in Microsoft Business Connectivity Services is one element in an

overall security strategy. Equally important is securing the data in external systems. How you
do this depends on the security model and features of the external system and is beyond the
scope of this article.
Note:
Business Connectivity Services uses the permissions on the metadata objects and the
permissions on the external system to determine authorization rules. For example, a security
trimmer can keep external data from appearing in users' search results. However, if users
somehow discover the URL to the trimmed external data, they can access the external data if
they have the necessary permissions to the metadata object and the external system. The
correct way to prevent users from accessing external data is to set the appropriate
permissions both in Business Connectivity Services and in the external system.
What can permissions be set on?
Each instance of the Business Data Connectivity service (or, in the hosting case, each partition)
contains a metadata store that includes all the models, external systems, external content types,
methods, and method instances that have been defined for that store’s purpose. These objects
exist in a hierarchy as depicted in the following illustration:
Note:
In the previous hierarchy graphic, labels in parentheses are the names of objects as they are
defined in the Microsoft Business Connectivity Services metadata schema. The labels that
are not in parentheses are the names of each object as it appears in the user interface of the
Business Data Connectivity service. For a full discussion of the Microsoft Business
Connectivity Services metadata schema, along with walkthroughs of many development
tasks, see the Microsoft SharePoint 2010 Software Development Kit
(http://go.microsoft.com/fwlink/?LinkId=166117&clcid=0x409 ).
The hierarchy of objects in a metadata store determines which objects can propagate their
permissions to other objects. In the illustration, each object on which permissions can be set,
and optionally propagated, is shown with a solid line; each object that takes its permissions
from its parent object is shown with a dotted line. For example, the illustration shows that an
External System (LobSystem) can be secured by assigning permissions to it, but an Action cannot
be assigned permissions directly. Objects that cannot be assigned permissions take the
permissions of their parent object. For example, an Action takes the permissions of its parent
External Content Type (Entity).
Security Note:
When the permissions on an object in a metadata store are propagated, permission settings
to all children of that item are replaced by the permissions of the propagating object. For
example, if permissions are propagated from an External Content Type, all Methods and
Method Instances of that External Content Type receive the new permissions.
Four permission levels can be set on the metadata store and the objects it contains:
Edit
Security Note:
The Edit permission should be considered highly privileged. With the Edit permission, a
malicious user can steal credentials or corrupt a server farm. We recommend that, in a
production system, you give Edit permission only to users whom you trust to have
administrator-level permissions.
Execute
Selectable in clients
Set permissions
The following table defines the meaning of these permissions on the various objects for which
they can be set.
Selectable in Set
Edit Execute clients permissions
Object Definition permissions permissions permissions permissions
Metadata The collection The user can Although Although The user can
store of XML files, create new there is no there is no set
stored in the external “Execute” “Selectable permissions
Business Data systems. permission in clients” on any
Connectivity on the permission object in the
service, that metadata on the metadata
each contain store itself, metadata store by
definitions of this setting store itself, propagating
models, can be used this setting them from
external to propagate can be used the
content types, Execute to propagate metadata
and external permissions these store.
systems. to child permissions
objects in to child
the objects in
metadata the
store. metadata
store.
Model An XML file that The user can The The The user can
contains sets of edit the “Execute” “Selectable set
descriptions of model file. permission is in clients” permissions
one or more not permission is on the
external applicable to not model.
content types, models. applicable to
their related models.
external
systems, and
information
that is specific
to the
environment,
such as
authentication
properties.
External The metadata The user can Although Although The user can
system definition of a edit the there is no there is no set
supported external “Execute” “Selectable permissions
source of data system. permission in clients” on the
that can be Setting this on an permission external
modeled, such permission external on an system.
as a database, also makes system itself, external
Web service, or the external this setting system itself,
.NET system and can be used this setting
connectivity any external to propagate can be used
assembly. system Execute to propagate
instances permissions these
that it to child permissions
contains objects in to child
visible in the objects in
SharePoint metadata the
Designer. store. metadata
store.
External A reusable Although The user can The user can The user can
content collection of there is no execute create set
type metadata that “Edit” operations external lists permissions
defines a set of permission on the of the on the
data from one on an external external external
or more external content content type. content
external content type type. type.
systems, the itself, this
operations setting can
available on be used to
that data, and propagate
connectivity these
information permissions
related to that to child
data. objects in
the
metadata
store.
Method An operation The user can Although There is no The user can
related to an edit the there is no “Selectable set
external method. “Execute” in clients” permissions
content type. permission permission on the
on a method on a method. method.
itself, this
setting can
be used to
propagate
Execute
permissions
to child
objects in
the
metadata
store.
Method For a particular The user can The user can There is no The user can
instance method, edit the execute the “Selectable set
describes how method method in clients” permissions
to use a method instance. instance. permission on the
by using a on a method method
specific set of instance. instance.
default values.
Special permissions on the Business Data Connectivity service
Along with the general capabilities of setting permissions described earlier, there is a set of
special permissions for the Business Data Connectivity service:
Farm administrators have full permissions to the Business Data Connectivity service.
This is necessary, for example, to be able to maintain or repair an instance of the
service. However, be aware that the farm administrator does not have execute
permissions on any object in the metadata store and this right must be given explicitly
by an administrator of an instance of the Business Data Connectivity service if it is
required.
Windows PowerShell users are farm administrators and can run commands on the
Business Data Connectivity service.
Application pool accounts on front end servers have the same permissions to the
Business Data Connectivity service as farm administrators. This permission is necessary
to generate deployment packages based on Microsoft Business Connectivity Services.
SharePoint Designer users should, in most cases, be given the following permissions on
the whole metadata store: Edit, Execute, and Selectable in clients. SharePoint Designer
users should not be given Set permissions permissions. If necessary, you can limit the
permissions of the SharePoint Designer user to a subset of the metadata store.
Caution:
To help ensure a secure solution, SharePoint Designer should be used to create external
content types in a test environment in which Edit permissions can be assigned freely. When
deploying the tested solution to a production environment, remove the edit permissions to
help protect the integrity of the external data.
Common tasks and their related permissions
This section describes common tasks in the Business Data Connectivity service and the required
permissions to perform them.
Task Permissions
Create a new To create a new metadata object, a user must have edit permissions on
object in the the parent metadata object. For example, to create a new method in
metadata store an external content type, a user must have permissions on the external
content type. See the illustration earlier in this article for child/parent
relationships among objects in the metadata store.
Delete an object To delete a metadata object, a user must have edit permissions on that
from the object. To delete an object and all its child objects (such as deleting an
metadata store external content type and all its methods) the edit permission is also
required on all the child objects.
Adding an To add an external content type to a model, a user must have edit
external content permissions on the model.
type to a model
Importing models To import a model to the metadata store, a user must have edit
permissions on the metadata store. If explicit permissions are not
assigned on the model, the user who imported it will be given edit
permissions on the model.
Exporting models To export a model from the metadata store, a user must have edit
permissions on the model and on all external systems contained in the
model.
Generating a Deployment packages are generated by the application pool account

deployment that is used by the front-end server. This account has full permissions
package to the metadata store so that it can perform this task.
Setting initial When an instance of the Business Data Connectivity service is first
permissions on created, its metadata store is empty. The farm administrator has full
the metadata permissions to the store and can set initial permissions.
store.
Securing Business Connectivity Services
This section discusses additional measures that can be used to help secure Business Connectivity
Services
Service account
For security isolation, the Business Data Connectivity service application and the front-end
server should not use the same service account.
Server to server communication

Securing the communication between the Business Data Connectivity service application and
external systems helps ensure that sensitive data is not compromised. You need to use an
encrypted communication channel to protect data that is sent between servers running
SharePoint Foundation 2010 and external systems. Internet Protocol security (IPsec) is one
method that can be used to help protect communication. The choice of which method to use
depends on the specific communication channels you are securing and the benefits and
tradeoffs that are most appropriate for your organization.
Applications that use FileBackedMetadataCatalog

For security reasons, RevertToSelf authentication mode is disabled on SharePoint Foundation
2010 by default. However, this does not prevent applications that use the
FileBackedMetadataCatalog class from importing models and executing calls that use
RevertToSelf authentication. This can result in elevating privileges for users by granting
privileges to the application pool account. You should review all applications to ensure that they
do not use FileBackedMetadataCatalog class and RevertToSelf authentication before installing
them on a production system.
Configure forms-based authentication for a claims-based Web application (SharePoint Server

2010)
Updated: September 23, 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)"
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>
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 SecurityTokenServiceAppliction sub-site.
4. Right-click SecurityTokenServiceAppliction and then click Explore.
6. Find the <Configuration> <system.web> section and add the following entry:
<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>
Important:
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:
port="389"
useSSL="false"
userContainer="OU=UserAccounts,DC=internal, DC=yourcompany,DC=com"
scope="Subtree"
Find the <roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">
section and add the following entry:
<add name="roleManager"
port="389"
useSSL="false"
groupContainer="DC=internal,DC=yourcompany,DC=com"
groupFilter="(&(ObjectClass=group))"
scope="Subtree" />
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.
5. From the Windows PowerShell command prompt, type the following:
$ap = New-SPAuthenticationProvider -Name "ClaimsForms" -

ASPNETMembershipProvider "membership" -ASPNETRoleProviderName "rolemanager"
$wa = New-SPWebApplication -Name "Claims Windows Web App" -ApplicationPool
"Claims App Pool" -ApplicationPoolAccount "internal\appool"
-Url http://servername -Port 80 -AuthenticationProvider $ap
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:
To configure the Central Administration Web.Config file
To configure the Security Token Service Web.Config file
To configure 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:
$cp = New-SPClaimsPrincipal -Identity "membership:SiteOwner" -IdentityType
FormsUser
$sp = New-SPSite http://servername:port -OwnerAlias $cp.Encode() -Template "STS#0"
Configure the security token service (SharePoint Server 2010)
This article provides guidance to enable you to configure the Microsoft SharePoint Server 2010
security token service (STS). An STS is a specialized Web service that is designed to respond to
requests for security tokens and provide identity management. The core functionality of every
STS is the same, but the nature of the tasks that each STS performs depends on the role the STS
plays in relation to the other STS Web services in your design.
In this article:
How Web applications that use an STS work
Configure a SharePoint claims-based Web application by using Windows PowerShell
Edit bindings
Configure a Web application that uses an STS
How Web applications that use an STS work
Web applications that use a security token service handle requests to issue, manage, and
validate security tokens. Security tokens consist of a collection of identity claims (such as a
user's name, role, or an anonymous identifier). Tokens can be issued in different formats, such
as Security Assertion Markup Language (SAML) tokens. Security tokens can be protected with an
X.509 certificate to protect the token's contents in transit and to enable validation of trusted
issuers. For additional information about the Security Token Service, see Plan authentication
methods (SharePoint Server 2010).
An Identity Provider-STS (IP-STS) is a Web service that handles requests for trusted identity
claims. An IP-STS uses a database called an identity store to store and manage identities and
their associated attributes. The identity store for an identity provider may be a simple, such as a
SQL database table. An IP-STS may also use a complex identity store, such as Active Directory
Domain Services (AD DS) or Active Directory Lightweight Directory Service (AD LDS).
An IP-STS is available to clients who want to create and manage identities, and to relying party
applications that must validate identities presented to them by clients. Each IP-STS has a
federated trust relationship with, and issues tokens to, federation partner Relying Party STS
Web applications, each of which are referred to as an RP-STS. Clients can create or provision
managed Information Cards (using a card selector such as CardSpace) that represent identities
registered with the IP-STS. Clients interact with the IP-STS when they request security tokens
that represent an identity that is contained in the identity store of the IP-STS. After
authentication, the IP-STS issues a trusted security token that the client can present to a relying
party application. Relying party applications can establish trust relationships with an IP-STS. This
enables them to validate the security tokens issued by an IP-STS. After the trust relationship is
established, relying party applications can examine security tokens presented by clients and
determine the validity of the identity claims they contain.
A relying party STS (RP-STS) is an STS that receives security tokens from a trusted federation
partner IP-STS. In turn, the RP-STS issues new security tokens to be consumed by a local relying
party application. The use of RP-STS Web applications in federation with IP-STS Web
applications enables organizations to offer Web single-sign-on (SSO) to users from partner
organizations. Each organization continues to manage its own identity stores.
Configure a SharePoint claims-based Web application by using Windows PowerShell
Perform the following procedures to use Windows PowerShell to configure a SharePoint claims-
based Web application.
To configure a SharePoint claims-based Web application by using Windows PowerShell

1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
5. From the Windows PowerShell command prompt (that is, PS C:\>), create an
x509Certificate2 object, as shown in the following example:
$cert = New-Object
System.Security.Cryptography.X509Certificates.X509Certificate2("path to cert file")
6. Create a claim type mapping to use in your authentication provider, as shown in the
following example:
New-SPClaimTypeMapping
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
-IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
7. Create a trusted login provider by first creating a value for the realm parameter, as
shown in the following example:
$realm = "urn:" + $env:ComputerName + ":domain-int"

8. Create a value for the signinurl parameter that points to the Web application, as shown
in the following example:
$signinurl = "https://test-2/FederationPassive/"
9. Create the trusted login provider, using the same IdentifierClaim value as in a claim
mapping ($map1.InputClaimType), as shown in the following example:
$ap = New-SPTrustedIdentityTokenIssuer -Name

"WIF" -Description "Windows® Identity Foundation" -Realm
$realm -ImportTrustCertificate $cert
-ClaimsMappings $map1[,$map2..] -SignInUrl
$signinurl -IdentifierClaim $map1.InputClaimType
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:
$account = "DOMAIN\" + $env:UserName
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:
$wa = New-SPWebApplication -name "Claims WIF"

-SecureSocketsLayer -ApplicationPool "SharePoint SSL"
-ApplicationPoolAccount $account -Url $webappurl -Port 443
-AuthenticationProvider $ap
12. Create a site by first creating a claim object, as shown in the following example:
$claim = New-SPClaimsPrincipal
-TrustedIdentityTokenIssuerr $ap -Identity
$env:UserName
13. Create a site, as shown in the following example:
$site = New-SPSite $webappurl -OwnerAlias

$claim.ToEncodedString() -template "STS#0"
Edit bindings
After you have configured a SharePoint claims-based Web application, edit the bindings.
To edit bindings
2. Go to the Claims Web Application site in IIS.
3. In the left pane, right-click Claims Web Application, and select Edit Bindings.
4. Select https and click Edit.
5. Under SSL Certificate, select any listed certificate.
Configure a Web application that uses an STS

After you have configured a SharePoint Server 2010 claims-based Web application, edited the
bindings and configured the Web.Config file, you can use the procedure in this section to
configure a Security Token Service Web application.
To configure a Web application that uses an STS

1. Open the Active Directory Federation Services (AD FS) 2.0Management 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. Click 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. If you are not planning to 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 an identifier, 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.
17. Under Outgoing Claim Type, select E-Mail Address.
18. In the left pane, click Save.
19. Security cmdlets (SharePoint Foundation 2010)

20. Published: May 12, 2010
21. You can use Windows PowerShell cmdlets to administer security for Microsoft
SharePoint Foundation 2010.
22.
Cmdlet name Description
Add-SPShellAdmin Adds a user to the SharePoint_Shell_Access role for

the specified database.
Get-SPShellAdmin Returns the names of all users who have the

SharePoint_Shell_Access role.
Remove-SPShellAdmin Removes a user from the SharePoint_Shell_Access

role.
Add-SPClaimTypeMapping Adds a claim mapping to a trusted security token

service (STS) identity provider.
Get-SPAuthenticationProvider Returns an authentication provider.
Get-SPCertificateAuthority Returns the SharePoint certificate authority (CA).
Get-SPClaimProvider Returns a claim provider.
Get-SPClaimProviderManager Returns a claim provider manager.

Get-SPManagedAccount Retrieves accounts registered in the configuration
database.
Get-SPManagedPath Returns all managed paths that match the given

criteria.
Get-SPSecurityTokenServiceConfig Returns the security token service (STS) for the farm.
Get-SPServiceApplicationSecurity Returns the SPObjectSecurity object for a service

application.
Get-SPTrustedIdentityTokenIssuer Returns an identity provider.
Get-SPTrustedRootAuthority Returns a trusted root authority.
Get-SPTrustedServiceTokenIssuer Returns the object that represents the farm trust.
Grant-SPObjectSecurity Adds a new security principal to an SPObjectSecurity

object.
Initialize-SPResourceSecurity Enforces resource security on the local server.
New-SPAuthenticationProvider Creates a new authentication provider in the farm.
New-SPClaimProvider Registers a new claim provider in the farm.
New-SPClaimsPrincipal Creates a new claims principal.
New-SPClaimTypeMapping Creates a claim mapping rule for a security token

New-SPManagedAccount Registers a new managed account.
New-SPManagedPath Creates a new managed path for the given Web

application for all host header site collections.
New-SPTrustedIdentityTokenIssuer Creates an identity provider in the farm.
New-SPTrustedRootAuthority Creates a trusted root authority.
New-SPTrustedServiceTokenIssuer Creates a trust with a SharePoint farm.
Remove-SPClaimProvider Unregisters a claim provider.
Remove-SPClaimTypeMapping Deletes a claim type mapping rule for a security token

Remove-SPManagedAccount Removes a managed account registration from the

farm.
Remove-SPManagedPath Deletes the specified managed path from the

specified host header or Web application.
Remove- Deletes a security token service (STS) identity

SPTrustedIdentityTokenIssuer provider from the farm.
Remove-SPTrustedRootAuthority Deletes a trusted root authority.
Remove- Deletes the object that represents the farm trust.

SPTrustedServiceTokenIssuer
Repair- Repairs the local managed account credential

SPManagedAccountDeployment deployment.
Revoke-SPObjectSecurity Removes a security principal from a SPObjectSecurity

object.
Set-SPClaimProvider Updates registration of a claims provider.
Set-SPManagedAccount Configures the managed account.
Set-SPSecurityTokenServiceConfig Updates the settings of the SharePoint security token

Set-SPServiceApplicationSecurity Updates the SPObjectSecurity object for a service

application.
Set-SPTrustedIdentityTokenIssuer Sets the identity providers of a Web application.
Set-SPTrustedRootAuthority Creates a new trusted root authority.
Set-SPTrustedServiceTokenIssuer Updates a trust with the farm.
Update-SPFarmEncryptionKey Changes the value of the farm encryption key and,

using the new key, re-encrypts all the data.

Moss2010 Security

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Moss2010 Security

Загружено:

Авторское право:

Доступные форматы

Planning, Administration, Configuration, Setup, Migration, and Upgrade

Plan authentication methods (SharePoint Foundation 2010)

Supported authentication methods

Method Examples Notes

Forms-based Lightweight Directory

Microsoft SQL Server

Authentication modes — classic or claims-based

SharePoint Foundation 2010 introduces claims-based authentication, which is built on Windows

Claims-based Identity for Windows: An Introduction to Active Directory Federation

Windows Identity Foundation home page

You do not have to be a claims architect to use claims-based authentication in SharePoint

Implementing Windows authentication

The process of implementing Windows authentication methods is similar for both

Integrated Windows authentication — Kerberos and NTLM

The following steps summarize the process of configuring Kerberos authentication:

1. Configure Kerberos authentication for SQL Server communications by creating SPNs in

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.

Scenario Additional configuration

Delegating a client's identity to a back-end Configure Kerberos constrained delegation for

Digest authentication and Basic authentication

Implementing Digest and Basic authentication requires configuring these authentication

Implementing forms-based authentication

Forms-based authentication is an identity management system that is based on ASP.NET

TechNet article: Configure forms-based authentication for a claims-based Web

MSDN blog article: Claims-based authentication "Cheat Sheet" Part 1

Implementing SAML token-based authentication

SAML token-based authentication requires coordination with administrators of a claims-based

4. Create a new authentication provider by using Windows PowerShell to import the

If you use SAML token-based authentication with AD FS on a SharePoint Foundation 2010

When a Web application is configured to use SAML token-based authentication, the

TechNet article: Configure authentication using a SAML security token (SharePoint

MSDN blog article: Claims-based authentication "Cheat Sheet" Part 2

Choosing authentication for LDAP environments

LDAP environments can be implemented by using either forms-based authentication or SAML

Planning zones for Web applications

Claims authentication — Multiple authentication providers can be implemented on a

Implementing more than one type of authentication on a single zone

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

Planning for crawling content

Implementing more than one zone

Architecture for SAML token-based providers

SharePoint security token service

Token-signing certificate (ImportTrustCertificate) :

The SPTrustedIdentityTokenIssuer object is created by using several parameters. The following

Overview of the SharePoint 2010 Security Model

· SPGroup – represents a group of SPUser objects

· SPRoleAssignment – represents an entry in the ACL for a particular role

· SPRoleDefintion – represents the combination of permissions that should be applied for a

Override Check Out - Discard or check in a document which is checked

Add Items - Add items to lists and add documents to document

Edit Items - Edit items in lists, edit documents in document libraries,

Delete Items - Delete items from a list and documents from a

Approve Items - Approve a minor version of a list item or document.

Open Items - View the source of documents with server-side file

View Versions - View past versions of a list item or document.

Delete Versions - Delete past versions of a list item or document.

Create Alerts - Create alerts.

View Application Pages - View forms, views, and application pages.

Manage Permissions - Create and change permission levels on the Web

View Web Analytics Data - View reports on Web site usage.

Create Subsites - Create subsites such as team sites, Meeting