What is the difference between service accounts and managed service accounts?

Modules

To regain control, you need to reset the service property which associates it with a managed account. To do this (for the service I tested against here), run the following command as an administrator:

sc managedaccount WFDSConMgrSvc false

You can also assign permissions to objects such as files etc, using the normal permissions dialogue
However, you won’t see the MSA unless you add ‘service accounts’ to the object types selection dialogue like this:

Group Managed Service Accounts

The gMSA was introduced with Windows Server 2012. Unlike an MSA, a gMSA can be associated with multiple computers. Otherwise, it behaves very similarly i.e, the password is complex and – for the gMSA – automatically managed by the Active Directory subsystem and stored as a new AD attribute.
[MSAs piggybacked on the computer account password distribution subsystem, which is why they were restricted to a single target endpoint].
Because a gMSA can be associated with multiple computers, there needs to be a new Active Directory attribute to manage it. There is also a subsystem, the group key distribution subsystem, which is responsible for propagating the complex password changes out regularly to all the devices which are associated with a gMSA.
Adding a gMSA is very similar to adding an MSA. However because you have an additional interface with Active Directory and the group key distribution subsystem, you need to ensure you have a root key for the subsystem. Normally it takes 10 hours before such a key becomes active, (as a safety measure to ensure replication is complete), but in a lab, you can ‘backdate’ this, as in the example below:

import-module activedirectory
add-kdsrootkey -effectivetime((get-date).addhours(-10))

You then add the gMSA in a very similar way to adding an MSA:

new-adserviceaccount -name MyNewMSA -enable $true -dnshostname wkssv001.urth.local
set-adServiceAccount -identity MyNewMSA -PrincipalsAllowedToRetrieveManagedPassword WKSSV001$

Note that you specify the computer account on the target endpoint as having permission to retrieve the managed password for the gMSA.
You then associate the gMSA with the endpoint, much as you did with an MSA. So on the endpoint WKSSV001, run the following:

import-module activedirectory
install-adserviceaccount mynewmsa

The critical difference, though, is that you can associate further devices with the account, not just a single device. You do so by allowing the device access (as in the set-adServiceAccount cmdlet above) and then repeating the association process on each endpoint you want to be associated with the gMSA.

Examining the gMSA managed password

The gMSA password can be retrieved using the example PowerShell script shown here. This must be run as LocalSystem, since only this account has the required AD privileges to retrieve the attribute. The password is stored in plaintext in the msDS_ManagedPassword attribute.
Here we retrieve the password for the mynewMSA account (credit: Ondrej Sevecek)

$svc = [ADSI] ‘LDAP://cn=mynewmsa,CN=Managed Service Accounts,DC=urth,DC=local’
$svc.AuthenticationType = ‘Sealing,Secure’
$svc.RefreshCache(‘msDS-ManagedPassword’)
$svc.’msDS-ManagedPassword’.Value
$gmsaBlob = $svc.’msDS-ManagedPassword’.Value
[UInt16] $pwdOffset = [BitConverter]::ToUInt16($gmsaBlob[8..9], 0) # Note: this value must not be 0x0000
[UInt16] $previousPwdOffset = [BitConverter]::ToUInt16($gmsaBlob[10..11], 0) # Note: if this value is 0x0000 then the account does not have any previous password
$pwdEnd = $pwdOffset
while (($gmsaBlob[$pwdEnd] -ne 0) -or ($gmsaBlob[$pwdEnd + 1] -ne 0)) { $pwdEnd += 2 }
[byte[]] $gmsaPwd = $gmsaBlob[$pwdOffset..$pwdEnd]
[BitConverter]::ToString($gmsaPwd)

 Domain accounts and local secrets

So…. Are these new account types more secure? Well – kind of. The passwords are long and complex and change regularly. However, they share the same vulnerability as normal domain accounts when used to manage service logons. A service has to be able to retrieve its login credentials even when the domain controller cannot be contacted. This is because local endpoint resources might be secured using those credentials. Consequently, the credentials have to be stored locally in the endpoint registry.
MSAs and gMSAs behave similarly to normal domain accounts with respect to the local secrets hive in the endpoint registry.
This means that a service set to log on as an MSA or gMSA will still have access to the plaintext password (which is reversibly encrypted in the registry). This also means that an attacker can still recover these credentials, just as they could for a normal domain account. Unfortunately, this is a more significant compromise than merely retrieving the NTLM hash of a local account or the MSCachev2 hash of a domain account.
A mitigating factor, though, is that MSAs and gMSAs cannot be used to interactively log in.
For an MSA, the local secret key looks like this:

