A SQL Alias is kinda like wearing disguise glasses…

From a security perspective, you can make things difficult for attackers by specifying a SQL alias and different port for SQL.

Symptom – discovery fails for WFM pack

Trying to monitor and figure out what the real database name, instance, etc. can be a challenge.

A couple of years ago, I was able to find an example for one customer where the registry key shed light on the alias.

The workflow manager management pack has a DataSourceModuleType “Microsoft.WorkflowManager.Addendum.v1.WFCommandExecuterDataSource”, where this change successfully retrieved the sql server name.

This datasource uses the PowerShell script (WorkflowPSDiscovery.ps1)

This function was changed in one example

# Get computer name from splitted dataSource
function GetPrincipalName {
param(
$ADDomain,
$ss
)

#$ssWithoutPort = $ss[0].split(‘,’)
#if (-not $ssWithoutPort[0].Contains(‘.’))
#{
# $ssWithoutPort[0] = $ssWithoutPort[0] + “.” + $ADDomain.Name
#}
#$principalName = $ssWithoutPort[0]

$key = ‘HKLM:\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo’
$sqlfromalias = (Get-ItemProperty -Path $key -Name $ss).$ss
$sqlserverstr = $sqlfromalias.Split(‘,’)
$sqlserver = $sqlserverstr[1]
$principalName = $sqlserver

return $principalName
}

Ran into this discovery issue a second time, and the function didn’t solve the failure.

Real quick – a shout out and my thanks to Chuck Hughes and Mike Sadoff, for their time and testing this more robust discovery method.

Added logic to fix the assumed InstanceName ($instname) – Most likely why my first function worked (configuration had default SQL instance name of MSSQLSERVER )

Added GetSqlAlias function to help decode the disguise

Gallery download here

Don’t forget to override the original workflow manager discovery!

Microsoft.WorkflowManager.v1.Addendum.WFPSDiscovery