Configuring Authentication

Authentication is the process of verifying the identity of a user making a request to an

application. The application must be assured that the user is authentic before the system
performs authorization, which is the process of verifying that the user has permission to make
the request, and personalization, which determines how the application interacts with the user.
Objectives
After completing this module, you will be able to:
Describe Microsoft SharePoint Server 2010 authentication.
Describe SharePoint Server 2010 federated authentication.
Lesson 1
Understanding Classic SharePoint Authentication Providers

Classic-mode authentication is one of two types of authentication supported by SharePoint

2010. Classic-mode authentication supports one authentication providerWindowsand
several methods of Windows authentication, each of which are described in this lesson.

You can use classic-mode authentication in simple environments that do not require the
benefits of claims-based authentication.
Objectives
After completing this lesson, you will be able to:
Describe identity and classic-mode authentication.
Configure classic-mode authentication.
Describe integrated Windows authentication.
Configure Kerberos authentication.
Describe additional Windows authentication methods.
Configure the Secure Store Service.
Identity and Authentication in SharePoint

SharePoint Server 2010 is a distributed application that is logically divided into three tiers: the
front-end Web server tier, the application server tier, and the backend database tier. Each tier
is a trusted subsystem, and authentication can be required, and by default is required for
access to each tier. Controlling access to each tier requires an authentication provider.
Authentication providers are software components that support specific authentication
methods.
In SharePoint Server 2010, there are two types of authentication:
Classic-mode authentication. Classic-mode authentication is the same type of
authentication that was used in Microsoft Office SharePoint Server 2007. Classic-mode
authentication uses Microsoft Windows as the authentication provider.
Claims-based authentication. Claims-based authentication is a new authentication mode,
built on the Windows Identity Framework (WIF). It supports Windows authenticationjust as

classic-mode doesas well as formsbased authentication (FBA) and Security Assertion Markup
Language (SAML) token-based authentication.
If you are upgrading from Microsoft Office SharePoint Server 2007, consider using classic-mode
authentication if you have no plans to implement forms-based authentication or SAML tokenbased authentication in the future. If you ever plan to use forms-based authentication or SAML
token-based authentication, claims based authentication is a requirement because classicmode authentication only supports the Windows authentication provider. FBA is not supported
by classic mode authentication, even though FBA was supported in SharePoint 2007. You must
use claims-based authentication to use FBA. The table below summarizes the authentication
modes, providers, and methods. You will learn about each as this lesson progresses.
Type Provider Methods

Type
Classic

Provider
Windows
Windows

Claims-based
FBA
SAML

Method
Anonymous, Basic, Digest,
Certificates, NTLM, Negotiate
(Kerberos or NTLM)
Anonymous, Basic, Digest,
Certificates, NTLM, Negotiate
(Kerberos or NTLM)
LDAP, SQL database, Other DB,
Custom
ADFS 2.0, Windows Live ID, Third
Party

Configure Classic-Mode Authentication

You can configure classic-mode authentication (CMA) when creating a new Web application or
subsequently by editing the authentication option as listed below for both situations.
Create a New Web Application

When you create a Web application, you can specify authentication settings on the Create New
Web Application page. At the authentication section of the page, you will be able to select
classic-mode authentication.
Edit Authentication
After a Web application is created, you can modify authentication settings on the Edit
Authentication page. You will then be able to change the settings for Security Configuration,
and review the settings under Authentication Type.
You can access the Edit Authentication page from the Web Applications Management or the
Authentication Providers page.
To configure authentication settings from the Web Applications Management page, follow these
steps:
1. In the Central Administration Quick Launch, click Application Management.
2. In the Web Applications section, click Manage web applications.
3. Select the Web application that you want to modify.
4. On the ribbon, click Authentication Providers.
5. Click the link to the zone that you want to modify.
By default, each new Web application has a single zone, called Default. You will learn more
about zones later in this module.
The Edit Authentication page appears.
6. Make your changes, and then click Save.
To configure authentication settings from the Authentication Providers page, follow these
steps:
1. In the Central Administration Quick Launch, click Security.
2. In the Web Applications section, click Specify authentication providers.
3. Click the Web Application menu to select the Web application that you want to modify.
4. Click the link to the zone that you want to modify.
The Edit Authentication page appears.
5. Make your changes, and then click Save.
Integrated Windows Authentication

Windows authentication is available in both classic-mode and claims-based authentication.

However, when a Web application is using classic-mode authentication, only the Windows
authentication provider is supported.
Windows authentication supports the following authentication methods:
Integrated Windows authentication. Can use either NT LAN Manager (NTLM) or
Negotiate (Kerberos or NTLM) authentication methods.
Basic. In the same fashion as Windows authentication, basic authentication relies on a set of
credentials for the user in Active Directory. However, basic authentication enables a Web
browser to submit credentials while making an HTTP request, and so the credentials are sent in
plaintext, and unencrypted, to the server.
Anonymous. Anonymous authentication enables users to connect to a Web application
without providing credentials.
Digest. Digest authentication provides the same functionality as basic authentication, but
with increased security. User credentials are encrypted instead of being sent over the network
in plain text.
Client certificates. Client-certificate authentication supports the exchange of public key
certificates using Secure Sockets Layer (SSL) encryption over HTTP.
NTLM
NTLM is the most established form of authentication in Microsoft products, as it was introduced
more than a decade ago.
The Process Behind NTLM Authentication
When a user logs on to a computer, the user is prompted for a user name and password. The
user name is sent to the domain controller, but the password is never sent over the network.
Instead, a hash of the password is passed through a one-way hashing algorithm (the
challenge) by both the client and the domain controller through an encrypted
challenge/response protocol. The client sends the result (the response) to the domain
controller. If the result matches what the domain controller obtained as a result, then the
password entered by the user must have been correct, and the user is authenticated.
It gets more complicated when a user connects to a server, such as a SharePoint server. If the
SharePoint server is a member servernot a domain controllerthen it has no way of knowing
the users password. Therefore, when the user connects to the server, the server has to pass

