oAuth, tokens, and powerShell

Google, Microsoft, Amazon, Box, Twitter, Trello, Facebook… what do they all have in common? oAuth authentication workflows.

Take your pick of languages to get samples on how to authenticate against all of the endpoints; and you will have to pick and decide between SDKs, NuGet packages, library after library to pull it all together. Sure, these options are great for application developers. But I’m not a developer. I’m a system administrator. An automation engineer. I don’t have interest to load assemblies into core infrastructure that is changing day to day…

Enter – powerShell, and Invoke-WebRequest/-RestMethod. With these two commands as the base, and a bit of ingenuity – you can do all the calls needed to authenticate yourself and start working with a site’s API endpoints. Added benefit of doing it this way? You can use the same code on powerShell 6 on Linux or Windows.

1. Figuring out the authentication flow.

oAuth 2 authentication flows are configured ahead of time by the vendor you are connecting to. Systems will very, but the general flow you will interact with seems to be answered by the following questions. Are you authenticating as a user every time you need to access a service? What about automating server to server work? Do you want to prompt user’s for consent once, assume consent from SSO referred connections, or require consent every single time you request an authentication? oAuth supports just about any combination of this, but isn’t necessarily configured to be consumed. Also, most user based authentication flows support the use of refresh tokens. These special tokens can be used to authenticate in a never ending loop without proving the requester is still valid. The idea is that you already went through the authentication, authorization, and validation process once – no need to do it again since only the authorized account holder would have gotten the refresh token.

Are you authenticating as a service account, or automation system? oAuth 2.0 is also setup to support authentication by signing a request with a private key. Vendors may vary – Google will provide a .p12 file. Box requires you to create your own, and upload the public key. Either way, you use this private key to digitally sign a configured request to get a token, and can be done with no user interaction.

2. The gotchas of doing oAuth tokens

In a user based authentication flow, at some point, you will need to make a request in a web browser. Works great if you are on linux and have access to the selenium-driver, but in a Windows world can get tricky. Invoke-WebRequest gets most of the way, but just not far enough in a complex vendor environments. Basic auth / form auth frequently don’t work well here either. As mentioned previously about refresh tokens though – it is possible to do this web browser process once, gather a refresh token, and then continue on in life for as long as you keep your refresh token uncompromised.

Getting an access token via Json-Web-Token(JWT) request only is more complicated, but is the general process for doing a service to service oAuth request. Google it, and you will get lots of explanations of all the bits and pieces. You’ll also get very few explanations on how to generate one.

3. Code some stuff – go go powerShell

Using the UMN-Google, UMN-Azure, or UMN-Trello repos at https://github.com/umn-microsoft-automation as an example, you will find functions that do the heavy lifting on getting access to various API endpoints.

In any of these cases there is a general flow of process.

  1. Gather who is requesting access to what
  2. Take that information and go to a claims end point to verify authentication. This is generally done in a web browser. These powerShell functions are setup to do an IE popUp to let a user login for verification.
  3. Take the claim received if verified, and go to token endpoint to exchange for a token and possibly a refresh token.

A. function ConvertTo-Base64URL
This is a core component that encodes json data into the needed Base64Url encoded strings. This is needed when using certificates to sign a JWT request.

B. function Get-xxOAuthTokenUser (where xxx = G for google, or Azure)
This function assumes that you have done the work ahead of time to create a google project or Azure application endpoint. Mostly, you just authenticate in a web browser to get an authorization code that is exchanged later for your tokens.

C. function Get-xxOAuthTokenService (where xxx = G for google, or Azure)
This function uses a signed JWT request from a private key (Google) or secret key (Azure)to get an access token. Service to Service flows have the possibility to go directly to the token endpoint with a properly formulated JWT request.

Emergency! We need that patched!

Infrastructure is never a perfect world when it comes to Microsoft patch management. Is your WSUS service healthy? Is it integrated to SCCM as a software update point? Are you free of errors, but still not sure? Did that security patch really go out?

Your security monitoring, SCOM, or log analytics tool might tell you otherwise; and what are you left to do?

Do you believe the SCCM deployment reports, or your monitoring that says a critical patch is missing?

No matter the case of what, or why – sometimes there comes a point where you just need to brute force install a patch. Also, you need it, like, NOW.

You’ve got options if you’re prepared with DSC, but this is production, and we need them patched now – reboot later! Business requirements… alas.

Hopefully you can pull a dynamic list of systems from SCOM, SCCM, VMWare, Hyper-V, AD, or where ever… and just pipe it through. Obviously, if you need to reboot now as well, that is easy enough to modify from this little one-off.

Prep:
1. Get a list of systems you need to apply the patch to.
2. Extract the .cab of the KB you download from Microsoft.
3. Assumes you have remote powerShell / Admin access.

$listOfComputers| foreach {
$session = new-pssession $_
copy 'path to patchKB.cab' 'path to patchKB.cab' -tosession $session

Invoke-Command -session $session -scriptBlock {
## Check if KB is already installed
$KB = get-hotfix |where{$_.hotfixid -eq 'KB#####'}
if (!$KB) {

## Just in case you need to verify the OS version ##
$os = (Get-WmiObject -class Win32_OperatingSystem).version

## dism... I know -- allows for remote execution using no new processes, or EULA to the KB ##
dism.exe /online /add-package /PackagePath:c:\windows\temp\patchKB.cab /norestart
}

Else {write-host 'KB previously installed'}}}