_SC_{262E99C9-6160-4871-ACEC-4E61736B6F21}_mynewMA$

As far as I can determine, the GUID value is the same for all MSAs created on the same endpoint.
For a gMSA, the local secret key looks like this:

_SC_GMSA_{84A78B8C-56EE-465b-8496-FFB35A1B52A7}_485624eaa822e587fdcdfd45f85df1ee01d7a31e4a73217e07382d084cca89b6

The GUID appears to be constant (but different from the MSA GUID) for all gMSAs associated with an endpoint. However, the remainder of the LSA key changes for each gMSA on the endpoint.
Nevertheless, the plaintext complex key can still be recovered from the gMSA local secret, as shown below:

[Note: this is recovered from a lab endpoint in its own test domain, so I am not revealing anything particularly sensitive here]
_SC_GMSA_{84A78B8C-56EE-465b-8496-FFB35A1B52A7}_485624eaa822e587fdcdfd45f85df1ee01d7a31e4a73217e07382d084cca89b6
————————————–
2201000000000000000000000000000001000000220100001000000012011a7caf7a39518793861df9705a88c2d190642b53d20392284062e10e24c42fd1e162e703bee3add0cce008b667f609eac66b4e19e1c6e99a2c757f3d39a16329650927875ad5f7594ee221a8248bb28d1293c7e19de8c5ececdcf67b9579eeb3c7d71df096d6f09980af3979fb8f515bb2ab8a6589a688f0686b13472b44f8166c8ab1ea7a67d41c6bf5cdc148a42e6f81603a9661f9aba52d745bce6006cda0936102bda2e5ee76f7830d14806bdb50a5b251dfbaf2d0c131b9f15c2cd64a1cf435f006d30fb31bac6e1d2d9f91756e288b56ce106ecebd541c49beb2a8b158c9ea2481a0600a4faa3faa848612ab4768e45cdd99a3d207fbae87556ff74166dbc600003b392c09481500003bdb5b56471500000000000000000000000000000000

How do I know this is the complex key? In running the PowerShell script above to retrieve it from Active Directory I can easily compare it to the decrypted local secret value and identify its location.
Note, however, that the NAME of the gMSA (unlike the MSA) doesn’t appear to be stored in plaintext in the secret. It is, presumably, recoverable – however, I don’t have information on how to do so currently. This – in theory – makes it a little more difficult for an attacker, since unlike an MSA, where the account name is clearly part of the local secret key, you don’t have that information here.
You may be wondering if the computer account itself is stored in the local secrets hive of the registry. The answer is yes. It can be retrieved using the LSA key

$MACHINE.ACC

As far as I am aware, the computer account password is also retrievable from the local secret in a similar way. Therefore, even when using local accounts to run a service, we need to be aware that the computer account they use to access network resources can potentially have its password ex filtrated and used by an attacker. However, like an MSA/gMSA, computer accounts cannot login interactively.

Summary

How do we retrieve all this information? Well, it’s quite complex but well documented and involves extracting some registry hives normally accessible only to LocalSystem, then decrypting the information held in them. The decryption process was developed using ‘security by obscurity’ but unfortunately the algorithms were reverse-engineered some time back, so there is plenty of code in the public domain. In fact, the definitive reference is written in Python, making it really easy to understand. Microsoft made a small change in Win 10 build 1703 to attempt to improve security but it, too, was reverse-engineered within a short period of time. Intrinsically, if a local process needs to decrypt information offline, there’s no way to protect that. This is why mobile devices should always enable full-disk encryption. That way, a stolen device cannot have credentials extracted from its disk storage subsystem.

What is a managed service account?

What are the different types of service accounts?

What is a service account?

What is the key difference between a managed service account and a group managed service account?