I want to get the privileges of a selected user on a local machine. I know how to get them from the current user, so my problem is how to open a process as as a different user.
I'm currently looking for more info about CreateProcessAsUser()
thanks
You shouldnt create a process as a different user just to get his priviledges. To get an user priviledges you need an iudentity token. To start a process as an user you need an impersonate token. Idenity tokens are very low security risk, impersonation tokens on the other hand are very serious business. At the very least, you need to know the password of the user in order to impersonate (or have an impesonation capable context, like an SSPI exchange security context).
Use LookupAccountName to get the SID, LsaOpenPolicy and LsaEnumerateAccountRights.
Check this link for how to do this from a service within Delphi: Launch your application in Vista under the local system account without the UAC popup
To launch a process under the local
system account I perform the following
steps (from a service application):
Get the Active Console SessionId using WTSGetActiveConsoleSessionId
Since I need to launch the application under a system account, I
use the token from Winlogon, since
Winlogon runs under the system
account. So I obtain the process ID of
Winlogon and Duplicate the token.
Then I make sure I sent the startupinfo parameter lpDesktop to
winsta0\Default since I need to launch
my process there.
Then I use CreateProcessAsUser with Winlogon's duplicate token to
launch my process into session 1.
That's all. I am done.
Related
I'm trying to launch a process from a system service using the token handle of the currently active user with elevated privileges (if user is in admin. group). My current attempt looks like this:
I'm getting the active session ID using WTSEnumerateSessionsW.
I'm getting the user token handle using WTSQueryUserToken.
I'm verifiying that the user is in the administrators group.
???
Launch the process with the user token using CreateProcessAsUserW
How do I need to modify the token so that the process will have elevated privileges? I'm aware that similar questions have been asked already, but none of them contain properly explained answers.
I'm using LogonUser to get a HANDLE to the target session token and use it for the function CreateProcessAsUser.
status = LogonUserW(sessiondata->UserName.Buffer, sessiondata->LogonDomain.Buffer,NULL,LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, &targettoken);
My executable is going to be executed by Administrator, but even though I'm administrator, I can't get the handle to the token and always get 1326 error: Logon failure: unknown user name or bad password.. I put NULL as lpszPassword with the hope that it checks if I'm administrator and give me the privilege to get the access token.
Of course I should not be using LogonUser for this purpose, so what do you suggest ?
I expected to get a HANDLE to the access token because of my high-level privilege(Administrator) without giving the password.
My executable is a simple application which is intended to get screenshots from all logon sessions
Hey, we can forget about getting the user's login token. There's actually a fairly good way to do this.
Enumerate all processes.
If the process is a WINLOGON process and the session id is not zero
Steal its token
Start a process using that token; pass it a file on the command line
That process takes a screenshot and saves it to a file
When all your processes have finished, pick up your files.
The token from WINLOGON has administrative rights and is on the correct session to see the user's desktop. If you don't create any windows you aren't vulnerable to the user messing with you. (In fact this token creates windows at a higher integrity level. Normal shatter attacks don't work however you can still receive fake keyboard or mouse input if you create windows.)
Most likely, you will only get a screenshot from the currently active screen and any active remote desktop sessions. Other sessions stop their redraw and drop their screen buffers to save memory.
It's most likely your user does not have SeAssignPrimaryTokenPrivilege and SeTcbPrivilege. I have given these to my user in the past; however the easiest way to get them is to become local system by setting up and launching as a service, then removing the service after its done.
OP commented that he got to SYSTEM by PsExec and was able to get the token. PsExec does CreateService under the hood so it's all the same.
I am running a process with loacl admin privilege in Windows and trying to obtain a credential handle for another user using AcquireCredentialsHandle .
It is possible to pass in SEC_WINNT_AUTH_IDENTITY structure with user info ( e.g. user, domain, password) and obtain the handle. I have verified it. Without the SEC_WINNT_AUTH_IDENTITY passing only the pszPrincipal does not work.
I wonder is there any other way one can do it without providing the user password?
I am running the following scenario:
Client obtains a kerberos token using UPN and sends it to server
Server tries to acquire the credential handle (AcquireCredentialsHandle) using UPN of the client.
Any suggestions please?
You normally don't get to request a ticket on behalf of other users. That would be a very dangerous security issue.
There are two ways around this.
Use S4U2Self which is where the application requests a ticket to themselves using the passed in username, which will get them a ticket on behalf of the user to themselves. This lets you see things like user group membership. You need to be running as SYSTEM or have SeImpersonatePrivilege to do this.
Use S4U2Proxy aka protocol transition which is where the application requests a ticket for another service using the passed in username. This lets you impersonate the user based only on the name, and must be explicitly granted to the server and target by AD. This is an incredibly dangerous privilege because you're allowing your application to have the equivalent rights as a KDC.
Unfortunately this is a fairly complicated bit of code so it's not shareable in this post as-is. You can find a sample application here: https://github.com/SteveSyfuhs/DelegatedAuthentication
The gist of the process is:
Client sends username to service.
Service is configured for SeImpersonatePrivilege or SeTcbPrivilege (meaning running as SYSTEM)
Service calls LsaLogonUser and passes just the username, returning an NT token handle.
Service calls SetThreadToken with the token from (3).
Service calls AcquireCredentialsHandle without any credentials (uses default SSO creds).
Service calls InitializeSecurityContext
Service sends token to target server
We have the angularjs application where we have different roles associated to the users. For ex: the two roles are Admin and Local. Based on the role, we show some menu items for the Admin and adds more features/screen to the Admin .
The userInfo with the Admin Property is returned from the login response and based on what we decide which all menu and screens to be rendered .
But if we user the developer tool, and the set the break point where the admin property is used, and set the admin property as true the user even he is a local user would be able to access admin privileges .
In short who has some idea about the javascript code can get the admin privileges . Is there any idea other than minification of the code to prevent this kind of security threats
Thanks
As the front-end of your application will run on the client machine there is actually no way to stop a user from debugging or modifying the code. Thus it's impossible to prevent someone from tricking their local instance of the application to think it's signed in as an administrator.
If you simply want to hide the admin interface, one possibility is to have separate (or additional) templates for administrators and restrict access to these based on the user's privilege. If there is anything to be gained from this is up to you. You will still need to validate the rights to execute any privileged action on the server anyway. Obtaining administrative privileges on the client must never be the same as obtaining them on the server side.
So I have a setup where clearcase and clearquest are integrated.
I.E. if I check in a file in clearcase clearquest will popup asking for a change request number.
Here's the deal, I don't have to "login" every time I start a new clearexplorer.
I have some other tools I have been writing that I would like to take advantage of that capability but I don't know where to start. Basically I want my tool to check the same place clearcase checks to see that I'm a valid user and create my object based on those credentials.
From the looks of things the ALDB server might have something to do with it but I don't know how to interact with it.
Anyone have any ideas on it?
UPDATE:
I guess What I mean is I don't have to login to Clearquest every time I open a new clearcase and check in files. That's what I'm really looking for. using the existing clearquest "authentication" object (If that's what its even called)
Update 2:
Based on Information I found here:
http://publib.boulder.ibm.com/infocenter/cqhelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearquest.apiref.doc/c_perf_user_admin.htm
You can use this method to obtain the Session object associated with the current user. See the description of the Session object for more information on how to use this object.
I look at Session Object and it doesn't seem to mention about how to use this object as it states.
Update #3
This has been a long time, but it's come up again, I think what I'm really looking to do is build something that shares the Session object since logging in takes quite a while my plan is to login once using a background process, and then I can query that running process for the object when I try to login with a second program, if it works all goes well and continues, if it doesn't then it will require a manual login, (or could spawn the process that logs in, and waits for a response).
If/When I make this I'll post some details on steps I took.
It is true the albd service (Atria Location Broker Daemon) requires a Windows account to function. But not yours. See Updating the Windows ClearCase ALBD Password.
The last one, the ALBD service, requires a Windows user account with ClearCase privileges to function properly.
In the definition of this service, during ClearCase installation, the ClearCase administrator must specify the name of this privileged account, the password, the Windows domain, and the Windows group for this account.
Any ClearCase-related operation will based the user identification on the
credmap informations (if you are with Windows clients and Unix server)
credmap registryServer
or the creds.exe informations
The clearcase objects (like a new version created after a checkin) will get those credentials.