Category: Code

Posted on

Azure AD Proxy, OpenID SSO, and Azure AD Request Identification via Header Values

Backstory

I recently found myself writing some OpenID/SSO code and realized that for some reason Azure AD Proxy doesn’t rewrite the header value for replyurl. This means that while you connect to Azure AD Proxy to access your app, when your internal app then attempts to authenticate to Azure AD via OpenID (or SAML), once it is successful it returns you to the internal URL not the proxied url.

Manually Setting the RedirectUri / Reply URL

First you must understand, you can not set this value on the Azure side, it MUST be set on the app. In our case we wrote our own app so to fix it we wrote code to trap the event for OnRedirectToIdentityProvider and then set our own hardcoded Azure AD Proxy external URL. We cleaned this up by making the external URL a parameter in the configuration file instead of code itself. 

options.Events.OnRedirectToIdentityProvider = (context) => {
    context.ProtocolMessage.RedirectUri = <Azure AD External URL/SSOpath>;
    await Task.FromResult(0);
}

Determining an Azure AD Proxy Client Request from a Normal one

Next up we didn’t want to just hard code the azure external url. This would mean we could never use the internal URL for testing. So we also added in a check of the following request header value:

Name: HTTP_X_MS_PROXY
Value: AzureAD-Application-Proxy

We now check to see if HTTP_X_MS_PROXY is present and if so change the RedirectUri to the Azure AD Proxy External URL. Otherwise, we let it return the internal URL.

Posted on

PowerShell Error: The underlying connection was closed: An unexpected error occurred on a send

I got mad the other day, trying to do a simple wget (i.e. invoke-webrequest) to an Azure Function I made and I was getting:

The underlying connection was closed: An unexpected error occurred on a send

I tried switching to .NET Webclient but still same error.

What was more frustrating is that it worked on my dev machine, worked on the server I was running to code on in a browser, just not in powershell.

The Fix

Apparently PowerShell version 5 defaults to TLS 1.0. Azure Functions require TLS 1.2. The fix is super simple, just add this in your code on its own line:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Posted on

Record Hyper-V Console

Every few months thanks to Windows 10 its time to roll out a new image. This is a simple yet tedious task.  Thanks to modern day multi-tasking its easy to miss something in testing of new images. Then I have to restart the whole process wasting time.

This script will record the screen by taking screenshots every second. I suppose you could use a 3rd party tool to merge them together into a video if you really needed to.

The script includes de-duplication of images so if the screen stops moving so does the recording. That plus using JPEG format makes the images fairly small.

Oh yes, dont forget to “Run as Admin”

Enjoy!

{{CODE1}}

Big thanks to Ben Armstrong for the original work on this script:

https://blogs.msdn.microsoft.com/virtual_pc_guy/2016/05/27/capturing-a-hyper-v-vm-screen-to-a-file/

Posted on

Query Azure SQL Database Table via Powershell

Real quick one… I have used similar code for ages to query local on-premise SQL databases. However Azure requires the use of encrypted connections.  Here is some fully working code:

#Set Defaults (Optional) which allows you to skip defining instance, user, and password each time
$AzureDefaultInstanceName = “myUniqueAzureSQLDBName”
$AzureDefaultUserID = “myUserIDToAzureSQL”
$AzureDefaultPassword = “myPasswordToAzureSQL”

#The actual function
Function get-azureSQL (
[string]$InstanceName = $AzureDefaultInstanceName
,[string]$UserID = $AzureDefaultUserID
,[string]$Password = $AzureDefaultPassword
,[string]$Query){

$connectionString = “Server=tcp:$($InstanceName).database.windows.net,1433;”
$connectionString = $connectionString + “Database=$($InstanceName);”
$connectionString = $connectionString + “User ID=$($UserID)@$($InstanceName);”
$connectionString = $connectionString + “Password=$($Password);”
$connectionString = $connectionString + “Encrypt=True;”
$connectionString = $connectionString + “TrustServerCertificate=False;”
$connectionString = $connectionString + “Connection Timeout=30;”

$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = $connectionString

$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = $Query
$SqlCmd.Connection = $SqlConnection

$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd

$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet) | Out-Null
$SqlConnection.Close()

return $DataSet.Tables[0]
}

#Querying Azure SQL using Defaults defined above
get-azureSQL -Query “select * from logs”

#Querying Azure SQL without Defaults
get-azureSQL -InstanceName “myUniqueAzureSQLDBName” -UserID “myUserIDToAzureSQL” -Password “myPasswordToAzureSQL” -Query “select * from logs”

Sure you can install the Azure Powershell module and then the SQL commands too but most of the time you need to get in quick and grab something, this code is super fast and works every time for me and best of all…. no installs.

If this helped you or you want to suggest an improvement, please just leave it in the commands.

Enjoy,

-Eric

Posted on

Secure PowerShell Scripts running via Windows Task Scheduler using MD5 Hashes to safeguard against Tampering

