Windows Server 2012: Group Managed Service Accounts

re: Windows Server 2012: Group Managed Service Accounts

Doug Symalla — Tue, 05 Mar 2013 01:57:15 GMT

@Sami;

It depends. Service accounts, in general, do require a CAL (assuming they are being used to access resources on another Windows host - which is generally the case). However, if you are using per device (rather than per user) licensing, you wouldn't need a CAL for the service account.

re: Windows Server 2012: Group Managed Service Accounts

Doug Symalla — Tue, 05 Mar 2013 01:53:42 GMT

@ Ryan

There is no (supported) way for a human to retrieve the password for the gMSA. After some further investigation, it appears that the System Center 2012 products (including SCVMM) are were not designed for gMSA's. The product teams are aware of this limitation, so hopefully they implement support in future versions.

re: Windows Server 2012: Group Managed Service Accounts

Sami Marzouki — Mon, 25 Feb 2013 13:22:39 GMT

Does gMSA accounts require a Windows CAL?

re: Windows Server 2012: Group Managed Service Accounts

Ryan — Thu, 07 Feb 2013 19:42:40 GMT

@dsymalla

We are attempting to install System Center 2012 components using Group Managed Service Accounts but have been running into issues with the installers not allowing you to specify a username without a password. We seem to have been able to overcome this limitation with Orchestrator by installing with one set of credentials and then changing to the gMSA (as documented www.ryanmelena.com). With Virtual Machine Manager, however, the documentation states that the credentials you install with can not be changed after the fact (as they are encrypted and stored in the VMM db). Is there any way you know of to retrieve the current gMSA password for a host in order to use it for an installation process like VMM?

Thanks!

re: Windows Server 2012: Group Managed Service Accounts

Santosh Bhandarkar — Thu, 03 Jan 2013 20:42:54 GMT

Great post Doug

re: Windows Server 2012: Group Managed Service Accounts

Doug Symalla — Wed, 02 Jan 2013 20:08:47 GMT

@ Drosper

The password for the gMSA is not actually stored in AD, but is generated on-demand by 2012 DCs as the constructed msDS-ManagedPassword attribute. When constructed (for a machine) it is returned as a binary blob. To actually de-construct this blob into the password you would need (among other things) the KDS root key (msdn.microsoft.com/.../hh881194.aspx). In short, this password is as secure as your DCs. If a DC is compromised, you must assume this password (as well as any other passwords) have been compromised.

When a machine attempts to retrieve the password, it creates an encrypted RPC session to a 2012 DC, using the DRSR RPC Interface. This session requires authentication, and the transfer of data on the wire is encrypted. It's much like a Netlogon RPC session, that is used as a secure channel between clients and DCs. The data is as secure as the computer/host that is using the gMSA. If the host is compromised, you must assume the gMSA has been compromised.

I don't believe there are any additional security details that need to be considered. A gMSA (or its password) is no less secure than a normal service account, other factors being equal. In either case you must assume a password has been compromised if the host has been compromised. So the real benefit of the gMSA is in the automatic changing of the password. gMSA account passwords aren't being exposed to administrators, who can sometimes be a weak link in securing passwords.

re: Windows Server 2012: Group Managed Service Accounts

Drosper — Thu, 27 Dec 2012 11:44:08 GMT

How is the password or hash encrypted or protected in AD? How is the password/hash protected in transit over the network when sent from the KDS service on the controller to the target machine?

What other security issues or precautions are there that you are not telling us about?

re: Windows Server 2012: Group Managed Service Accounts

Nebuly — Wed, 26 Dec 2012 12:56:43 GMT

@dysmalla : thanks for confirming it. I'm afraid those requirements will be a show stopper for LoB apps, however i can see a few uses on dedicated infrastructure servers, especially stuff like WSUS by example.

re: Windows Server 2012: Group Managed Service Accounts

Doug Symalla — Wed, 19 Dec 2012 01:24:10 GMT

@Byron;

Your observation is spot on. If you allow a machine access to use a gMSA, it can use the account for any service/scheduled task on the machine. Thus, anyone who has access to configure services/scheduled tasks could potentially use/abuse the gMSA.

Ultimately, gMSAs don't absolve you from security best practices such the principal of least privilege. So don't grant any service account privileges greater than it requires, and don't grant users privileges greater than they require to do their job.

re: Windows Server 2012: Group Managed Service Accounts

Byron — Tue, 18 Dec 2012 20:32:23 GMT

If this service account is granted Domain Admin privileges for a task, what is to stop another admin user from using that account for other purposes other than the one(s) it was intended for?

Historically, this was done by not sharing the password, but in this case, knowing what the password is is not needed it seems.