I've got a script that basically creates a user account on a number of systems, including Active Directory, and an IIS webserver that authenticates against that same Active Directory Domain.
Right now, if I just do my Invoke-WebRequest without specifying credentials, I get a 401 error, and if I use the credential switch, I have to specify or prompt for credentials. However, when it creates the Active Directory account, PowerShell is smart enough to uses the credentials of the user running the script to create the account, without having to specify or prompt for credentials.
Is it possible to do this same thing with Invoke-WebRequest?
As per TechNet for Invoke-WebRequest the -UseDefaultCredentials switch should do exactly what you are asking for:
Indicates that the cmdet uses the credentials of the current user to send the web request.
Related
I would like to run a one-off automated PowerShell task on my server but on behalf of other user/organization. For simplicity, this task should get list of inbound connectors (Get-InboundConnector).
Import-Module ExchangeOnlineManagement
# authentication step
Get-InboundConnector
As for authentication method, my thoughts is that I could use Connect-ExchangeOnline -Device (Device Based Log-In) in my script, somehow parse the unique code and send it to the user, once he enters the code in his browser and approves, the script will resume running.
What are other possible authentication methods that could work in this situation?
Can I create a PowerShell application in Azure that requests from the user permission to manage his Exchange Online account and then ask him (thru UI) to grant this application the required permissions so it can be used to run the PowerShell script using access tokens & refresh tokens?
Few notes:
Hardcoding user credentials is not an option (Connect-ExchangeOnline -InlineCredential is a no go)
I don't want to ask the user to start configuring things on his end (should be as lazy as possible for him)
REST API would be the best option (as far as I know it is not supported by Microsoft Graph)
Hi I'm trying to build a powershell script to post a file from fileshare to Google drive using Invoke-WebRequest and Google script, I already got a script which works when the Google script is public unfortunately I need to have it locked to domain of company I'm working for.
My idea is to login to my Google account and then direct the session to the Google script but I'm stuck on login form is this even possible or it will never work ? I know there are easier ways with oauth tokens but everything is locked down by security policies from IT and we don't have access to GCP
Here's the Powershell script that You Can use for the automatic logon to Gmail under Internet Explorer:
I am working on Microsoft Graph with powershell script.
I am using authorization grant flow to get the access token to retrieve the emails from a shared mailbox using my user account, whenever I provide my login credentials, its giving me below error related to the MFA.
Invoke-RestMethod :
{"error":"invalid_grant","error_description":"AADSTS50076: Due to a
configuration change made by your administrator, or because you moved
to a new location, you must use multi-factor authentication to
access '00000003-0000-0000-c000-000000000000'
Is there any way to launch a MFA authentication window from powershell script?
Any help or example is appreciated.
You say “you provide credentials”, do you mean you’re setting the username and password in powershell?
You have several ways, it would suggest to use the “device code flow”. Then the login part is done in the browser, where you have all those multi-factor things configured.
Someone made a great blog about it, https://blog.simonw.se/getting-an-access-token-for-azuread-using-powershell-and-device-login-flow/
Searching around the windows authentication methods and protocols, i decided to understand the exact difference between Negotiate, Kerberos, and NTLM used in a simple executable file before liking it with IIS and Web Authentication.
I reached to good results, BUT I still need more details about the Negotiate and Kerberos.
I have the following scenario :
I have created very simple C# windows forms application that shows a message box displays the value for :
System.Security.Principal.WindowsIdentity.GetCurrent().AuthenticationType
Note that i'm a domain user with admin privileges on my local machine, I have the following results :
When i run the exe file (double click) while i'm actively connected to the DC, i got "Negotiate".
When i run the exe file (run as differnet user / using local user) while i'm actively connected to the DC, i got "NTLM".
When i run the exe file using "Run as Administrator", or "Run as Different User" i got "Kerberos".
When i run the exe file while i'm locally logged in using local account, i got "NTLM".
I understand that the LSA will use NTLM for local accounts. Also i understand that Active Directory uses Kerberos to authenticate domain users and computers.
My question is, why i'm getting the Negotiate Authentication Type when i run the exe using my account either by (Double Click), or "run as different user" using my Same account ?
Update : I noticed the following :
- If local user is running the exe then it is NTLM
- If domain user run the exe then it is Negotiate (If that user is local admin) but is is Kerberos (if that user is not local admin)
- If domain admin run the exe then it is Kerberos
I just a clarification about this behavior.
First off, (which you seem to understand in the question, but just to be clear) an EXE doesn't have any authentication - it is just an executable. The OS creates a process object which executes it within a logon session identified by a principal. It's this principal which has been authenticated by NTLM or Kerberos (or some other protocol).
Next, Negotiate means that when the logon session was created the Negotiate authentication package was used to decide which authentication package - Kerberos or NTLM - would be used.
When you query the WindowsIdentity.AuthenticationType value, you are ultimately calling a function in the Local Security Authority (LSA) called LsaGetLogonSessionData. This reports details of the logon session used to run the process you are executing. The way that this logon session was created probably has the largest effect on the authentication package used to verify the credentials.
When logging into Windows the first time, Winlogon.exe establishes an interactive logon by calling LsaLogonUser. It queries the authentication packages in HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages in order until it finds one that can authenticate the given credentials. Once an interactive logon has been established, you can create new processes using noninteractive logons under different credentials, and in this case, the LogonUser function is likely called. One of the parameters to this function is dwLogonProvider which has the following default (which is likely the one used):
LOGON32_PROVIDER_DEFAULT
Use the standard logon provider for the system.
The default security provider is negotiate, unless you pass NULL
for the domain name and the user name is not in UPN format.
In this case, the default provider is NTLM.
So, the package reported for the logon session the process is running under depends on how the logon session was created. (It isn't clear from your question exactly how you create the logon sessions you are testing... doing "Run As" in all cases? Logoff / Logon Windows for some cases?) It also depends on which package Winlogon was able to successfully authenticate with first for the interactive logon session. Ultimately, though, note that the authentication mechanisms all call down to some authentication package, and if Negotiate is used, Kerberos is preferred, though Negotiate is what is reported.
Here is an old but still relevant diagram which shows how all the authentication fits together in Windows:
Source
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