What about group managed service accounts, or gMSAs for short?
Say that three times quickly, by the way. The situation
here is our user accounts are for humans.
They're interactive identities, right? And that's fine.
That's the way it should be.
Well,
what about when you need to provide a security context for a Windows
service or perhaps for a scheduled task or perhaps for a load
balanced server farm like you see in this diagram I created? You
might have an IIS‑based server farm. And if you've worked with
Internet Information Services,
you know that you have the application pool that, in turn,
requires some kind of service account identity.
Now there's special identities called anti‑authority accounts
that you're probably familiar with like system,
local system service, network service, everyone, authenticated users,
interactive users. Those are great, but those are dynamically
populated identities. You probably need a dedicated, non‑interactive
service account to attach to these services so that you can give
that service account permissions.
This is the use case for the managed service account.
Now, there are two flavors or types of managed service accounts,
standalone, which is available only on a single server, or what really is
the standard nowadays, the group managed service account. What are some of
the value propositions of using one of these?
Well, the main thing is that you don't have to worry about password changes.
In other words,
if you're configuring an IIS app pool service identity and it's not a
gMSA, and you do a password change on the service account that you
might've manually created in Active Directory,
then you better quickly update that password in the app pools, or
you're going to have service breakdowns. When you do a gMSA, Active
Directory automatically manages the password. And the
auto‑generated passwords are super long,
240 characters, and we have the security advantage that none
of your administrators know that gMSA password. It's private
to Active Directory. What else?
Well,
we can instruct Active Directory to rotate or change the
password automatically and wait for it.
The password change is automatically picked up by registered applications.
This is so cool.
Also,
what's particularly cool about the group managed
service account is that your credential,
your gMSA is then shareable across multiple computers instead of having to
have a separate standalone MSA for each server in your farm,
which is not very scalable.
Now let's take a look at my diagram at right.
The high‑level overview for implementing a gMSA is as
follows. You're going to create an Active Directory group of
some kind, a domain local group, say,
or a global group that consists of your web servers that are going to
be, in this case, load balanced. In this example,
I'm using IIS web servers.
So I've got those computer accounts. We'll also want to include if
we're going to apply a gMSA to a Windows service,
we would aggregate the servers that run that service, or if we were
doing a distributed scheduled task, same thing.
So you organize the servers in question who will consume the
gMSA into an Active Directory group. Then,
when you define the managed service account,
you link it both to the group, and then lastly,
you link the gMSA to the service.
Isn't that beautiful?
I'll do a demo so that the theory really locks over, but I've certainly covered what you need to know for your AZ‑800 exam success.