Virtual Accounts, as discussed in Part One, are local computer accounts which must use the domain computer account if they need to reach out and access network resources.
Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs), on the other hand, are domain accounts already, so when they access the network resources, they do so using the domain account credentials directly.

Managed Service Accounts

You’ll recall that every computer in a domain has its own Active Directory account, of the form domain\computername$. Unlike normal user accounts, this is associated with a complex password which is automatically upgraded every 30 days.
The computer account is used by any local account (that has permission to do so) to access any external resources. Thus, a service running as NT AUTHORITY\Network Service running on device Fooble123  in the domain Glatch (or, indeed, as a Virtual Account as discussed previously), will access external resources as the computer account GLATCH\FOOBLE123$
Managed Service Accounts (or MSAs) piggyback on this infrastructure to allow new domain accounts to be created that behave like computer accounts. They are named the same as a computer account in that they must have a $ on the end, so a valid MSA might be GLATCH\MYMSA$
[You don’t put the $ in when you’re creating them, however. It gets added automatically]
Also, like a computer account, they are associated with one, and only one computer. So, after creating one you have to assign it to a computer. Then you can set a service, or whatever, to use that account.
They are called Managed Service Accounts because the password for the account is automatically managed, just as it is for the domain computer account. Therefore, both MSAs and gMSAs have long, complex passwords which change regularly and which are not specifically managed manually, unlike normal domain (and local) accounts.
MSAs have an important limitation. Because the account is associated with a single computer, there are considerations when clustering. If a failover occurs, the account won’t work on the failover device because it’s not associated with that device.
Because of this, Microsoft went on to develop the Group Managed Service Account, or gMSA, which was introduced with Windows 2012. gMSAs are very similar to MSAs but they allow multiple devices to share the account, not just one.

Creating an MSA

The process of creating an MSA involves adding it to the domain and then on the target device, associating it with the device.
Note: the examples assume Win Server 2012 or (for endpoints) Win 10. The PowerShell cmdlets (below) got tidied up for Win Server 2012 so that MSAs and gMSAs were managed in a uniform way.
For example, add the account mynewMA to the domain (it will become domain\mynewMA$ when added)

import-module activedirectory
New-ADServiceAccount mynewMA –RestrictToSingleComputer
Add-ADComputerServiceAccount -Identity wkssv001 -ServiceAccount mynewMA

On the target endpoint (wkssv001 in this case) associate the account with the device

import-module activedirectory
Install-ADServiceAccount -Identity MynewMA

Note: You may need to download and install the RSAT subsystem, particularly if your target endpoint is not running a server OS (e.g Win10).
We can now set a service to log in using our new MSA, as in the dialogue below. Note that when you acknowledge the dialogue you see that the account is set (in this case) to URTH\mynewMA$

accounts
accounts

You need to delete the password before you can apply the change.
After you have done this, if you go back in and try and change the login details, you’ll be in for an unpleasant shock. They are greyed out, as shown below:

accounts

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:

accounts

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.