the authentication request to a domain controller. If the domain controller responds to the
server that the user is valid, then the authentication succeeds.
NTLM Summary
While NTLM is not the most efficient authentication method, and while it is slightly less secure
than Kerberos, it is often chosen as the authentication method for SharePoint Web applications
because it is easy to set up.
Kerberos
Kerberos is the default authentication method for Windows clients and servers in an Active
Directory domain.
The Process Behind Kerberos Authentication
Kerberos uses a process that involves encrypted tickets to verify authenticity. When a user logs
on and authenticates with the domain, the domain controllers Key Distribution Center (KDC)
issues the user a ticket-granting-ticket (TGT) that effectively represents that the user has been
authenticated. For the lifetime of the TGTten hours by defaultthe user no longer needs to
be authenticated.
When the user wants to connect to a service, such as a SharePoint Web application that uses
Kerberos authentication, the client application returns to a domain controllers KDC, presents
the TGT, which confirms that the client has already been authenticated, and requests from a
domain controller a service ticket for the specific service to which the client will connect. The
client then goes to the service and presents the service ticket.
Because the entire process is encrypted with keys unique to each requestor (the client, the
service, and the domain), the service is able to examine the service ticket and determine that
it is being presented by an authenticated client. The service ticket contains the clients identity
and roles; the session is established.
Summary of Kerberos Authentication
One of the benefits of Kerberos is that when the client connects to the service, the service
does not have to send back to the server and back to the client for the authentication to
happen to a domain controller, as in NTLM. Instead, the clients ticket for the service ensures
the client has been authenticated. This results in improved authentication performance for
Kerberos as compared with NTLM.
Another benefit is that Kerberos tickets can be delegatedforwarded or proxiedbetween
tiers. For example, a client connecting to a Web site provides a Kerberos ticket, and the Web
site can pass the ticket to a back-end data source that can authenticate the user for data
access. The Web tier does not need to know the users password to achieve this double-hop
authentication. The Web tier also does not need permissions to the back-end data source,
since it is all done by using the authentication of the client.
Kerberos is considered by many organizations to be a preferable authentication mechanism
because of the following advantages:
More secure than NTLM. Kerberos protocols ensure mutual authentication, which prevents
what are called man in the middle attacks whereby a rogue service could pretend to be a
domain controller and intercept authentication requests from clients. Kerberos tickets also
contain timestamps that reduce the likelihood of replay attacks in which an authentication
token can be intercepted and used later for malicious purposes.
More scalable than NTLM. Kerberos supports authentication across trusted realms and,
because it is an industry standard, is supported by platforms other than Windows.

 Supports delegation. Delegation was explained previously. It allows a service to

impersonate a user without knowing the users password. Windows Server 2003 and later
support constrained delegation as well, which adds a further level of security to the
implementation of Kerberos in a Windows enterprise.
Reduced load on domain controllers. Kerberos requires fewer trips to a domain controller
for authentication than NTLM. The disadvantage of Kerberos is that it requires additional steps
to configure. For example, the process of setting the SPN entries for services.
Kerberos Constrained Delegations
Kerberos Constrained Delegations is used on many implementations of SharePoint,
PerformancePoint, Reporting Services, and so forth. It is required when you do a double-hop
such as between a SharePoint server and a Microsoft SQL Server Reporting Services server.
Constrained delegation is not required for Kerberos to work with SharePoint 2010, but it is
highly recommended. Constrained delegation restricts which services are allowed to delegate
user credentials. This prevents unauthorized applications from logging into remote services on
behalf of the user.
If you choose to configure constrained delegation, we recommend that you test your Kerberos
configuration with unconstrained delegation and resolve any issues you might encounter prior
to configuring constrained delegation.
To configure constrained delegation, you must specify which services trust the application pool
identity to present credentials. For constrained delegation to work properly, each application
pool identity must be trusted for delegation for the specific services associated with the data
source.

Considerations and Known Issues

Web applications that will use Kerberos should be running on an application pool that uses a
domain account. If you have used local accounts to install and configure SharePoint, then you
would need to change the account through Central Administration (not through IIS).
Service Principal Name (SPN) has to be registered in the domain controller being used.
Kernel-mode authentication has to be disabled in order to use the app pool account to
receive the ticket from the KDC.
Crawl has problems with communication and ticket handling when the site is running on nondefault ports (HTTP: 80 and HTTPS: 443) and configured for Kerberos authentication.
Kerberos authentication requires the creation of SPNs in Active Directory Domain Services
(AD DS). If the services to which these SPNs correspond are listening on non-default ports, the
SPNs should include port numbers.
Negotiate (Kerberos or NTLM)
To use Kerberos authentication, select the Negotiate (Kerberos or NTLM) authentication
method. Negotiate tries to use Kerberos authentication. However, if Kerberos authentication is
not supported in the deployed environment, or if the client does not support Kerberos,
authentication falls back to NTLM.
IIS passes the Negotiate security header when Windows Integrated authentication is used to
authenticate client requests. The Negotiate security header lets clients select between

Kerberos authentication and NTLM authentication. The Negotiate process selects Kerberos
authentication unless one of the following conditions is true:
One of the systems involved in the authentication cannot use Kerberos authentication.
The calling application does not provide enough information to use Kerberos authentication.
If the Negotiate process cannot use the Kerberos protocol, the Negotiate process selects the
NTLM protocol.

Configure Kerberos Authentication

Configuring Kerberos authentication requires that you create service principal names, or SPNs,
for your SharePoint services, Web applications, and SQL Server. To summarize the process of
Kerberos Authentication, it is important to keep in mind that when a client wants to connect to
a Web application that uses Kerberos authentication, the client requests a service ticket from a
domain controllers KDC. The request indicates the service to which the client will connect by
specifying the services SPN.
The SPN is made up of the following three components:
1. The service class for the request, which is always HTTPthe HTTP service class includes
both the HTTP and HTTPS protocols.
2. The host name.
3. The port (if not port 80) of the Web application.
For example, a request to http://intranet.contoso.com on port 80 equates to an SPN of
HTTP/intranet.contoso.com. Note that the SPN syntax uses a single forward slash between the
service class and host name portions of the name. A request to http://sp2010-wfe1:9999 for
Central Administration equates to an SPN of HTTP/sp2010-wfe1:9999.
A security principala user or computer account in Active Directorycan have one or more
associated SPNs.

When a domain controllers KDC receives the service ticket request from a client, it looks up
the requested SPN. The KDC then creates a session key for the service and encrypts the
session key with the password of the account with which the SPN is associated. The KDC issues
a service ticket containing the session key, to the client. The client presents the service ticket
to the service. The service, which knows its own password, decrypts the session key and
authentication is complete.
If a client submits a service ticket request for an SPN that does not exist in the identity store,
no service ticket can be established, and the client will cause an access denied error to occur.
For this reason, each component of a SharePoint infrastructure that uses Kerberos
authentication requires at least one SPN. For example, the intranet Web application app pool
account must have an SPN of HTTP/intranet.contoso.com.
Note that it is the app poolnot the serverthat is associated with the SPN because the app
pool is the security context within which the servicethe Web application in this caseis
running. It also makes sense if you consider that each SPN can be associated with only one
security principal. Therefore, if a Web app is load balancedrunning on several serversit is
the one app pool account that is constant across all servers and therefore must have the SPN.
For each Web application, you should assign two SPNsone with the fully qualified domain
name for the service, and one with the NetBIOS name of the service. Thats why the intranet
Web application pool account should also be assigned an SPN of HTTP/intranet.
In many environments, a single application pool may be used by multiple Web applications.
The app pool account should be given a pair of SPNs for each of its Web applications that use
Kerberos authentication.
Configure Service Principal Names for a Service or Application Pool Account Using ADSI Edit
To configure an SPN for a service or application pool account, you must have domain
administrative permissions or a delegation to modify the servicePrincipalName property.
1. Start ADSI Edit.
2. In the console tree, right-click ADSI Edit, and then click Connect To.
The Connection Settings dialog box appears.
3. Click OK.
4. In the console tree, expand Default naming context, expand the domain, and then
expand the nodes representing the OU(s) in which the account exists.
Click the OU in which the account exists.
5. In the details pane, right-click the service or application pool account, and then click
Properties.
The Properties dialog box appears.
6. In the Attributes list, double-click servicePrincipalName.
The Multi-Valued String Editor dialog box appears.
7. In the Value to Add field, type the SPN, and then click Add.
Repeat Step 7 for additional SPNs. Remember that an app pool account should have two SPNs,
in the form HTTP/site.domain.com and HTTP/site, for each Web application that uses Kerberos
authentication in the app pool. Remember also to add the port number if the site runs on a
port other than port 80, for example, HTTP/site.contoso.com:9999 and HTTP/site:9999.

