Everyone who knows Kerberos will agree that it is still one of the most secure authentication mechanism but at the same time it is the dubious task to configure Kerberos authentication because his complexity and presents a difficult task to undertake if you don't know how. As with most things, if you have the right info, it is really quite easy.
Among the key benefits of Kerberos authentication that make it popular are:
This article will focus on how to get Kerberos working on IIS and how to solve double hop authentication issues.
There are many reasons why Kerberos authentication can be used rather than the default NTLM, but the main reason should be because it is faster and more secure than NTLM.
When any impersonated Web Application makes a request to IIS server, then IIS Server verifies the user token, as soon as your client browser is sends those along with the web request. Once the verification (which involves an windows active directory roundtrip) is completed, then IIS transfers that web request to ASP.NET Runtime, which can see the user's windows token as well. Now, inside the ASP.NET code, if there is a call to an external resource, like database server with Windows authentication, (which is your case), then same above mentioned complex process of verification against active directory will again happen. That process is called Double Hop issue. Your application is failing on the second verification process.
The second step of re-authentication will never happen, if web server and client browser is at the same machine. I think that's the case in your development environment. But If database is on separate machine, then that machine will reject your impersonated web user, because from database server view point, web server machine is not a trusted source of token sender and the active directory has not marked the windows user as delegated one.
Following are the steps which needs to be taken care for configuration of Kerberos Authentication.
The first thing you need to do in order to enable Kerberos for your web application is to configure Service Principle Names (SPN's) for the service account in Active Directory. Here lies the first stumbling block, depending on your configuration it is very hard to figure out which SPN's need to be applied to which accounts.
If you are installing the application properly, you'll use the "least privilege" account principle. These account should have the minimum privileges that they need to perform their jobs.
SPN's are used by Kerberos to ensure that only certain accounts have permission to delegate a specific service on a user's behalf. An SPN needs to be configured for each service and address that the account needs to delegate for. SPN's are configured by using SetSPN.exe (for Windows 2003 you can find it here). Take a care on the following points prior configuration:
Short overview on SetSPN tool can be reached here.
In addition to setting the SPN's for each of service accounts, it is also needed to trust each of the computer accounts and some of the service accounts for delegation. Trusting for delegation means that the accounts are allowed to delegate on a user's behalf.
In order to trust for delegation you need to open Active Directory Users and Computers as a user with domain administration rights and follow these instructions
This step-by-step article describes how to configure IIS to support both the Kerberos protocol and the NTLM protocol for network authentication.
IIS passes the Negotiate security header when Integrated Windows authentication is used to authenticate client requests. The Negotiate security header lets clients select between Kerberos authentication and NTLM authentication. The Negotiate process selects Kerberos authentication unless one of the following conditions is true:
To enable the Negotiate process to select the Kerberos protocol for network authentication, the client application must provide a service principal name (SPN), a user principal name (UPN), or a NetBIOS account name as the target name. Otherwise, the Negotiate process always selects the NTLM protocol as the preferred authentication method.
Detailed description can be found here.
So, now you are ready for the new challenges. Still if you have further difficulties, try these articles:
Would these same principles apply to setting up a WMS streaming server as well?
We have a MOSS 2007 farm and would like to setup a WMS server using Kerberos.
Josh@ yes, those are the principles of Kerberos, so you can apply them to WMS.
Odlicen post. Edno prasanje imam teoreticno dali e vozmozno...
Znaci imame MOSS07 koj ima intranet i extranet dostap. Na drug server imame publikuvano nekakov CMS koj e dostapen samo preku intranet. Dali e vozmozno, spored ova sto go procitav vo ovoj post, da moje preku extranet sharepoint site da se napravi delegation i da moje da se gleda CMS sajtot od drugiot server. Kerberos ke go napravi toa siguren sum, sum probal za fajlovi, no za aplikacii ne sum probla.
Sharepoint e publikuvan preku ISA2006 kako extranet, no CMS sajtot ne bi sakale da e preku ISA-ta.
Слободно пробај... :-)