SharePoint Security And Authentication Part 4 Choosing The Right Authentication Strategy

When Designing authentications strategies for SharePoint 2010, there are guidelines to be aware of with the process for authentication with SharePoint Server 2010. So let's just get down to it. The authentication process is configured through the web application. A server farm may be configured to host sites for many organizations. However, the authentication is configured on an individual level for each of the organizations. It is possible for web applications in SharePoint Server 2010 to be configured with up to five different methods being used. Authentication for internal employees can be completed through one of the standard Windows methods. When a partner organization is involved, their employees can be authenticated with the identity management system that is in place for that particular organization. In order to be able to configure a web application so that it can be accessed by at least two systems of authentication, the additional zones must be configured in the web application. Each of the zones is a representation of a different path for accessing the same application. Typically when there is a partner application, the employees of a partner company are going to gain access to the application through the internet. Internal employees will be able to do so through intranet.  The zone type is a category for naming purposes but it won’t affect the overall configuration of a zone. Once you have successfully extended the web application, you can move on to configuring a new method of authentication for that zone. The default zone that will be in place should only be used by the internal employees. Partner access can be used by configuring the internet zone for forms based authentication.

If you are planning to implement more than one method of authentication for a web application, you will need to plan how to create those zones. There is some best practices to follow. The default zone can be use to implement secure settings for authentication. If a request isn’t able to be associated with a given zone then the settings and security policies of the default zone will apply. The default zone is one that is going to be created when you first initialized the web application. The secure authentication settings are to be used by end user access. Therefore, end users are the most likely to be the ones accessing the default zone. Use the least number of zones that are required by any given applications. Each of the zones will be associated with a new IIS site and domain. They will be used when a user is accessing that web application. You should only add new points of access when they are required. In order for content from the web application to be included in search results you need to make sure there is at least one zone configured with NTLM authentication. This requirement is going to result in the crawl content being indexed. Only create a dedicated zone for that indexing if it is necessary.

There are some methods of authentication that you need to consider when you are planning which of them you will use. Ensure that the methods of authentication are compatible with the browsers that your users will be accessing, understand the methods use for your user accounts to be managed, understand how credentials of users and identity are cached in SharePoint Server 2010, evaluate the pros and cons of each method of authentication available, and evaluate the security of the web applications to be used in SharePoint Server 2010.

Security should be a huge factor that you consider when you are looking at authentication methods for your applications. There are some common security environments for you to evaluate. External anonymous implementations allow for some access without authentication occurring. However, the permission is a read only basis. There isn’t the ability to modify. Authentication can be used to allow access to specific materials. External secure collaboration requires configuring a separate zone for each partner organization that will be connecting to the site. Once a user is no longer employed they won’t be able to continue accessing the application. Intranet implementations are used to protect the credentials of users from being in plain sight.

There are some significant advantages to using certain authentication methods. However, there are also some tradeoffs that occur as well. Exploring both sides of this issue will help you to determine which ones are best for your organization. The advantages of claims include the implementation being a collection of materials for the security token to determine if the user has permission to access a network. These types of materials can include a user name, password, role, or employee ID. All of which can determine the authorization as well as the level of permission.

The tradeoff is that the configuration to manage it all takes a great deal of planning and training. It can be a complex process that a person needs time to fully understand. Windows allows for the authentication of existing Active Directory Accounts to be used. This makes managing any given user simple to take care of. There is no need to write custom code either. Active Directory groups can be beneficial when you complete the configuration in SharePoint Server 2010. The trade off is that not all of the IIS authentication protocols offered are supported by the various web browsers. Therefore you will have to make sure those browsers users are going to use are going to be compatible with it. With forms based authentication, the environment doesn’t use AD DS or Windows accounts. It is possible to have more than one authentication method in place that can help with Identity Management Systems for partner applications to be completed. Authentication users come from the internet. It is possible to customize the authentication process to based on specific criteria. The trade off is that this also requires the web.config file to be customized. It can also be risky if the SSL is in place for an additional layer of security.

Share

SharePoint Security And Authentication Part 2 – User Management

The proper management of user identity information is very important for any organization deploying SharePoint. SharePoint Server 2010 makes it very easy to process user credentials and identifiers. This can also naturally help you to decide which method of authentication is best for your purposes. User identity information is processed in several ways based on category. They include:

  • Binary ID’s This is where ID’s are created in SharePoint Server 2010. A unique binary ID can be created with the provider name and the user name.
  • Cache This is the process of storing the identity of a user for a period of time. By doing so the process of authentication each time they make a request can be avoided. A cookie that is encrypted will keep the credentials for the user during a given session.
  • Role membership There can be different roles or groups that a given user belongs to. That information is also important during the authorization process. It is used to determine which actions a user is allows to access and perform. Both ASP.NET and Active Directory groups are considers to be the same in SharePoint Server 2010.

SharePoint Server 2010 provides a majority of the tooling or relevant API hooks to handle user accounts and to successfully manage them. The way you select for that management to occur can be influential for your authentication method decision. When users are members of a zone, their accounts can still be managed across all zones with the right permissions being granted. It is important to keep in mind all of these elements of user account management apply with SharePoint Server 2010. It doesn’t matter which is the authentication methods you select.

