Hi, Not necessarily - NTLM pass through authentication can be used: here the username is used only, plus the corresponding password. This is what allows you to use a common username/password on two workgroup machines and access resources on one from the other.
In the case here, Kerberos delegation is not going to be relevant unless the end user is a domain user, and all the machines are in the same Forest. If the end user is just an anonymous user, or ASP.NET authenticated user, then Kerberos is irrelevant. Cheers Ken -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of mike smith Sent: Saturday, 7 January 2012 3:51 PM To: ozDotNet Subject: Re: Network shares as virtual directories (answer?) On Tue, Jan 3, 2012 at 11:49 AM, Ken Schaefer <[email protected]> wrote: > 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). > And they'd still have different SIDs (IIRC) - isn't it the SID that's ultimately used? > > > 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. > Harder, but possibly more robust. > > > 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 -- Meski http://courteous.ly/aAOZcv "Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough" - Adam Hills
