Managed Service Accounts and Group Managed Service 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
————————————–
22010000000000000000000000000000010000002201000010000000120
11a7caf7a39518793861df9705a88c2d190642b53d20392284062e10e24c4
2fd1e162e703bee3add0cce008b667f609eac66b4e19e1c6e99a2c757f3d39
a16329650927875ad5f7594ee221a8248bb28d1293c7e19de8c5ececdcf67
b9579eeb3c7d71df096d6f09980af3979fb8f515bb2ab8a6589a688f0686b
13472b44f8166c8ab1ea7a67d41c6bf5cdc148a42e6f81603a9661f9aba52d
745bce6006cda0936102bda2e5ee76f7830d14806bdb50a5b251dfbaf2d0c
131b9f15c2cd64a1cf435f006d30fb31bac6e1d2d9f91756e288b56ce106ece
bd541c49beb2a8b158c9ea2481a0600a4faa3faa848612ab4768e45cdd99a
3d207fbae87556ff74166dbc600003b392c09481500003bdb5b564715000
00000000000000000000000000000

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.