wntrunasuser err 1213 on win7 remote computer

[jat6923]

Have a program that remote associates on win7-64bit pcs need to run to map network drives.  They are logged into a workstation with a generic local user account then use a VPN Array connection to our computer network.   UAC is turned off.  Once connected I need them to run the program to add their personnel network drive maps based on their individual user network user id.   Program runs fine in testing at office in a simulated environment as a 64bit application. 

Here is the section of code:
:username
ret = wntRunAsUser("domain", otheruser, pword, 2, 1)
usr = StrTrim(StrUpper(AskLine("Information1", "Enter domain User ID: ", "", 0)))
If usr == ""  || !wntuserexist("\\loumilwps03.domain.com", "%usr%", 0)then
   Message("ALERT!!", "You must enter a valid DOMAIN%@crlf% Lan user id in the form of abc0000")
   goto username
endif
ret = wntRunasuser("", "","",0,0)

When associates run this, the code errors out on first line with an 1213 CMD Extender Minor Error.
Without the wntrunasuser line in testing, the wntuserexist statement never locate the domain account.

any suggestions.

[Deana]

Windows Vista/2008 or newer: wntRunAsUser cannot be use to escalate ( or elevate) privileges.

Also wntRunAsUser changes the security context of the script. Security context is nothing more than a sandbox in which programs can all play. When you are logged on to a NT platform system, your session consists of multiple processes, with each process running one program. When you connect a drive letter to a network resource, that drive letter only exists within your security context. Other sessions [e.g. other terminal sessions on a terminal server system, services running under separate user accounts different from your own] have separate security contexts and thus they don't see your drive letter mappings as they exist in their own private sandboxes.

When you use wntRunAsUser() to make use of impersonation in one form or another, you are causing your own process [e.g. via wntRunAsuser()] to run in a separate security context.

In the case of using wntRunAsUser(), it is obvious that your existing process continues executing your script, but the first time you attempt to access a resource on via mapped drive you get a failure because that drive letter doesn't exist in your process' security context.

[td]

Have a program that remote associates on win7-64bit pcs need to run to map network drives.  They are logged into a workstation with a generic local user account then use a VPN Array connection to our computer network.   UAC is turned off.  Once connected I need them to run the program to add their personnel network drive maps based on their individual user network user id.   Program runs fine in testing at office in a simulated environment as a 64bit application. 

Here is the section of code:
:username
ret = wntRunAsUser("domain", otheruser, pword, 2, 1)
usr = StrTrim(StrUpper(AskLine("Information1", "Enter domain User ID: ", "", 0)))
If usr == ""  || !wntuserexist("\\loumilwps03.domain.com", "%usr%", 0)then
   Message("ALERT!!", "You must enter a valid DOMAIN%@crlf% Lan user id in the form of abc0000")
   goto username
endif
ret = wntRunasuser("", "","",0,0)

When associates run this, the code errors out on first line with an 1213 CMD Extender Minor Error.
Without the wntrunasuser line in testing, the wntuserexist statement never locate the domain account.

any suggestions.

Assuming your simulation uses local and domain accounts with the same security level as is used in the field, there is no obvious reason why wntRunasUser should fail. 

It does seem strange that you you are getting the generic extender error number and message instead of a specific error generated by the extender.  This suggests that something quite out of the ordinary is going on in the extender.

I am hoping the Chuck C. will notice this topic and comment.  Because I have no suggestions other than perhaps checking all the possible difference between the in-house and field environments for clues as to the cause and perhaps trying the script in the field as a 32-bit exe instead of a 64-bit exe. There is some very small chance that it is bitness related.

[ChuckC]

Yes, I just saw this thread and read through it.

The OP states that UAC is disabled, and provided that the local user account has the LSA privileges required to create & impersonate an access-token, I would think that the call to wntRunAsUser() would execute properly.  Of course, the domain user account that is being passed in to wntRunAsUser() needs to have the LSA right to logon interactively on the computer since logon type "2" is being passed to wntRunAsUser().

One thing that looks slightly odd in the code is the call to wntRunAsUser() is that the domain name is specified as "domain", but in the call to wntUserExist(), the domain name is "loumilwps03.domain.com".  Additionally, the value of the variable "otheruser" is not being defined, and the value of the "usr" variable doesn't seem to be getting used to redefine the value of "otheruser".

I'm curious to know if the WWWBATCH.INI file is getting updated with any diagnostic information from the call to wntRunAsUser() that might be more helpful.

[td]

Thanx Chuck.  Good points.  Besides solving the user's issues, I am a bit concerned about the lack of a proper error message. Any info about the contents of the wwwbatch.ini file might be enlightening on both fonts.  Hopefully, we will hear back from same.