Run as a different user. (Requires NT 4.0 or newer)
Windows Vista/2008 or newer: wntRunAsUser cannot be use to escalate ( or elevate) privileges.
wntRunAsUser( domain/server, user-name, password, login-type, flags)
(s) domain/server: the name of the domain or server on which the specified user account resides, or "." to indicate that the local account database should be searched for the user, or "" to indicate that the local account database and (then) any trusted domain account databases should be searched for the user.
(s) user-name: the name of the user to run as.
(s) password: the specified user's login password.
(i) login-type: see below.
(i) flags: see below.
(i) always 1.
login-type can be one of the following:
|
Type |
Meaning |
|
2 |
Interactive login: This logon type is intended for users who will be interactively using the machine, 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 operation, and is therefore inappropriate for some client/server applications, such as a mail server. |
|
3 |
Network login : This is the fastest logon path, but there is one main limitation. Any programs launched by the WIL script will not be able to access network resources. |
|
4 |
Batch login: This logon type is intended for batch servers, where processes may be executing on behalf of a user without their direct intervention. |
|
5 |
Service login: Indicates a service-type logon. The account provided must have the service privilege enabled. |
|
6 |
New credentials login: Indicates credentials are for remote connections only. Requires Windows Vista/2008 and newer versions of Windows. This login-type can be used as a replacement the wntAddDrive() function with the "\\workstation-name\IPC$" net-resource when the wntAddDrive() function method does not provide remote access for other WIL and extender functions. |
flag can be a combination of any of the following:
|
Flag |
Meaning |
|
0 |
Default. |
|
1 |
Allow new child processes to inherit security privileges. |
|
2 |
Load user profile into HKEY_USERS\<User SID> |
This function causes the specified user to be impersonated for the duration of the currently-running instance of the WIL Interpreter.
Required Privileges
The specified user must have the appropriate user rights assigned to be able to log in as a batch job or service. In order to use this function, the currently-logged-in user must have the following rights assigned:
"Act as part of the operating system"
"Increase quotas"
"Replace a process level token"
These user rights can be set in one of two ways:
(Note: these privileges will not take affect until next login)
1) Using the function wntPrivAdd
Act as part of the operating system
wntPrivAdd("\\server","server\user","SeTcbPrivilege",0)
Increase quotas
wntPrivAdd("\\server","server\user","SeIncreaseQuotaPrivilege",0)
Replace a process level token
wntPrivAdd("\\server","server\user","SeAssignPrimaryTokenPrivilege",0)
2) Or manually set user rights from the "Policy" menu in the NT User Manager (note that the "Show Advanced User Rights" option in the dialog box must be checked).
Password Protection
If you do not want password information displayed to a user in case of an error, make sure to create a variable for the password, as follows:
pswd="boom"; notice a variable has been created for the password
ret = wntRunAsUser( "", "Joe", pswd, 3, 0)
Do not hard code the password or use variable substitution. If you do the following, the password could be displayed to the user.
pswd="boom"; notice a variable has been created for the password
; WRONG this next line uses variable substition
ret = wntRunAsUser( "", "Joe", "%pswd%", 3, 0)
End impersonation
To end the impersonation in the script, you can specify a user name of "" .
wntRunAsUser( "", "", "", 0, 0)
User Profile
wntRunAsUser will not create a user’s profile, if the user has never logged on to the system before. The flag bit that requests that the user’s registry hive be loaded from the user’s own profile only works as expected if the user’s profile already exists. The RunWithLogon function that is built into WIL is capable of creating the user’s profile. see the RunWithLogon function in the WIL help file, for an alternative function to wntRunAsUser.
Windows Vista/2008 or newer: wntRunAsUser cannot be use to escalate ( or elevate) privileges. You can use this function to act as a specific standard user from an admin account as long as you do not run as an elevated admin.
Issues involved with RunWithLogon and wntRunAsUser when you change the credentials under which a program runs:
1. Drive mappings
RunWithLogon and wntRunAsUser change 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() or RunWithLogon() to make use of impersonation in one form or another, you are causing either your own process [e.g. via wntRunAsuser()] or another process [e.g. via RunWithLogon()] 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.
In the case of using RunWithLogon(), things are tougher because the process gets created in a new security context, but when it tries to execute the program that it was created to execute, that program is not accessible as the drive letter for the program path doesn't exist in that process' security context.
Note: If you are using NetWare servers, things are little worse off. When a process is created and it is in a new security context, or if an existing process begins impersonating another user, then the Novell Client's authentication information & mapped drive table changes when the security context changes. In a new security context, the Novell Client isn't authenticated to any servers and thus it has no drive letters mapped. It would be necessary for the program being executed to exist locally so that it could be accessed, and then the program would have to perform its own authentication to NDS/eDir before it could access any NetWare-related resources via either a UNC path or a mapped drive letter.
2. Elevation
Windows Vista/2008 or newer: wntRunAsUser cannot be use to escalate ( or elevate) privileges.
Windows 7: When UAC is on, a standard user can specify Administrative credentials but the script will still only act as a standard user. When UAC is off, a standard user can specify Administrative credentials but privileges actually get reduced to less than a standard users (anonymous impersonation.)
If you are an administrator and UAC is on, you can use wntRunAsUser to act as a standard user, as long as you don't elevate to full administrator privileges before you run the script. If you elevate first, wntRunAsUser basically doesn't lower your privileges and the process continues to use your administrator privileges.
; Load Appropriate Extender AddExtender('wwwnt34i.dll',0,'wwwnt64i.dll')
curuser=wntGetUser(@DEFAULT) Message("Current user:",curuser)
;run as new user user="Administrator" pswd="goat" ret = wntRunAsUser( "", user, pswd, 2, 0)
newuser = wntGetUser(@DEFAULT) Message("Running as new user:",newuser) Exit