Hi

I'm having problems with forcing IIS to delegate requests to remote resources.
In order to solve the problem I wrote a simple Asp.Net application that reads a file on a remote server. Except for the 3 lines of code that open the file, I added:
‘<Identity impersonate="true" /> to the web.config file.

The site is set to use integrated security as the authentication type.

In these settings, delegation works when I access the site from localhost but fails when I access the site from another computer. If I change the authentication type to basic, everything works.

After some research I found out that the reason for this behavior is that integrated seucirty uses NTLM instead of Kerberos and therefore the IIS server only has a hash code of the user's password which cannot be used to further delegate requests. Basic works since the user’s password is sent in blank text to the server and therefore the server has the username and the password in order to delegate requests.

I also understood that in order to enable Kerberos I must set Active Directory to allow delegation.

The two options to do this are:
1. Set the computer account in Active Directory to be trusted for delegation (by checking a box in its properties).
2. Set IIS to run under a user account in the domain and set this account in active directory to be trusted for delegation.

I tried the first option but it didn't work.
As for the second option, I couldn't get IIS to run under an account of a user in the domain since the service is shared.

Some more details:
1. The OS is Win2k Server. (I also tried it on Win2k workstation and nothing worked either. The only difference was that the workstation did let me run IIS service under a user account, but this option didn't help also).
2. At some time in the past I changed the machine.config file in the framework configuration file. The change was in the tag <processModel> where I changed the attribute user="machine" to user="System".
This changed allowed uploading files to the server and allowed contacting LDAP
3.None of the accounts in active directory is marked 'sensetive and cannot be delegated'
4.All the browsers have their advanced options set to use integrated security.

If anyone solves this mystery it would be a lot of help.
Thanks.

something I have found is that if you still allow anon users then impersonation wont work its still registers the user on the ASPNET user rather than trying to authenicate themif you turn off the annon users then it forces IIS to authenicate them and will allow them to impersonate properly

if this causes a problem with the rest of you site then put it in to a sub folder and set the app setting on this area

There are a couple gotchas on using delegation. It sounds like you are well on your way to making it work however, and you understand exactly why things worked when on localhost versus a remote client. Please note that you must be in Native domain and not Mixed for Kerberos delegation to work.

Here are complete steps for Kerberos delegation to work:

Server-side tasks:
---------------------------------------------------------------------------------
1. IIS server is member of domain
2. Set IIS server computer account in AD Users & Computers MMC as "Trusted for Delegation"
3. IIS Server must be rebooted for this policy to take effect.
4. Integrated Windows Authentication only must be selected for site / virtual directory
5. IIS must not have NTLM only set as authentication method (this is usually not a problem, NEGOTIATE is default, so unless you specifically ran a script to change this, don't worry about it).
6. IIS server name either must match exactly account name in AD, or SetSPN tool should be used in cases where IIS site is set as alternative name (e.g. server is called server01.domain.com, and website is called www.application.com).

Client-side tasks
---------------------------------------------------------------------------------
1. Client must be using IE 5.x+. If client is running IE 6, ensure that "Enable Integrated Windows Authentication (requires restart)" is selected from Tools > Internet Options > Advanced.
2. Web site MUST be recognized as Local Intranet (not Internet Zone) site to client. I have not seen any documentation explaining why, but I just have never been able to get it to work otherwise. If necessary, specifically add this to Local Intranet sites list.
3. Client account must not be marked as "Sensitive, Do not Delegate" in AD Users and Computers MMC.

If all of that does not work, then there is possibility of bad hardware killing UDP packets for Kerberos (it has happened to me before).

Dunnry, thanks for your help. I guess the whole problem I was having since the beginning was that I was not passing the right credentials for search in active directory. Originally I thougth that IIS would operate just as a vb script, and would not need to be assigned a username and password. These are the changes that I made:


1. <identity impersonate = "true", username = " ", password = " " /> in the web.config application level

2. changed the username in the <processmodel username = "System"> and it worked.

Thanks a lot.

hello Ivan

Not wanting to point something that you might already know, but, are you aware that by doing "<processModel> where I changed the attribute user="machine" to user="System". "> you are executing your Asp.Net code with "System" priviledges?

In another words: "any code that executes in that server has total control over the box and (potentially the network)"

I hope you are the only one that is able to create and execute Aspx scripts on that server and that the server is very well protected from your internal network. If not, you could be in for a nasty suprise one of these days.

If you where already aware of this, sorry for poiting out the obvious.

Best regards