I am writing a Powershell script for renewing user certificates.
I am trying to automate a step in which
I log in to a server using the account's credentials,
Go to mmc,
Right click on the certificate and then renew it.
I have been successful in writing the script for renewal But I am stuck at the login part.
Accessing the server remotely using Enter-PSSession and Invoke-Command doesn't install the user's certificate the way it does in case of a manual login.
Is there any powershell command or any work around that can be used to fetch a user's certificate just like it happens automatically in case of a manual login?
Related
We have an application where we use several PowerShell scripts. We received a complain regarding about they aren't signed and unable to run them if they have the strictest Execution Policy - AllSigned.
I signed with our certificate issued by well-known issuer via signtool as we do it for dlls and exe app but even after that there is an issue if I try running the script I'm getting warning:
Do you want to run software from this untrusted publisher?
It's signed by a certificate issued by know CA (Sectigo). Only how can I get rid of this warning is to add the certificate to Trusted Publishers. It's not good for customers to do those steps (but maybe it's necessary security step). Note: With the same certificate, we sign exe app and it works fine and Windows doesn't complain. (Look like PowerShell policies are stricter.)
Is it possible somehow avoid getting this warning on a customer side without manually adding our certificate into Trusted Publishers? Looks to me that it is not possible.
What I've found out so far:
I've searched across internet and it looks like there is no solution for that. Even if I used PowerShell script signed by Microsoft Corporation I get the same warning unless I add to the Trusted Publishers folder.
Also e.g. HP directly recommends to add the certificate manually to the cert store.
In a documenation about execution policies is written in AllSigned section: Prompts you before running scripts from publishers that you haven't yet classified as trusted or untrusted.
From those all information, I got it as there is no way how to avoid getting this warning on a customer side without adding to the cert store. I want just to assure myself I'm right.
I am working with PowerShell. So we can connect MFA enabled O365 through connect-exopssession but we need to manully enter password and Code sent to mobile. But I want to schedule a solution which has to connect to O365 automtically without any manual intervention in MFA enabled O365. Is there any solution which can bypass MFA without disabling MFA in O365.
The only way to do this is to setup an account that is dedicated for these types of tasks and remove MFA for it, or use Conditional Access to bypass MFA when connecting from your Public IP etc. Just make sure that you secure this account as much as possible.
To create non-interactive scripts, you need EXO V2 PowerShell module version 2.0.3 preview or later version. This unattended script authentication uses Azure AD applications, certificates, and Modern authentication.
Connect to Exchange Online PowerShell with existing service principal and client-secret:
To connect Exchange online with existing service principal and client-secret, you need to follow the steps below.
Step1: Get an OAuth access token using Active Directory Authentication Library (ADAL) PowerShell.
Step 2: Create PSCredential object
$AppCredential= New-Object System.Management.Automation.PSCredential(<UPN>,<Token>)
Step 3: Pass the PSCredential to the EXO V2 module.
Connect-ExchangeOnline -Credential $AppCredential
For more information please read https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps#setup-app-only-authentication
Use App passwords. App passwords do not need MFA.
From docs:
An app password is a code that gives an app or device permission to access your Office 365 account. If your admin has turned on multi-factor authentication for your organization, and you're using apps that connect to your Office 365 account, you'll need to generate an app password, so the app can connect to Office 365.
Read more and how to in MS Docs here:
The following set-up is given:
We are a fairly small branch of a big enterprise sitting on the bottom of a complex WinServer 2012 R2 AD. Therefore we are somehow restricted in our policies.
Our development department has three PowerShell developers who want to use their scripts securely.
We implemented an AD CS to sign our scripts by our own root certificate authority.
The technical steps to implement our certificates are the following:
Create a private key with a public certificate using openssl.
Sign the certificate by our certificate authority.
Import the signed certificate into an AD users account along with the public certificate of the CA into the trusted CAs.
The certificate user "ScriptUser" is not an AD user, therefore we import his certificate into the trusted users area.
Signing and testing:
On the client system (Windows 7 or Windows 10) we tested to sign a
PowerShell script which went ok.
When running the script locally we get an error message that the certificate owner is not trustworthy. After committing the script runs.
We expected the script to run without any dialogue.
What's our fault?
I have a service which need to read a cert to get authorized to query a web. The service is scheduled by windows task scheduler in non-interactive mode("Run whether the user is logged on or not".
In this case, where should i install the cert?
For user certificate you need to install that cert under personal store
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