Why can't NTLM double hop?

Question

My understanding is that NTLM is a challenge response protocol, whereas Kerberos passes a ticket around. Most information I come across just says this is the reason Kerberos can double hop but NTLM can't, without explaining why NTLM can't just forward responses and challenges.

I.e., why isn't this scenario possible:

A client authenticates with a front end server, the front-end server then needs to authenticate with a back-end server on the clients behalf. The front end then attempts to authenticate and sends the user's name, the back-end then issues a challenge to the front end, the front end forwards this challenge to the client, the client issues a response that the front-end then forwards this response to the back-end.

I know that it doesn't work like this, but I am curious about specifics. Why can't a server forward responses and challenges allowing for a double hop?

Thanks.

Answer 1

While you could feasibly forward the challenge / response messages through an intermediary, what you're describing is not possible. What you described is not really double-hop authentication, what you describe is trying to authenticate a single session twice. NTLM authenticates a session, and a client should not reauthenticate an already authenticated session.

That is to say that in your example after the client has authenticated with the "front end server", that front end server could not then send a new challenge.

Answer 2

Unfortunately, when a client authenticates using NTLM, the front-end server cannot authenticate as the client to another (next-hop) server. This is because of how NTLM authentication works: the server sends the client a challenge, which the client combines with its password hash, computing another hash based on this combination and sending it back to the server. The only way to verify that the client’s returned value is correct and thereby authenticate it is by performing the same calculation on the server side, which requires access to the client’s real password (well, a hash of it, but for our purposes it’s the same thing). For security purposes the domain controller doesn’t hand out this password, which means the service server has to pass along the client’s authentication hash to the DC for verification. The DC then lets the front-end server know that all is okay with the client’s authentication.

Please see this blog post: https://blogs.msdn.microsoft.com/besidethepoint/2010/05/08/double-hop-authentication-why-ntlm-fails-and-kerberos-works/