Domain Admin is definitely overkill. IUSR etc. are local accounts - whilst the username might exist on another machine, the password is most likely different (unless you manually sync the passwords).
If you have an AD domain, then you can create a regular domain user account. Restrict the machines that the user can logon to (the IIS server and the file server), and use that account. The machine running IIS will use the "Connect As" credentials to connect to the File Server. As the account is a domain account, the credentials would be valid on the file server. The other option is to enable Kerberos delegation, but that's a whole different kettle of fish. Cheers Ken From: [email protected] [mailto:[email protected]] On Behalf Of Greg Keogh Sent: Tuesday, 3 January 2012 7:18 AM To: 'ozDotNet' Subject: Network shares as virtual directories (answer?) After an hour of stuffing around a few days ago I have found a way to overcome the password prompt and 403 errors trying to access files on a network share that is mapped as an IIS virtual directory. Procmon was telling me that NETWORK SERVICE impersonating IUSR was denied access to the network share. I thought that adding accounts like IUSR to the virtual directory would fix the problem, but no matter what accounts or stupid desperate combinations of accounts I added absolutely nothing would change the 403 error. So the problem was elsewhere. There is a option button when you create a virtual directory to change "Connect As ... Path Credentials". It was unclear what to put in the "Specific user" option, so I stuck the domain administrator name and password in. The problem is fixed. The relationship between the various accounts in the different IIS dialogs is unclear. I hope using the domain admin isn't dangerous overkill. I don't think so, as the path is readonly is IIS anyway and shouldn't open an external vulnerability. Greg
