SPSTCDC: Setting up a Kerberos Configuration in a SharePoint Farm
I attended L. Carlos Rodriguez’ session entitled “Setting up a Kerberos Configuration in a SharePoint Farm” yesterday. As a developer, I knew a little bit about Kerberos coming in but wanted to get a better understanding of what it was, how it works, and why it seems to be every system administrator’s worst nightmare.
Carlos warned that since there was so much information to cover in 75 minutes, he likely wouldn’t be able to get to all of it. He wasn’t kidding! The talk was divided into 5 main subject areas:
- Authentication
- Kerberos
- SharePoint
- IIS
- SQL Server
As it turns out, SharePoint and Kerberos don’t have much in common. In fact, beyond selecting “Negotiate (Kerberos)” as an option for Windows authentication in the Authentication Providers for a new Web Application screen in Central Administration, one really doesn’t see mention of Kerberos inside of SharePoint anywhere at all (and even there, it’s in parentheses!)
NT LAN Manager (NTLM) was initially designed in the Windows NT days to handle local username and password authentication. SharePoint really wants you to use NTLM if possible. And what does SharePoint say if you do select Kerberos authentication? It pops up a message box indicating that “manual steps” must be performed by an administrator to complete the configuration. Of course, it doesn’t say what those steps are…
So why would anyone in their right mind want to use Kerberos? Well, since NTLM was originally designed for local authentication only, it does not handle transmitting credentials across the network all that well (or securely). In fact, 90% of problems people have passing credentials between systems in a SharePoint environment involve the so-called “double hop” problem: I log in to SharePoint using my NTLM credentials, but those credentials cannot be passed along to the SQL Server behind it (the “second hop”) and I receive an Access Denied error. (NTLM can be manipulated to connect between systems over the network, but the password is passed along and can easily be sniffed. Furthermore, NTLM requires re-authentication anytime a new resource is accessed.) Kerberos helps us overcome this!
Kerberos is a ticketing system that was initially invented at MIT. Despite its complexity, the system is actually quite simple and only consists of 6 or 7 different messages. Though it was initially invented for Unix, it works perfectly fine in a Windows environment as well (though Active Directory is a requirement for Kerberos in Windows). Because Kerberos tickets do not contain a user’s password, they can securely be passed around the network across many hops. Tickets are used for delegation and impersonation across the network. Tickets are time-sensitive (in fact, time synchronization across the network is very important!) and have a time-to-live of 5 minutes. After 5 minutes, a new ticket must be generated (this is done automatically, without the user having to re-enter his/her credentials). Tickets are granted by a Key Distribution Center (KDC) server. In a Windows environment, the Windows Time Service (w32time) is often adequate to provide the necessary time synchronization.
Kerberos requirements in a Windows environment:
- Windows 2000, XP, or greater
- TCP/IP (although it uses UDP as well)
- Open communication on port 88
- DNS
- Active Directory
In Kerberos, Service Principal Names (SPNs) are extremely important. Services (or protocols–Carlos wanted to make absolutely sure we knew to think of a service in terms of a protocol) in the network often make use of domain accounts. The SPN is associated with the account that the service instance uses to log on in Active Directory. A single account may have many SPNs associated with it (though it is generally not a best practice to use the same account for multiple different services). A domain controller or KDC will make LDAP queries for SPN records to locate services, and the SPN must be configured to be exactly correct. SPNs are case sensitive and there may not be duplicate SPNs or there will be errors, frustration, and lots of headaches! Furthermore, there must be DNS/NetBIOS name resolution, and all HOSTS/LMHOSTS files must contain only valid entries. SPNs are only set for service accounts.
SPNs may be created using ADSEdit or the SETSPN command, though ADSEdit is simpler. An SPN consists of a protocol or service, a hostname or URL, and an account. For example:
MSSQLSvc/mycomputer ServiceAccount
Beginning with Windows Server 2008 R2, it is necessary to create a privileged, non-Administrator user in Active Directory (that is part of the Domain Admins group) to manage these.
We played around with the Advanced Features option in Server Manager and used the attribute editor in Active Directory to learn about the different types of delegation (allowing a service to authenticate on behalf of a user) that may be configured:
- Regular delegation – turned on explicitly, allows the account to be trusted for delegation to any service without restriction
- Constrained delegation – restricts the service type to a set of hosts (an Access Control List on delegation, but using Kerberos only)
- Protocol Transition – from one protocol to another (e.g., Basic to Kerberos)
The session concluded with a discussion of tools that can be used to assist administrators with debugging and trobuleshooting in a Kerberos environment, including KLIST and Kerbtray. Carlos also indicated the value of a protocol analyzer tool such as WireShark (many members of the class agreed that WireShark is often the only way to truly get down to the bottom of many Kerberos problems!) and highly recommended Laura Chappell’s book Wireshark Network Analysis: The Official Wireshark Certified Network Analyst Study Guide.
The class consisted of a lot of lively discussion and many questions and answers from a very engaged audience. Carlos is an outstanding presenter with a great sense of humor, which kept everyone’s attention and made the sometimes difficult material very easy to understand. It certainly helped me to learn a lot more than I knew going in. My only regret is that he couldn’t get a half-day or full-day workshop to cover this subject with the detail and attention it deserves.
The slides from this session are available for download here.
Top Authors
No Comments
Trackbacks/Pingbacks