ASP.NET Impersonation in a Windows 2003 non domain member server

[Johann Granados]

Hi everybody,

Is it possible to do ASP.NET Impersonation in a windows 2003 non domain
member server (locate at the DMZ)? If so, how can I do that?

Thanks in advance for your kind reply

Best regards,

Johann Granados
Staff DotNet

 

[Dominick Baier]

You need Windows authentication enabled for that.

Then you either generally impersonate for the length of the whole request
using the <identity impersonate="true" /> config switch - or programmatically
by calling

using (((WindowsIdentity)Context.User.Identity).Impersonate())
{
}

 

[Johann Granados]

Hi Dominick,

Thanks a lot for your answer.

I've tried both approaches you mention. They both work very well in a
domain member server but they don't work in a non domain member server (cause
there are no domain controller to authenticate the user). What I need is a
way to call a server component located at the internal network by passing it
a windows identity credential created at the non domain member server.

Thanks again for your help.

Best regards,

Johann Granados

 

[Joe Kaplan]

Yeah, you can't really do this as you can't create a domain identity to
impersonate on a non-domain machine. That's not the way Windows security
works. You would need a way to do this that didn't not require
impersonation.

Joe K.

 

[Johann Granados]

I found this article about Protocol Transition:
http://msdn2.microsoft.com/en-us/library/ms998355.aspx. It mentioned the
Service-for-User-to-Self (S4U2Self) for Kerberos implemented in Windows
Server 2003 (this service allows the developer to obtain a WindowsIdentiy
without passing out a password). The article does not mentioned if this
service works in a non domain member server but I guess it may does. Have
you ever heard this service? Have you used it?

Best regards,

 

[Joe Kaplan]

I have used it and it won't work for you either if the server isn't a domain
member. Sorry.

Joe K.

 

[Dominick Baier]

OK - you are talking about delegation. Which is something different.

Yeah - you need domain connectivity for that.

 

[Joe Kaplan]

I don't think he can impersonate a domain account on a non-domain member
machine whether or not he wants to delegate. He wouldn't be delegating if
he was using S4U or called LogonUser, but I don't think he can get that
logon token and impersonate it no matter what. Is that your understanding
of how it works?

Joe K.

 

[Dominick Baier]

"What I need is a way to call a server component located at the internal
network by passing it a windows identity credential created at the non domain
member server."

Well - the question is - do you need to call the internal component using
client credentials??

 

[Joe Kaplan]

It sounds to me like he just wants a way to call the component period and
needs to impersonate any domain account. Whether or not it is the client's
credential and he is delegating seems to be not as important.

I'm saying that I don't think you can impersonate a domain account on a
non-domain machine, but I'm not totaly positive, so I'm asking you.

Joe K.

 

[Dominick Baier]

you cannot impersonate a domain account on a non-domain machine.

What would work is to have mirrored accounts on both sides. This means that
on the server and the internal machine/domain there are two matching account
with the same uname/password.

Either the worker process runs as such an account - or this account is impersonated
before doing internal component access.

 

[Dominick Baier]

or maybe (though i haven't tried that) - you could impersonate a domain account
using a token created with the NEW_CREDENTIAL option.

 

[Joe Kaplan]

That's kind of what I was thinking too, but I haven't tried it either. Not
today though.

Joe K.