The Dreaded Double-hop dilemma and it’s dynamic destroyer, Kerberos

The "Double-hop" issue: Back in the good old days, Microsoft developed a way of authenticating clients (users) against a common database of User Name / Password pairs. They called it NTLM (for NT Lan Manager, as it managed authentication across a Lan… and they were prefixing everything back in those days with the letters NT… like NTFS, NTDS, NTCR, NTLDR and NTLM… something about corporate branding I suppose.) Back in those days, multi-tiered environments normally used either "process" accounts or an alternate form of authenticating between the first software tier and the second software tier (like a SQL account). Too easy.

Unfortunately, it wasn’t long before developers wanted to start passing through the user’s authentication details to a back-end system so that the data was secure as well as the interface to the data (Kind of makes sense – if an account is compromised, you only have the rights of the compromised account on the target system, rather than a god account *cough* sa, blank pwd *cough*). However, security restrictions on the ability for accounts to impersonate other accounts (or perhaps an architectural oversight ) meant that the NTLM authentication system was not secure enough to allow this sort of caper – so once you authenticate to a server, you need to use another account (programmatically) to get to the back-end data.

So how do you tell you’re suffering from double-hop madness? There’s a couple of dead giveaways.

  • First, the web application works the way you intended it to when you access it from the web server, where your access is either user or power user – but from your local machine you get access denied (Because you are already on the Web server, the first "Hop" is to the back end database. When you’re on your workstation, your first "Hop" is to the front end web server).
  • Second, you open up the web application page successfully but the back-end part of the application keeps getting requests for anonymous access in the security event logs every time you refresh the page.
  • You are constantly getting prompted to log in when accessing a site, even though you are entering valid credentials (although this can mean other things as well).

Kerberos was created to be more secure and faster than NTLM – and to fill the double-hop void… but by default, even it does not allow accounts to impersonate other accounts unless you explicitly force them to do so. That’s why you need to allow the service accounts of the web application to impersonate the user’s account that is currently logged into it.


About Brad Saide

I'm a SharePoint consultant. I'm also slowly going bald, seem to have a permanent spare tyre around my waist and enjoy socialising with friends over a beer or 10. The last 2 may possibly be related. Started working with SharePoint when the first version was in limited beta release (participated in the Technology Adoption Program while at Woolworths) and have been committed to the adoption of the technology as a business enabler ever since.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s