Follow me on Twitter @AntonioMaio2

Thursday, November 14, 2013

Securing SharePoint 2013: Plan for Authentication

This post is the second in a series where I introduce concepts and considerations for security in Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those that have SharePoint up and running and are looking at built-in features and third-party solutions to secure their sensitive information.

Microsoft SharePoint 2013 comes with a variety of authentication options to fit your organization’s requirements. At its most basic level, authentication is the process of determining that a user is who they say they are. This usually occurs at login, and typically with a simple username/password match. So, when a user presents a username and password, SharePoint will then verify that the username/password combination matches what it has in its database. If it does then the user is authenticated.

Considering authentication a little more broadly, authentication can also be seen as the process of validating a user’s identity against an identity provider. Identity providers include Active Directory - Directory Services (AD DS), LDAP directories, or Active Directory Federation Services (AD FS). The use of identity providers becomes important when we look at new methods of authentication like Claims Based Authentication, which is discussed further below.

Within Microsoft SharePoint, the authentication method is configured uniquely for each web application. It’s important to note that authentication is configured when a web application is created through the Central Administration console. However, it cannot be modified through this console after a web application has been configured. To modify the authentication configuration of an existing web application, a SharePoint farm administrator will need to use the appropriate PowerShell commands.

Very similar authentication options are available in Microsoft SharePoint 2013 compared to those that were available in SharePoint 2010. However there are 2 big differences:

1.      When creating a new web application in SharePoint 2013 the default authentication method is now Claims Based Authentication.

2.      The configuration options for Windows Authentication has been removed from the Central Administration console. It can only be done through Windows PowerShell.

The authentication options available in Microsoft SharePoint 2013 are: 

§  Claims-Based Authentication (SAML Token Based)
Microsoft introduced Claims Based Authentication as an option in SharePoint 2010, in part to better support third-party authentication providers and multi-vendor environments that support internet, federated partners, or cloud computing models. Traditional authentication mechanisms did not support these environments well. With claims based authentication, once authenticated a user obtains a digitally signed security token from a commonly trusted identity provider. The token contains a set of attributes about the user—or claims—and each claim represents a specific piece of data about the user such as their name, group membership, role, title, security clearance, or even age. Applications like SharePoint which support claims based authentication receive a security token from a user, as opposed to credentials, which they use to determine user access to resources. This can be accomplished without having to make separate queries to directory services such as Active Directory.

Some of the more traditional Windows domain authentication protocols, such as NTLM and Kerberos, may also be used along with claims-based authentication. When using these protocols in conjunction with claims based authentication, SharePoint 2013 will make an authentication request using the classic protocol and the response (a Windows NT Token) will then be translated to a new SAML token by the SharePoint Security Token Service (STS).

As mentioned, claims based authentication is now the default authentication method within SharePoint 2013 when new web applications are created. This, combined with the fact that classic Windows Authentication has been removed from the Central Administration console and is only configurable through PowerShell, is a significant move by Microsoft. It indicates that Microsoft believes strongly in the power and robustness of claims based authentication and that it is highly recommending claims based authentication moving forward.

§  Forms-Based Authentication
Forms-based authentication validates users that enter their credentials (usually) on a web login form. It is typically used in extranet deployments of SharePoint, where external users need to log in to access SharePoint resources but those users do not have accounts in Active Directory.

Forms-based authentication is enabled through claims-based authentication and the use of a custom ASP.NET membership and role provider. Forms-based authentication can be used against credentials that are stored in various accounts sources including: a database (such as SQL Server), an LDAP directory, or even Active Directory.

§  Classic Windows Authentication
Classic Windows authentication makes use of the classic Windows authentication protocols that are supported by Windows domains to validate user credentials, such as NTLM, Kerberos, Digest Authentication and Basic Authentication. This is sometimes referred to as Integrated Windows Authentication.

Configuring Classic Windows Authentication for a SharePoint 2013 web application requires the use of PowerShell as the configuration interface has been removed from the Central Administration console.

In addition, it’s important to be aware that several caveats exist when continuing to use Classic Windows Authentication with SharePoint 2013 web applications. For example: if migrating a system using Office Web Apps with a SharePoint 2010 web application with classic mode authentication, the SharePoint web application must be migrated to the 2013 claims-based authentication method for it to continue working with Office Web Apps. Viewing and editing with Microsoft Office Web Apps will not work on SharePoint 2013 web applications that use classic mode authentication.

§  Anonymous Authentication
SharePoint 2013 also supports Anonymous Authentication for users who do not need to authenticate any credentials in order to access site resources. Anonymous Authentication is often used for public facing SharePoint sites.

Anonymous Authentication is disabled by default.  It must be enabled on each web application separately by performing the following steps:

1.      In the Central Administration Console select Application Management on the left side and then select Manage Web Applications

2.      Select the web application you are interested in, then select Authentication Providers in the ribbon, select the zone and then check Enable Anonymous Access

3.      Click Anonymous Policy in the ribbon bar

4.      Select a network zone and an Anonymous User policy

Once these steps are complete, site owners or site collection administrators for specific sites still need to enable anonymous access for individual site collections or sites.  Until this is done, no site collections, sites or libraries will be available for Anonymous Access.  This is accomplished through the following steps:

1.      A site collection administrator accesses the site targeted for Anonymous Access

2.      Select Site Settings and then select Site Permissions

3.      In the ribbon select Anonymous Access

4.      Finally select if an anonymous user can view the entire site or simply lists or libraries

For additional detailed information on the authentication options available in Microsoft SharePoint 2013, please visit the following Microsoft TechNet article:



  1. This comment has been removed by a blog administrator.

  2. This comment has been removed by a blog administrator.

  3. This comment has been removed by a blog administrator.

  4. This comment has been removed by a blog administrator.

  5. Article is informative and clear. Thanks a lot!

  6. This comment has been removed by a blog administrator.