20411B-ENU-TrainerHandbook

		Administering Windows Server® 2012		MCT
			4-11
To use a fine-grained password policy, your domain functional level must be at least Windows Server
2008, which means that all of your domain controllers in the domain are running at least Windows
Server 2008, and the domain functional level has been raised to at least Windows Server 2008.
To confirm and modify the domain functional level:				USE
1. Open Active Directory Domains and Trusts.
2. In the console tree, expand Active Directory Domains and Trusts, and then expand the tree until
	you can see the domain.
3. Right-click the domain, and then click Raise domain functional level.				.ONLY
Configuring Password Settings Objects
You can create and apply Password Settings
Objects in the Windows Server 2012 environment
by using either of the following tools:				STUDENT
•	Active Directory Administrative Center
•	Windows PowerShell
Configuring Password Settings Objects
By Using Windows PowerShell
In Windows Server 2012, new Windows
PowerShell cmdlets in the Active Directory
module for Windows PowerShell can be used to
create and manage Password Settings Objects in
your domain.

•New-ADFineGrainedPasswordPolicy

This cmdlet is used to create a new Password Settings Object, and define the Password Settings Object parameters. For example, the following command creates a new Password Settings Object named TestPwd, and then specifies its settings:

New-ADFineGrainedPasswordPolicy TestPswd -ComplexityEnabled:$true -	USE
LockoutDuration:"00:30:00" -LockoutObservationWindow:"00:30:00" -LockoutThreshold:"0"
-MaxPasswordAge:"42.00:00:00" -MinPasswordAge:"1.00:00:00" -MinPasswordLength:"7" -

•Add-FineGrainedPasswordPolicySubject PROHIBITED

This cmdlet enable you to link a user or group to an existing Password Settings Object. For example,

the following command links the TestPwd Password Settings Object to the AD DS group named group1:PasswordHistoryCount:"24" -Precedence:"1" -ReversibleEncryptionEnabled:$false -

4-12 Managing User and Service Accounts

Configuring Password Settings Objects By Using Active Directory Administrative Center

The Active Directory Administrative Center provides a GUI for creating and managing Password Settings Objects. To manage Password Settings Objects in Active Directory Administrative Center, follow these steps:

1.Open Active Directory Administrative Center.

2.Click Manage, click Add Navigation Nodes, select the appropriate target domain in the Add Navigation Node dialog box, and then click OK.

3.In the Active Directory Administrative Center navigation pane, open the System container, and then click Password Settings Container.

4.In the Tasks pane, click New, and then click Password Settings.

5.Fill in or edit fields inside the property page to create a new Password Settings object.

6.Under Directly Applies To, click Add, type Marketing, and then click OK.

7.This associates the Password Policy object with the members of the global group that you created for the test environment.

8.Click OK to submit the creation of the Password Settings Object.

Note: The Active Directory Administrative Center interface for Password Settings Object management uses the Windows PowerShell cmdlets mentioned previously to carry out the creation and management of Password Settings Objects.

Considerations for Configuring Password Settings Objects

It is possible for you to link more than one Password Settings Object to a user or a security group.

You might do this if a user is a member of multiple security groups, which might each have an assigned Password Settings Object already, or if you assign multiple Password Settings Objects directly to a user object. In either case, it is important to understand that you can apply only one Password Settings Object as the effective password policy.

If you assign multiple Password Settings Objects to a user or a group, the msDS-PasswordSettingsPrecedence attribute helps to determine the resultant Password Settings Object. A Password Settings Object with a lower value takes precedence over a Password Settings Object with a higher value.

The following process describes how AD DS determines the resultant Password Settings Object if you link multiple Password Settings Objects to a user or a group:

1.Any Password Settings Object that you link directly to a user object is the resultant Password Settings Object. If you link multiple Password Settings Objects directly to the user object, the Password Settings Object with the lowest msDS-PasswordSettingsPrecedence value is the resultant Password Settings Object. If two Password Settings Objects have the same precedence, the Password Settings Object with the mathematically smallest objectGUID is the resultant PSO.

2.If you do not link any Password Settings Objects directly to the user object, AD DS compares the Password Settings Objects for all global security groups that contain the user object. The Password Settings Object with the lowest msDS-PasswordSettings

Precedence value is the resultant Password Settings Object. If you apply multiple Password Settings Objects to the same user, and they have the same msDS-PasswordSettingsPrecedence value,

AD DS applies the Password Settings Object with the mathematically smallest globally unique identifier (GUID).

PROHIBITED USE STUDENT .ONLY USE MCT

To view the effect of a policy that AD DS is applying to a user, open Active Directory Users and Computers, and then, on the View menu, ensure that Advanced Features is enabled. Then open the properties of a user account. You can view the msDS-ResultantPSO attribute on the Attribute Editor tab, if the Show Constructed Attributes option has been configured under the Filter options.

