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
Related
We have a PowerShell script to pull Power BI activity data (using Get-PowerBIActivityEvent), and I have been trying to automate it so that it can pull this data daily using an unattended account. The problem is the script must necessarily use the Connect-PowerBIServiceAccount cmdlet, which requires a credential. I don't want to have the passwords hard-coded anywhere (obviously) and ideally don't want to be passing it into the script as a plaintext parameter in case of memory leaks.
I've tried using SSIS as a scheduling mechanism since it allows for encrypted parameters in script tasks, but can't call the PS script with a SecureString parameter since the System.Management.Automation namespace isn't in the GAC (a commandline call wouldn't be possible).
I don't believe task scheduler would offer the functionality needed.
Does anyone know of any elegant ways to connect to the power BI service using encrypted credentials?
In the docs of Connect-PowerBIServiceAccount there are 2 options for unattended sign-in:
Using -Credential, where you pass AAD client ID as username and application secret key as password
Using -CertificateThumbprint and -ApplicationId
For both options you need to configure service pricipal and add proper permissions. I'm not going into details how to configure that, but most probably you'd need (at least) the following application permissions:
I'm not really sure what functionalities you need in the script, but in my experience, majority of the cases can be covered by scheduled task, so the explanation below will apply to that solution.
How you can secure the credentials?
There are variuos possible solutions, depending on your preferences. I'd consider certificate-based authentication as more secure (certificate is available only to current user/all users of the machine).
What's important in certificate-based authentication - make sure that the certificate is available for the account running the script (in many cases it's service account, not your user account).
How can I secure more?
If you want, you can store application ID as secure string (I don't have SSIS to test, so I'm not sure if there's any workaround to make it working in there) or use Export-CliXml. They use Windows Data Protection API (DPAPI), so the file can be decrypted only by the account which was used to encrypt.
To add one more level of security (I'm not even mentioning setting correct access rights to the files as it's obvious) you might put the file in the folder encrypted (you might already have a solution for disk encryption, so use it if you wish).
There are probably some solutions to secure the keys even better, but these ones should do the job. I'm using other Microsoft 365 modules with similar approach (Outlook, SharePoint PnP) and it works quite well.
NOTE: If you need to use user account, instead of service principal, make sure that you have MultiFactor Authentication disabled on that account for that specific application.
The relevant documentation to this (https://learn.microsoft.com/en-us/power-bi/developer/embedded/embed-service-principal) states that admin APIs (i.e. those served via Get-PowerBiActivityEvent) do not currently support service principals. This means it's not currently possible to use a registered app to run these cmdlets unattended.
There is a feature request open to provide this at the moment: https://ideas.powerbi.com/forums/265200-power-bi-ideas/suggestions/39641572-need-service-principle-support-for-admin-api
I need to take regular backups of a suite of VM’s in an Azure environment. I thought the obvious solution to this would be to use PowerShell to automate the process so have written a script to do just that. I want this to run on a schedule, unattended with no manual intervention. However, the problem I have is that every few days I get the error:
Your Windows Azure credential in the Windows PowerShell session has expired. Please use Add-AzureAccount to login again.
Which means I have to re-run Add-AzureAccount and sign back in through the associated popup and everything works again. Obviously this is no good and negates the benefit of doing this automation.
Is there any way I can prevent these credentials from expiring?
Thanks
Yes, by using certificate authentication instead. One of the drawbacks of using Add-AzureAccount is that the credentials expire from time to time. You could just run Add-AzureAccount again but certificate authentication would be best for you in this scenario.
Firstly, remove the current accounts you have registered in PowerShell using the Remove-AzureAccount cmdlet. Something like:
Remove-AzureAccount -Name name#account.onmicrosoft.com
This doesn't remove your account from Azure, just the reference you hold to it in your PowerShell console (from when you used Add-AzureAccount). Then you run
Get-AzurePublishSettingsFile
this will open a browser window, ask you to authenticate to your account and you'll download a file ending in .publishsettings
Then, in Azure PowerShell you run
Import-AzurePublishSettingsFile -PublishSettingsFile <path_to_file>
which will import the certificates from the publishsettings file, allowing you to execute your scripts without using Add-AzureAccount.
You may also need to use Set-AzureSubscription -SubscriptionName <name_of_subscription> if you happen to have more than one subscription.
Additionally, the following MSDN blog describes the process just as I have above. http://blogs.technet.com/b/ricardma/archive/2014/07/04/managing-azure-subscriptions-in-powershell.aspx
Introduce the Problem
I like to manage Windows Azure Websites through PowerShell. For instance, I like to run Get-Website to view a list of all my websites. Before I do that, I need to authenticate with Windows Azure.
Research
One way to do this is via Add-AzureAccount, which prompts me to sign in with my Azure username and password, afterwhich I can run Get-AzureWebsite to view the list. At this point, I have no Management Certificates, and it doesn't seem to matter. I can run Remove-AzureAccount some#account.com to sign out.
Another way to do this is via a Management Certificate. I run Get-AzurePublishSettingsFile followed by Import-AzurePublishSettingsFile. Then I can run Get-AzureWebsite to view my list.
This seems like two ways to do the same thing.
Question
Other than allowing me to save a Management Certificate for convenience, what is the difference, if any, between the two methods?
Import-AzurePublishSettingsFile is not interactive, so I can use a batch process.
Add-AzureAccount is interactive. Since I do not require the certificate, I use Add-AzureAccount because it is easier.
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 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.