16 Jul Using managed service accounts

Posted at 12:12h in Microsoft, Microsoft SQL server, Security by

It’s no news to you that nowadays we’re targeted more than ever before security-wise. So we need to push every button we have at our disposal to increase our defenses.

One of the weak points is that the accounts are used to run services. In most companies, the traditional ways are still hallowed: a dedicate account for the service is created and the sysop does her/his/its utmost best to come up with a hard to guess password. To put the icing on the cake, the option “password does not expire” is enabled so that the service doesn’t stop unexpectedly after a certain amount of time.

There are several problems with this approach:

  • The password must be stored in a safe way so that only authorized people can retrieve it.
  • Even then, there is still a risk that somehow the password “escapes” into the world (e.g. when the sysop is fired).
  • Quite vexing, is that when the password needs to be changed, you must stop/start the service which might result in a downtime for your end-users.

Fortunately, there is an elegant solution by using a “managed” service account. These accounts come in 2 flavors:

 

Managed service account (MSA)

Just like the traditional accounts, a managed service account is a type of domain account.
You assign this account to a single member computer to run a service.
The password is managed automatically by the domain controller. If the domain controller decides to change the password, then you don’t have to stop/start the service.
Administrators do not require to store the passwords in a password vault.
It uses a very complex password (120 characters), that it is not even known by the administrators. This also avoids the risk of circulating the password unknowingly.
You cannot use this account to log in into a computer: it can only be used to run a service.
MSA accounts have the suffix “$”.

Advantages
  • The password is unknown which reduces the risk of hacking.
  • The password is changed automatically without needing to stop/start the service (no downtime!).

 

Disadvantage
  • An MSA is assigned to a single computer, it cannot be used e.g. on different nodes of a Windows cluster.

 

Group managed service accounts (gMSA)

This option is similar to an MSA but in this case you can assign this account to more than one computer (e.g. the nodes of a cluster).
Since SQL Server 2014 this is also supported for standalone servers.
Since SQL Server 2016 and later: it is supported for failover cluster instances, and availability groups.
It requires Windows Server 2012 R2 or later. If you use Windows 2012 R2 servers then you must install KB 2998082.

Advantages
  • Idem as for an MSA
  • It can run on multiple servers (e.g. on all nodes of a cluster).

 

Caveat for SQL Server

For an SQL Server, you have to specify “delayed start” and add dependencies for Netlogon and W32Time.

If you weren’t to do this, there is a big chance that your SQL Server service(s) won’t start after a reboot.

Here is the “how to”:

  1. Start “services.msc” (or your preferred method) to view the services running on your SQL Server:
  2. Change the “Startup type” from automatic to “automatic (Delayed start)”.
  3. Use the registry editor and search for “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLSERVER”
  4. Create a new multi-string value “DependOnService”.
  5. Add these values:
    1. W32Time
    2. Netlogon
    3. KEYISO: this value should already be present.