I have an installation package that installs a service process that I create. I'd like to prompt the user for the username/password of the account that the service process should run under. I'd like to verify the the username/password combination are valid before continuing with the installation. I have a C DLL that I am using for special installation behavior, but I can't figure out how to use the Windows API to verify an account's credentials. I'd like to be able to support the same account name syntax used by the service control manager.
The function you want to use is LogonUser. You can even be extra-cool and specify the LOGON32_LOGON_SERVICE flag which checks to make sure the user has the appropriate permissions to run a service.
LogonUser is the canonical way to do this, though Microsoft somewhat discourages it.
I've implemented this using the LogonUser function as you guys have mentioned (by the way, this service requires WinXP SP2 or later so I'm not worried about the privilege issue). However, this isn't quite working as I had hoped. If I call QueryServiceConfig, lpServiceStartName is in the format ".\accountname". If I pass this string as is to LogonUser, it fails. I assume the portion before the '\' represents the machine on which the user belongs?
Also, if I call ChangeServiceConfig specifying "LocalSystem" and "" for the lpServiceStartName and lpPassword parameters respectively, this works fine. However, calling LogonUser with these parameters does not work.
I'd really like to use the same syntax that the SCM uses for the account names.
Related
I'm working on a System Service project with SYSTEM privilege (cleaning utility)... It does not interactive with any user interface.
My goal is to check files in "Desktop" and "AppData" folders for any user that exists on the PC.
I'm using NetUserEnum() to get the user list on the PC. Then I want to get the path of each user's Desktop and AppData with SHGetKnownFolderPath(), but I can't find a way to get each user's access token for SHGetKnownFolderPath(). Without a token defined in SHGetKnownFolderPath(), it returns the path for SYSTEM and not specific users.
Q1. How can I get the token of each user for SHGetKnownFolderPath()?
Q2. If no answer for Q1, is there any documented way to get the desktop & appdata path of each user in the PC?
I understand this can be achieved with dirty way ---> Registry key with some string replacement. However, the Registry key method is undocumented, which may easily break in future updates to Windows.
Edit Update:
#RaymondChen Thanks for pointing out that some user profiles may not exist. Also,
About Q1 : #Remy Lebeau provides a solution with LogonUser/Ex(),login to each user with their credentials,might be the only answer that fits the need of Q1.
About Q2 : There might have no documented way to achieve this. The only method might have to stick with Windows Registry (Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders) , as #Remy Lebeau and #Olaf Hess said. I tried to dig more information on Microsoft Community Forum and I got Microsoft would never allow access other users' profile with their native API for security reason. They do not provide APIs that can possibly violate the security rules. Each user profile can only access by its credentials.
btw, I totally understand that "Cleaning utility" aka "Windows-breaking tool", especially when the tool is not being well codded(ex. compatibility problem). For the sake of avoiding to make it become a totally Windows-Destroyer, I tried to use more documented API as possible.
For Windows Vista with SP1 / Server 2008 and better you can query the existing user profiles using the WMI class Win32_UserProfile. This allows you to retrieve the profile path and check whether it is a local or roaming profile and to get status information. The rest (retrieving the paths to APPDATA, DESKTOP, etc.) is likely going to involve reading values straight from the registry (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders or HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders).
We were trying to deliver a solution to manage a Windows 2012 server for a client using Chef, but unfortunately chef-client run failed with Chef::Exceptions::WindowsNotAdmin: can not get the security information for <some_file> due to missing Administrator privileges exception.
This was a bit weird as we have confirmed that the domain account we used to remotely manage the server is a member of the Administrators group. And we were able to use it to manage other servers within the same domain. Besides, when we connected to the server using the domain account via Remote Desktop, started PowerShell as an administrator and initiated a chef-client run, it failed with the same exception.
Running below commands reveals that the domain account is indeed a member of the Administrators group. This can be verified by the SID of the group.
Get-WmiObject -Class Win32_UserAccount
Get-WmiObject -Class Win32_Group
[System.Security.Principal.WindowsIdentity]::GetCurrent().Groups
Not sure what settings on the server could have caused this.
With insights provided by this thread, further digging into the code of Chef reveals that a win32 function GetNamedSecurityInfoW gets called here to determine the security information of an object (file, folder etc.). This occurs during cookbook installation where some resource files or gems need to be created on the endpoint server.
Firstly an empty file will be created, after that the file content will be updated atomically if that is an option. During file content update, the file’s security access control list needs to be checked by the function GetNamedSecurityInfoW. To call this function, the logged-on user needs to have a privilege SE_SECURITY_NAME. Chef itself also tries to handle this by adding this privilege before calling the function and revert it after the function call, but this is not always guaranteed. System settings seem to prevail.
We hacked Chef code a bit to try to print out the output of the function call on GetNamedSecurityInfoW, and it was a status code 1314, indicating a required privilege is not held by the user.
We tried to run whoami /priv on the server and found that SeSecurityPrivilege privilege is not found in the list. Below is just a sample output on a normal Windows server.
Privilege Name Description State
========================================================================
SeLockMemoryPrivilege Lock pages in memory Disabled
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeSecurityPrivilege Manage auditing and security log Disabled
...
Note that the state column only indicates whether a privilege is being used by the user. It's existence indicates whether the user has it or not.
After adding back this privilege to the domain account, i.e. set the security setting of Manage auditing and security log to Administrators group in the Local Securtiy Policy editor, and rebooting the server, chef-client run became successful.
It seems that Chef is heavily using win32 API functions to manage Windows nodes. And these API functions seem to need various privileges to run. It's a bit strange that Chef rescued all win32 API errors and just propagated the Chef::Exceptions::WindowsNotAdmin to chef-client run log, as indicated here. It would be good to actually parse the error a bit and provide some more useful information.
Using System.Diagnostic.Process.Start() from IIS Express running in my interactive session, I can execute a program running as a different user with correction functionality. Unfortunately, it seems that this doesn't work from non-interactive sessions.
Process.Start internally calls CreateProcessWithLogonW(CPLW) when
credentials are specified. CreateProcessWithLogonW cannot be called
from a Windows Service Environment (such as an IIS WCF service). It
can only be called from an Interactive Process (an application
launched by a user who logged on via CTRL-ALT-DELETE).
-- from this SO answer
I need to publish this site to IIS 8 from the app pool account. So I CreateProcessAsUser as suggested by the above-quoted answer. I've set the service account and agent account with Local Security Policies and restarted as suggested in that answer - service account can replace token, modify quotas and agent account can logon as batch (and as service for that test). But I can't get it to work in IIS Express (or a console test app) nor IIS 8. I've tried running as LOGON32_LOGON_BATCH, LOGON32_LOGON_NETWORK_CLEARTEXT, and LOGON32_LOGON_SERVICE, and even LOGON32_LOGON_INTERACTIVE. I've even given my own account "logon as service" and "act as part of the operating system" privilege with no change - all tested after a reboot.
I'm getting "A required privilege is not held by the client" from IIS Express for all configurations. On the server, I get the same running the console app. But publishing the app, it seems to start the process just fine, but then I seem to be getting permissions errors subsequently.
I'd like to know WHICH privilege my accounts are missing when running locally so I can debug them properly (and eventually figure out whatever permissions error I'm getting). Is there any way to determine that? Either way, if you know what the issue is, I'd like that too!
Thanks!
Per the documentation:
CreateProcessAsUser function
Typically, the process that calls the CreateProcessAsUser function must have the SE_INCREASE_QUOTA_NAME privilege and may require the SE_ASSIGNPRIMARYTOKEN_NAME privilege if the token is not assignable. If this function fails with ERROR_PRIVILEGE_NOT_HELD (1314), use the CreateProcessWithLogonW function instead. CreateProcessWithLogonW requires no special privileges, but the specified user account must be allowed to log on interactively. Generally, it is best to use CreateProcessWithLogonW to create a process with alternate credentials.
...
If hToken is a restricted version of the caller's primary token, the SE_ASSIGNPRIMARYTOKEN_NAME privilege is not required. If the necessary privileges are not already enabled, CreateProcessAsUser enables them for the duration of the call.
The calling thread can use OpenThreadToken() and AdjustTokenPrivileges() to enable individual privileges as needed before calling CreateProcessAsUser(). But since it does that internally anyway, that implies the user associated with the calling thread does not have those privileges available to begin with.
Operating system is Windows 7 or higher with UAC enabled. Calling process has admin rights, already confirmed by the UAC box.
I want to spawn a new Console window (cmd.exe) under user SYSTEM (don't ask why). I can do this interactively by using PsExec tool from Sysinternals or something similar, but I don't have the source code and I need to understand how this works.
I understand that I have to call CreateProcessAsUser() and that works fine with the first parameter (hToken) set to NULL, but now I need to know how to get the hToken. I understand that I can get such a token by calling LogonUser() - but not for SYSTEM. How would I get the token for SYSTEM?
I thought of using DuplicateTokenEx(), but that requires an original token, that I don't have.
Would I have to query the process list, find any SYSTEM process and try to get that token duplicated or something? I don't want to reverse engineer the PsExec tool or one of the others doing exactly this.
Typically you would install and launch a service, configured to log in as SYSTEM. You can then use OpenProcessToken and DuplicateTokenEx to make a copy of the token.
You will probably need to use SetTokenInformation to change the session ID for the token to match that of the interactive user. You need Act As Part Of the Operating System privilege to do that, so you should do this from inside the service itself. Once the duplicate token is ready to use, you can use DuplicateHandle to copy the handle into the administrative process, or (with the right options) you could launch the command shell directly from the service too.
alternative open the winlogon process with maximum permitted access, try to open the process token, (also with maximum permitted) and then try to duplicate this winlogon handle with impersonate rights. On win8.1 this will succeed. On others, you will need to temporary change the token dacl, with either a null or your own admin process token
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.