Impersonation and UNC network resources

Discussion in 'ASP .Net Security' started by Colin Nicholls, Mar 8, 2005.

  1. Hi guys -

    I've been getting knotted up with this for a few days now. Originally I was
    in an ASP.NET context (using VFP8 OleDB to access tables located on a
    network fileshare from inside of ASP.NET) but after much simplification and
    reduction, I've reduced my question to a simple .NET console application.
    The two tests I'm using in the console applications are: a) dirInfo on a
    network folder (as per the example) and b) an VFP8 OleDB connection.

    Excuse me for asking this question here in the aspnet.security when it could
    be a more generic problem, but there have been some great minds answering
    here...

    Anyway. I based my code on this excellent sample:
    http://www.netomatix.com/ImpersonateUser.aspx. It's using LogonUser() to
    impersonate a known DOMAIN\user with appropriate permissions.

    (I know the user credentials are fine, if for no other reason than because
    if I set up ASP.NET to impersonate the user, I have no problems, providing I
    don't cause ASP.NET to recompile the ASPX files. If I update the aspx files,
    I get an exception on the compiler permissions. I guess the impersonated
    user doesn't have appropriate rights.)

    I've stepped through the code and observed two things:

    On my laptop - a Windows XP Pro machine not part of the domain - the
    LogonUser() succeeds, but the directory code:

    System.IO.DirectoryInfo dirInfo = new
    System.IO.DirectoryInfo(@"\\SERVERNAME\sharename\folder");
    Console.WriteLine( dirInfo.Exists );
    string strFolderToCreate = @"\\SERVERNAME\sharename\folder" + "\\" +
    "boogle";
    System.IO.Directory.CreateDirectory(strFolderToCreate);

    I get:

    False
    Error: Could not find a part of the path "\\SERVERNAME\sharename".

    The Vfp OleDb code generates a "invalid path or filename" exception which I
    recognise from my regular VFP apps when directories aren't visible.

    Interestingly, when I run the console app on a different machine, Windows
    2000 SP3 which *is* on the DOMAIN, the LogonUser() fails with error 1314 -
    "A required privilege is not held by the client".

    I understand that on Wind2k I would have to allow this user account to "act
    as part of the operating system" - which I did, but it didn't seem to make
    any difference. Do I need to reboot???

    But apart from that - why would LogonUser() say it succeeded, but my code is
    still prevented from accessing the resources it needs?

    Question 2 is, I guess, is if this is insolveable, and instead of using
    custom impersonation code in my aspx.cs files, I *have* to use the
    web.config <impersonate true, user, DOMAIN> etc, then why does the recompile
    fail?

    If I'm being an idiot, please let me know.

    Thanks in advance,
    - Colin
     
    Colin Nicholls, Mar 8, 2005
    #1
    1. Advertising

  2. > Question 2 is, I guess, is if this is insolveable, and instead of using
    > custom impersonation code in my aspx.cs files, I *have* to use the
    > web.config <impersonate true, user, DOMAIN> etc, then why does the
    > recompile fail?


    Well, I don't know the answer to this, but I found a solution to the problem
    on a web thread posted by shamrox
    (http://forums.rainbowportal.net/ShowPost.aspx?PostID=5503):

    "Is this error happening when you try to run your project? I guess what I am
    asking is that it compiles fine but when it goes to the first screen you get
    this error. IE would never open if it didn't compile.

    If it is what I think it has to do with the aspnet_wp. It does some weird
    stuff. You don't have to restart www to fix it, all you need to do is go to
    task manager and [terminate the aspnet_wp.exe process]. Don't worry it
    restarts automatically. That will fix the problem for now. It comes up from
    time to time so if there is a better way I would like to know too."

    Thanks shamrox - this works for me. Now I can use the <impersonate ...>
    switch in the web.config in order for my web site to "see" the network
    resources, and when I upload a new version of the aspxs to my web site - it
    will stick on the recompile but a restart of the aspnet_wp.exe will fix it.

    I still don't know the answer to my Question 1 though.

    - Colin
     
    Colin Nicholls, Mar 9, 2005
    #2
    1. Advertising

  3. Colin Nicholls

    Paul Clement Guest

    On Wed, 9 Mar 2005 13:07:28 -0800, "Colin Nicholls" <> wrote:

    ¤ > Question 2 is, I guess, is if this is insolveable, and instead of using
    ¤ > custom impersonation code in my aspx.cs files, I *have* to use the
    ¤ > web.config <impersonate true, user, DOMAIN> etc, then why does the
    ¤ > recompile fail?
    ¤
    ¤ Well, I don't know the answer to this, but I found a solution to the problem
    ¤ on a web thread posted by shamrox
    ¤ (http://forums.rainbowportal.net/ShowPost.aspx?PostID=5503):
    ¤
    ¤ "Is this error happening when you try to run your project? I guess what I am
    ¤ asking is that it compiles fine but when it goes to the first screen you get
    ¤ this error. IE would never open if it didn't compile.
    ¤
    ¤ If it is what I think it has to do with the aspnet_wp. It does some weird
    ¤ stuff. You don't have to restart www to fix it, all you need to do is go to
    ¤ task manager and [terminate the aspnet_wp.exe process]. Don't worry it
    ¤ restarts automatically. That will fix the problem for now. It comes up from
    ¤ time to time so if there is a better way I would like to know too."
    ¤
    ¤ Thanks shamrox - this works for me. Now I can use the <impersonate ...>
    ¤ switch in the web.config in order for my web site to "see" the network
    ¤ resources, and when I upload a new version of the aspxs to my web site - it
    ¤ will stick on the recompile but a restart of the aspnet_wp.exe will fix it.
    ¤
    ¤ I still don't know the answer to my Question 1 though.

    I'm not sure if I understood your first question. If it has to do with accessing a network resource
    the problem is likely one of delegation, which is next step after impersonation.

    If you can confirm what type of application this is we might be able to help.


    Paul ~~~
    Microsoft MVP (Visual Basic)
     
    Paul Clement, Mar 10, 2005
    #3
  4. "Paul Clement" <> wrote in message
    news:...
    >
    > I'm not sure if I understood your first question. If it has to do with
    > accessing a network resource
    > the problem is likely one of delegation, which is next step after
    > impersonation.
    >
    > If you can confirm what type of application this is we might be able to
    > help.


    Hi Paul -

    The original application was an ASP.NET page (hence posting here) that uses
    OleDb to access Foxpro tables on a network share on a different physical
    machine. I could only get it to work if I used <identity impersonate="true"
    username="DOMAIN\netuser" password="***"/> in the web.config, which had
    other problems.

    I investigated workarounds, including performing impersonation in code
    bracketing the OleDb calls. I couldn't get it to work, and started reducing
    it down to a "simple" console app example.

    My example ended up looking like the sample here:
    http://www.netomatix.com/ImpersonateUser.aspx.

    So, forget the ASP layer; forget OleDb. It uses DirInfo to look at the
    folders. I can repro the problem with that sample.

    The network resource resides on a Win2K server (\\SERVER\Share\Folder) on
    domain DOMAIN.
    There is a known domain user, DOMAIN\netuser, that we want to use to access
    the resource.

    Test 1: Windows XP Laptop, not on the DOMAIN:

    When I run the console app from there, the LogonUser()/impersonation code
    seems to work (no errors, returns true, etc) but:

    DirectoryInfo dirInfo = new DirectoryInfo(@"\\SERVER\Share\Folder");
    Console.WriteLine( dirInfo.Exists );

    False

    string x = @"\\SERVER\Share\Folder" + "\\" + "test";
    Directory.CreateDirectory( x );

    Error: Could not find a part of the path \\SERVER\Share.

    Test 2: Win2k workstation, part of the DOMAIN:

    The LogonUser() fails with error 1314 - "A required privilege is not held by
    the client".

    So question 1 is really two questions:

    -- Why does the LogonUser fail on Windows 2k?
    -- Why, if the LogonUser succeeds, should the network resource still be
    unavailable?

    ....I get the feeling I have re-typed my first post. Sorry for that.

    Thanks in advance,
    - Colin
     
    Colin Nicholls, Mar 10, 2005
    #4
  5. Did you read the docs on LogonUser? It is pretty clear where it states you
    need the "Act as part of the operating system" privilege to call it under
    Win2K. Generally, only the SYSTEM account has this. You can add this
    privilege to any account you want to, but be very careful about that as it
    significantly compromises the security of your application.

    Another option for you would be using impersonation with Kerberos delegation
    or possibly setting up your process account as an appropriate domain account
    and not using impersonation. Lots of choices.

    Joe K.

    "Colin Nicholls" <> wrote in message
    news:uj6%...
    > "Paul Clement" <> wrote in message
    > news:...
    >>
    >> I'm not sure if I understood your first question. If it has to do with
    >> accessing a network resource
    >> the problem is likely one of delegation, which is next step after
    >> impersonation.
    >>
    >> If you can confirm what type of application this is we might be able to
    >> help.

    >
    > Hi Paul -
    >
    > The original application was an ASP.NET page (hence posting here) that
    > uses OleDb to access Foxpro tables on a network share on a different
    > physical machine. I could only get it to work if I used <identity
    > impersonate="true" username="DOMAIN\netuser" password="***"/> in the
    > web.config, which had other problems.
    >
    > I investigated workarounds, including performing impersonation in code
    > bracketing the OleDb calls. I couldn't get it to work, and started
    > reducing it down to a "simple" console app example.
    >
    > My example ended up looking like the sample here:
    > http://www.netomatix.com/ImpersonateUser.aspx.
    >
    > So, forget the ASP layer; forget OleDb. It uses DirInfo to look at the
    > folders. I can repro the problem with that sample.
    >
    > The network resource resides on a Win2K server (\\SERVER\Share\Folder) on
    > domain DOMAIN.
    > There is a known domain user, DOMAIN\netuser, that we want to use to
    > access the resource.
    >
    > Test 1: Windows XP Laptop, not on the DOMAIN:
    >
    > When I run the console app from there, the LogonUser()/impersonation code
    > seems to work (no errors, returns true, etc) but:
    >
    > DirectoryInfo dirInfo = new DirectoryInfo(@"\\SERVER\Share\Folder");
    > Console.WriteLine( dirInfo.Exists );
    >
    > False
    >
    > string x = @"\\SERVER\Share\Folder" + "\\" + "test";
    > Directory.CreateDirectory( x );
    >
    > Error: Could not find a part of the path \\SERVER\Share.
    >
    > Test 2: Win2k workstation, part of the DOMAIN:
    >
    > The LogonUser() fails with error 1314 - "A required privilege is not held
    > by the client".
    >
    > So question 1 is really two questions:
    >
    > -- Why does the LogonUser fail on Windows 2k?
    > -- Why, if the LogonUser succeeds, should the network resource still be
    > unavailable?
    >
    > ...I get the feeling I have re-typed my first post. Sorry for that.
    >
    > Thanks in advance,
    > - Colin
    >
    >
     
    Joe Kaplan \(MVP - ADSI\), Mar 11, 2005
    #5
  6. "Joe Kaplan (MVP - ADSI)" <> wrote
    in message news:...
    > Did you read the docs on LogonUser? It is pretty clear where it states
    > you need the "Act as part of the operating system" privilege to call it
    > under Win2K. Generally, only the SYSTEM account has this. You can add
    > this privilege to any account you want to, but be very careful about that
    > as it significantly compromises the security of your application.
    >


    Yes, thanks, Joe, I tried that. It didn't seem to make any difference. And
    it doesn't explain the WinXp results.

    > Another option for you would be using impersonation with Kerberos
    > delegation or possibly setting up your process account as an appropriate
    > domain account and not using impersonation. Lots of choices.


    Yup, and some learning on my part. Thanks for the pointers.

    - Colin
     
    Colin Nicholls, Mar 11, 2005
    #6
  7. Another helpful thing is to check the value of
    System.Security.Principal.WindowsIdentity.GetCurrent().Name to see what the
    identity of the current thread is when you call the code.

    If you change the process account but are impersonating, then the
    impersonated account will be used to call LogonUser. In that case, the
    impersonated account would need the extra privilege.

    Joe K.

    "Colin Nicholls" <> wrote in message
    news:...
    > "Joe Kaplan (MVP - ADSI)" <> wrote
    > in message news:...
    >> Did you read the docs on LogonUser? It is pretty clear where it states
    >> you need the "Act as part of the operating system" privilege to call it
    >> under Win2K. Generally, only the SYSTEM account has this. You can add
    >> this privilege to any account you want to, but be very careful about that
    >> as it significantly compromises the security of your application.
    >>

    >
    > Yes, thanks, Joe, I tried that. It didn't seem to make any difference. And
    > it doesn't explain the WinXp results.
    >
     
    Joe Kaplan \(MVP - ADSI\), Mar 11, 2005
    #7
  8. "Joe Kaplan (MVP - ADSI)" <> wrote
    in message news:...
    > Another helpful thing is to check the value of
    > System.Security.Principal.WindowsIdentity.GetCurrent().Name to see what
    > the identity of the current thread is when you call the code.
    >
    > If you change the process account but are impersonating, then the
    > impersonated account will be used to call LogonUser. In that case, the
    > impersonated account would need the extra privilege.


    Interesting. I'll check this out. I'm fairly sure, though, that because the
    LogonUser() call appears to be successful under WinXp, that the user account
    I expect is, in fact, being used. But I'll check.

    Thanks
    - Colin
     
    Colin Nicholls, Mar 11, 2005
    #8
  9. Remember that anyone (just about) can call LogonUser on XP or 2003, so you
    aren't likely to see any surprising privilege issues on those OS's. Thus, I
    would expect to see LogonUser work in general on XP, regardless of your
    impersonation settings.

    Joe K.

    "Colin Nicholls" <> wrote in message
    news:...
    > "Joe Kaplan (MVP - ADSI)" <> wrote
    > in message news:...
    >> Another helpful thing is to check the value of
    >> System.Security.Principal.WindowsIdentity.GetCurrent().Name to see what
    >> the identity of the current thread is when you call the code.
    >>
    >> If you change the process account but are impersonating, then the
    >> impersonated account will be used to call LogonUser. In that case, the
    >> impersonated account would need the extra privilege.

    >
    > Interesting. I'll check this out. I'm fairly sure, though, that because
    > the LogonUser() call appears to be successful under WinXp, that the user
    > account I expect is, in fact, being used. But I'll check.
    >
    > Thanks
    > - Colin
    >
    >
     
    Joe Kaplan \(MVP - ADSI\), Mar 11, 2005
    #9
  10. Joe -

    Thanks for your suggestions. Very helpful. I added some debug code to report
    the Principal.WindowsIdentity like you suggested. Let me describe what I am
    seeing and see if it makes sense:

    I'm logged into my laptop as LAPTOP\colin. LAPTOP is WindowsXP, not part of
    the domain.
    I run my test program, which attempts to impersonate DOMAIN\netuser.

    Here is the console.WriteLine() debug output that I see:

    Current/Normal user: LAPTOP\colin
    After impersonating: LAPTOP\netuser
    Directory exists: False
    Create folder: Error: Could not find a part of the path \\SERVER\Share.

    (LAPTOP\netuser exists and has the same password as DOMAIN\netuser.)

    I've read and been told that LogonUser() works on local accounts. It seems
    that it ignores the domain part of the account and finds a local user and
    successfully logs in using that.

    I suspect that if LAPTOP were part of the NT DOMAIN, and there was a trust
    relationship thingy in place, then the network resource would be available.

    I ran the same test on the Win2k workstation. Now I see:

    Current/Normal user: DOMAIN\colin
    Error: LogonUser failed with error code : 1314

    In other words, I am logged into the workstation with my NT Domain
    credentials...

    Just for kicks, my Workstation's Local Security Policy setting for "Act as
    part of the operating system" looks like this:

    WORKSTATION\netuser [x]
    WORKSTATION\aspnet [x]
    DOMAIN\colin [x]

    Perhaps instead of trying to impersonate "DOMAIN\netuser", I should be
    trying to impersonate "WORKSTATION\netuser" and then rely on the trust
    relationship thing.

    - Colin
     
    Colin Nicholls, Mar 11, 2005
    #10
  11. You definitely need to have your laptop be a domain member if you want to
    authenticate a domain account using LogonUser. That user needs to be able
    to login, after all.

    I'm still not sure why your console application is failing on LogonUser with
    1314 if the account you are running under really has "act as OS" privilege.
    Did you log out and log back on after that?

    In general, if you need to access the network share with a domain user's
    privileges, it would make the most sense to be able to use the domain user
    account on the local machine as well.

    Another option would be to set up your ASP.NET processModel on the Win2K box
    to run as the required domain user (and turn off impersonation). Then,
    access to the network share would use its credentials. There are some kbase
    articles on how to set this up correctly.

    Joe K.

    "Colin Nicholls" <> wrote in message
    news:...
    > Joe -
    >
    > Thanks for your suggestions. Very helpful. I added some debug code to
    > report the Principal.WindowsIdentity like you suggested. Let me describe
    > what I am seeing and see if it makes sense:
    >
    > I'm logged into my laptop as LAPTOP\colin. LAPTOP is WindowsXP, not part
    > of the domain.
    > I run my test program, which attempts to impersonate DOMAIN\netuser.
    >
    > Here is the console.WriteLine() debug output that I see:
    >
    > Current/Normal user: LAPTOP\colin
    > After impersonating: LAPTOP\netuser
    > Directory exists: False
    > Create folder: Error: Could not find a part of the path \\SERVER\Share.
    >
    > (LAPTOP\netuser exists and has the same password as DOMAIN\netuser.)
    >
    > I've read and been told that LogonUser() works on local accounts. It seems
    > that it ignores the domain part of the account and finds a local user and
    > successfully logs in using that.
    >
    > I suspect that if LAPTOP were part of the NT DOMAIN, and there was a trust
    > relationship thingy in place, then the network resource would be
    > available.
    >
    > I ran the same test on the Win2k workstation. Now I see:
    >
    > Current/Normal user: DOMAIN\colin
    > Error: LogonUser failed with error code : 1314
    >
    > In other words, I am logged into the workstation with my NT Domain
    > credentials...
    >
    > Just for kicks, my Workstation's Local Security Policy setting for "Act as
    > part of the operating system" looks like this:
    >
    > WORKSTATION\netuser [x]
    > WORKSTATION\aspnet [x]
    > DOMAIN\colin [x]
    >
    > Perhaps instead of trying to impersonate "DOMAIN\netuser", I should be
    > trying to impersonate "WORKSTATION\netuser" and then rely on the trust
    > relationship thing.
    >
    > - Colin
    >
     
    Joe Kaplan \(MVP - ADSI\), Mar 11, 2005
    #11
  12. "Joe Kaplan (MVP - ADSI)" <> wrote
    in message news:%...
    > You definitely need to have your laptop be a domain member if you want to
    > authenticate a domain account using LogonUser. That user needs to be able
    > to login, after all.


    Yeah, that's how I figure it. I was just curious as to explain what I was
    seeing, but I think I have that straight now, thanks!

    > I'm still not sure why your console application is failing on LogonUser
    > with 1314 if the account you are running under really has "act as OS"
    > privilege. Did you log out and log back on after that?


    Um, I think so, but I want to do more tests before I say for sure <grin>.

    > Another option would be to set up your ASP.NET processModel on the Win2K
    > box to run as the required domain user (and turn off impersonation). Then,
    > access to the network share would use its credentials. There are some
    > kbase articles on how to set this up correctly.


    Yes, I understand. I have the ASP.NET app working now (with <identity
    impersonation/>) so the urgency is not as much as it was. I understand the
    processModel would be another way to go that would probably work as well.

    I will persevere with the simple console impersonation to make sure I
    understand what is going on.

    Thanks for all your help, I appreciate it.
     
    Colin Nicholls, Mar 11, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dwaine
    Replies:
    0
    Views:
    550
    Dwaine
    Feb 16, 2004
  2. Dwaine
    Replies:
    0
    Views:
    255
    Dwaine
    Feb 17, 2004
  3. Tom Bennart

    Impersonation doesn't work with UNC

    Tom Bennart, Jun 9, 2006, in forum: ASP .Net Security
    Replies:
    4
    Views:
    137
    Tom Bennart
    Jun 11, 2006
  4. Steve
    Replies:
    0
    Views:
    256
    Steve
    Jun 8, 2007
  5. KittyHawk

    Impersonation on Remote UNC

    KittyHawk, Jun 11, 2007, in forum: ASP .Net Security
    Replies:
    3
    Views:
    248
    KittyHawk
    Jun 19, 2007
Loading...

Share This Page