8. Click OK.
9. Click OK.
Configure Service Principal Names for a Service or Application Pool Account Using SetSPN
You can also use the command line tool Setspn.exe to add SPNs to an account. The following
example adds the SPNs for the intranet Web application to the app pool account:
setspn CONTOSO\SP_Service a HTTP/intranet.contoso.com
setspn CONTOSO\SP_Service a HTTP/intranet
Type Setspn.exe /? for more information.
Configure Service Principal Names for SQL Server
To configure Kerberos authentication for SQL Server, you will need to add SPNs to the SQL
Server service account, for example, CONTOSO\SVC_SQL. By default, SQL Server
communication is over port 1433, so the two SPNs for a SQL Server running on a server named
SQLSERVER01 would be the following:
MSSQLSvc/sqlserver01:1433
MSSQLSvc/sqlserver01.contoso.com:1433
Additional Reading
Configure Kerberos Authentication (SharePoint Server 2010) at
http://go.microsoft.com/fwlink/?LinkID=197059&clcid=0x409.
Kerberos (Windows Server 2008 and Windows Server 2008 R2 Technical Library) at
http://go.microsoft.com/fwlink/?LinkID=197060&clcid=0x409.
Kerberos Authentication Technical Reference (Windows Security Collection) at
http://go.microsoft.com/fwlink/?LinkID=197061&clcid=0x409.
Windows Authentication at http://go.microsoft.com/fwlink/?LinkID=197062&clcid=0x409.
Kerberos Explained at http://go.microsoft.com/fwlink/?LinkID=197063&clcid=0x409.
How to use SPNs when you configure Web applications that are hosted on Internet
Information Services at http://go.microsoft.com/fwlink/?LinkID=197065&clcid=0x409.
SETSPN at http://go.microsoft.com/fwlink/?LinkID=198479&clcid=0x409.
How to create a SharePoint farm with Kerberos authentication, see
Configure Kerberos authentication (SharePoint Server 2010) at
http://go.microsoft.com/fwlink/?LinkID=197066&clcid=0x409.
Additional Windows Authentication Methods

Although NTLM or Negotiate (Kerberos or NTLM) are the most commonly-used authentication
methods, classic-mode and Windows authentication also support anonymous, basic, digest,
and client certificate authentication methods.
Anonymous
You can enable anonymous authentication on either the Create New Web Application or Edit
Authentication pages.
Anonymous authentication does not provide anonymous users with permission to view content
within a Web application. Anonymous access must be granted at the securable object level.
You can grant anonymous users permission to an entire site or to specific lists and libraries.
Basic
Because basic authentication relies on the exchange of plaintext, unencrypted credentials if
you choose to use basic authentication, it is recommended to enable Secure Sockets Layer
(SSL) encryption to provide a secure implementation.
Digest
User credentials are sent as an MD5 message digest in which the original username and
password cannot be deciphered. Digest authentication uses a challenge/response protocol that
requires the authentication requestor to present valid credentials in response to a challenge
from the server. To authenticate against the server, the client has to supply an MD5 message
digest in a response that contains a shared secret password string.
Digest authentication for SharePoint is not particularly common. To implement digest
authentication, you must:
1. Select Windows authentication in Central Administration.
2. Configure the IIS Web site for digest authentication.
Client Certificates
Client certificates are issued by a Certificate Authority (CA), and they must conform to the
Public Key Infrastructure (PKI). To implement client certificate authentication, you must:
1. Select Windows authentication in Central Administration.

2. Configure the IIS Web site for certificate authentication.

3. Enable SSL.
4. Obtain and configure certificates from a CA.

Secure Store Service

Secure Store Service, or SSS, is the replacement to Microsoft Single Sign On. An important
point: SSO and SSS are an enterprise single sign on solution. This means that it only stores the
user name and passwords. It is not the responsibility of the SSS to do any logging on. An
application must make a call to SSS, and then based on the application or services that make
the call, a set of credentials are returned. The new SSS has improved APIs and more
integration across the SharePoint farm through various service applications. BCS, Excel
Services, and PerformancePoint are examples of this. They require credentials for users that
execute reports when they do not explicitly have access to those data sources.
How Does SSS Work?
An application or user requests credentials for an application, via an application ID. The SSS
will then respond with credentials if there is a mapping for the user making the request.
Secure Store Service Preparation
When you prepare to deploy the Secure Store Service, be aware of the following important
guidelines:
Run the Secure Store Service in a separate application pool that is not used for any other
service.
Run the Secure Store Service on a separate application server that is not used for any other
service.
Create the Secure Store database on a separate application server running SQL Server. Do
not use the same SQL Server installation that contains content databases.
Back up the Secure Store database before generating a new encryption key.
You should also back up the Secure Store database after it is initially created, and again each
time credentials are re-encrypted. When a new key is generated, the credentials can be re-

encrypted with the new key. If the key refresh fails, or the passphrase is forgotten, the
credentials will not be usable.
Back up the encryption key after initially setting up the Secure Store Service, and back up
the key again each time it is regenerated.
Do not store the backup media for the encryption key in the same location as the backup
media for the Secure Store database. If a user obtains a copy of both the database and the
key, the credentials stored in the database could be compromised.
Application IDs
Each Secure Store Service entry contains an application ID that is used to retrieve a set of
credentials from the Secure Store database. Each application ID can have permissions applied
so that only specific users or groups can access the credentials that are stored for the
application ID. Applications use application IDs to retrieve credentials from the Secure Store
database on behalf of a user. The application can then use the retrieved credentials to access a
data source.
Application IDs map your users IDs to credential sets. Mappings are available for groups or
individuals. In a group mapping, every user that is a member of a specific domain group is
mapped to the same set of credentials. In an individual mapping, each individual user is
mapped to a unique set of credentials.
Secure Store Service Mappings
The Secure Store Service supports individual mappings and group mappings. The Secure Store
Service maintains a set of credentials for the application IDs of resources stored in the Secure
Store database. The application ID retrieves individual credentials. Individual mappings are
useful when you need logging information about individual user access to shared resources.
For group mappings, a security layer checks group credentials for multiple domain users
against a single set of credentials for a resource identified by an application ID that is stored in
the Secure Store database. Group mappings are easier to maintain than individual mappings
and can provide improved performance.
Secure Store Service and Claims Authentication
The Secure Store Service is a claims-aware service. It can accept security tokens and decrypt
them to get the application ID, and then perform a lookup. When a SharePoint Server 2010
Security Token Service (STS) issues a security token in response to an authentication request,
the Secure Store Service decrypts the token and reads the application ID value. The Secure
Store Service uses the application ID to retrieve credentials from the Secure Store database.
The credentials are then used to authorize access to resources.