Administering Windows Server® 2012	MCT
	4-13

3.If you do not link any Password Settings Objects to the user object, either directly or indirectly (through group membership), AD DS applies the Default Domain Policy.

All user objects contain a new attribute called msDS-ResultantPSO. You can use this attribute to help determine the distinguished name of the Password Settings Object that AD DS applies to the user object.USE If you do not link a Password Settings Object to the user object, this attribute does not contain any value

and the Default Domain Policy GPO contains the effective password policy. ONLY.STUDENT

PROHIBITED USE

	4-14 Managing User and Service Accounts			MCT
	Lesson 3
	Configuring Managed Service Accounts			USE
	Creating user accounts to provide authentication for applications, system services, and background
	processes is a common practice in the Windows environment. Historically, accounts were created, and
	often named, for use by a specific service. Windows Server 2012 supports AD DS account-like objects
	called managed service accounts that make service accounts easier to manage and less of a security risk
	to your environment.			.ONLY
	This lesson will introduce you to managed service accounts, and new functionality related to managed
	service accounts in Windows Server 2012.
	Lesson Objectives
	After completing this lesson, you will be able to:
	• Identify the challenges of using standard user accounts for services.
	• Describe managed service accounts.			STUDENT
	•	Explain how to configure managed service accounts.
	• Describe group-managed service accounts.
	What Are The Challenges Of Using Standard User Accounts For Services?
	Many applications such as Microsoft SQL Server®
	or Internet Information Services (IIS) contain
	services that are installed on the server that hosts
	the application. These services typically run at
	server startup or are triggered by other events.
	Services often run in the background and do not				USE
	require any user interaction.
	For a service to start up and authenticate, a
	service account is used. A service account may be
	an account that is local to the computer, such as
	the built-in Local Service, Network Service, or
	Local System accounts. You also can configure a

•Extra administration effort may be necessary to manage the service account password securely. This PROHIBITED includes tasks such as changing the password and resolving situations that cause an account lockout.

Service accounts also typically are configured to have passwords that do not expire, which may go against your organization’s security policies.

•It can be difficult to determine where a domain-based account is being used as a service account. A standard user account may be used for multiple services on various servers throughout the

environment. A simple task, such as changing the password, may cause authentication issues for some applications. It is important to know where and how a standard user account is being used when it is associated with an application service.

•Extra administration effort may be necessary to manage the service principal name (SPN). Using a MCT standard user account may require manual administration of the SPN. If the logon account of the

service changes, the computer name is changed. Or, if a Domain Name System (DNS) host name

property is modified, the SPN registrations may need to be manually modified to reflect the change. A misconfigured SPN causes authentication problems with the application service. USEmanaged service accounts in Windows Server 2012.

What Is A Managed Service Account?

A Managed Service Account is an AD DS object class that enables simplified password and SPN management for service accounts.

Many network-based applications use an account to run services or provide authentication. For example, an application on a local computer might use the Local Service, Network Service, or Local System accounts. These service accounts may work fine. However, these typically are shared among multiple applications and services, making it difficult to manage for a specific application. Furthermore, you cannot manage these local service accounts at the domain level.

Alternatively, it is quite common that an application might use a standard domain account that is configured specifically for the application. However, the main drawback is that you need to manage passwords manually, which increases administration effort.

STUDENT .ONLY

A managed service account can provide an application with its own unique account, while eliminating the
need for an administrator to administer the account’s credentials manually.	USE

How a Managed Service Account Works

Managed Service Accounts are stored in AD DS as msDS-ManagedServiceAccount objects. This class inherits structural aspects from the Computer class (which inherits from the User class). This enables an Managed Service Account to fulfill User-like functions such as providing authentication and security context for a running service. It also enables an Managed Service Account to use the same password update mechanism used by Computer objects in AD DS, a process that requires no user intervention.

Managed service accounts provide the following benefits to simplify administration:

•	Automatic password management. A managed service account automatically maintains its own	PROHIBITED

password, including password changes.

• Simplified SPN management. SPN management can be managed automatically if your domain is configured at the Windows Server 2008 R2 domain functional level or higher.

Managed Service Accounts are stored in the CN=Managed Service Accounts, DC=<domain>, DC=<com> container. You can see this by enabling the Advanced Features option in the View menu within Active Directory Users and Computers. This container is visible by default in the Active Directory Administrative Center.

4-16 Managing User and Service Accounts

Requirements for Using Managed Service Accounts

To use a managed service account, the server that runs the service or application must be running Windows Server 2008 R2 or Windows Server 2012. You also must ensure that .NET Framework 3.5.x and the Active Directory module for Windows PowerShell are both installed on the server.

