To Be or To Impersonate, that is the Question

[Gary Bagen]

Alrighty, my continued foray into accessing network resources from the
web server continues...

When employees hit the intranet ASP.NET applications on our web
servers (dev, test, prod), they may need access to network resources
from those servers (like the network printer or another network
share).

We are not running Kerberos so that throws out IIS impersonation of
the Windows user hitting the app. (<identity impersonate="true" /> in
web.config).

That leaves three options that I have found:
1) In the web.config of each app: <identity impersonate="true"
username="registry:HKLM\Software\HiddenCredential\ ASPNET_SETREG,userName"
password="registry:HKLM\Software\HiddenCredential\ ASPNET_SETREG,password"
/>

2) In the machine.config of each server: <identity impersonate="true"
username="registry:HKLM\Software\HiddenCredential\ ASPNET_SETREG,userName"
password="registry:HKLM\Software\HiddenCredential\ ASPNET_SETREG,password"
/>

3) In the ProcessModel of machine.config using the registery pointers
as above. If IIS 6, then the GUI Admin.

Between option 2 & 3, which is the preferred method? The applications
don't care, they'll get that user in either situation (unless they
override identity in web.config).

When I present these three options to the group I want to be able to
tell them the pros and cons between 2 & 3 since they appear very
similar on the surface. I think I understand that underneath option 2
has the worker process imporsonating an identity while option 3 has
the inetinfo.exe being the identity.

Thanks,
Gar

[Paul Glavich]

With option 1, obviously web.config is easier to access for a malicious user
than the machine.config (yes, you have the credentials encrypted, but it is
still easier to find this 'clue' than with the machine.config) as the
machine.config is locked down further using ACL's.

The machine.config option affects ASP.NET globally though, so any other
ASP.NET applications on the machine would also be affected.

What about setting up a defined network user, with only minimum priveleges
(to the printer and network share), and storing these credentials in the
database, to use for you to programmatically impersonate. Just a thought.

--
- Paul Glavich


"Gary Bagen" <garbage400@hotmail.com> wrote in message
news:8b702e36.0403050921.ca7e364@posting.google.co m...

> Alrighty, my continued foray into accessing network resources from the
> web server continues...
>
> When employees hit the intranet ASP.NET applications on our web
> servers (dev, test, prod), they may need access to network resources
> from those servers (like the network printer or another network
> share).
>
> We are not running Kerberos so that throws out IIS impersonation of
> the Windows user hitting the app. (<identity impersonate="true" /> in
> web.config).
>
> That leaves three options that I have found:
> 1) In the web.config of each app: <identity impersonate="true"
> username="registry:HKLM\Software\HiddenCredential\ ASPNET_SETREG,userName"
> password="registry:HKLM\Software\HiddenCredential\ ASPNET_SETREG,password"
> />
>
> 2) In the machine.config of each server: <identity impersonate="true"
> username="registry:HKLM\Software\HiddenCredential\ ASPNET_SETREG,userName"
> password="registry:HKLM\Software\HiddenCredential\ ASPNET_SETREG,password"
> />
>
> 3) In the ProcessModel of machine.config using the registery pointers
> as above. If IIS 6, then the GUI Admin.
>
> Between option 2 & 3, which is the preferred method? The applications
> don't care, they'll get that user in either situation (unless they
> override identity in web.config).
>
> When I present these three options to the group I want to be able to
> tell them the pros and cons between 2 & 3 since they appear very
> similar on the surface. I think I understand that underneath option 2
> has the worker process imporsonating an identity while option 3 has
> the inetinfo.exe being the identity.
>
> Thanks,
> Gar