Lesson 2
Understanding Federated Authentication

Federated authentication provides a unified approach to combining credentials from a

heterogeneous environment where multiple methods for authentication exist and different
authentication databases play a role.
While this lesson does not focus on setting a standard, it does cover the process of unifying an
enterprise and giving access to the SharePoint Server resource.
Objectives
After completing this lesson, you will be able to:
Describe federated identity.
Describe Active Directory Federated Services (ADFS).
Describe how claims authentication works.
Understand the federated sign-in process.
Describe SharePoint identity normalization.
List the forms-based authentication changes.
Compare claims with the Windows token service.

Overview of Federated Identity

Key Points
Federated identity allows you to use credentials hosted in select external authentication
systems. This results in lower costs from not having to manage your own authentication
provider. In addition, usability increases because users have only one user name and password
that they can use with any application. There are many large identity providers in the world;
for example, the largest is Windows Live ID and OpenID.
In most cases, your users are not located in a single authentication system, which means you
must set up a gateway to map each of those external users into a gateway with a single
integration point for your own applications to use. This is an alternative to implementing your
own gateway in each of your applications.
When we talk about federating these attributes, we call them claims. Since the
authentication system is external, these claims are not known to contain valid facts about the
users until further identified.
What Are Claims?
A claim is the process of establishing a mechanism as proof or having privileges that allow a
transaction to be completed and accepted. For example, when presenting a credit card to
complete a purchase transaction, the store requires a validation for the identity of the
individual making the purchase.
Claims Providers
Claim providers are the entities that do all the work. They implement the WS-* standards and
provide the claims back to the calling clients (in this case, SharePoint). Keep in mind that a
system can be a consumer and provider at the same time. SharePoint implements its own
claims provider for forms-based identity in 2010. Claims providers perform the following tasks:
Augmentation of Claims
Add application-specific claims

 Authorize over the claims

Search and Resolve
Enumerate and select claims
Use the claims in SharePoint applications
Federated identity uses the following three industry standard specifications:
WS-Federation 1.1. Provides the architecture for a clean separation between trust
mechanisms, security tokens formats, and the protocols for obtaining tokens.
WS-Trust 1.4. Requests and receives security tokens.
SAML Token 1.1. XML vocabulary represents claims in an interoperable way.
Active Directory Federated Services (ADFS)

Key Points
ADFS is a platform for integrating external authentication stores and trusting them with
federated authentication. This means that instead of creating a user name and password
database for external users or creating a new domain, you can simply point to an external
authentication store and allow users to continue to use their own user name and password. As
part of any authentication system, users have attributes.
ADFS implements industry standards of the WS-* stack which means that it can integrate with
any authentication system in the world that implements these global standards.
ADFS has a simple to use interface that allows you to build rules around the target systems
and the claims that will be trusted. You can build rules to use these claims and allow or
disallow requests based on claims information.

Claims Authentication Process and Normalization

Key Points
When authenticating to an external system, a token is generated that contains the information
about the user. This token can be used by the target application to make decisions about what
you will let the user do in the system.
A key element about a claims-based system is trust. An external system can claim many things
about a user, but you have to determine if your systems trust what that external system claims
about that user. Advanced claims-based authentication systems may pull claims from more
than one system and aggregate them together to make an authorization decision.
The following describes the federated sign-in process for a user to perform an action that
requires authentication:
As a user, you will request to access the SharePoint site you are interested in visiting.
You are then redirected to the Identity Provider (IP) and after that, the external Secure Token
Service (STS) generates the requested token.
You are given a token, which will then be forwarded to the application (in this case,
SharePoint).
SharePoint uses the token to authorize you for the actions requested.
For example, most Microsoft sites require you to have a Live ID to log in. When you click login
on the Microsoft system, it will redirect you to Live ID where Live ID will let the user logon.
Then the user will be redirected to the application with claims data, for example, a token. The
site then uses that token to allow the user to access its resources.
SharePoint Identity Normalization

NTLM works by passing NT Tokens, commonly known as credentials. In SharePoint 2007, a NT

Token is translated to SPUser, and then access to resources is determined based on that
SPUser object.
In SharePoint 2010, at logon, all identities are converted to ClaimsIdenties. These claims
identities are then translated to the SPUser.
That is what happens behind the scenes, but we see it represented by an identity (or user
name claim) and it being translated to a valid and recognized (therefore validating the claim)
SharePoint user.
SharePoint and the Security Token Service
An Identity Provider-STS (IP-STS) is a Web service that handles requests for trusted identity
claims. IP-STS uses a database called an identity store to store and manage identities and their
associated attributes. For example, IP-STS can use a SQL database table to store and manage
identities. IP-STS can also use a complex identity store. For example, IP-STS can use Active
Directory Domain Services or Active Directory Lightweight Directory Service (AD LDS).
There are two parts in this process, IP-STS and the relaying party STS. There is a federated
trust relationship between each IP-STS and the federated partner RP-STS Web applications.
Clients can create managed information cards that will represent the identities registered and
known by the IP-STS. An example of this information card system is Windows CardSpace.
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 IPSTS. This enables them to validate the security tokens issued by IP-STS. After the trust
relationship is established, relying party applications can examine security tokens presented
by clients to determine the validity of the identity claims they contain.
Forms-Based Authentication Changes

Key Points
Forms-based authentication has changed in SharePoint Server 2010. It is no longer based on
ASP.NET Generic Identities, but rather a claims identity is created. This is accomplished by the
SecurityToken.svc service and a custom Microsoft Identity Framework Token Service Host
Factory. You must also enable your forms membership and role providers in this SecurityToken
service or your Web application will not be able to use forms-based authentication.

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

