Sql-server – how service sid operate under the covers

From the WMI documentation, I couldn't find any way to directly obtain a service SID, probably because as far as I've seen, service SIDs aren't physical directory objects, and thus couldn't be queried except where they appear as part of ACLs. This would also explain why the values aren't persisted in the registry.

Having said that, the service SIDs definitely do not appear in Win32_SystemAccount. Using PowerShell on a sample machine, you can verify this by running Get-WmiObject -Query "SELECT * FROM Win32_SystemAccount".

Luckily, however, there are alternatives:

1. Per this TechNet blog post, the non-well-known portion of a service SID is generated by taking a SHA1 hash of the uppercase service name, and then splitting apart the results into five unsigned 4-byte numbers. The following code performs this computation and returns the SID as displayed in Windows:

   DECLARE @serviceName nvarchar(128) = 'MSSQL$SQL2008R2DEV';
   
   SELECT
       'S-1-5-80' +
           '-' + CONVERT(varchar(20), CONVERT(bigint, CONVERT(varbinary(4), sys.fn_varbintohexsubstring(0, a.BinSid, 17, 4), 2))) +
           '-' + CONVERT(varchar(20), CONVERT(bigint, CONVERT(varbinary(4), sys.fn_varbintohexsubstring(0, a.BinSid, 13, 4), 2))) +
           '-' + CONVERT(varchar(20), CONVERT(bigint, CONVERT(varbinary(4), sys.fn_varbintohexsubstring(0, a.BinSid, 9, 4), 2))) +
           '-' + CONVERT(varchar(20), CONVERT(bigint, CONVERT(varbinary(4), sys.fn_varbintohexsubstring(0, a.BinSid, 5, 4), 2))) +
           '-' + CONVERT(varchar(20), CONVERT(bigint, CONVERT(varbinary(4), sys.fn_varbintohexsubstring(0, a.BinSid, 1, 4), 2)))
       FROM
       (
           SELECT
               CONVERT(varbinary(20), REVERSE(HASHBYTES('SHA1', UPPER(@serviceName)))) AS BinSid
       ) a;
   

   The binary SID can also be obtained by using the SUSER_SID function (with some extra processing to handle the fixed portion) in lieu of HASHBYTES. (Note that the raw binary SID must have its endianness reversed before conversion and output. Also, the @serviceName variable being nvarchar is important.)

   If you have .NET available, doing the hash calculation is trivial. Here's the C# code to do it:

   using System.Security.Cryptography;
   
   ...
   
   string serviceName = "MSSQL$SQL2008R2DEV";
   
   HashAlgorithm ha = HashAlgorithm.Create("SHA1");
   byte[] hash = ha.ComputeHash(serviceName.ToUpper().SelectMany(c => BitConverter.GetBytes(c)).ToArray());
   
   string sid = "S-1-5-80";
   
   for (int i = 0; i < 5; i++)
       sid += "-" + BitConverter.ToUInt32(hash, i * 4);
   

2. I suspect the SIDs could be found using classes in the .NET System.DirectoryServices namespace, either by inspecting group membership (fragile), or by some other method. Unfortunately, the methods I tested to directly translate a principal name into a SID failed, so I'm not sure how SQL Server does it (PInvoke?). In any event, computing the hash isn't a big deal if .NET is available (in fairness, the code will be longer without the use of LINQ).

3. Capture the relevant part of the output of the sc utility as used below, or run this manually if you don't care about being able to automate the solution:

   sc showsid MSSQL$SQL2008R2DEV
   

This means the cluster network name (tcsdb) can't be registered with Active Directory at the moment. It could be that your newly primary node can't see a domain controller, or can't see a writeable domain controller, may have a network interface down, may be having routing problems, etc.