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,r ef
token);
System.Security.Principal.WindowsIdentity myWI2 = new
System.Security.Principal.WindowsIdentity(token);
System.Security.Principal.WindowsImpersonationCont ext 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/de.../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.