membership and role provider authentication. In SharePoint Server 2010, FBA is only available
when you use claims-based authentication.
FBA is used for authentication purposes. The process accounts that connect to Microsoft SQL
Server database software and run the farm must be Windows accounts, even when using
alternative methods of authentication to authenticate users.
SharePoint Server 2010 supports SQL Server authentication and local computer process
accounts for farms that are not running Active Directory Domain Services. For example, you
can implement local accounts by using identical user names and passwords across all servers
within a farm.
To use FBA to authenticate users against an identity management system that is not based on
Windows, or that is external, you must register the custom membership provider in the
Web.config file. In addition to registering a membership provider, you can register a role
manager. SharePoint Server 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 Server 2010. You register role managers in the Web.config
file the same way you register membership providers for authentication.
When you want to manage membership users or roles from the Central Administration site,
you can register the membership provider and the role manager in the Web.config file for the
Central Administration site. You would do this in addition to registering those membership
users in the Web.config file for the Web application that hosts the content.
Ensure that the membership provider name and role manager name that you registered in the
Web.config file is the same as the name that you entered in Central Administration. If you do
not enter the role manager in the Web.config file, the default provider specified in the
Machine.config file might be used instead. For example, the following string in a Web.config file
specifies
a
SQL
membership
provider:
<membership
defaultProvider="AspNetSqlMembershipProvider">.
Integrating with FBA places additional requirements on the authentication provider. In addition
to registering the various elements in the Web.config file, the membership provider, role
manager, and HTTP module must be programmed to interact with SharePoint Server 2010 and
ASP.NET methods.
Claims to Windows Token Service

Key Points
Since SharePoint uses claims identities, SharePoint must convert that identity to the
corresponding NT Token in order for a user to access Windows-only authenticated resources.
In SharePoint 2010, claims to Windows Token Service (C2WTS) are responsible for converting
the claims identity to the NT Token. C2WTS is a Windows service that monitors requests and
then creates the mappings and token (NT Token) creation.
If this service is not running, then calls to Windows authenticated resources will not succeed.

Securing Content

Many organizations must store sensitive or confidential information. Microsoft SharePoint

2010 includes a complete set of security features. You can use these features to ensure that
users can access the information they need, can modify the data they are responsible for, but
cannot view or modify confidential information. The SharePoint 2010 security model is highly
flexible and adaptable to your organizations needs.
In this module, you explore the objects you can use to authorize users in SharePoint 2010,
including users, groups, permissions, and roles. You also experience the integration with Active
Directory Domain Services (AD DS) users and groups and set up and test an authorization
scheme.

Lesson 1
Administering SharePoint Groups

In SharePoint 2010, you can grant permissions and roles directly to user accounts in AD DS in
addition to other identity providers. However, if you have more than a small number of users,
or if you plan to have more users in the future, you should organize users into groups and
grant those permissions and roles to the groups. By using groups, you can manage large
numbers of users in single operations and help to ensure that permissions oversights do not
occur. In this lesson, you learn about SharePoint groups and AD DS groups, how they integrate
together, and how you should use them to organize your user accounts for authorization.
After completing this lesson, you will be able to:
Describe the SharePoint 2010 security model.
Implement security by using default groups.
Administer SharePoint custom groups.
Compare SharePoint groups with AD DS groups.
Implement security with AD DS groups.
Understand how to use SharePoint administrative groups.
Describe the user information list.

Overview of Site Security

In SharePoint 2010, there is a flexible model for organizing users and authorizing them to
access content. This consists of security principals, permission levels, and securable objects
such as lists or libraries.
Security Principals
A security principal is an object to which you can assign permissions. You can organize user
accounts into groups to ease administration. For example, if you place all Sales staff into a
single group, you can authorize them all to access the Sales Team Site in a single operation by
assigning permissions to the group.
Furthermore, when a new member of staff starts work you do not need to assign that user
permission individually. By placing the new member in the Sales group, you implicitly grant the
user permission to the Sales Team Site and all the other resources to which you have granted
the Sales group permission. By grouping users in this way, you can significantly reduce
administrative overhead.
In SharePoint 2010, you can create SharePoint groups to assign permissions and permission
levels. Alternatively, you may use AD DS groups that you already have to secure access to
computers and Microsoft Windows resources.
Permissions and Permission Levels
In SharePoint 2010, permission grants a security principal the ability to perform a certain
operation. For example, you can use the following permissions:
View Items
Open Items
Edit Items
A permission level is a combination of permissions that grants a range of operations that are
commonly required. For example:
The Read permission level includes the View Items and Open Items permissions but not the
Edit Items permission.

 The Full Control permission level includes all the permissions.

You can use the five permission levels included with SharePoint 2010 or create your own by
assembling a combination of permissions.
Securable Objects
A securable object is an object in the SharePoint hierarchy on which you can assign permission
levels for a user account or group. These include the following:
Sites
Lists
Libraries
Folders
Documents
Items
You can assign permission level at a very granular level, right down to single items, but
consider that these many permissions granted at low levels can make access confusing for
users and difficult to administer and troubleshoot. Instead, place items with similar sensitivity
in lists or libraries and assign permission levels on the list or library.

Using Default Groups

SharePoint 2010 creates some SharePoint groups by default whenever you create a new site. In
many cases, these default groups may satisfy all your authorization requirements and render
custom groups unnecessary. Before you plan to create extra groups, understand the
membership and permission levels applied to the default groups.
Common Default Groups
Some default groups are created no matter which site template you chose at site creation. You
can find these groups throughout your SharePoint organization in different site collections and
farms.
Visitors. This group is assigned the Read permission level that allows members to view site
contents, open items, and open documents but not make any changes.
Members. This group is assigned the Contribute permission level that grants all the
permissions of the Read level and adds the ability to add, edit, and delete items and
documents.
Owners. This group is assigned the Full Control permission level that grants all permissions
to members. Owners can therefore assign permission levels, change content, read content,
and take other actions.
Default Groups Added by Site Templates
Some site templates add extra default groups to the site that reflect the roles users take in
that specific kind of site. For example, if you create a site based on the Publishing Site
template, you will notice the following default groups:
Viewers. Members can view pages, list items, and documents.
Approvers. Members can approve new and changed items for publishing.
Designers. Members can alter page designs in the browser and by using SharePoint
Designer.
Hierarchy Managers. Members can create and manage folders, lists, and libraries.
Restricted Readers. Members can read items in certain parts of the site and have limited
access to specific lists.
Style Resource Readers. Members can read only master pages and the style library.

Other site templates create different default groups.

Using Custom Groups

When default groups are not sufficient for your needs, you can choose to create custom
SharePoint groups. You should consider custom groups in the following situations:
When you have more user roles in your site than you can model with the default groups.
When you want to use names different from the default groups. For example, in your
organization those people who design sites may be referred to as Interface Managers or
some other name. In this case, rename the Designers group to Interface Managers.
When you want to preserve a one-to-one relationship between SharePoint groups and AD DS
groups.
Permissions and Custom Groups
When you create a custom group you are prompted to assign a permission level to it, but you
can choose not to do this. These permission levels are applied at the site level and propagate
down to lower objects such as folders and items. If you do not assign a permission level to a
custom group at creation, you use the custom group to assign more granular permissions by
setting them at list or item level.
Using Hierarchical Membership Management
In some cases, you might want to delegate group membership to users. For example, where
each site relates to a single project, the project manager may need to grant team members
access without involving an IT administrator. You can model this situation by using a group, for
example Project Managers, whose membership is assigned by IT administrators. A second
group, for example, Project Members, is owned by the Project Managers group and they can
assign membership in it. Members of Project Members have the required permission level to
the site content.
Group Membership Visibility
For each SharePoint group, you can control whether the membership is visible to other users
who are not members. This can be useful in security-sensitive situations in which it should not
be generally known who has what level of access.

