I'm trying to find the Window API for creating user profile.
I'm creating local user in windows, and i'm trying to run process with this user using CreateProcessWithLogonW with LOGON_WITH_PROFILE flag set.
Since the profile does not exist (the user was not interactively logged on yet) the CreateProcessWithLogonW fails.
When performing interactive logon with this user and then running the program it works.
Anyone knows how can I create user profile using Win32 API?
Thanks!
Lior
Try with User Profiles API (see http://msdn.microsoft.com/en-us/library/bb776901.aspx). On Vista and later you can use CreateProfile. On old systems you can use LogonUser and LoadUserProfile, UnloadUserProfile (see http://msdn.microsoft.com/en-us/library/bb762281.aspx).
Related
Delphi XE app running on Windows 2012 Server. How do I limit the user's permissions when they open Adobe Viewer using ShellExecute. As it stands now, the uses are not permitted to see the drivers on the server. However, when the user opens a pdf from the application, the permissions revert back to admin, which allows them to see and access the drives.
Are there settings within ShellExecute that can apply the proper permissions based on the user login credentials?
When you create a process using ShellExecute, the new process runs under the credentials of the parent process. So it would seem that the process with is calling ShellExecute has more rights than you wish to grant to the process that is started by ShellExecute.
One way to solve the problem would be to call ShellExecute from a process running under the desired credentials. There may be other ways to solve it, but without any knowledge of your network security configuration, it's unlikely that we can give you much more specific advice.
I have a process that runs as LocalSystem on Windows XP and following. I am trying to find a way to have it start another process impersonating another user without having to provide the user password.
In principle this should be possible as LocalSystem has the privilege "Act as part of the operating system". But I am unable to find the correct API.
Can somebody tell me how to do this either:
with an API, or
from a batch file?
You can do it by first getting the token of the user via WTSQueryUserToken, then calling CreateProcessAsUser to start the process. Note that you can only do this for a user who is currently logged-in in the system.
I've read all the posts on Stack Overflow about CreateProcessAsUser and there are very few resolved questions, so I'm not holding my breath on this one. But it seems like I'm definitely missing something, so it might be easy.
The target OS is Windows XP. I have a service running as "Local System" from which I want to create a process running as a different user. For that user, I have the username and password, so LogonUser goes fine and I get a token for the user (in this case, an Administrator account.) I then try to use that token to call CreateProcessAsUser, but it fails because that token does not come with SeAssignPrimaryTokenPrivilege - however, it does have SeIncreaseQuotaPrivilege. (I used GetTokenInformation to dump all the privileges associated with that token.) According to the MSDN page for CreateProcessAsUser, you need both privileges in order to call CreateProcessAsUser successfully.
It also says you don't need the SeAssignPrimaryTokenPrivilege if the token you pass in to CreateProcessAsUser() is a "restricted version of the calling process' primary token", which I can create with CreateRestrictedToken(), but then it will be associated with the Local System user and not the target user I'm trying to run the process as.
So how would I create a logon token that is both a restricted version of the calling process' primary token, AND is associated with a different user? Thanks!
Note that there is no need for user interaction in here - it's all unattended - so there's no need to do stuff like grabbing WINSTA0, etc.
SE_ASSIGNPRIMARYTOKEN_NAME is a privilege you can enable in your process/thread with OpenProcessToken/OpenThreadToken+LookupPrivilegeValue+AdjustTokenPrivileges (It is easy to confuse this with TOKEN_ASSIGN_PRIMARY, and MSDN says you need both to attach a primary token to a process)
On this XP:SP2 machine, just calling LogonUser(...,LOGON32_LOGON_INTERACTIVE,...)+CreateProcessAsUser works just fine without messing with any privileges (Using a fake cmd.exe service, but that should not matter)
This quote on MSDN:
If the necessary privileges are not
already enabled, CreateProcessAsUser
enables them for the duration of the
call
and the fact that you are running as SYSTEM and should be able to enable any privilege leads me to believe that this assign primary stuff is not the problem.
From the Microsoft website (see msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx) it clearly says "Services cannot directly interact with a user as of Windows Vista".
So I decided to test this by using "psexec -s cmd.exe". As far as I know, "psexec" creates a service in order to open a command prompt. Needless to say it worked. I then decided to use "EnumWinSta GUI" in combination with psexec to switch to the winlogon desktop. To my surprise, I could even start "cmd.exe" on this desktop. Does this mean a new process created from a service can be interactive?
Or is it because psexec does some kind of black magic? If so how does it do it?
I am trying to display a full screen window from a service into the winlogon desktop object in Vista as well as XP.
Code running within a service cannot directly interact with an interactive session.
However, code running as a service with sufficient privileges can create a new process running within a specific user's desktop - getting the interactive session's user's token and calling CreateProcessAsUser, for example.
You can use WTSGetActiveConsoleSessionId to get the active console session, the session of the user who is actually on the machine. WTSQueryUserToken can then be used to get the token.
Your service can also use session change notifications in its handler function to see when users logon/logoff, unlock their session, and so on.
From a Windows Service running on a Terminal Server (in global space), we would like to be able to start up a process running a windows application in a specific user's Terminal Server sessions.
How does one go about doing this?
The Scenerio: the windows service starts at boot time. After the user has logged into a Terminal Server user session, based on some criteria known only to the windows service, the windows service wants to start a process in the user's session running a windows application.
An example: We would like to display a 'Shutdown in 5 minutes' warning to the users. The windows service would detect this condition, and start up a process in each user session that starts the windows app that displays the warning. And, yes, I know there are other ways of displaying a warning dialog, this is the example, what we want to do is much more invasive.
You can use CreateProcessAsUser to do this - but it requires a bit of effort. I believe the following steps are the basic required procedure:
Get the user's session (WTSQuerySessionInformation).
Get a token for that user (WTSQueryUserToken).
Create a duplicate token for your use (DuplicateTokenEx).
Use the token to create an environment block (CreateEnvironmentBlock).
Launch the application with CreateProcessAsUser, using the block above.
You'll also want to make sure to clean up all of the appropriate handles, tokens, etc., after you've launched the process.
Really late reply but maybe somebody will find this helpful.
You can use PsExec to launch an application on a remote (or local) server inside a specified session by using the following command:
psexec \\COMPUTER_NAME -i SESSION_ID APPLICATION_NAME
Where SESSION_ID indicates the session id in which to launch the application.
You will need to know what sessions are active on the server and which session id maps to which user login. The following thread provides a nice code sample for this exact problem: How do you retrieve a list of logged-in/connected users in .NET?
Late reply but in the answer above DuplicateToken is not necessary since WTSQueryUserToken already returns a primary token.