LogonUser from ASP.NET

[laimis]

Hello everybody,

this is rather complicated, but intriguing problem that I have been having.
What I want to do is: after user connects to my asp.net application, I want
to elevate the thread's user from ASPNET to let's say administrator so that
priviledged operation could be performed. I don't want to change account
under which ASP.NET runs. My idea is to impersonate in COM+ app that runs
under priviledged account.

Currently here is how I have it implemented.

1. HttpModule intercepts the request for the application.
2. Module calls COM+ app that runs with priviledged account
3. COM+ app calls LogonUser to obtain security handle which later is used in
creating windows identity and impersonaiting the identity, thus receiving
context.
4. Context is returned to the module
5. Module uses it to assign to the current context of the executing thread

All of the steps work just fine. I call LogonUser, I can see in the security
log the succesful audit event. However, the context assigned doesn't make a
difference to the running thread and the thread's user still returns ASPNET.

Does anyone see a problem with my method?

Thanks!

Laimis

 

[Paul Clement]

¤ Hello everybody,
¤
¤ this is rather complicated, but intriguing problem that I have been having.
¤ What I want to do is: after user connects to my asp.net application, I want
¤ to elevate the thread's user from ASPNET to let's say administrator so that
¤ priviledged operation could be performed. I don't want to change account
¤ under which ASP.NET runs. My idea is to impersonate in COM+ app that runs
¤ under priviledged account.
¤
¤ Currently here is how I have it implemented.
¤
¤ 1. HttpModule intercepts the request for the application.
¤ 2. Module calls COM+ app that runs with priviledged account
¤ 3. COM+ app calls LogonUser to obtain security handle which later is used in
¤ creating windows identity and impersonaiting the identity, thus receiving
¤ context.
¤ 4. Context is returned to the module
¤ 5. Module uses it to assign to the current context of the executing thread
¤
¤ All of the steps work just fine. I call LogonUser, I can see in the security
¤ log the succesful audit event. However, the context assigned doesn't make a
¤ difference to the running thread and the thread's user still returns ASPNET.
¤
¤ Does anyone see a problem with my method?
¤

Not sure if I understand your configuration completely. Is the privileged operation being performed
by the COM+ application? From your description is appears that the COM+ application is already
running under a privileged account.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)

 

[Joe Kaplan \(MVP - ADSI\)]

Also, after you call LogonUser, do you take the resulting token and
impersonate it?

Joe K.

 

[laimis]

COM+ application is running under the priviledged account so that the
LogonUser could be invoked.

I do call impersonate with the token received.

I was just wondering if the impersonization was done on one thread that COM+
is running under and the ASP.NET request handling thread was not affected by
the impersonization since i call impersonate in the COM+ component.

I tried returning the Identity object that was created using the token
obtained from the LogonUser and then calling Impersonate from ASP.NET app.
However I would get error message saying that impersonation not allowed and
that web config should be modified or security setting for the application
chagned. What should I change in the config file to allow ASP.NET app to
call Impersonate?

Laimis

 

[sgelfmann]

There's an article that you might find helpful:
http://www.devx.com/SummitDays/Article/6666/0/page/1

If fact it mentions this on page 2:
"Since the worker process normally runs as ASPNET (with very few
privileges), this attempt to elevate privileges will fail. ".

 

[Joe Kaplan \(MVP - ADSI\)]

What error did you get when you tried to impersonate? Was it a
SecurityException or some other type of exception?

If the COM+ component is running as a separate server process, then the
impersonation will happen in the context of that process. It won't affect
what's going on the ASP.NET process.

Joe K.

 

[laimis]

Alright, that is what I was afraid, that the impersonation call in COM+ will
affect only the process that COM+ runs under. That's ok, since I just need
COM+ to call LogonUser to get the token handle.

The exception that I get while trying to call Impersonate from the ASP.NET
app is the SecurityException. Is the call to Impersonate() on the identity
also a priviledged operation that ASP.NET is not allowed to perform while
running under the machine account?

Thanks guys for the discussion and your suggestions and help,

Laimis

 

[Joe Kaplan \(MVP - ADSI\)]

This is a Code Access Security issue then. Apparently, your web application
is running in partial trust then and you don't have the SecurityPermission
with SecurityPermissionFlag.ControlPrincipal flag. According to the docs,
creating a WindowsIdentity from a token or impersonating a token directly
requires this:
..NET Framework Security:

a.. SecurityPermission for ability to manipulate the principal object.
Associated enumeration: SecurityPermissionFlag.ControlPrincipal.
What's in your <securityPolicy> node in web.config under system.web? Note
that this could be defined at the root website level or could be defined in
machine.config by the admin. I think SharePoint uses partial trust by
default, but plain ASP.NET does not.

Joe K.