Kerberos Delegation issue! Web server isn't utilizing client's credentials to access remote re

Hi,

I'm developing an Intranet application that requires the Web server to impersonate a client to access remote resources (the app accesses my company's exchange server using WebDAV) on behalf of the client (all within the same Active Directory domain). However, I'm having a problem with the authentication delegation part- I don't think the user's credentials are being passed to the exchange server).

In my app, I attempt to use the DefaultCredentials of the user (which should be the user credentials of the logged-in user, since we use Integrated Windows authentication):

Request.Credentials = CredentialCache.DefaultCredentials;

If I build my own CredentialCache object (complete with hard-coded username, password, and domain) and set Request.Credentials to it, the app works fine.

Also, when running off my own computer's server (localhost)- i.e., delegation is not an issue- the app also works as expected.

I've confirmed that my server computer is trusted for delegation within Active Directory ('trust computer for delegation') . I've also confirmed that the client user accounts can be delegated within Active Directory.

web.config file for ASP.NET app:
<identityimpersonate="true"
/>
<authenticationmode="Windows"/>

machine.config file on server:
<
processModel
userName
="SYSTEM"
comImpersonationLevel="Impersonate"
(also tried "delegate")
..
<identityimpersonate="false"userName=""password=""/> (also tried "true")

According tothis link,
The server process account (the user account under which the server process is running, or the computer account if the process is running under the local SYSTEM account) must be marked as trusted for delegation in Active Directory.

I figure I must be missing something that prevents the server process account (SYSTEM, right?) to be trusted for delegation.. or is it something else?
I am using:
.NET Framework, ASP.NET 1.1
C#
Windows Server 2003
Exchange 2003

Any help would be greatly appreciated!

Thanks!!

[4113 byte] By [kevin888] at [2007-12-17]
# 1
It sounds suspiciously like the double-hop problem. The problem, if this is the case, is that you can't use delegation to hop from one machine to another. Part of the reason is technical, the other part a security risk. Needless to say the problem is that the client is authenticating to IIS (which works) but when IIS attempts to connect to another server it can't use the user's credentials because it doesn't have enough information (the double hop). Therefore the account it uses will likely fail. You can pretty easily verify this problem. If IIS is running under the correct user's context (display it on a test page) and the user can access resources on the IIS box with this user context (try a file or something) then delegation is working. Enable auditing of logon requests on the secondary server and see if the account coming across is valid. It is probably the ASPNET account or something. This is the problem.
There are numerous articles on how to work around this issue. Depends on what OS you're running and whatnot but I believe there is an option in the AD somewhere to permit a machine (such as IIS) to pass along the delegation to another machine (the second server). This would resolve the issue but you should never do this on a production, extranet web server since a hacker could get in and have access to not only your web server but also the secondary server. Here are some links on the issue and more solutions:
http://odetocode.com/Blogs/scott/archive/2005/02/24/1053.aspx
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sds/sds/troubleshooting_authentication_problems_on_asp_pages.asp
Hope this helps,
Michael Taylor - 10/13/05
TaylorMichaelL at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Base Class Library...
# 2

First of all, I want to thank you for your prompt response and apologize that my reply is so long overdue. There is a reason- although the information and resources you provided were extremely helpful, I have yet to determine the resolution for my problem. For those facing similar issues, I have found a wealth of resources that may help:

Helpful thread-
http://forums.asp.net/163508/ShowPost.aspx
Overview- http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/featured/kerberos/default.mspx
Troublshooting Kerberos Delegation-
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerbdel.mspx
Troublshooting Kerberos Errors-
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx
ASP.NET 2.0 Security Practices-
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGPractices0001.asp
Configure ASP.NET for a delegation scenario
http://support.microsoft.com/default.aspx?scid=kb;en-us;810572

For those with the patience to continue helping me with my issue, here's where I am:

Access to the secondary server is being attempted using the NTAUTHORITY\ANONYMOUS account

Why?
The Windows anonymous account is used by the operating system when an identity cannot be authenticated.

Why can't the identity be authenitcated?
The browser client is authenticated to the IIS ASPX page by using NTLM authentication. The NTLM protocol does not support delegation.

The Kerberos protocol is the default for Windows Server 2003, Windows 2000, and Windows XP- why is authentication using the NTLM protocol?
No idea...
--

Troubleshooting steps:
-All infrastructure requirements, according to 'Troubleshooting Kerberos Errors' are met.
-Using klist, I've confirmed that I do not have a session ticket, but I have a tgt
-Security event log shows that I am auditing successful logons using NTLM instead of Kerberos (logon user is the impersonated AD user, which is correct)

Client-
-Enable Integrated Windows Authentication is selected in IE
-Web app is in the Local Intranet zone
-user account is not sensitive to delegation

Server-
-Integrated Windows authentication is used, anonymous logon is disabled
-SPN has been set for the http/ header for the server computer account
-IIS server is trusted for delegation to any service

Upon configuring the registry to display Kerberos specific messages, the System event log of my IIS server occasionally shows this error when I access the Intranet website:

A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 17:58:36.0000 10/24/2005 Z
Error Code: 0xd KDC_ERR_BADOPTION
Extended Error: 0xc00000bb KLIN(0)
Server Name: host/serverName.domain.ad
Client Realm:
Client Name:
Error Data is in record data.

The Network Monitor also shows a similar error.

A possible cause, according to this site, is that the SPN to which the client is attempting to delegate credentials is not in its Allowed-to-delegate-to list. I'm not quite sure how to apply the recommended changes in AD. I'm trying to get an impersonated client to authenticate to the IIS server with Kerberos. Right clicking the user I am impersonating in AD does not give the option of a 'Delegation' tab. And it seems awkward that I would have to make these config changes for everyone that needs to authenticate to the IIS server using Kerberos.

Considering everything else, I'm assuming that this must be the issue. The problem is, I can't seem to find the right solution. Is it an AD configuration issue? Did I set my SPN incorrectly ('Server Name' in error log is in the server's spn list, along with http/servername.domain.ad, along with http/hostheader.domain.ad)? Is it really supposed to be this difficult?

Any comments, suggestions, or help would be greatly appreciated. Thanks for your time.

kevin888 at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Base Class Library...
# 3
If SPN is not properly set up for the service account in then the Delegation tab won't show up in the service account properties. You can use the SetSPN tool (available in W2K Resource Kit at least) to set up your server. I've only used it once but it was something like:
setspn -A servername:port serviceaccount
This is run on the server machine that you are delegating to if I remember correctly.
As far as NTLM goes if Kerberos can't be used (such as in load balanced environments or over proxy servers) then you'll go back to NTLM.
Some more articles for you:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerbdel.mspx
http://support.microsoft.com/default.aspx?scid=kb;en-us;810572
http://www.dotnet247.com/247reference/msgs/58/290448.aspx
Good luck,
Michael Taylor - 10/24/05
TaylorMichaelL at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Base Class Library...
# 4

FYI - our developer had add a web application pool with network service as the user account - but the other (working) application pools were using a domain service account which also had an SPN set up.

Once he changed his new app pool to use the domain service account ( and as such delegated authentication to the SPN) all worked OK.

PaulHillalphacomp at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Base Class Library...

.NET Development

Site Classified