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:
This comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteArticle is informative and clear. Thanks a lot!
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteNicely written..!!
ReplyDelete