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_I NTERACTIVE (2) instead of
LOGON32_LOGON_N ETWORK (3). Here's the code snippet that gets access to
my users...
bool bValidUser =
LogonUser("UNAM E","DOMAIN","PA SSWORD",(int)LO GON32_LOGON_INT ERACTIVE,(int)L OGON32_PROVIDER _DEFAULT,ref
token);
System.Security .Principal.Wind owsIdentity myWI2 = new
System.Security .Principal.Wind owsIdentity(tok en);
System.Security .Principal.Wind owsImpersonatio nContext myWIC2 =
myWI2.Impersona te();
string sDir = "\\\\UNCPAT H";
string[] arFiles = System.IO.Direc tory.GetFiles(s Dir);
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_I NTERACTIVE 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_N ETWORK 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.
