Workflow Manager Addendum MP for SQL Aliases
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