Note: A standard managed service account cannot be shared between multiple computers or be used in server clusters where the service is replicated between nodes.

To simplify and provide full automatic password and SPN management, we strongly recommend that the AD DS domain be at the Windows Server 2008 R2 functional level or higher. However, if you have a domain controller running Windows Server 2008 or Windows Server 2003, you can update the Active Directory schema to Windows Server 2008 R2 to support this feature. The only disadvantage is that the domain administrator must configure SPN data manually for the managed service accounts.

To update the schema in Windows Server 2008, Windows Server 2003, or mixed-mode environments, you must perform the following tasks:

1.Run adprep/forestprep at the forest level and run adprep/domainprep at the domain level.

2.Deploy a domain controller running Windows Server 2008 R2, Windows Server 2008 with the Active Directory Management Gateway Service, or Windows Server 2003 with the Active Directory Management Gateway Service.

Note: The Active Directory Management Gateway Service allows administrators with domain controllers running Windows Server 2003 or Windows Server 2008 to use Windows PowerShell cmdlets to manage managed service accounts.

Considerations for Managed Service Accounts on Windows Server 2012 Domain Controllers

On Windows 2012, Managed Service Accounts are created as the new group Managed Service Account object type by default. However, to accommodate this, you must fulfill the one of the requirements for group Managed Service Accounts before you can create any Managed Service Account on a Windows 2012 domain controller.

On a Windows 2012 domain controller, a key distribution services root key must be created for the domain before any Managed Service Accounts can be created. To create the root key, run the following cmdlet from the Active Directory PowerShell module for Windows PowerShell:

Add-KDSRootKey –EffectiveTime ((Get-Date).AddHours(-10))

More information on group Managed Service Accounts, including further explanation of the cmdlet above, and creating a Key Distribution Services (KDS) root key can be found later in this lesson.

PROHIBITED USE STUDENT .ONLY USE MCT

Add-ADComputerServiceAccount –identity <Host Computer Name> -ServiceAccount <MSA Name>

	Administering Windows Server® 2012	MCT
		4-17
Demonstration: Configuring Managed Service Accounts by Using
Windows PowerShell
Creating and configuring a Managed Service Account requires the use of four cmdlets from the Active
Directory Module for Windows PowerShell:		USE
• Add-KDSRootkey creates the KDS root key to support group Managed Service Accounts, a
	requirement on Windows Server 2012 DCs:
	Add-KDSRootKey –EffectiveTime ((Get-Date).AddHours(-10))
• New-ADServiceAccount creates the Managed Service Account within AD DS:
	New-ADServiceAccount –Name <MSA Name> -DNSHostname <DC DNS Name>
• Add-ADComputerServiceAccount associates the Managed Service Account with a computer account
	in the AD DS domain:	ONLY.

•Install-ADServiceAccount installs the Managed Service Account on a host computer in the domain, and makes the Managed Service Account available for use by services on the host computer:

Install-ADServiceAccount –Identity <MSA Name>

In this demonstration, you will see how to:

• Create the KDS root key for the domain.

Create and associate a managed service account.

Demonstration Steps

Create the Key Distribution Services (KDS) root key for the domain

STUDENT

1.On LON-DC1, from Server Manager, open the Active Directory Module for Windows PowerShellUSE console.

2.Use the Add-KDSRootKey cmdlet to create the domain KDS root key.Create and associate a managed service account

1.	On LON-DC1, open the Active Directory Module for Windows PowerShell console.
2.	Use the New-ADServiceAccount cmdlet to create a Managed Service Account.
3.	Use the Add-ADComputerServiceAccount cmdlet to associate the Managed Service Account with
	LON-SVR1.	PROHIBITED
4.	Use the Get-ADServiceAccount cmdlet to view the newly created Managed Service Account and
	confirm proper configuration.
Install
1.	On LON-SVR1, open the Active Directory Module for Windows PowerShell console.
2.	Use the Install-ADServiceAccount cmdlet to install the Managed Service Account on LON-SVR1.
3.	Open Server Manager, and start the Services console.
4.	Open the Properties pages for the Application Identity service, and then select the Log On tab.
5.	Configure the Application Identity service to use Adatum\SampleApp_SVR1$.

Group Managed Service Accounts enable Managed Service Account functionality across multiple servers by delegating the management of Managed Service Account password information to Windows Server 2012 domain controllers. By doing this, the management of passwords is no longer dependent on the relationship between a single server and AD DS, but rather controlled entirely by AD DS.

Understanding Group Managed Service Account Functionality

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

The group Managed Service Account object contains a list of principals (computers or AD DS groups) thatUSEPROHIBITED are allowed to retrieve group Managed Service Account password information from AD DS, and then use

the group Managed Service Account for authentication for services.