Group Management Comparison

AD DS has a rich and flexible set of features for grouping users, and in SharePoint, you can
assign permissions and permission levels directly to AD DS groups. However, this approach
limits some SharePoint capabilities. This topic compares AD DS and SharePoint groups to help
you understand when to use each.
AD DS Groups
AD DS groups are managed outside SharePoint. Therefore:
You must use Active Directory Users and Computers to set up membership; this tool is
designed for technically able IT personnel and other users may not find it easy.
SharePoint cannot provision group membership. For example, the members of the Site
Managers group cannot assign members to the Site Members group if it is stored in AD DS.
You centrally manage AD DS groups. If you want only one set of groups for all systems in
your organization, place them in AD DS.
SharePoint Groups
By contrast, the following points are true of SharePoint groups:
SharePoint has a membership user interface for SharePoint groups that is easy for
nontechnical authors to use and appears in the relevant site.
SharePoint can provision group membership. For example, a workflow can add a member to a
SharePoint group.
You can view SharePoint groups and users for a site in a single Web page.
You can use SharePoint groups only in SharePoint.

Using Active Directory Domain Service Groups

You can choose from several approaches for using groups in SharePoint.
Using AD DS Groups Without SharePoint Groups
In this approach, AD DS administrators set up groups and manage membership. SharePoint
administrators grant permissions directly to AD DS groups. If you use this configuration, you
must use AD DS in classic or claims-mode authentication because the authentication provider
for Web applications and the AD DS groups must be security groups, not distribution groups.
The AD DS groups should also be email-enabled so that SharePoint can send alerts.
Using SharePoint Groups Without AD DS Groups
Another approach is to place AD DS user accounts directly in SharePoint groups without using
AD DS groups. Again, this requires the AD DS authentication provider. Full SharePoint
functionality is preserved by this approach. For example, each site to which you grant a user
access automatically appears in that users My Sites list. However, when the number of users
in a site is large, SharePoint groups can soon become unmanageable.
Nesting AD DS Groups in SharePoint Groups
You can nest AD DS groups in SharePoint groups and grant permissions to SharePoint groups.
Members of the AD DS groups automatically inherit the access granted. This approach is
recommended as the most flexible and scalable.
Advantages
AD DS administrators remain in control of group membership and structure.
SharePoint administrators remain in control of SharePoint resources.

 AD DS membership changes are automatically reflected in SharePoint access.

For example, if a user moves to another role, and AD DS administrators move their account to
another AD DS group, their access to SharePoint resources changes automatically, without any
action from SharePoint administrators.

Disadvantages
SharePoint administrators cannot see the individual members of a group in the SharePoint
user interface (UI). They must trust AD DS administrators to assign membership correctly.
Sites to which you grant the group access do not automatically appear in MySites. However,
the user can manually add them.
The User Information List does not show individual users until they have contributed to the
site.
AD DS groups with deep nesting or contacts as members can cause issues in SharePoint.

Administrative Groups

SharePoint 2010 also has built-in groups for system administration, and Windows
administrators can configure SharePoint settings.
Note: In a small or medium-sized company, or in a larger organization with a single
administration team, a user may be a member of more than one of the following groups.
Site Collection Administrators
When you create a SharePoint site collection, you must specify a security principal (a user
account or group) as primary Site Collection Administrators. Optionally, you can also specify
secondary Site Collection Administrators. Site Collection Administrators have the following
characteristics:
Have Full Control access to a site collection and all the sites in it.
Have access to all the content in a site collection. This overrides any permissions assigned by
site owners.

 Can create and configure subsites.

Are the administrative contacts for the site collection.
Receive administrative alerts for the site collection.
Can configure permissions, permission levels, and SharePoint groups in the site collection.
Can configure auditing in the site collection.
Can use all the tools under Site Collection Administration on the Site Settings page at the site
collection level.
You can also add new users or groups to the Site Collection Administrators after the site
collection has been created.
SharePoint Farm Administrators
When you create the SharePoint farm, that is, when the first server in the farm is installed, you
must specify a user or group to be Farm Administrators. A group is recommended so that
administration can be performed by more than one person, but membership of this group
should be carefully controlled. These administrators have the following characteristics:
Are responsible for the configuration of the farm as a whole.
Have access to all settings in Central Administration.
Can create and configure site collections.
Can control which users can manage server and farm settings.
Have no access to site collections and their content by default.
Can take ownership of any site collection to get access to content if necessary.
Windows Administrators
Members of the local Administrators group on the SharePoint server also take a role in
SharePoint administration. A user account can be a direct member of this account, such as the
local Administrator account, or inherit membership from an AD DS group, such as the Domain
Admins group. Windows Administrators have the following characteristics:
Can perform all the actions of a SharePoint Farm Administrator.
Can install new products and applications on the server, such as antivirus packages.
Can deploy Web Parts and other custom components to the global assembly cache (GAC).
Can create Web sites, Web applications, and control other Internet Information Services (IIS)
settings.
Can stop and start Windows Services on the SharePoint server.
Can run Stsadm.exe commands.

User Information List

For every site collection, SharePoint maintains a User Information List to store details of current
users and their activities. This differs from the People and Groups list because the users it
displays are dynamic. When SharePoint displays who last modified a file, for example, it takes
the information from the User Information List.
People and Groups
In Site Settings, click People And Groups to view a list of user accounts and groups that have
been granted permissions on this site. This list is not dynamic; for example, if you grant access
to a group, the members receive authorization to the site, but they are never displayed
individually on this list.
User Information List
Like People and Groups, the User Information List also displays a list of user accounts and
groups that have been granted permissions on this site. However, individual user accounts are
added to this list in the following circumstances:
When their user account is granted access individually
When they contribute to the site content, for example, by adding or editing a file
When they set up an alert to be notified about events in the site collection
Only Site Collection Administrators can view the User Information List. The list is at the
following location:

http://sharepointserver/sitecollection/_catalogs/users/simple.aspx.

Lesson 2
Implementing SharePoint Roles and Role Assignments

SharePoint permission levels are also referred to as roles. Now that you understand how
SharePoint uses user accounts, AD DS groups, and SharePoint groups, you can study how to
assign permissions and roles to those security principals.
After completing this lesson, you will be able to:
Plan for and enable anonymous access to SharePoint sites.
Assign permissions to lists and libraries.
Assign permissions to folders and items.
Understand permission inheritance in the SharePoint hierarchy.
Assign the Override Checkout permission to appropriate users.

