ASP .NET 2 Remoting User identity

[Brian Stoop]

Hi,

I have a TCP .NET 2 secure remoting interface and I can connect to it from a
remote Windows Console Remoting client, and when the service calls
"Thread.CurrentPrincipal.Identity.Name", the name of the user running the
client is found. All correct.

But when my ASP .NET 2 application calls it, it gets: "NT
AUTHORITY\\ANONYMOUS LOGON".

I have tried wrapping the ASP TcpClientChannel registration and call in
this code:

WindowsIdentity winId = (WindowsIdentity)HttpContext.Current.User.Identity;
WindowsImpersonationContext ctx = null;
try
{
// Start impersonating
ctx = winId.Impersonate();

....... but still I get ANONYMOUS LOGON.


Is is possible using a TcpClient Channel call from ASP .NET 2 application to
a remoting interface in a remote Windows Service, for the service to tell
the identity of the Web user ? Please note that I do not wish to use a
custom sink to pass it in, as this defeats the whole point.


Thanks B,

 

[Mr. Arnold]

Hi,

I have a TCP .NET 2 secure remoting interface and I can connect to it from
a
remote Windows Console Remoting client, and when the service calls
"Thread.CurrentPrincipal.Identity.Name", the name of the user running the
client is found. All correct.

But when my ASP .NET 2 application calls it, it gets: "NT
AUTHORITY\\ANONYMOUS LOGON".

All ASP.Net solutions run under the context of the ASP.NET worker process.
The ASP.NET worker process is using the NT AUTHORITY account, unless it is
being told other wise by using the <Identity> tag in the Web.config, which
allows the ASP.NET to impersonate its identity as a user running the
application.

It's being talked about in the link.

http://www.15seconds.com/Issue/020312.htm

So what you would do is set-up a generic account on the targeted machine so
that the solution using ASP.NET can impersonate the user account's
credentials.

 

[Brian Stoop]

I read the link and I appear to have set up okay. I checked my Web.config
and its set to:
<identity impersonate="true"/>

<authentication mode="Windows"/>

But I don't understand what you mean by "set-up a generic account". Do you
mean embedding a username and password in the web config like this:

<identity impersonate="true" name="impersonate_this_account"
password="passw0rd"/>



thanks, B.

 

[Mr. Arnold]

I read the link and I appear to have set up okay. I checked my Web.config
and its set to:
<identity impersonate="true"/>

<authentication mode="Windows"/>

But I don't understand what you mean by "set-up a generic account". Do you
mean embedding a username and password in the web config like this:

<identity impersonate="true" name="impersonate_this_account"
password="passw0rd"/>

That's what I mean. The user-id and password given for the impersonation
would match a NTFS account on the targeted machine, a special/generic
user-id and psw setup for this purpose only on the targeted machine. The
purpose of this special/generic/ account on the targeted machine is to allow
the ASP.NET solution access to resources.

The psw should be cryptic with a series of uppercase/lowercase characters,
some numericss and special characters.

You know, if you have used SQL Server on the back-end of an ASP.NET
solution where a generic user-id and psw is given in the connection string,
because Windows Authentication to login to SQL server for the ASP.NET
solution is not allowed, a generic user-id and psw is given in the
connection string.

 

[Brian Stoop]

The application has allready been configuered for the double-hop. The ASP
application connects to MS SQL with a trusted connection. I had to make a
custom APP Pool, map it to a domain user, and map that domain user via SPNs
for it to work. So now none of the database connection strings have users or
passwords.

The IIS, Application Service and MSSQL instances are on separate servers,
and members of a domain. Should the impersonate_this_account be a local
account on the IIS Server ?

Thanks again for you assistance, B

 

[Brian Stoop]

Thanks again for your time. I'm writing a custom sink to get around the
problem

Brian