Impersonating doesn't work on Win2003

[fab]

Hello,

i'm trying to browse a UNC share through an ASP.NET application and i've got
a problem :
i've tried some examples from MSDN or other web sites (using LogonUser from
Win32 API) and it works perfectly from my computer (windows XP) but it
doesn't work from a windows2003 server : i've got the famous error 1326 :
Logon failure: unknown user name or bad password. ERROR_LOGON_FAILUREis
there a special configuration for Win2003 ? i've tried to set ASPNET user
account "as part of the operating sysem" in local security policy but it
makes nothing...

thanks in advance.

 

[Winista]

On Windows user account is "Network Service" and not ASPNET.

 

[fab]

i've also tried "Network Service" for the same result

 

[Winista]

For UNC path...

1. Make sure that you are impersonating as domain account who has rights on
the shares.
2. Make sure that web.config is modified to use impersonation.

Is file server same as web server?
Does your file server allow ASPNET/Network Service account to access the
share?

 

[fab]

the domain account has rights on the share because when i try to browse the
share from windows explorer, it works.
I've put <identity impersonate="true" /> " in the web.config (if i set this
parameter to false, it works on my winxp config)

The file server is not the same as the web server.
How can i give the network service account of the web server (witch is a
local account on the web server i think) access to the file server ? I
thought i've to give access to the file sever's share only the account that
i impersonate ?

 

[tommy.finch]

For what it's worth, I just solved this problem within my own ASP.NET
application. Here's the code snippet I used to do it. The fix for me
was changing the LogonType to LOGON32_LOGON_INTERACTIVE (2) instead of
LOGON32_LOGON_NETWORK (3). Here's the code snippet that gets access to
my users...

bool bValidUser =
LogonUser("UNAME","DOMAIN","PASSWORD",(int)LOGON32_LOGON_INTERACTIVE,(int)LOGON32_PROVIDER_DEFAULT,ref
token);
System.Security.Principal.WindowsIdentity myWI2 = new
System.Security.Principal.WindowsIdentity(token);
System.Security.Principal.WindowsImpersonationContext myWIC2 =
myWI2.Impersonate();

string sDir = "\\\\UNCPATH";
string[] arFiles = System.IO.Directory.GetFiles(sDir);

Before switching the LogonType, my try block would catch the the
'access to UNCPATH is denied' error. I don't use web.config
impersonation, but I do use integrated windows authentication (just so
I'm sure only people on the domain are accessing the intranet app I'm
building). With this method, I don't think either web.config
impersonation or integrated win auth have any bearing on the results.

From
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/logonuser.asp


LOGON32_LOGON_INTERACTIVE This logon type is intended for users who
will be interactively using the computer, such as a user being logged
on by a terminal server, remote shell, or similar process. This logon
type has the additional expense of caching logon information for
disconnected operations; therefore, it is inappropriate for some
client/server applications, such as a mail server.
LOGON32_LOGON_NETWORK This logon type is intended for high performance
servers to authenticate plaintext passwords. The LogonUser function
does not cache credentials for this logon type.

I figured that maybe LOGON_NETWORK wasn't keeping the appropriate user
cached for my attempt to access the UNCPATH. I hope this helps you
out, yesterday was a pretty infuriating day trying to puzzle this out.