Triple hop issue with ASP.NET delegation Part II: Fixing our remote users.

Where did I left the previous part?… ah yes, our Terminal Server users. Well the XP users were okay and happy but the remote users were not… what could possibly be different for both?

First, the OS, our remote users connect to windows servers (Windows 2000 Standard servers ) so we checked the kerberos.dll version and nope, everything was up to date…

We also checked the kerberos tickets for the logged user and there they were…We again checked our SPN on the domain (setspn), both the SQL Server service and our web service URL were registered in AD with the proper ports.

With the help of a tech support call we landed on this KB article:
Unable to negotiate Kerberos authentication after upgrading to Internet Explorer 6

Windows Server 2000 ships with Internet Explorer 5, it turns out that when IE5 is upgraded to IE6 the advanced option Enabled Integrated Security Option (requires restart) is checked off by default. This option is normally checked on on Windows Server 2003, Windows XP, Vista and 2008.

It turns out that this setting indicates to IE to use NTML as the authentication protocol when the option is unchecked.

This option is equivalent to the following registry key:

HKEY_CURRENT_USER\Software\Microsoft\Windows
\CurrentVersion\Internet Settings

and administrators can enable Integrated Windows Authentication by setting the EnableNegotiate DWORD value to 1

The name of the option is very misleading. You can find more information on this setting here, unfortunately I didn’t find much on the official Microsoft curriculum.

On our web server, we do not allow protocol transition which means the authenticated user should use Kerberos in order to enable the credentials to be delegated to a second hop:

The PROBLEM:

With the client set up to disable Kerberos authentication and with the IIS box set up to disable protocol transition, the credentials passed to the back end were not the end user credentials. Challenge protocols such as NTML do not allow delegation of credentials to a second hop.
A great article regarding the difference between Kerberos and the NTLM, WWW-Authentication such as Basic, Digest etc can be found on Larry Osterman “the Ping of Death”‘s amazing blog post.

The SOLUTION:

Enabling Protocol Transition on our web box at the domain controller would have done the trick:

Or setting up a Group Policy for our end users to have the IE setting checked up. See how to create a Group Policy here.

Cheers!

One thought on “Triple hop issue with ASP.NET delegation Part II: Fixing our remote users.”

Leave a Reply

Your email address will not be published. Required fields are marked *