401.1 Error when accessing virtual directory pointing to network share

Question

IIS5 is running on SERVER1.

One of the virtual directories in IIS, myfiles, is pointing to "A shared location on another computer", //SERVER2/myfilesshare

When I try to access the page: http://SERVER1/myfiles

... I get the error:

You are not authorized to view this page

HTTP 401.1 - Unauthorized: Logon Failed

Internet Information Services

I have triple-checked the "Connect As..." settings in IIS. The credentials I'm using to access the share are correct-- they work when connect to the share in Windows Explorer, but not through the IIS virtual directory. I've tried granting full permission to Everyone on the folder in SERVER2, but no luck.

Any thoughts?

Answer 1

This was how I solved my problem, might help you.

By default, IIS uses local user called IUSR for virtual directories when using anonymous authentication. It does not use application identity, which should be obvious, if you use procmon.

How can you force it to use application identity?

Easy, under IIS manager:

1) go to Authentication

2) Edit "Anonymous authentication"

3) Select "Application pool identity"

4) Restart IIS & it should work.

The same accomplished with PS: Set-WebConfigurationProperty -filter /system.WebServer/security/authentication/AnonymousAuthentication -name username -value ""

This link contains the pros/cons: http://blogs.technet.com/b/tristank/archive/2011/12/22/iusr-vs-application-pool-identity-why-use-either.aspx

Answer 2

Permission issues can be tricky. Try running filemon on the 'other computer' It can be downloaded over here: http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx (it's not a big application just a tiny lightweight tool)

After you've started filemon, stop the monitor process (I believe it's turned on by default when you start the application), clear the logged data, create a filter for the folder you have trouble getting access to. Start the monitor process. Request your webpage. Stop the monitor process and look for "access denied" messages in filemon. When found, filemon will also mention the name of the actual user which is trying to get access. This might help you to get to a solution.

Btw when using Windows Server 2008 you will need processmon instead: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Answer 3

Imagine a scenario where for whatever reason you want to have your IIS Server access a Share on a File server and they are not on the same domain.

If you can follow and get this to work for you (I have done it Win2008-R1 32-bit File Server and Win2008-R2 64-bit with IIS 7), then you should be in good shape for any scenario.

• Same name local account on both servers with same password
• On IIS, use aspnet_regiis -ga MyAccount to give local account access to IIS guts
• Now use that as the Application Pool Identity of the Website
• Using Local Security Policy (Admin Tools) enable trust for delegation for local account
• Restart IIS server
• On File Server, use Local Security Policy to enable access from network for local account
• Create Share granting desired permissions to local account (also Security tab permissions as needed)
• Open up File & Print Sharing ports on both (as restrictive as possible) to point where it works for you when you are using Windows Explorer between the two
• Back to IIS, create Virtual Directory using UNC path to Shared folder from File Server
• Just use Pass-through authentication (which would use your local account)
• You can tell Anonymous Authentication setting of the Virtual Directory to use Application Pool Identity as well

Use something that will test/verify. The key really is trust for delegation using a Service Account (domain or otherwise), and having IIS use the account you want it to use instead of Local Server or Network Service.

This took me all day to figure out. Various threads in StackOverflow and other Internet sources helped point me to various resources me but didn't find my exact answer anywhere. Hopefully next person stuck with this problem will get a speed boost on the path to resolving with my description of what worked for me.

Answer 4

try enabling windows authentication on the virtual directory security tab (in IIS).