SharePoint Stream

A wide-ranging SharePoint study guide focused to IT Consultants

Tag Archives: Secure Store Service

Develop a security approach

This objective may include but is not limited to: authentication (NTLM, Kerberos, Forms-based Authentication, claims, Single Sign-On, Anonymous), authorization (SharePoint groups, AD groups, claims, permission levels) enterprise-wide security policies


Windows Challenge/Response (NTLM) is the authentication protocol used on networks that include systems running the Windows operating system and on stand-alone systems.

The Microsoft Kerberos security package adds greater security than NTLM to systems on a network. Although Microsoft Kerberos is the protocol of choice, NTLM is still supported. NTLM must also be used for logon authentication on stand-alone systems.

NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user’s password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user’s password over the wire. Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials.

Interactive NTLM authentication over a network typically involves two systems: a client system, where the user is requesting authentication, and a domain controller, where information related to the user’s password is kept. No interactive authentication, which may be required to permit an already logged-on user to access a resource such as a server application, typically involves three systems: a client, a server, and a domain controller that does the authentication calculations on behalf of the server.


Kerberos is a secure protocol that supports ticketing authentication. A Kerberos authentication server grants a ticket in response to a client computer authentication request, if the request contains valid user credentials and a valid Service Principal Name (SPN). The client computer then uses the ticket to access network resources. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). The KDC distributes shared secret keys to enable encryption. The client and server computers must also be able to access Active Directory directory services. For Active Directory, the forest root domain is the center of Kerberos authentication referrals.

If you are creating an Intranet web application, strongly consider using Kerberos for user authentication. Kerberos is more secure and offers better performance than NTLM. Because both the client and IIS server must see the KDC, Kerberos does not work with most Internet-facing sites with SP 2010.

Forms-based Authentication

Forms-based authentication (FBA) is based on ASP.NET, and provides users access to a system using a prompt (or login page) that will collect a username and password from the user trying to access the system. You’ll see this quite a bit when you want to provide access to registered users (to add content to a site, for example), but the users do not exist as a record within AD.

FBA is a cookie-based authentication system that either prompts or redirects users to a login page, where the user provides the appropriate credentials to access a SharePoint site. When the user enters his or her credentials into the login page, there is a comparison with a credential store. If there is a match, then the user is allowed to access the site. If there is not a match, then the user is denied access.

The custom identity store (or membership provider) can manifest in a number of ways, such as an XML file, SQL Server database, Access database, and so on — although, SQL Server is the easiest of the these options to set up and use.

You store what is referred to as membership information in the custom identity store, which includes information about roles, profile, and personalization information.

There are a number of steps when setting up FBA for SharePoint that you’ll need to walk through. At a high-level, these steps are as follows:

  1. Create an identity store/membership provider.
  2. Provision access to the membership provider.
  3. Configure IIS to support the new membership provider.
  4. Create a new Web application that enables FBA in the Default zone.

When using FBA, note that you must amend SharePoint’s web.config file to include information to support. For example, you may need to include the connection string to your membership provider and PeoplePicker wildcards in the web.config file.

Claims authentication

SharePoint Server 2010 incorporates a powerful and flexible approach to authenticating users. It works with any organizational identity system, including AD, Lightweight Directory Access Protocol (LDAP), system-specific databases, and more Web-centric models such as LiveID. This approach is known as claims-based authentication.

Claims-based authentication was created around the concept of an identity, and is based on accepted industry standards such as WS-* and protocols such as the Security Assertion Markup Language (SAML). SAML is an XML-based standard for exchanging authentication data between an identity provider and a service provider that live on different domains. At the heart of this data exchange is a SAML token, which essentially provides information about the users trying to authenticate themselves against a particular system. The SAML token is essentially the “claims” part. It provides information that makes a claim as to who users are, and what they have access to. You might think of a token as metadata about the users that stays with them throughout their sessions.

While AD provides limited claims (or information) about a user, you can create an identity through information such as a name, email address, phone number, title, and so on. This is one of the reasons why claims-based authentication is a more flexible model than AD. You can provide as much information as you want within a claim, and then use standards to communicate that claim across systems and domains.

Single Sign-on

The SPS 2010 Secure Store Service is roughly equivalent to MOSS 2007 single sign on (SSO). Nevertheless, it covers more features than before, providing improvements in the areas of management, extranet scenario usage, security trimming, and role provider support. The Secure Store Service is leveraged by many others SPS 2010 service applications, such as BCS, PerformancePoint, Visio Services, Excel Services, and Project Server.

Secure Store Service is most used by SharePoint developers when they need to take a user from SharePoint given his username to another system with another username or account. Using the Secure Store Service on those situations overcomes the “double hops” problem for users authentication with NTLM or Basic authentication.


Anonymous authentication is first set on the Web application level. Although enabling access on a Web application doesn’t enable any content to anonymous users, it does give the ability for site collection administrators to enable the feature. If a site collection is primarily used for collaboration, you should strongly consider limiting anonymous access when possible.

It’s important to notice that even though it is possible to set anonymous authentication through IIS, it’s strongly recommended not to. Always perform authentication provider changes from the Central Administration. Using this approach  writes the changes to the configuration database for propagation to existing Web servers and to new servers added to the farm.

SharePoint groups and AD Groups

A group is a collection of users through which SP 2010 manages security. User-based management is straightforward for simple sites, but becomes more complex as the number of uniquely secured resources grows. For example, a user may have the Contribute role for list 1, the Read role for list 2, and the Design role for list 3. This model does not scale well if there are, for example, 50,000 users—which would result in access control lists (ACLs) being 50,000 access control entries (ACEs) long on every uniquely secured object.

Groups provide an answer to the manageability and scale problems of user-based permissions management. Group-based management may be more abstract or more difficult to conceptualize, but it enables easier management of complex sites with many uniquely secured objects. For example, when adding a user to a group that has already been granted the appropriate role on various objects in the system. The permissions checking for groups scales better because far fewer group ACEs need to be stored.

SP 2010 supports two kinds of groups: domain groups and SharePoint groups. Domain groups remain outside SP control; users cannot use SP 2010 to define, browse, or modify domain group membership. SharePoint groups are scoped to the site-collection level, and they can be used only within the site collection. Domain groups can be used anywhere within the scope of the Active Directory directory service.

A principal is a user or group that is used to control security. If you add a user to a site, the user is the principal, but if you add a group to the site, the group is the principal. The key to scaling security in SP 2010 is to keep the number of principals per scope reasonable. By using groups, a smaller number of principals can be used to grant access to a much larger number of users.

Claims authorization

Authorization refers to the process by which SP 2010 provides security for Web sites, lists, folders, or items by determining which users can perform specific actions on a given object. The authorization process assumes that the user has already been authenticated, which refers to the process by which SP 2010 identifies the current user. SP 2010 does not implement its own system for authentication or identity management, but instead relies solely on external systems, whether Windows authentication or non-Windows authentication.


Get every new post delivered to your Inbox.