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:SOFTWAREMicrosoftMSSQLServerClientConnectTo'
$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
My thanks to Chuck Hughes and Mike Sadoff, for their time and testing this more robust discovery method.
Gallery download here
Don't forget to override the original workflow manager discovery!
Microsoft.WorkflowManager.v1.Addendum.WFPSDiscovery