Group Managed Service Accounts are created by using the same cmdlets from the Active Directory Module for Windows PowerShell. In fact, the cmdlets used for Managed Service Account management will create group Managed Service Accounts, by default.

Note: The –EffectiveImmediately switch uses the current time to establish the timestamp that marks the key as valid. However, when using –EffectiveImmediately, the actual effective time is set to 10 hours later than the current time. This 10-hour difference is to allow for AD DS replication to replicate the changes to other domain controllers in the domain. For testing purposes, it is possible to bypass this functionality by setting the –EffectiveTime parameter to 10 hours before the current time:

Add-KdsRootKey –EffectiveImmediately

4-18 Managing User and Service Accounts

What Are Group Managed Service Accounts?

Group Managed Service Accounts enable you to extend the capabilities of Standard Managed

Service Accounts to more than one server in your domain. In server farm scenarios such as network load balancing (NLB) clusters or IIS servers, there often is a need to run system or application services under the same service account. Standard Managed Service Accounts cannot provide managed service account functionality to services that are running on more than one server. By using Group Managed Service Accounts, you

can configure multiple servers to use the same

Managed Service Account, and still retain the benefits that Managed Service Accounts provide, like automatic password maintenance and simplified SPN management.

Group Managed Service Account Requirements

In order to support group Managed Service Account functionality, your environment must meet the following requirements:

•At least one domain controller must be running Windows Server 2012 to store managed password information.

•A KDS root key must be created on a domain controller in the domain.

To create the KDS root key, run the following command from the Active Directory Module for Windows PowerShell on a Windows Server 2012 domain controller:

STUDENT .ONLY USE MCT

Administering Windows Server® 2012	MCT
	4-19

On a Windows Server 2012 domain controller, create a new Managed Service Account by using the

New-ADServiceAccount cmdlet with the –PrinicipalsAllowedToRetrieveManagedPassword parameter. This parameter accepts one or more comma-separated computer accounts or AD DS groups that are permitted to obtain password information for the group Managed Service Account that is stored in AD DS on Windows Server 2012 domain controllers.

For example, the following cmdlet will create a new group Managed Service Account called SQLFarm, and

enable the LON-SQL1, LON-SQL2, and LON-SQL3 hosts to use the group Managed Service Account:	USE
New_ADServiceAccount –Name LondonSQLFarm –PrincipalsAllowedToRetrieveManagedPassword LON-
SQL1, LON-SQL2, LON-SQL3

Once a computer has been added to using the –PrincipalsAllowedToRetrieveManagedPassword, theONLY group Managed Service Account service account is available to be assigned to services by using same assignment process as standard Managed Service Accounts.

Using AD DS Groups to Manage Group Managed Service Account Server Farms

AD DS security groups can be used to identify group Managed Service Accounts. When you use an AD DS.

group for the PrincipalsAllowedToRetriveManagedPassword parameter, any computers that are

members of that group will be allowed to retrieve the password and utilize group Managed Service STUDENT Account functionality. When using an AD DS group as the principal allowed to retrieve a managed

password, any accounts that are members of the group will also have the same capability. USEPROHIBITED

4-20 Managing User and Service Accounts

Lab: Managing User and Service Accounts

Scenario

A. Datum is a global engineering and manufacturing company with its head office in London, UK. An IT office and data center is located in London to support the London office and other locations. A. Datum has recently deployed a Windows Server 2012 server and client infrastructure, and needs to implement changes to how user accounts are managed in the environment.

Objectives

After completing this lab, you will be able to:

•Configure password-policy and account-lockout settings.

•Create and associate a Managed Service Account.

Lab Setup

Estimated Time: Estimated time: 45 minutes

Virtual Machine	20411B-LON-DC1
User Name	Administrator
Password	Pa$$w0rd

For this lab, you will use the available virtual machine environment. Before you begin the lab, you must complete the following steps:

1.On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2.In Hyper-V® Manager, click 20411B-LON-DC1, and in the Actions pane, click Start.

3.In the Actions pane, click Connect. Wait until the virtual machine starts.

4.Log on using the following credentials:

a.User name: Adatum\Administrator

b.Password: Pa$$w0rd

Exercise 1: Configuring Password-Policy and Account-Lockout Settings

Scenario

A. Datum has recently completed a security review for passwords and account-lockout policies. You need to implement the recommendations contained in the report to control password complexity and length. You also need to configure appropriate account-lockout settings. Part of your password policy configuration will include a specific password policy to be assigned to the Managers security group. This group requires a different password policy than what has been applied at the domain level.

The report has recommended that the following password settings should be applied to all accounts in the domain:

•Password history: 20 passwords

•Maximum password age: 45 days

•Minimum password age: 1 day

•Password length: 10 characters

PROHIBITED USE STUDENT .ONLY USE MCT