About ASP.Net Impersonation

[Andrew]

Hello, friends,

Our asp.net app needs to access other servers from our IIS servers. In
web.config, we set:

<identity impersonate="true"/>

However, this works on some IIS servers, and does not work on the rest of
IIS servers. We have to explicitly set:

<identity impersonate="true" userName="IISGroup\userName"
password="password" />

to make it work again.

Why? Any ideas? We don't want to have userName/password in web.config...

Thanks a lot.

 

[Joe Kaplan \(MVP - ADSI\)]

In order to delegate a user's security context that was authenticated with
integrated Windows auth, you need to properly configure Kerberos delegation.

The best thing you can do for yourself is get yourself Keith Brown's book
(The .NET Developer's Guide to Windows Security) and read about it. You can
also read it online.
http://www.pluralsight.com/wiki/default.aspx/Keith.GuideBook.HomePage

There are also some good articles on the MS website that you can search for.

Joe K.

 

[Dominick Baier [DevelopMentor]]

Hello Joe,

First of all - why do you set impersonate to true - in the original question
i cannot see that this is a requirement??

just my usual rant about auto impersonation

 

[Joe Kaplan \(MVP - ADSI\)]

I don't think the OP was specific about why he needed to access the remote
resource with the logged on user's credentials.

I always forget that you prefer to impersonate only when necessary by
creating a WindowsImpersaonationContext from Context.User.Identity. It is a
better solution for sure in terms of tightening up the security.

Don't you have a blog posting referencing this technique and expanding on it
more?

It seemed like his first order of business though was to get Kerberos
delegation working.

Joe K.

 

[Dominick Baier [DevelopMentor]]

Hello Joe,

"Our asp.net app needs to access other servers from our IIS servers"

i still see no need for impersonation ....

that's why i was asking...

 

[Joe Kaplan \(MVP - ADSI\)]

Yes, he was not totally clear on whether he really needed a delegated model
(implying impersonation) or a trusted sub-system. Perhaps he will
elaborate.

I took his comment regarding not wanting to put specific credentials in the
impersonate tag to indicate that he wanted a delegated model, but the fact
that the solution worked that way perhaps indicates that a trusted
sub-system would be fine. That could be accomplished more cleanly with an
appropriate process account and no impersonation of either the authenticated
user or a service account.

Joe K.

 

[Paul Clement]

On Thu, 15 Dec 2005 09:21:17 -0800, Dominick Baier [DevelopMentor]

¤ Hello Joe,
¤
¤ First of all - why do you set impersonate to true - in the original question
¤ i cannot see that this is a requirement??
¤
¤ just my usual rant about auto impersonation
¤
¤ ---------------------------------------
¤ Dominick Baier - DevelopMentor
¤ http://www.leastprivilege.com

Hi Dominick,

I think you mentioned this before when I stated that impersonation needed to be enabled, but I never
followed up. The way I understand it is that if you don't enable impersonation at the app level, by
default the account that will be delegated is ASPNET (or NetworkService under Windows 2003) which
appears to the network as the Windows anonymous account (NT AUTHORITY\ANONYMOUS LOGON).. This is
determined by the userName value (which defaults to "machine") in the processModel section of the
Machine.config file.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Dominick Baier [DevelopMentor]]

Hello Paul,

it depends if you are in a domain or not - NETWORK SERVICE will authenticate
as MACHINE$ in a domain -

in non-domain environments you are right - it will appear as ANONYMOUS

You can always change the AppPool identity to something that has a meaning
on the remote machine - you can also do that using the processModel element
- but using IIS5 is insane anyway

 

[Paul Clement]

On Thu, 15 Dec 2005 22:38:26 -0800, Dominick Baier [DevelopMentor]

¤ Hello Paul,
¤
¤ it depends if you are in a domain or not - NETWORK SERVICE will authenticate
¤ as MACHINE$ in a domain -
¤
¤ in non-domain environments you are right - it will appear as ANONYMOUS
¤
¤ You can always change the AppPool identity to something that has a meaning
¤ on the remote machine - you can also do that using the processModel element
¤ - but using IIS5 is insane anyway
¤

Yeah, unless you're still using Windows 2000 (and a lot of folks are) which means you're stuck with
IIS 5.0. ;-)


Paul
~~~~
Microsoft MVP (Visual Basic)