Challenge 2: A Second-Hop SQL Query Losing the User's Identity --
Solution Walkthrough

This is the double-hop problem. Windows Authentication successfully
identifies the user to IIS itself -- that's the first hop, and it
works fine. The application then tries to use that same identity for
a second hop, calling a separate SQL Server machine and expecting the
database to see and enforce permissions for the original end user.
By default, a user's Windows identity cannot be forwarded past the
first hop at all: NTLM has no delegation mechanism whatsoever, so if
NTLM was used for the original authentication (including a silent
Negotiate-to-NTLM fallback per this chapter's own SPN gotcha), there
is no way to pass that identity onward under any circumstances.

Even if Kerberos was used successfully for the first hop, delegation
to the second hop still doesn't happen automatically -- it requires
explicit configuration: the Application Pool's identity account must
be trusted for delegation in Active Directory, and the target SQL
Server itself needs its own registered SPN. Without that explicit
setup, the second-hop call either fails authentication outright, or
succeeds using the Application Pool's own service account identity
instead of the original user's -- which would explain queries
"working" from the application's perspective while any per-user
permission enforcement on the SQL Server side never actually reflects
the real end user.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader recognizes the double-hop
problem by its real-world shape (an app trying to forward an
authenticated identity to a second backend server) and understands
that it isn't a bug to patch in application code -- it requires
explicit Kerberos delegation configuration in Active Directory, and
doesn't work under NTLM at all.