Good day, Cloud Gurus, and welcome back.
In this lesson, we're going to take a look
at securing service accounts.
Let's take a look at what we're going to cover.
First up, we'll take a look at managing service accounts
and we'll do a bit of an introduction
to what service accounts are,
and then we'll take a look at virtual accounts,
Managed Service Accounts,
and then finally,
we'll take a look at group Managed Service Accounts.
And then to wrap up, we'll do a bit of a demo
where we will deploy a group Managed Service Account.
Let's get started.
Let's take a look at some situations
where you might have a background process
that runs on the server with no user interaction.
Typically, this is part of an application
or more commonly, a Windows Service.
A Windows Service is a long running background process
running on a Windows computer.
Now, typically services run 24 by 7,
but they may also start and stop on demand,
and that application might require access to resources
that are located on another computer in the network.
And to access these resources,
that service is going to need an account
so that they can be authenticated
and authorized to access that resource.
Now, it might seem like a good idea to create a user account
and then grant that user account access to the resources
and then go ahead and configure that service
to run as the user account.
And then you might go ahead
and store the credentials like the username and password
for that account in a safe place.
Now, there are a few good reasons
why this is not a good idea,
and despite this, I still see this practice widely used
in enterprise environments.
The first reason why this is a bad idea
is around password management.
The password for that account will need to be managed
and ideally rotated frequently.
But worse than that,
it must be recorded and updated somewhere else,
and because it is known,
it can be used by anyone who knows the password.
The second reason is around account lockout,
standard user accounts can be easily locked out
by someone accidentally entering in an incorrect password
when they're configuring the service
to log on as the account.
Another common issue is around account confusion.
Standard user accounts,
and those that are used to run services
can be easily confused.
And that means that the account
might get accidentally disabled or deleted.
So what are some of the better alternatives?
Well, to solve this problem,
Microsoft gave us quite a few better alternatives
over a few versions of Windows.
Firstly, we got the virtual account,
then a little bit later on
we got the Managed Service Account
sometimes referred to as a standalone
Managed Service Account,
and then finally, we got the group Managed Service Account.
Let's take a look at each of these alternatives
in a bit more detail.
Our virtual account's best feature
is that the virtual account passwords
are automatic and not known.
But virtual accounts need to be configured per server,
which is okay if you don't have something
like Active Directory.
But if you do,
it would be better if you could configure permissions
for all of the servers at the same time,
say, using an Active Directory group, for example.
But when services are configured to use a virtual account,
you allow that service access to network resources
by adding the servers computer account object
to the access control list,
which might be okay on a small scale
but it can be troublesome with lots of servers.
But one of the big problems with virtual accounts
is that you can't isolate permissions per application.
If you have multiple applications
that run on a single server,
all the applications using virtual accounts
on the same server
access resources using the computer account.
So you'll never be able to tell which application
performed which function if you rely on auditing.
Around the same time as virtual accounts,
Microsoft also gave us Managed Service Accounts,
and Managed Service Accounts
are the same as virtual accounts
in that password management is automatic,
and it's not known by anyone who configures
the Managed Service Account.
But they do have an advantage over virtual accounts,
and that is that permissions
can be configured per application.
But Managed Service Accounts do have one limitation,
and that is that they cannot be shared between servers,
making scaling up and scaling down
by adding a removing servers a bit of a problem.
And then finally, with the release of Windows Server 2012,
Microsoft gave us the best option of the three,
group Managed Service Accounts.
With group Managed Service Accounts,
password management is automatic.
Permissions are configured per application
and the group Managed Service Account
can be shared between servers.
And group Managed Service Accounts
can be considered the gold standard in service accounts.
Let's take a closer look
at how you can use group Managed Service Accounts.
The first step in configuring group Managed Service Accounts
involves creating a Key Distribution Service root key,
that your domain controllers can use
to generate group Managed Service Account passwords.
And you can create a KDS root key using Windows PowerShell,
using the Add-KdsRootKey cmdlet.
Now, normally when you create a KDS root key
you need to wait up to 10 hours
for the root key to be available for the domain controllers.
But in the demo a little bit later in this lesson,
I'll show you a workaround that you can use
in a test environment to avoid that 10 hour wait.
And it's important to know,
that membership of the domain admins group
is required to create a KDS root key.
The second step involves
creating a group Managed Service Accountin Active Directory
using the New-ADServiceAaccount cmdlet.
Membership of domain admins or account operators
is required to create a new service account.
It's also important to know,
that the password change interval
for a group Managed Service Account
can only be set during creation.
And the third step
is to configure the service or application to use the gMSA.
Common applications and services
that can use group Managed Service Accounts
include IIS and SQL Server,
and you can use the Install-ADServiceAccount cmdlet
to cache the group Managed Service Account credentials
and test the account.
Now, let's take a look at a demo
of implementing a group Managed Service Account.
In this demo, we have a domain controller
in the Identity Subnet of the Brisbane Corporate Network,
and then we have 2 web servers.
Now, typically these web servers
will sit behind some sort of load balancing device,
and they're both identical
and we've deployed 2 for high availability,
and we also have a file server in the data subnet.
And that file server has some data on it
that the web servers need to use.
In this demo, we're going to create
and configure a group Managed Service Account,
and configure the servers
to use the group Managed Service Account
to access the file server.
Let's jump into the demo.
All right, so here we are logged on to CORP-BNE-DC01,
our domain controller in the corp.barrierreefaudio.com
Active Directory domain,
and we're going to use PowerShell
and Active Directory Users and Computers
to configure a group Managed Service Account.
To start, we've got to Add-KdsRootKey.
And for that, we need to use PowerShell.
So we'll go ahead and launch PowerShell,
and then we're going to go ahead and add the KDS root key
using the Add-KdsRootKey cmdlet,
and we're going to specify an effective time
10 hours in the past
so we don't have to wait the normal 10 hours
that you need to wait when you add a KdsRootKey.
And we'll do that with the EffectiveTime parameter.
And we're using the Get-Date cmdlet
to get the current date
and we're using the AddHours method
to get the date time 10 hours ago.
And we can go ahead and run that command
to add the KdsRootKey.
All right, with the KDS root key created,
let's create a global group for the web servers
that will be used to grant access
to retrieve the group Managed Service Account password.
To do that, we're going to use Active Directory
Users and Computers.
We'll launch Administrative Tools,
and then we'll launch Active Directory Users and Computers,
and then we'll navigate to the users container,
and we'll create a new group called Brisbane web services.
So we'll right click Users, New, Group.
We'll create a new global security group
and we'll call it BrisbaneWebServers.
We'll go ahead and click OK.
And then we're going to add our 2 web servers
as members of that group.
So we'll navigate into users.
We'll open up our new security group.
We'll select the Members tab, we'll select Add,
and we need to add the computers object type.
So we'll select Object Types,
we'll select Computers, and then OK,
and then we'll type the names of our 2 computers.
And then we'll hit Check Names to confirm the names.
And then we can go ahead and click OK.
All right, we now have a security group created
with our 2 web servers in it.
We're going to use that group to grant access
to retrieve the group Managed Service Account password.
Let's use PowerShell now
to create the group Managed Service Account.
And to do that, we're going to use
the New-ADServiceAccount cmdlet.
We'll specify the name of the service, bnewebsvc,
and we'll specify the DNSHostName for this service,
bnewebsvc.corp.barrierreefaudio.com.
And then we'll specify the Active Directory objects
that are allow allowed to retrieve the managed password
for this group Managed Service Account.
And we'll do that with the principles
allowed to retrieve managed password parameter,
oh, that's a decent parameter name.
And because that parameter is so long,
we're going to use tab to complete that parameter.
And then we'll specify the name of our group,
BrisbaneWebServers.
All right, we'll go ahead and run that command
to create our group Managed Service Account.
All right, with our new service account created,
we now need to restart our web servers,
so that they can update their group memberships.
So we'll come back once we've restarted those web servers.
All right, now that our web servers
have both completed their restart,
we're going to move across to our corporate file server,
CORP-BNE-FS01,
and we're going to configure the network share
that the web servers are going to access.
And I just wanted to show you that on CORP-BNE-FS01,
we have a shared folder called Web,
and I'm going to update these permissions
so that only our administrators
and our new group Managed Service Account
have access to this folder.
And we're going to cover file sharing
and permissions later on in this course.
So I'll go ahead and reconfigure these permissions,
and we'll come back when that's done.
All right, with the file share
that our web servers are going to access now configured,
we're going to jump across to CORP-BNE-WEB01,
and we'll configure the web server
to use the group Managed Service Account.
All right, so here we are on CORP-BNE-WEB01
we're going to go ahead and reconfigure
the default website on this server
to use the share that we've just set up on our file server.
So we'll open up Administrative Tools
and we'll open the IIS Manager,
and we'll navigate into the default site.
We'll edit the basic settings,
and we'll change the physical path
to the share on our file server.
And then we'll go ahead and select OK.
Now, let's install and configure
the group Managed Service Account.
To do that, we'll use PowerShell.
So we'll go ahead and launch PowerShell,
and we're going to use the Install-ADServiceAccount
PowerShell cmdlet,
and then specify the name of our service account.
We'll go ahead and run that.
All right, now that our server
has cached that group Managed Service Account,
let's go ahead and test the service account
using the Test-ADServiceAccount PowerShell commandlet.
All right, and it's returned true,
which means that this server is now successfully configured
to use that group Managed Service Account.
Now, we're going to reconfigure the application pool
for the default website on this server
to use the group Managed Service Account.
We'll minimize PowerShell,
and we'll navigate to Application Pools.
We'll select the DefaultApplicationPool,
which is used by the default website.
And we'll select Advanced Settings,
and we're going to change the identity
to use our group Managed Service Account.
So we'll select the Identity;
we'll select Custom account; we'll select Set,
and we'll type in the name
for our group Managed Service Account.
So we can go ahead and select OK.
We'll click OK again, and then OK one more time.
And now we need to navigate back to our default website
and configure Anonymous Authentication.
We'll go ahead and select Authentication,
and then we're going to select the Anonymous Authentication,
and then we'll go Edit.
And we're going to set the Anonymous Authentication
to use the Application Pool identity.
And then we'll go ahead and click OK.
Now, let's navigate back to the default website
and see if we're able to access that website.
We'll go Browse and we'll minimize the IIS Manager
and we can see that we're successfully retrieving
the data from that file server
using the group Managed Service Account.
All right, that concludes this demo,
let's go and wrap up with a bit of a summary
of what we've covered in this lesson.
All right, so what have we covered?
Virtual Accounts can be configured per server
and provide access to the network
using the computers account.
Managed Service Accounts are configured in Active Directory
for each application on a server.
And group Managed Service Accounts
can be configured in Active Directory,
and each application service
can have their own group Managed Service Account.
And the group Managed Service Account
can be shared between servers.
In order to generate passwords
for group Managed Service Accounts, domain controllers
require a Key Distribution Service root key.
And you can create the Key Distribution Service root key
using the Add-KdsRootKey PowerShell cmdlet.
All right, thanks for being with me in this lesson,
and I hope you've gained a great understanding
of how you can secure your own service accounts,
and I look forward would to seeing you in the next lesson.