Configuring Anonymous Access

In scenarios with sensitive data, anonymous access presents a security concern.

Therefore, it is disabled in SharePoint 2010 by default. However, in many scenarios you need
users to be able to access SharePoint Server anonymously. For example, if you host your
organizations Internet-facing Website in SharePoint, most users need anonymous access to
the majority of the content. You can authenticate them for access to certain parts of the site if
you wish.
To enable anonymous access you must make two administrative changes.
Configuring Anonymous Access in Central Administration
Start your configuration by enabling anonymous access on the Web application that hosts your
site.
1. Start Central Administration.
2. Click Manage Web Applications.
3. Click the Web application that you want to configure.
4. On the ribbon, click Authentication Providers.
5. Click the zone you wish to configure.
6. Select Enable anonymous access.
7. Click Save.
Configuring Anonymous Access in Site Settings
Complete your configuration by enabling anonymous access for the site collection.
1. Navigate to the top-level site of the site collection.
2. Click Site Actions, and then click Site Settings.
3. Click Site Permissions.
4. On the ribbon, click Anonymous Access.
5. Select the level of access you want to grant to anonymous users, and thenclick OK.

Note: The Anonymous Access button on the ribbon is disabled until you have configured
anonymous access in Central Administration.

Site, List, and Library Security

In many cases, with careful planning and good use of permissions levels at the site collection
level, you can avoid assigning permissions to users at the site, list, or library levels. Such a
permissions scheme is easy for users to understand because the level of access they receive is
consistent throughout a site collection. It also eases troubleshooting because administrators
have a single location where all permissions are assigned. However, in other cases, you may
have to assign more granular permissions at the site, list, or library levels.
Site-Level Permissions
When you create a new site, permissions are inherited by default from the parent site and you
cannot set extra permissions on the site. However, if you wish not to use this inheritance
model, click More Options in the Create dialog. Then, under User Permissions, click Use Unique
Permissions. You can also break inheritance at any subsequent time on the Site Permissions
page for a subsite by clicking Stop Inheriting Permissions on the ribbon.

When you break permissions inheritance in this way, the initial permissions for the site are
those that would have been inherited from the parent. However, you can now remove these or
configure additional permissions.
List and Library Permissions
As for sites, permissions on lists and libraries are inherited from the parent site, and, by
default, you cannot modify them. However, you can break inheritance either when you create
the list or library or at any later time. This enables you to remove or add permissions
independently of permissions on the site.
Note: For site, list, and library permissions, if you choose to break inheritance, you can later
reestablish permissions inheritance and remove any customized permissions you applied.
The Check Permissions Tool
When you view a Site Permissions or List Permission page, the Check Permissions tool is
displayed on the ribbon. With this tool, you can check the effective permissions for a user
account, and it is useful when users complain of permissions that are too restrictive or when
you suspect that a user has too much access.
When you click Check Permissions, a dialog prompts you to enter a user name. When you click
Check Now, all the permissions that apply to the user account at different levels are displayed.
You can easily see the effective permissions in a single view and diagnose problems.

Folder and Item Security

You can also control permissions at the level of individual items, documents, and folders.
Inheritance
Permissions on items, documents, and folders are inherited from the parent by default. You
should maintain inheritance whenever possible as a best practice for the following reasons:
Users can easily understand their level of access because it is consistent throughout the site.

 You can manage permissions more easily because they are set at a single level in the
hierarchy.
You can maximize performance because multiple levels of permissions need not be
evaluated.
However, when required, you can break inheritance on folders and items. If you break
inheritance, you can remove inherited permissions and configure additional permissions to
create an entirely independent level of access. Subsequently, you can reestablish inheritance if
your requirements change.
Indexing and Item Permissions
SharePoint 2010 includes advance search and indexing functionality that is useful in all
deployment scenarios. When the SharePoint crawler indexes an item, document, or other
content, it stores the permissions in the search service properties database; it does this so that
permissions can be evaluated when users run searches. Any items to which the user does not
have Read access are removed from the results and security is maintained.
However, when the crawler indexes an ASPX page, security issues may arise. This is because
the page is run in the security context of the search user account. Web Parts and other user
interface components display all the items and resources the search account has access to,
and the search account usually has Read access to all resources.
When users run searches, because they have permission to read the ASPX page, the result is
returned to them. However, the page title or summary may include text about resources to
which they do not have permission because the crawler does have permission.
For this reason, the Search service in SharePoint is configured not to crawl ASPX pages by
default. If you wish to enable this functionality and have considered the security implications
fully, you can do so by clicking Site Settings, Search And Offline Availability, and then
configuring Indexing ASPX Page Content.

Permission Levels

SharePoint 2010 eases the administration of authorization by providing permission

levels. You can define permission levels at the site collection level. Each permission

level consists of a set of individual permissions that apply to items, sites, and other
objects. These permissions are inherited by objects in the site collection. When users
access SharePoint resources, the permissions they receive are determined by the
permission level assigned to their user account or groups.
Default Permission Levels
You can examine the permission levels that exist in a site collection on the site permission
page:
1. Click Site Actions, and then click Site Permissions.
2. On the ribbon, click Permission Levels.
3. Click a permission level to examine the individual permissions that it includes.
Some permission levels, such as Read and Full Control, exist by default in every site collection.
Other default permission levels are added by certain site templates.
For example, when you create a site using the publishing template, the Approve and Manage
Hierarchy permission levels are added.
The Read permission level, for example, consists of the following permissions:
List Permissions
View Items
Open Items
View Versions
Create Alerts
View Application Pages
Site Permissions
View Pages
Browse User Information
Use Remote Interfaces
Use Client Integration Features
Open
Creating and Customizing Permission Levels
Site collection administrators can customize the default permission levels to create the
appropriate level of access. You can use the following methods to do this:
By customizing the default site permissions. This is not recommended as a best practice.
By copying default site permissions and customizing the copy.
By creating new permission levels from scratch.
It is a recommended best practice to define permission levels and allow inheritance to
determine access to resources instead of applying permissions at lower levels. By using
permission levels in this way you ensure that the following occur:

 Administrators can troubleshoot permissions rapidly without having to investigate

permissions at multiple levels.
Users understand their level of access because it is consistent throughout sites.
Performance is maximized because multiple levels of permissions need not be evaluated for
every access.

Override Check Out Permission