Over the years the number of Task Scheduled based PowerShell scripts has increased. However, this poses serious potential security risks.

The Security Issue

Given that these tasks commonly run as a service account, with additional rights, it is a potential attack vector.

Simply changing the underlying script can allow a hacker access to anything the service account has access to.Even signing the scripts can be useless as the system can be configured to ignore signing.

The Solution

I have created this one-liner that Task Scheduler can use that will only run the script if the hash of the script matches the hash listed in the one-liner. If someone tries to change this in Task Scheduler they would be required to reenter the proper password.

powershell.exe -command if ([System.BitConverter]::ToString((New-Object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider).ComputeHash([System.IO.File]::ReadAllBytes(‘C:\temp\test.ps1‘))) -eq ‘33-CD-2A-54-ED-F3-0F-94-5F-D2-97-D9-FE-4F-45-79‘) {. c:\temp\test.ps1} else {Send-MailMessage -SmtpServer smtp.server.domain.com -From whatever@domain.com -To you@domain.com -Subject ‘Failed to Run Script – Hash Not Correct’}

Notes about One Line Script Executor

  • You need to replace c:\temp\test.ps1 with the path to your script. (two places in this example)
  • You must supply the hash of the script. (use the following command to get it)

[System.BitConverter]::ToString((New-Object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider).ComputeHash([System.IO.File]::ReadAllBytes(‘C:\temp\test.ps1‘)))

  • Script will email you if hash fails.
    • Change TO: and FROM: to match your needs.
  • Do NOT use double quotes in this script, do NOT forget that CMD will pass this to PowerShell, and will strip out double quotes.

If this helped you or perhaps you have suggestions to make it better, please do leave them in the comments.

Enjoy

-Eric

Posted on

Connect to Azure SQL Database using ColdFusion 10/11/2016

My how the years fly and things change.

Even in 2017 I still find value in making quick enterprise applications in Coldfusion. However the world is a changing, many of my endpoint are beyond the boundaries of my corporate firewalls.

I have ended up with a ton of nodeJS webservices endpoints  running as docker containers in Azure jamming away data in Azure SQL. I want Coldfusion to be able to utilize that data.

The Solution

The solution is stupid easy… you can use the native Microsoft SQL Driver, no need to mess with anything else.

Go ahead put in the basics

  • Database: Name as shown in Azure
  • Server: something.database.windows.net
  • Port: 1433
  • Username: <sqlaccountname>@<databasename>
  • Password: <password>

Then for the secret sauce

  • Hit Show Advanced Settings
  • In the connection string put the following:

EncryptionMethod=SSL;Encrypt=yes;TrustServerCertificate=no;

Note: Encrypt=yes may not be needed but since its working I am not touching it.

And that’s it!

If this was helpful or have a way to make it better? Let me know in the comments.

-Eric

 

 

 

 

Posted on

Get a list of all System Center Virtual Machine Manager (SCVMM 2012 R2) Users via SQL

Ever need to send a notice to your System Center Virtual Machine Manager (SCVMM) users like “Upgrade to UR7 coming” but realized you never took the time to collect all of their names?

Here is some quick SQL that will give you the names of anyone who has actually used the platform:

select
distinct replace(SessionOwner, ‘contoso\’,”) as Username
from [tbl_TR_TaskTrail]
order by 1

As a added bonus if you replace contoso with your domain name it will strip that out making it ready to past into outlook for name resolution.

Enjoy!

-Eric

Posted on

Search Active Directory for Specific Word or Phrase (string) in a Group

Ever tried to search for a group by name but the part you know is in the middle? Did you think you would be smart and go to the advanced tab then do “blah” contains, hit search and find nothing?

Quickest way to find is actually via PowerShell

Get-ADGroup -Filter {Name -like “*blah*”} | select SAMAccountName

Works great!

Enjoy

-Eric

Posted on

Powershell | Using Modify AD Groups with Alternate Credentials

Quick one. Had an issue where I needed to remove a user from a AD group in another domain. To my surprise it was harder then I had thought. At first I settled on using set-QADGroupMember (the Quest Powershell CMDLET) as it takes -connectionusername and -connectionpassword. However it was dog slow. I think that was due to being over a WAN link and it was querying all members (which took about 2-3 mins).

I needed something swifter. I went directly to the .NET controls and reduced the time to about 15 second.

$GroupDN = “LDAP://CN=GroupName,OU=Distribution Lists,DC=domain,DC=local”
$Group = New-Object -TypeName System.DirectoryServices.DirectoryEntry -ArgumentList $GroupDN,”username”,”Password”
#To Add
$Group.Properties[“member”].Add(“DN of the User you wish to add”)
#To Remove
$Group.Properties[“member”].Remove(“DN of the User you wish removed”)
$Group.CommitChanges()
$Group.Close()

Enjoy!

-Eric