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.