MCITP 70-640: Managed Service Accounts
Uploaded by itfreetraining on 21.08.2012
Transcript:
Welcome back to IT Free Training course for Active Directory. In this video I will look
at a new feature in Windows 7 and Windows Server 2008 R2 to automate the management
of service accounts. This video will show you how managed service accounts can be used
in your organization to simplify user account management, remove the need to manage passwords
for service accounts, and give you a higher level of security.
To refresh your memory about service accounts, a service account is simply a user account
that gets created to run a particular piece of software or service. In order to have good
security you will want to limit a service account to one application or service. The
problem with this approach is the management of these service accounts and, in particular,
the management of their passwords becomes difficult.
In one of our previous videos about computer accounts, we learnt that a computer account
is created for each computer in the domain. These computer accounts have a password associated
with them that is automatically updated without any intervention from the user. Managed service
accounts use this system for password updating. This means that if you use a managed service
account, you never need to worry about setting or changing the password.
The password used is a random string of 120 characters. This makes managed service accounts
very secure as the password is not easily guessable. By default, the password is changed
automatically every 30 days without any intervention from the administrator just like the password
on computer accounts. Managed service accounts are bound only to
the one computer. This ensures the service account will not be used other than on the
computer it was created on. Managed Service Accounts can be placed into groups so this
is a work around to give them access to other resources on the network if you need to.
Before you start using managed service accounts you need to meet a few requirements. First
the domain function level needs to be Windows Server 2008 R2. Managed service accounts also
requires schema changes. For this reason you need to run ADPrep /ForestPrep using the Windows
Server 2008 R2 DVD in your forest. This will expand the schema to meet the requirements
for managed service accounts. Even though you need to expand the schema, you do not
need to raise the forest function level in order to use managed service accounts.
The next requirement is that the client that is using the managed service accounts is running
Windows Server 2008 R2 or Windows 7. Lastly you need some software components installed
in order to create the managed service accounts and configure them to be used with that computer.
These components are .Net framework 3.5 and the Active Directory module for Windows PowerShell.
Both of these can be installed by adding the component using server manager.
Once you have met all these prerequisites you can start using managed service accounts
in your organization. The next step is to determine which software will work with managed
service accounts. Managed service accounts don’t work with
all software. By design they do not allow interactive use which means no support for
GUI based operations or logging in the computer via the login prompt. You will need to check
that the software that you are trying to run supports managed service accounts.
Here is a list of common Microsoft products and their level of support for Managed Service
Accounts. Exchange supports managed services accounts except for sending e-mails. This
means that you can use a managed service account to run Exchange but will need to configure
another service account to handle sending e-mails from Exchange.
Next, managed service accounts can be used in IIS to configure application pools. In
the demonstration I will look at how to configure a managed service account to work with IIS.
Microsoft listed SQL as not being compatible with managed service accounts. A lot of people
have use managed service accounts with SQL and had some success. The risk you run with
using a managed service account with SQL is that if you have problems, Microsoft will
not give you any support for that configuration. Next a managed service account cannot be used
with the task scheduler. Lastly a managed service account can be used
with Active Directory Lightweight Directory Services, not to be confused with Active Directory
Domain Services which is the software used to run a Domain Controller. Active Directory
Lightweight Directory Services is used with 3rd party applications that require some of
the features of Active Directory but do not need a full Active Directory environment.
In order to get Active Directory Lightweight Services to operate with a managed service
account, some additional configuration needs to be done, but Microsoft does support this
configuration. I will now change to my Windows Server 2008
R2 member server to look at how to configure a managed service account to operate with
IIS. First of all I want to make sure that the
prerequisites for managed service accounts are met. To do this, open server manager and
select features. From features select add features to see which features have already
been installed. The prerequisite for the .Net Framework 3.5
or above framework is shown at the top as being installed. Scrolling down, I can see
that some components of Remote Administration Tools have been installed. These were installed
to allow Active Directory administration to be performed on this server. The important
thing to look for is that Active Directory module for Windows PowerShell is installed.
This allows power shell to interface with Active Directory to create the service account
and configure it to be used on this server. Now that I know that the prerequisites have
been meet, I will exit out of here and from the start menu open PowerShell.
The first command that I will run is import-module ActiveDirectory. This command loads the ActiveDirectory
module which allows Active Directory administration to be performed from PowerShell. If you do
not run this command, all the other commands will fail.
The next command New-ADServiceAccount will create a managed service account. The name
of the service account needs to be given with the name parameter. In this case I will create
a service account called ManagedIISService. This service account will be used later on
with IIS. Following this is the enable parameter followed by $True. This ensures the managed
service account is enabled when it is created. This server is not a domain controller, but
since it has Active Directory tools installed it is able to create the service account in
Active Directory. If I now open Active Directory Users and Computers from the start menu, I
can see the newly created service account by expanding down to managed service accounts.
Any managed service account will appear in here. It should be remembered that even though
it appears in Active Directory here, it still is tied to the one computer.
If I minimize Active Directory Users and Computers and go back to PowerShell. I next need to
associate the service account with the computer that it will be used with. This is done using
the command Add-ADComptuerServiceAccount. The first parameter, identify is used to specify
the computer that the service account will be linked to in this case this will be Svr1.
The next parameter, ServiceAccount, specifies the service account that we want to link,
in this example it is ManagedIISService. So basically this command is linking the service
account ManagedIISService with the computer Svr1.
The previous commands could have been run on any computer that is able to perform Active
Directory administration. The next command needs to be run on the Windows Server 2008
R2 install or Windows 7 install that you want to use the managed service account on. PowerShell
can also connect to a computer remotely to run the command as long as the commands target
is the local computer. The command is Install-ADServiceAccount. The
only parameter that you need is identity followed by the service account name. This command
makes the necessary changes on the local computer in order to allow the managed service account
to operate. Now that all the hard work is done creating
the managed service account, I will now open internet information Services from the start
menu to change the service that is used in IIS to the service account that I just created.
From IIS manager, expand down to application pools. Form here right click on the default
app pool and select advanced settings. From the advanced settings, select the option identity.
Currently this is configured to run with the default settings. This means a local service
account on the server will be used. When running multiple application pools on
the same IIS install, you may want to create each pool to run with its own service account.
There is nothing stopping you from using the same procedure that I went through to create
multiple service accounts and associating these service accounts with the same computer.
Once I select custom account I can press the set button to specify the managed service
account. For the user name, enter in the managed service account but make sure the user name
ends with a dollar sign. Managed service accounts differ from regular user account in that a
dollar sign must always be added to the end. If you do not enter in the dollar sign, Windows
will not be able to find the managed service account. Having the dollar sign at the end
can mean some Windows interfaces will not be able to detect the managed service account.
A work around is to place the managed service account in a group. The Windows interface
should not have trouble finding the group and using it even though it cannot find the
managed service account. Since Active Directory will automatically
change the password for the managed service account, leave the password blank in the password
and confirm passwords fields. That’s it; I can now exit out of here and go back to
the application pool which will now be using the managed service account.
To show that it worked, I will stop the service and start it again. The managed service account
is now set up and the administrator will never have to worry about changing the password
on the account. Also since the service account is bound to this computer, even though it
is located in Active Directory, it cannot be used on any other computer in the domain.
In the next video I will look at the exam objective offline domain join. This is another
new feature available in Windows 7 and Windows Server 2008 R2. This allows a computer to
join the domain when it does not have access to a domain controller. Thanks for watching
another free video from IT Free Training.
at a new feature in Windows 7 and Windows Server 2008 R2 to automate the management
of service accounts. This video will show you how managed service accounts can be used
in your organization to simplify user account management, remove the need to manage passwords
for service accounts, and give you a higher level of security.
To refresh your memory about service accounts, a service account is simply a user account
that gets created to run a particular piece of software or service. In order to have good
security you will want to limit a service account to one application or service. The
problem with this approach is the management of these service accounts and, in particular,
the management of their passwords becomes difficult.
In one of our previous videos about computer accounts, we learnt that a computer account
is created for each computer in the domain. These computer accounts have a password associated
with them that is automatically updated without any intervention from the user. Managed service
accounts use this system for password updating. This means that if you use a managed service
account, you never need to worry about setting or changing the password.
The password used is a random string of 120 characters. This makes managed service accounts
very secure as the password is not easily guessable. By default, the password is changed
automatically every 30 days without any intervention from the administrator just like the password
on computer accounts. Managed service accounts are bound only to
the one computer. This ensures the service account will not be used other than on the
computer it was created on. Managed Service Accounts can be placed into groups so this
is a work around to give them access to other resources on the network if you need to.
Before you start using managed service accounts you need to meet a few requirements. First
the domain function level needs to be Windows Server 2008 R2. Managed service accounts also
requires schema changes. For this reason you need to run ADPrep /ForestPrep using the Windows
Server 2008 R2 DVD in your forest. This will expand the schema to meet the requirements
for managed service accounts. Even though you need to expand the schema, you do not
need to raise the forest function level in order to use managed service accounts.
The next requirement is that the client that is using the managed service accounts is running
Windows Server 2008 R2 or Windows 7. Lastly you need some software components installed
in order to create the managed service accounts and configure them to be used with that computer.
These components are .Net framework 3.5 and the Active Directory module for Windows PowerShell.
Both of these can be installed by adding the component using server manager.
Once you have met all these prerequisites you can start using managed service accounts
in your organization. The next step is to determine which software will work with managed
service accounts. Managed service accounts don’t work with
all software. By design they do not allow interactive use which means no support for
GUI based operations or logging in the computer via the login prompt. You will need to check
that the software that you are trying to run supports managed service accounts.
Here is a list of common Microsoft products and their level of support for Managed Service
Accounts. Exchange supports managed services accounts except for sending e-mails. This
means that you can use a managed service account to run Exchange but will need to configure
another service account to handle sending e-mails from Exchange.
Next, managed service accounts can be used in IIS to configure application pools. In
the demonstration I will look at how to configure a managed service account to work with IIS.
Microsoft listed SQL as not being compatible with managed service accounts. A lot of people
have use managed service accounts with SQL and had some success. The risk you run with
using a managed service account with SQL is that if you have problems, Microsoft will
not give you any support for that configuration. Next a managed service account cannot be used
with the task scheduler. Lastly a managed service account can be used
with Active Directory Lightweight Directory Services, not to be confused with Active Directory
Domain Services which is the software used to run a Domain Controller. Active Directory
Lightweight Directory Services is used with 3rd party applications that require some of
the features of Active Directory but do not need a full Active Directory environment.
In order to get Active Directory Lightweight Services to operate with a managed service
account, some additional configuration needs to be done, but Microsoft does support this
configuration. I will now change to my Windows Server 2008
R2 member server to look at how to configure a managed service account to operate with
IIS. First of all I want to make sure that the
prerequisites for managed service accounts are met. To do this, open server manager and
select features. From features select add features to see which features have already
been installed. The prerequisite for the .Net Framework 3.5
or above framework is shown at the top as being installed. Scrolling down, I can see
that some components of Remote Administration Tools have been installed. These were installed
to allow Active Directory administration to be performed on this server. The important
thing to look for is that Active Directory module for Windows PowerShell is installed.
This allows power shell to interface with Active Directory to create the service account
and configure it to be used on this server. Now that I know that the prerequisites have
been meet, I will exit out of here and from the start menu open PowerShell.
The first command that I will run is import-module ActiveDirectory. This command loads the ActiveDirectory
module which allows Active Directory administration to be performed from PowerShell. If you do
not run this command, all the other commands will fail.
The next command New-ADServiceAccount will create a managed service account. The name
of the service account needs to be given with the name parameter. In this case I will create
a service account called ManagedIISService. This service account will be used later on
with IIS. Following this is the enable parameter followed by $True. This ensures the managed
service account is enabled when it is created. This server is not a domain controller, but
since it has Active Directory tools installed it is able to create the service account in
Active Directory. If I now open Active Directory Users and Computers from the start menu, I
can see the newly created service account by expanding down to managed service accounts.
Any managed service account will appear in here. It should be remembered that even though
it appears in Active Directory here, it still is tied to the one computer.
If I minimize Active Directory Users and Computers and go back to PowerShell. I next need to
associate the service account with the computer that it will be used with. This is done using
the command Add-ADComptuerServiceAccount. The first parameter, identify is used to specify
the computer that the service account will be linked to in this case this will be Svr1.
The next parameter, ServiceAccount, specifies the service account that we want to link,
in this example it is ManagedIISService. So basically this command is linking the service
account ManagedIISService with the computer Svr1.
The previous commands could have been run on any computer that is able to perform Active
Directory administration. The next command needs to be run on the Windows Server 2008
R2 install or Windows 7 install that you want to use the managed service account on. PowerShell
can also connect to a computer remotely to run the command as long as the commands target
is the local computer. The command is Install-ADServiceAccount. The
only parameter that you need is identity followed by the service account name. This command
makes the necessary changes on the local computer in order to allow the managed service account
to operate. Now that all the hard work is done creating
the managed service account, I will now open internet information Services from the start
menu to change the service that is used in IIS to the service account that I just created.
From IIS manager, expand down to application pools. Form here right click on the default
app pool and select advanced settings. From the advanced settings, select the option identity.
Currently this is configured to run with the default settings. This means a local service
account on the server will be used. When running multiple application pools on
the same IIS install, you may want to create each pool to run with its own service account.
There is nothing stopping you from using the same procedure that I went through to create
multiple service accounts and associating these service accounts with the same computer.
Once I select custom account I can press the set button to specify the managed service
account. For the user name, enter in the managed service account but make sure the user name
ends with a dollar sign. Managed service accounts differ from regular user account in that a
dollar sign must always be added to the end. If you do not enter in the dollar sign, Windows
will not be able to find the managed service account. Having the dollar sign at the end
can mean some Windows interfaces will not be able to detect the managed service account.
A work around is to place the managed service account in a group. The Windows interface
should not have trouble finding the group and using it even though it cannot find the
managed service account. Since Active Directory will automatically
change the password for the managed service account, leave the password blank in the password
and confirm passwords fields. That’s it; I can now exit out of here and go back to
the application pool which will now be using the managed service account.
To show that it worked, I will stop the service and start it again. The managed service account
is now set up and the administrator will never have to worry about changing the password
on the account. Also since the service account is bound to this computer, even though it
is located in Active Directory, it cannot be used on any other computer in the domain.
In the next video I will look at the exam objective offline domain join. This is another
new feature available in Windows 7 and Windows Server 2008 R2. This allows a computer to
join the domain when it does not have access to a domain controller. Thanks for watching
another free video from IT Free Training.