Is there any way to change the registry permission through cmd directly. I am developing an application and want registry access. I don't want the user to know about the back end process. And the user can't get administrator rights every time. So once the application run as administrator, the permission should be changed.
I use PsExec and run my registry commands via a reg file. You can impersonate the user if they are a local admin or as a user that has remote registry access.
Depending on what exactly you're trying to do, the REG command allows command-line registry manipulation, including adding, exporting, querying or importing entries.
Related
So, I have an admin account to install programs, but with that admin account, I do not have access to a network location, which I can access as local user.
I am building scripts that installs multiple programs and afterwards copies a bunch of config files from a network location to a local machine. Some items require admin rights to be copied.
Ideally I want to execute a script as administrator, but use the local user rights to access the config files on the network location within the same script.
I have searched google for hours now, but I still do not have a solution. Someone an idea on how to accomplish this? asking for the missing access rights, is unfortunately not an option.
IT admin here, First Question on this site. Online I found a simple Powershell script that manually creates a System Restore Point on a user's PC. I want to deploy this to all company computers via a GPO scheduled task. Script as follows:
Checkpoint-Computer -Description 'System Restore Point' -RestorePointType modify_settings
Script work perfectly fine. Issue is that powershell needs to run as an admin. In scheduled task menu, the option to run with highest privileges only works if the user is a local admin. For security reasons at our company, it will not be possible to grant user's local admin access.
My question, is there some simple commands I can add that will elevate powershell to have admin privileges? Also, have to make sure that the user will not be prompted, and that the rest of the command will still execute. I do not mind having to store username or admin passwords in the script itself as the users will not see the script. I appreciate any suggestions, but only if it is fairly simply to execute. Keep in mind, I am not a programmer, I am a Cisco network engineer as well as a Windows Server admin. My boss just wants me to create manual restore points on a set schedule and I think powershell might be the best. Open to other script types though.
There are 2 parts to your question. The first part is about how to run a scheduled task as a specific user with elevated rights. I don't think it's correct that it's only possible to do so with a local admin account, but that's off-topic for this site. Consider posting that separately on ServerFault (if you do and link it, I will take a look).
The second part concerns embedding credentials into the script.
This is typically a bad idea. Saying that the user "won't" see it is not the same as saying they can't see it. If they can see it, the credential is compromised and essentially that user now can trivially have elevated rights.
So you would need to secure the script file well enough so that the unprivileged user cannot read the file.
Encrypted Credentials
PowerShell also has a [PSCredential] object which stores the password as a secure string. It is possible to store and retrieve an encrypted version of this object.
For example:
$cred = Get-Credential
$cred | Export-CliXml -Path C:\my\cred.xml
The XML file will contain the credential but it will be encrypted. It can only be decrypted by the same user on the same machine that encrypted it to begin with.
This could be a way for you to use a credential if needed. But to be honest it probably isn't.
How I would do this
Run your scheduled task as SYSTEM.
It should be privileged enough to take a restore point
It's local
It's easy to set a scheduled task to run as SYSTEM even through GPO
It requires no password handling
Let's say I'm an administrator on a Windows7 box. I'd like to be able to run commands as other users without knowing their passwords.
This is what happens on linux. If I'm root, I can 'su' to other accounts without providing any password and run commands in their own name.
su (substitute user or switch user) allows changing the account associated with the current terminal. Where Normal user have to give password of the account he wants to change to, super user (root) can change to any ID he wants without giving password.
sudo executes a command as another user but observes a set of constraints about which users can execute which commands as which other users (generally in a configuration file named /etc/sudoers, best editable by the command visudo). Unlike su, sudo authenticates users against their own password rather than that of the target user (to allow the delegation of specific commands to specific users on specific hosts without sharing passwords among them and while mitigating the risk of any unattended terminals).
On windows runas.exe allows a user to run a programs with different permissions than the user's current logon provides. But for this you have to provide credentials. Windows security does not allow an administrator to execute as another user without his credentials. Administrators can do what they want but not under certains limits without control(discretionary power)
Now once it's said, on Windows an administrator can take and give ownership of ressources and then do what he wants, but it's logged.
I want to control thinreg.exe util via powershell script. This util is used for registering vmware thinapp packages on the system(it creates shorcuts and add registry entries under HKCU hive.)
If I run my ps script as admin then also thinreg runs under admin account and register app to the admin.
So it is possible to get user credentials from AD and use them to run PS script or just thinreg util ?
I'm domain admin and other users are domain users. AD is win 2008r2 and client OSes are winXP sp3.
Thank you very much.
EDIT
Is it possible to install windows service via login script so that would run under logged user account ?
Via this service I could then control thinreg.exe util
I would try two ways.
Add the powershell script run once during the logon script of the user
If user are using roming profiles, try to modify their profiles when they are logged off.
If you want to be more "interactive", and do it as the user is log in, you can try to play with PSTOOLS you can have a look to this post to have an example how to call your powershell script from PSTOOLS.
I have been maintaining an installation for a while but I am not really an expert. now I've been asked to come up with a solution for this:
Our software is always sold together with a computer as it has to be run in a very controlled environment. The installer needs administrative privileges to be executed. So far we had two different users, one with administrative rights and other one without. Our custumer service login as Administrator, install the software and restart the machine so that the user can access as a normal user.
Now we want the user to be able to install the software themselves but we don't want them to have access as an administrator because they can modify things it shouldn't be modified.
So, is there any way to programmatically raise the user privileges during the installation and afterwards lower them back? The installer is made using InstallShield but we use vbscript to check some pre-requisites.
Check out CPAU. It allows you to create an encrypted command that will run the installation as administrator.
EDIT: This is a more comprehensive list of like tools.
If you are looking for a toolkit to do this kind of thing, well, Microsofts MSI technology has this built in: Administrator access is required to install the initial MSI file, additional patches (MSPs I think) are digitally signed by the original MSI and are thus deemed safe - users can install them without requiring administrator elevation.
You can do the same thing: As part of your administrative install, install a service. The service can create a named pipe - that you explicitly give user ACLs to - or even just a socket or monitor a drop off folder that allows the user level code to communicate with the service code (running with SYSTEM or configured access). The service can then use its SERVICE or configured account level permissions to either impersonate an administrator, or do other tasks on the behalf of the user without EVER giving the user any kind of elevated permission - even temporarily.