Why kerberos sharepoint 2010

So for example if you have www. In our www. SVC would look like this:. Also, we recommend —S instead of the older —A because —S will ensure there are no duplicates. Enabling SharePoint to accept Kerberos for authentication is straight forward. You go into Central Administration, select Manage Web Applications, click in the whitespace to the right of the web application name you want and in the ribbon click the Authentication Providers option. From the Authentication providers dialog click on the default zone and in the Edit Authentication dialog select the drop down under Integrated Windows authentication and select Negotiate Kerberos.

Next scroll down and click the Save button. There are plenty of walkthroughs on how to do that. Once you have Fiddler running try to login to the site.

The initial request will get a HTTP response from the server unauthorized. There are two approaches to delegation — unconstrained and constrained. On the surface it would seem like unconstrained would be a better approach less constraining. However, unfortunately in a claims mode implementation will require constrained delegation. This was the method we used in SharePoint and for SharePoint when not using claims.

What we need to be able to do is to do a protocol transition. That is we need to be able to use our claims based authentication protocol and transition to a Kerberos login which we pass along.

Constrained delegation works like unconstrained delegation in that the service can reuse the credentials of the user except the credentials can only be used for prespecified services. When delegation is setup for the computer and service account the administrator specifies what services can be delegated to. This is essential.

I see that the user logged-in using Kerberos! So what now? Why was I still getting prompted to login? I forgot something—Internet Explorer security settings! If you have admin rights to the workstation, you can probably edit the list of sites in Intranet Zones in IE Security settings and enable automatic logon in Intranet sites Well, in my setup, the workstation—what a user can change and cannot change—is controlled by group policies.

After editing GPO, propagate the new policy by restarting the workstation. After the workstation restarts, I hit the SharePoint site again and no more login prompts!! Also, notice on the status bar that the SharePoint site is detected as an Intranet site:. Hopefully, this article demonstrated to you how to configure Kerberos for SharePoint If anything, this article serve as a jump point to other great articles out there on how to accomplish Kerberos in SharePoint.

List of links below. Save my name, email, and website in this browser for the next time I comment. Notify me of follow-up comments by email. Notify me of new posts by email. SharePoint Products environments use claims authentication for intra- and inter-farm communications with most SharePoint service applications and SharePoint integrated products regardless of the incoming authentication mechanism used.

This means that even where classic authentication is used to authenticate with a particular web application, SharePoint Products convert the incoming identity into a claims identity to authenticate with SharePoint Service Applications and products that are claims-aware. Note: Some products integrated with SharePoint Server, such as SQL Server Reporting Services, are not claims-aware and do not take advantage of the intra-farm claims authentication architecture.

SharePoint Server may also rely on classic Kerberos delegation and claims in other scenarios, for example when the RSS viewer web part is configured to consume an authenticated feed. Outbound identity in SharePoint Products represents the scenarios where services within the farm have to authenticate with external line-of-business systems and services.

Depending on the scenario, authentication can be performed in one of two basic conceptual models: Trusted subsystem In the trusted subsystem, the front-end service authenticates and authorizes the client, and then authenticates with additional back-end services without passing the client identity to the back-end system. The back-end system trusts the front-end service to do authentication and authorization on its behalf. The most common way to implement this model is to use shared service account to authenticate with the external system: In SharePoint Server, this model can be implemented in various ways: Using the IIS application pool identity — usually achieved by running code in the web application that elevates permissions while making a call to an external system.

Using a service account — typically achieved by storing application credentials in the Secure Store then using those credentials to authenticate with an external system.

Other methods include storing the service account credentials in other ways such as embedded connection strings. Anonymous Authentication — this is where the external system requires no authentication. Therefore the front-end SharePoint Server service does not have to pass any identity to the back-end system.

Note: Currently, most of the service applications that are included with SharePoint Server do not allow for outbound claims authentication, but outbound claims is a platform capability that will be taken advantage of in the future. Further, many of the most common line-of-business systems today do not support incoming claims authentication, which means that using outbound claims authentication may not be possible or will require additional development to work correctly.

The scenarios in this set of articles about Kerberos authentication require that the SharePoint Server service and external data sources reside in the same Windows domain, which is required for Kerberos constrained delegation.

The Kerberos protocol supports two kinds of delegation, basic unconstrained and constrained. Basic Kerberos delegation can cross domain boundaries in a single forest, but cannot cross a forest boundary regardless of trust relationship. Kerberos constrained delegation cannot cross domain or forest boundaries in any scenario. Some SharePoint Server services can be configured to use basic Kerberos delegation, but other services require that you use constrained delegation. NTLM does not allow this delegation.

Claims authentication, like Kerberos authentication, can be used to delegate client credentials but requires the back-end application to be claims-aware. Security — Features such as AES encryption, mutual authentication, support for data integrity and data privacy, just to name a few, make the Kerberos protocol more secure than its NTLM counterpart. If PAC verification is disabled or not needed, the service that authenticates the client does not have to make an RPC call to the DC see: You experience a delay in the user-authentication process when you run a high-volume server program on a domain member in Windows or Windows Server Kerberos authentication also requires less traffic between client and server compared with NTLM.

However, this improvement is typically not noticed on low latency networks on a per-transaction basis, but can typically be noticed in overall system throughput. Remember that many environmental factors can affect authentication performance; therefore Kerberos authentication and NTLM should be performance-tested in your own environment before you determine whether one method performs better than the other. The Kerberos version 5 protocol on the Windows platform supports two kinds of identity delegation: basic unconstrained delegation and constrained delegation: Type Advantages Disadvantages Basic delegation Can cross domain boundaries in a single forest Requires less configuration than constrained delegation.

Does not support protocol transition Secure. If the front-end service is compromised, client identity can be delegated to any service in the forest that accepts Kerberos authentication. Identities can only be delegated to specified service.

Cannot cross domain boundaries Requires additional setup configuration Kerberos enabled services can delegate identity multiple times across multiple services and multiple hops. Windows Server R2 and Windows 7 introduce new features to Kerberos authentication. In addition, you should make yourself familiar with IIS 7. Most of the basic concepts of configuring Kerberos authentication in SharePoint Products have not changed.

You still have to configure service principal names and you still have to configure delegation settings on computer and service accounts. However there are several changes that you should be aware of: Constrained Delegation — required for services which use the Claims to Windows Token Service.

Constrained delegation is required to allow protocol transition to convert claims to Windows tokens. In SharePoint Products, service applications use claims authentication and the Claims to Windows Token service, so these changes are no longer needed.