Impersonation Redux

written by Ryan Rinaldi on Thursday, December 11 2003

So, I've been trying to get my stupid ASP.NET app to create a couple folders out on the network.  That would sound easy enough, but apparently Microsoft decided that was a security risk.  So I need to use Impersonation.  Okay, well I tried that but apparently trying to impersonate a web user that logged in using NT Authentication does not give that user network access (KB Article describing this is here). 

<RANT>

According to the KB article I linked to above, NT Authentication does not give you access to network resources.  BUT Basic Authentication does.

“So Ryan, what is the difference between the two?”, you ask.

Well, funny you should ask that.  You see NT Authentication passes a token from your machine to the web server informing the web server as to your identity.  The token contains no information that can actually be used to log you onto the machine in the event that somebody was to intercept it.  Now, Basic Authentication on the other hand passes your username and password in clear text to the web server.

I'll let that sink in for a minute or two.

[Ryan hums “The Spanish Flea“]

Oh sorry.  I'm back now.

If you didn't catch it, I said CLEAR TEXT.  Meaning anybody and their half retarded chihuahua can sniff your web traffic and log onto the machine as you.  And this abomination of security gives you greater access to the domain's resources?

Huff.

Either I am completely wrong when it comes to NT Authentication versus Basic Authentication or that needs some SERIOUS looking into.

</RANT>

Okay, so I'm done ranting now but that still doesn't solve my problem about Impersonation.  So I tried the standard .NET way of impersonating an user.  But as you can see, that didn't work.  So I tried using some interop and logging on as an user with a known username and password. [Thank you Scott for the post.  It gave me a glimmer of hope.]  That doesn't cut it either.  To make the LogonUser API call, the security context that the process is running under needs to have the “Act as part of the operating system.” flag set.  The ASPNET worker process does not.

Huff.

So it looks like I will be using the CreateProcessWithLogonW call, which allows me to spawn a new process under a new known logon, using that logons security credentials. 

So, as soon as I get that taken care of I'll probably wrap it up with a nice little bow and throw it out here for you.

Right now though, I'm going home.

posted in:

Blog and tagged as:

5 Comments

Similar Posts

  1. VSM354: Building .NET Office Solutions using Microsoft Visual Studio Tools for Office 2005
  2. Review: Axosoft OnTime 2004
  3. PDC2008: Reflections

Comments

  • Paul Bartlett on on 12.11.2003 at 10:04 AM

    Not sure if it's feasible in your scenario, but Kerberos supports "delegation" of credentials in a secure manner (i.e. supports it unlike NTLM, doesn't pass clear text passwords unlike Basic Authentication)...

  • Paul Bartlett on on 12.11.2003 at 10:18 AM

    Looks like Justin got there first and better: http://blogs.geekdojo.net/justin/posts/430.aspx

  • http:// on on 12.20.2003 at 5:41 AM

    I ran into a single problem trying to use COM server side automation with an app that required a user hive. It worked perfectly fine on my dev machine with the web service using impersonation (xp professional) but blew up on the win 2000 server (And probably nt 4.0) because they do impersonation differently. (One big difference, is that XP doesn't require act as part of the OS.)



    This probably won't work for the problem I was working on (the project is long since dead and the company sold, so I won't find out until my 10 mile long tasklist is cleaned out) but can you put your folder creation code into a COM+ package which runs as a specific user, and then lock it down? It shouldn't have the same act as OS requirement, and should get the job done.

  • Jon Galloway on on 2.20.2004 at 7:33 PM

    Argh. So I've done the exact same thing - saw the code on Scott's site, tried it, got access denied errors. I got to your post by searching on CreateProcessWithLogonW. Did you ever get it to work with CreateProcessWithLogonW? Is this a no go?

  • prashant on on 9.10.2004 at 8:00 AM

    Hi


    I am facing a same probloem with my application. My Client application is supposed to read files stored on server. My client's requirement is not to share server drives. So I created a hiden user on server and shared drives for it. When I launch my application on client machine I use CreateProcessWithLogonW and swith to the hidden user so that I can access the file on server. This works fine.


    But I have given automation support for my application. When a third party application call createdispatch of my client application dispatch gets created but my application doesnt get desktop. Also the calling application cant get dispatch handle back.


    If I stoppped locading profile through CreateProcessWithLogonW then everything works fine on XP but it gives problem on 2k.


    What can be a solution for this problem.

Comments are closed

Options:

Size

Colors