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.
Related
I have a whole bunch of GMSA used throughout my org. I'm able to see through AD what machines have permissions to install the GMSA but cannot find a way to see what machines have actually gone through the Install-ADServiceAccount step to actually have the GMSA installed.
An older post How can I see if a Groupmanaged Service Account is installed with Install-ADServiceaccount? suggests usingGet-ADServiceAccount and checking the HostComputers property but I only see this populated for MSA. For GMSA it's blank.
Any ideas on how I can get this without needing to connect to each machine and running Test-ADServiceAccount for each permitted GMSA? (especially given the whole PSRemoting and network access that causes problems) A WMI/CIM query I could run would be second to actually getting the data centrally from AD.
Thanks for any help.
I recently came across an interesting feature of Windows PowerShell JEA (Just Enough Administration) which by default makes use of Windows virtual accounts to run the remote end point in admin context. I also understand these virtual accounts are created ephemeral for that session and get destroyed when the session ends. This also by default has the local admin rights on the machine for that session while the user running the session is a standard user who can carry out privileged operations using that virtual admin account.
This got me into thinking - we have a few apps in our organisation which sadly need local admin rights to run. We are reluctantly granting admin rights for the users of those apps. So I was wondering if there is a way through PowerShell we can create this Virtual account for the duration of however long that application runs? What I am thinking is some sort of wrapper PowerShell which is targeted by the application shortcut which would internally first spin up this virtual account to run that app as? I am assuming we need to configure some sort of one-off constrained custom app-specific JEA endpoint during the installation of the application. Then again, if the app requires the launching user's context to access back-end database etc. I am not sure how that would be taken into account.
I was just wondering if you have any clever thoughts? Thanks, Steve
I am upgrading Collaborative lifecycle management version to 6.0.5 current version is 5.0.2. As specified in IBM Interactive upgrade guide one of the step is to run upgrade script on your databases and below are the command
cd D:\IBM\JazzTeamServer6.0.5\server
upgrade\jts\jts_upgrade.bat -oldJTSHome "D:\IBM\JazzTeamServer5.x\server\conf" -updateTomcatFiles no -updateAppServerFiles no
After running this command I am getting message as "Upgrade must be run with administrator rights"
I am logged in as administrative user on the system, assigned all the full access control permission of folder where CLM server is installed to user still everytime same problem persist.
I was going through links to troubleshoot the problem but nothing seems to be working out for me. Some of the links I have referred are
https://www.techsupportall.com/how-to-enable-administrator-account-on-welcome-screen/
http://www.thewindowsclub.com/elevated-privileges-windows
Can anyone please suggest I am missing anything here?
This could be caused by User Account Control, a feature which makes so that, even if you have administrative rights, you don't actually have them unless you explicitly request them. There are two distinct policies governing UAC behaviour (both found in Computer settings\Windows settings\Security settings\Local policies\Security options), one for the built-in Administrator account, and another one for all other administrative users:
User Account Control: Admin Approval Mode for the built-in Administrator account (disabled by default)
User Account Control: Run all administrators in Admin Approval Mode (enabled by default)
What this means is: by default, the built-in Administrator account is not affected by UAC, while all other administrative users are; thus, it's possible for an administrative user (different from the built-it Administrator) to not actually have administrative rights, even if it's a member of the Administrators group.
More info -> https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd835564(v=ws.10)
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.