In SharePoint sites that use version control, users must check out documents and other items
before they can make changes. While the document is checked out, other users cannot make
changes; this ensures that proper version control is maintained so that no two users can
simultaneously make changes to the same document, thereby overriding one anothers edits.
Sometimes, however, a user forgets to check a document back in. If this happens, other users
cannot be productive until the check-out is removed. To prevent productivity barriers like this,
you should ensure that you grant users the Override Check Out permission.
Override Check Out Permission
With the Override Check Out permission, a user can check a document back in or discard the
check-out even if another user checked the document out. In this way, you can remove the
barrier to productivity even if the user who checked out the document is unavailable.
Overriding a check-out is usually a last resort because it can result in lost changes. Consider
the situation where a user has checked out a document and taken a vacation:
If the user saved the document to SharePoint but forgot to check the document in, you can
check it in and no changes are lost.
If the user saved some changes to SharePoint but did not upload the last version, you can
check the document in and lose the latest changes.
If the user uploaded no changes and instead changes the local copy, you can check the
document in or discard the check-out and lose all the changes.
Override Check Out Permission and Permission Levels

The Override Check Out permission is included by default in the Full Control permission level
usually granted to site collection administrators. However, this may not be the most
appropriate arrangement. For example, in a project site, project managers may need this
permission because they manage the content the team develops. Therefore, consider who has
this permission carefully whenever version control is in place. You should ensure that you do
the following:
Grant the powerful Override Check Out permission to only a restricted set of users.
Explain the implications of overriding check-out to those users and provide guidance on how
to use this feature.
Ensure that there is always at least one person available to override check-outs.
You should consider creating a new permission level that includes only the Override Check Out
permission so that you can carefully manage the assignment separately from other
permissions. A separate permission also reduces the chance that you accidentally grant
Override Check Out to users who should not have it.

Lesson 3
Securing and Auditing SharePoint Content

SharePoint also provides a range of settings at the Web application level; as a farm
administrator, you can use these to impose restrictions on site collection administrators and
set policies that govern users, anonymous access, and permissions. You can also set up
auditing to record user actions and ensure that you can always determine who made a
particular change.
After completing this lesson, you will be able to:
Set up user policies for a Web application.
Manage permissions that are available in a Web application.
Configure auditing for a site collection.

Web Application Security

In the SharePoint Central Administration site, when you manage a Web application, you can set
a range of security options. These settings determine, for example, default permission levels
that appear in every site collection in the Web application. Farm administrators can use Web
application security settings to restrict the capabilities of site collection administrators.
User Policy
With user policies, you can grant user accounts or groups permission levels that apply to all
site collections in the Web application. These policies override any permissions set at lower
levels by site collection administrators.
To configure a user policy, first select the Web application you wish to administer, and then
click User Policy. When you add a policy you can select the zone to which it applies. In this way,
you can apply a different policy to a user depending on the authentication mechanism the user
used to connect.
Anonymous Policy
The anonymous policy for a Web application restricts what anonymous users can do. You can
use anonymous policies to deny users Write access or prevent any access at all. As for user
policies, you can apply different anonymous policies to users depending on the zone through
which they connect.
Permission Policy

In the permission policy for a Web application, you can create permission levels just as you do
in site collections. The permission levels in the Web application policy appear as default
permission levels for all site collections in that application. Also, these permission levels are
those selectable in the user policy.
Note: Site templates may add extra default permissions to sites as you create them.

Managing Web Application Permissions

You can also restrict the permissions that are available in the site collections in a Web
application. This is an unusual step, but you might find it useful when you need to place
boundaries on user actions throughout a site collection.
Web Application User Permissions
In Central Administration, click Manage Web Applications, and then select the Web application
you want to configure. On the ribbon, click the Web Application User Permissions button.
The User Permissions For Web Application dialog appears and displays all the permissions
available for lists, sites, and personalization. If you wish to prevent any user in the Web
application from performing an action, you can remove the corresponding permission from this
list, and then click Save.
When you remove a permission in this way it is no longer available to add to permission levels
or to apply to sites, lists, or items anywhere in the site collections in that Web application.

Configuring Auditing

You can use auditing to create a record of the actions of users. Use this record to
examine who is doing what in your SharePoint farm. By examining audit reports
regularly, you can be confident that permissions are appropriate, users are viewing
information appropriate to their role, and sensitive documents are not being seen by
unauthorized personnel. Auditing is thus essential for good security.

Configuring SharePoint Auditing

In SharePoint 2010, auditing is configured at the site collection level:
1. In a site collection top-level site, click Site Settings.
2. Under Site Collection Administration, click Site collection audit settings.
With the Audit Log Trimming settings, you can ensure that audit logs are stored for a
limited time and so do not consume large amounts of disk space. Specify the number
of days to keep audit logs and a location to store audit log reports.

Viewing Audit Reports

After auditing is configured and running, you should examine audit logs regularly to
spot unauthorized or inappropriate access.
1. In a site collection top-level site, click Site Settings.
2. Under Site Collection Administration, click Audit log reports.
A large range of audit reports is available to display different events in your site
collection, and you can also create custom reports. Only site collection administrators
can view audit reports.

Information Rights Management

Permissions and permission levels provide administrators with a secure and flexible system of
authorization on the server. However, they do not restrict the actions a user can take on a
document after download to the client computer or another location. For example, by granting
Read Items permission only, you can ensure that users cannot make changes to the copy of a
document on the server. However, users could download that document and make changes to
their local copy. Information Rights Management (IRM) can prevent such actions regardless
of the location where a document is stored.
When you enable and configure IRM on a SharePoint list, SharePoint encrypts each document
and adds an IRM license to it before it serves the document to a user. The license lists the
permitted actions.
SharePoint Permissions and IRM Permissions
The IRM permissions that are included in the license map to the SharePoint permissions on the
document in the library. In the following table, you can see how SharePoint assigns these
permissions.
SharePoint Permissions
Manage Permissions
Manage Web

Edit List Items

Manage List
Add and Customize Pages

View List Item.

All other SharePoint permissions,

IRM Permissions
Full control of the documents, as defined by
the
client application. This generally permits the
user
to read, edit, copy, save, and modify
permissions
of the document.
Edit, copy, and save permissions. The user
can
print the document only if the document
library
IRM settings are configured to allow document
printing.
Read permissions The user can read the
document
but not copy or edit its content. The user can
print
the document only if the document library IRM
settings are configured to allow document
printing.
Not applicable; no corresponding IRM

such as Edit User Info

Permissions.

Active Directory Rights Management Services

Before you can use IRM in SharePoint lists and libraries you must set up the Active Directory
Rights Management Services in your organization. To do this, install the Active Directory Rights
Management Services (AD RMS) server role in Server Manager. You can configure a single AD
RMS server to handle all requests.
However, it is recommended that you install several servers in a load-balanced configuration
to enable greater scalability and stability.
Configuring IRM in SharePoint
When the AD RMS are available to SharePoint servers, you can enable and configure IRM for
your SharePoint lists and libraries. To do this, complete the following steps:
1. In the browser, open the list or library you want to secure.
2. On the ribbon, click the Library tab.
3. On the ribbon, click Settings, and then click Library Settings.
4. In the Permissions and Management section, click Information Rights Management.
5. On the Information Rights Management Settings page, select the Restrict
permission to documents in this library on download check box to apply restricted
permission to documents that are downloaded from this list or library, and then click OK.