You can add new users from any zone for any authentication method that you have configured. However, the membership provider and role manager must first be registered with web.config file. SharePoint 2010 resolves the user name against sources:

  • UserInfoList table If a user has already been added to another site they will be found here.
  • Authentication Provider The configuration is for a current zone. That is where SharePoint Server 2010 will check for a membership provider first.
  • All other Authentication Providers If SharePoint Sever 2010 doesn’t find the membership in that current zone, it will look at all of the other authentication providers.

When any account is marked as deleted by the SharePoint Sever 2010 database they will be considered deleted. However, their record isn’t removed. Consider the fancy picture I have made below (select for an automagically larger image):

SharePoint Security Membership Provider

There are many instances when a user account behavior will change within SharePoint Server 2010. It will depend on what type of authentication the provider has in place what the appropriate response is. Understanding how those account tasks can be different with various authentication methods in place is important. They include:

  • Adding new users The user identity is validated using AD DS. SharePoint Server 2010 calls the membership provider and the role manager for verification of that both the user and the roles exist.
  • Changing Logon names When such updates are made they should be immediately recognized by SharePoint Server 2010. However, for this to occur you must delete the old account name and then add a new one.
  • Logging on A user doesn’t have to manually long on to SharePoint sites as long as Kerberos or NTLM is used. The browser also has to be configured for an automated log on to occur. When logging on is required, the user will need to enter a user name and password. This is a standard format for SharePoint Server 2010. Once the log on information is validated a cookie will be issued.

Next we will be talking about claims based authentication. For a refresher, there are about 20 claims articles already written for you review on the site:

Share

SharePoint Security And Authentication Part 1 – Understanding Authentication In SharePoint 2010

There are numerous authentication methods that are supported by SharePoint Server 2010. Through authentication the identity of a user can be validated. Once that occurs the process of authorization will also determine which sites, what types of content, and which of the features available a given user has authority to access. SharePoint Server 2010 can be considered a type of distributed application. There are three tiers that it is divided into which are all important to consider when determining your authentication strategy:

  • Application server
  • Back end database
  • Front end web server

Each of these tiers offers a sub-system and corresponding authentication. A user has to be authorized before they can go from one tier to the next. The provider has control over what levels of access each user has. Those providers offer various software elements that are used to support a specific method of authentication. With SharePoint 2010 you can use a classic mode of authentication or a claims based method. If you are upgrading from Microsoft Office SharePoint Server 2007 Microsoft documentation will recommended you use the classic mode, personally I think it's advisable to just go claims since you can use the identity generation service to generate Windows identities. If you plan to use a forms based authentication or one that is SAML token based you should use the claims based method. This is because the classic mode authentication will only support Windows authentication.

There are several methods of authentication that can be supported by SharePoint Server 2010. As you explore the basics of them you can decide what will work best for your organization. There are three:

Windows

This is the standard method of authentication. There are many methods that fall into this particular category. They include:

  • Anonymous This allows users to find and access resources from public areas of websites. They don’t have to provide any credentials for authentication to do so.
  • Basic This requires a user to have account credentials that have been assigned ala Windows. There is a web browser that is enabled to provide such credentials when someone makes a request. The credentials of users aren’t encrypted but sent across the network as clear-text. Therefore it isn’t recommended for the use of basic authentication to be used on any connection that isn’t secure. Always use SSL encrypting for additional security.
  • Digest This type of authentication is very similar in function to basic authentication. However, it offers a much higher level of security with it. The credentials are encrypted as they are sent across a network. The username and password can’t be deciphered along the way. Valid credentials must be given by a user that belong to the secret password string.
  • Certificates This offers an exchange of the public key certifications. The use of SSL encryption is used. These certificates are issued by a Certificate Authority. They have to fit the Public Key Infrastructure. This can be done by selecting Windows authentication in the Central Administration area. Once SSL is enabled then the configured certification can be obtained from Certificate Authority.
  • NTLM This is a requirement for any network that receives requests for authentication from client computers which don’t support Kerberos authentication. NTLM is secure and it allows for credentials of users to be encrypted before they are transmitted. Windows NT Server, Windows 2003 Server WorkGroup, and Active Directory use NTLM authentication. It may be the default and need to be disabled if you don’t want to use it.
  • Negotiate With negotiate authentication for either NTLM or Kerberos, they client has to choose one of them. The default is Kerberos. The client application has to provide a Service Principal Name and a User Principal Name for the account. When such information can’t be offered then NTLM has to be used for authentication.

Forms Based

This type of authentication offers support for management systems that need to make identifications. They aren’t based on Windows because they make it possible to work with identity management systems. These use the MembershipProvider interface. This includes:

  • Custom membership providers
  • Lightweight Directory Access Protocol
  • SQL Database

This based on ASP.NET as well as role provider authentication. With SharePoint 2010 it is only able to be used when claims based authentication is used. Forms Based Authentication can be used to be able to authenticate other user accounts too when connected to Microsoft SQL Server database. You need to register the membership provider in the Web.config file in order to use this type of authentication.

SAML Token Based

This type of authentication is claims based. It is created to support a Windows Identity Foundation. This is a set of .NET framework entities used for the implementation of claims based identity. They include:

  • 3rd Party identity providers
  • Active Directory Federation Services 2.0
  • Windows Live ID

Next, we are going to be talking about user management in this SharePoint security series.

Share