IIS 7.5 running Classic ASP connecting to UNC path problem

Question

Moving from Windows Server 2003 to Windows Server 2008 R2. We have a classic ASP site that connect to a remote UNC '\10.1.40.7\' path. When I run PROCMON on the web server, it says ACCESS DENIED....Impersonating: NT AUTHORITY\IUSR.

On the 10.1.40.7 server, the IUSR_COMPUTER account was setup with the same password on both the web server and the file share server. This worked fine for IIS 6.

Moving this application to IIS 7.5 and going through just about every google page I can find along checking the iis.net, learn.iis.net pages has gotten me no closer to a resolution.

This script was ran on the Windows 2003 IIS 6 server to retrieve the IUSR_COMPUTER password: http:// www.iisfaq.com/Default.aspx?tabid=2796 -Sorry, first time poster, only 1 hyperlink permitted.-

Is classic ASP under IIS 7.5 really using just IUSR as the user, so if I get the IUSR password from IIS 7.5, and set that up on 10.1.40.7, It will work again?

Of course, it gets a little more complicated. This classic ASP web site also has some .NET mixed in with it. Again, everything works perfect on Windows 2003 IIS 6. So If some fix allows the Classic ASP to work, hopefully it won't break the .NET code.

Again, I have been through many documents. This article was pretty close to my issue: http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.inetserver.iis&tid=fafc2d90-662f-4c61-a2c4-5328303fc429&cat=&lang=en&cr=US&sloc=en-us&p=1

While I have you looking at this is there an App that you can run on the remote server that will tell you what ID someone is trying to use to access your share? For example in Windows XP under Computer Management, Shared Folders, Sessions/Open Files. You can see what current user is connecting to your share, but how do you see what other users are trying to connect(the failed attempts)?

!THANK YOU!

---UPDATE!---

Here is what I was able to find. Under the Default web Site, click Authentication, then for 'Anonymous Authentication', right click, Edit. Changed Specific User to my newly created IUSR_MACHINE user account.
Now when Classic ASP connects to UNC paths, it uses the specified account.
Is this the best Solution?

Recap: So on my old IIS 6 server, I had an account :IUSR_DELL-1SBLAH. I used the above link to extract the password for it. I then created that same user and ID on my new 2008 box. I changed the Anonymous Authentication to use that specific account.

Seems to work. Will test for a few days on some of the site to see if anything fails.

Also reading more of this document to see if this is a better method:

http:// www.iis.net/ConfigReference/system.webServer/security/authentication/anonymousAuthentication

Solution

Seems the above solution is working fine. Too bad no one else was able to chime in, I would like to know if this is the best solution.

Anyway, here is a recap.

Under the Default web Site, click Authentication, then for 'Anonymous Authentication', right click, Edit. Changed Specific User to my newly created IUSR_MACHINE user account. Now when Classic ASP connects to UNC paths, it uses the specified account.

Comments

[Coding Gorilla]

I think the solution you have is probably as good as you're going to get. The issue you ran into is that on IIS7.5 each application pool has it's own identity. The "IUSR" you were seeing is sort of a parent user, the actual app pool identity would be "IUSR_[AppPoolName]". This is different than IIS6; if you want more information about how that works just google around for AppPoolIdentity

[Powpow]

Thanks Coding Gorilla.. Based on that. I could possibly create an App Pool called DELL-1SBLAH. So it would end up being IUSR_[AppPoolName] or IUSR_DELL-1SBLAH. The problem would be determining the Password IUSR_DELL-1SBLAH is using to connect to remote computers. in Previous version of windows. IUSR_XXX was listed under LOCAL USERS AND GROUPS.. I can see all the IIS Users/AppPools under GROUPS >> IIS_IUSERS, but don't see how to view any info/passwords for them. Will see what Google has to say. Thanks again..