In short: don't do it to yourself!
Okay, so that's not a realistic solution. But you know what? It is a pain in the butt. Terrible. Teeeeeeerrible. I've spent the last two days battling Kerberos, Active Directory, and NLB trying to figure out what the heck is going on with a test environment I'm building.
So this is what I came away with:
- Setting up Network Load Balancing. This is a great article on how to set up NLB before you set up your SharePoint environment.
- Setting up SharePoint with Kerberos. This is your starting point for configuring SharePoint for Kerberos. It's confusing as heck and creates an inordinate number of domain accounts which I think are totally extraneous, but it's the most extensive document that I found on the subject.
- Enabling Kerberos Logging. You're going to need it.
- Troubleshooting Kerberos/IIS Errors. Good tips on working with Kerberos.
- HTTP 401.1 with Kerberos. This document probably had the most important tip:
Important An SPN for a service can only be associated with one account. Therefore, if you use this suggested resolution, any other application pool that is running under a different domain user account cannot be used with Integrated Windows authentication only.
- Ask The Directory Services Team. A blog with many good posts on Kerberos issues. The Kerberos introduction is useful to start with.
- Wireshark. This will let you watch the Kerberos and DNS traffic which can help surface errors and provide more diagnostic information than the Windows Kerberos event logging alone. You can just trap all traffic on the physical interface and filter using "kerberos".
The tip in KB871179 was particularly useful since this, I think, was what was causing me all this trouble. Be sure that you're not registering an SPN multiple times!