Impersonation and UNC network resources

[Colin Nicholls]

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]

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

 

[Paul Clement]

¤ > 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 ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)

 

[Colin Nicholls]

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\)]

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]

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

 

[Joe Kaplan \(MVP - ADSI\)]

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]

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\)]

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]

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\)]

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]

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?

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.