20411B-ENU-TrainerHandbook

			4-1
	Module 4		MCT
			USE
	Managing User and Service Accounts
	Contents:
			.ONLY
	Module Overview	4-1
	Lesson 1: Automating User Account Management	4-2
	Lesson 2: Configuring Password-Policy and User-Account Lockout Settings	4-7
	Lesson 3: Configuring Managed Service Accounts	4-14
	Lab: Managing User and Service Accounts	4-20
	Module Review and Takeaways	4-24
			STUDENT
	Module Overview
	Managing user accounts in an enterprise environment can be a challenging task. You must ensure
	that you configure the user accounts in your environment properly, and that you protect them from

unauthorized use and from users who abuse their account privileges. Using dedicated service accounts for system services and background processes, as well as setting appropriate account policies, will help to ensure that your Windows Server® 2012 environment gives users and applications the access they need to function properly.

This module will help you to understand how to manage large groups of user accounts, explain the different options available for providing adequate password security for accounts in your environment, and show you how to configure accounts to provide authentication for system services and background processes.

Objectives

	After completing this module, you will be able to:		USE
	• Automate user account creation.		PROHIBITED
	• Configure password-policy and account-lockout settings.
	•	Configure managed service accounts.

4-2 Managing User and Service Accounts

	Lesson 1		MCT
	Automating User Account Management
			USE
		Active Directory® Users and Computers and the Active Directory Administrative Center provide
		graphical user interfaces (GUIs) for creating one or more user accounts. While the interface that these
		tools provide is easy to navigate, creating multiple users or performing modifications for multiple users
		can be cumbersome. Windows Server 2012 contains a number of tools that enable you to manage user
		accounts more efficiently in your Active Directory Domain Services (AD DS) domain. This lesson introduces
		tools that allow you to perform tasks such as changing user attributes for many users, searching for users,	.ONLY
		and importing and exporting users to and from external data sources or directories.
		Lesson Objectives
		After completing this lesson, you will be able to:
		• Explain how to export users by using the Comma-Separated Values Data Exchange tool.
		• Explain how to import users by using the Comma-Separated Values Data Exchange tool.
		• Describe how to import user accounts by using the LDAP Data Interchange Format (LDIFDE) Internet	STUDENT
		standard.
		• Explain how to import user accounts by using Windows PowerShell®.
		Demonstration: Exporting Users Accounts with Comma-Separated Values
		Data Exchange Tool
		Comma-Separated Values Data Exchange tool is a command-line tool that exports or imports AD DS
		objects to or from a comma-delimited text file, which also is known as a comma-separated value text
		file or .csv file. You can create, modify, and open comma-delimited files by using familiar tools such as
		Notepad and Microsoft Office Excel®. Additionally, you can use these files to export information from
		AD DS, for use in other areas of your organization, or you can use them to import information from		USE
		other sources for use in creating or modifying your domain’s AD DS objects.
		The following is the basic syntax of the Comma-Separated Values Data Exchange tool command for
		export:
		csvde -f filename
		However, this command will export all objects in your Active Directory domain. You will want to limit the	PROHIBITED
		scope of the export, which you can do with the following four parameters:
		• -d RootDN. Specifies the distinguished name of the container from which the export will begin. The
		default is the domain itself.
		• -p SearchScope. Specifies the scope of the search relative to the container specified by -d.
		SearchScope can be either base (this object only), onelevel (objects within this container), or subtree
		(this container and all subcontainers). The default is subtree.
		• -r Filter. Filters the objects returned within the scope configured by -d and -p. Filter is specified in
		Lightweight Directory Access Protocol (LDAP) query syntax. You will work with a filter in the lab for
		this lesson. The LDAP query syntax is beyond the scope of this course. For more information, see
		http://go.microsoft.com/fwlink/?LinkId=168752.

Administering Windows Server® 2012	MCT
	4-3
• -l ListOfAttributes. Specifies the attributes that will be exported. Use the LDAP name for each
attribute, separated by a comma, as in

-l DN,objectClass,sAMAccountName,sn,givenName,userPrincipalName

The output of a Comma-Separated Values Data Exchange tool export lists the LDAP attribute names on the first line. Each object follows, one per line, and must contain exactly the attributes listed on the first line, as illustrated in the following examples:

DN,objectClass,sn,givenName,sAMAccountName,userPrincipalName

"CN=David Jones,OU=Employees,OU=User

Accounts,DC=contoso,DC=com",user,Jones,David,david.jones,[e-mail]

"CN=Lisa Andrews,OU=Employees,OU=User

Accounts,DC=contoso,DC=com",user,Andrews,Lisa,lisa.andrews,[e-mail]

In this demonstration, you will see how to:

•Export user accounts with Comma-Separated Values Data Exchange tool.

Demonstration Steps

.ONLY USE

1.On LON-DC1, open a command prompt.

2.In the command prompt window, type the following command, and then press Enter:

csvde -f E:\Labfiles\Mod04\UsersNamedRex.csv -r "(name=Rex*)" -l DN,objectClass,sAMAccountName,sn,givenName,userPrincipalName

5.	Close all open windows on LON-DC1.	STUDENT
3.	Open E:\LABFILES\Mod04\UsersNamedRex.csv in Notepad.
4.	Examine the file, and then close Notepad.

Demonstration: Importing User Accounts with the Comma-Separated Values Data Exchange Tool

You also can use Comma-Separated Values Data Exchange tool to create user accounts by importing a
.csv file. If you have user information in existing Excel or Microsoft Office Access® databases, you will find
that Comma-Separated Values Data Exchange tool is a powerful way to take advantage of that	USE
information to automate user account creation.
The following is the basic syntax of the Comma-Separated Values Data Exchange tool command for
import:
csvde -i -f filename -k

The i parameter specifies import mode. Without this parameter, the default mode of the CommaSeparated Values Data Exchange tool is export. The f parameter identifies the file name to import from or export to. The k parameter is useful during import operations because it instructs the Comma-

Separated Values Data Exchange tool to ignore errors, including Object Already Exists.	PROHIBITED

4-4 Managing User and Service Accounts

The import file itself is a comma-delimited text file (.csv or .txt) in which the first line defines the imported attributes by their LDAP attribute names. Each object follows, one per line, and must contain exactly the attributes listed on the first line, for example, a sample file will be as follows:

DN,objectClass,sn,givenName,sAMAccountName,userPrincipalName

"CN=David Jones,OU=Employees,OU=User

Accounts,DC=contoso,DC=com",user,Jones,David,david.jones,[e-mail]

"CN=Lisa Andrews,OU=Employees,OU=User

Accounts,DC=contoso,DC=com",user,Andrews,Lisa,lisa.andrews,[e-mail]

This file, when imported by the Comma-Separated Values Data Exchange tool command, will create a user object for Lisa Andrews in the Employees organizational unit (OU). The file configures the user logon names, last name and first name. You cannot use the Comma-Separated Values Data Exchange tool to import passwords. Without a password, the user account will be disabled initially. After you have reset the password, you can enable the object in AD DS.

In this demonstration, you will see how to:

•Import user accounts with the Comma-Separated Values Data Exchange tool.

Demonstration Steps

1.On LON-DC1, open E:\Labfiles\Mod04\NewUsers.csv with Notepad. Examine the information about the users listed in the file.

2.Open a command prompt, type the following command, and then press Enter:

csvde -i -f E:\Labfiles\Mod04\NewUsers.csv -k

3.From Server Manager, open Active Directory Users and Computers, and confirm that the users were created successfully.

4.Examine the accounts to confirm that first name, last name, user principal name, and pre-Windows® 2000 logon name are populated according to the instructions in NewUsers.csv.

5.Reset the passwords of the two accounts to Pa$$w0rd.

6.Enable the two accounts.

7.Close all open windows on LON-DC1.

Demonstration: Importing User Accounts with LDIFDE

You can also use LDIFDE.exe to import or export Active Directory objects, including users. LDPA Interchange Format (LDIF) is a standard file format that you can use to store information and perform batch operations against directories that conform to the LDAP standards. LDIF supports both import and export operations, and batch operations that modify objects in the directory. The LDIFDE command implements these batch operations by using LDIF files.

The LDIF file format consists of a block of lines, which together constitute a single operation. Multiple operations in a single file are separated by a blank line. Each line, comprising an operation, consists of an attribute name followed by a colon and the value of the attribute. For example, suppose you wanted to import user objects for two sales representatives named Bonnie Kearney and Bobby Moore. The contents of the LDIF file would look similar to the following example:

PROHIBITED USE STUDENT .ONLY USE MCT

Administering Windows Server® 2012

dn: CN=Bonnie Kearney,OU=Employees,OU=User Accounts,DC=contoso,DC=com

changetype: add objectClass: top objectClass: person

objectClass: organizationalPerson objectClass: user

cn: Bonnie Kearney sn: Kearney

title: Operations

description: Operations (London) givenName: Bonnie

displayName: Kearney, Bonnie company: Contoso, Ltd. sAMAccountName: bonnie.kearney

userPrincipalName: [e-mail] mail: [e-mail]

dn: CN=Bobby Moore,OU=Employees,OU=User Accounts,DC=contoso,DC=com changetype: add

objectClass: top objectClass: person

objectClass: organizationalPerson objectClass: user

cn: Bobby Moore sn: Moore title: Legal

description: Legal (New York) givenName: Bobby

displayName: Moore, Bobby company: Contoso, Ltd. sAMAccountName: bobby.moore

userPrincipalName: [e-mail] mail: [e-mail]

Each operation begins with the domain-name (DN)attribute of the object that is the operation’s target. The next line, changeType, specifies the type of operation: add, modify, or delete.

As you can see, the LDIF file format is not as intuitive or familiar as the comma-separated text format. However, because the LDIF format also is a standard, many directory services and databases can export LDIF files.

After creating or obtaining an LDIF file, you can perform the operations that the file specifies, by using the LDIFDE command. From a command prompt, type ldifde /? for usage information. The two most important switches for the LDIFDE command are:

•i. Turns on import mode. Without this parameter, LDIFDE exports information.

•f filename. The file from which to import, or to which to export.

In this demonstration, you will see how to:

•Import user accounts with LDIFDE.

Demonstration Steps

1.Open E:\Labfiles\Mod04\NewUsers.ldf with Notepad. Examine the information about the users that is listed in the file.

2.Open a command prompt, type the following command, and then press Enter:

ldifde -i -f E:\Labfiles\Mod04\NewUsers.ldf -k

3.Open Active Directory Users and Computers, and then confirm that the users were created successfully.

4MCT-5 USEONLY

STUDENT . PROHIBITED USE

	4-6 Managing User and Service Accounts		MCT
	4.	Examine the accounts to confirm that user properties are populated according to the instructions in
		NewUsers.ldf.
	5.	Reset the passwords of the two accounts to Pa$$w0rd.	USE
	6.	Enable the two accounts.
	7.	Close all open windows on LON-DC1.
		Question: What advantages does LDIFDE have over the Comma-Separated Values Data
		Exchange tool when managing user accounts in an AD DS environment?	.ONLY
	Demonstration: Importing User Accounts with Windows PowerShell
	The Active Directory module for Windows PowerShell also can utilize the contents of a .csv file to import
	objects into AD DS.
	Two cmdlets are used to perform this task:
	•	Import-CSV. This cmdlet creates objects from .csv files that can then be piped into other Windows	STUDENT
		PowerShell cmdlets.
	•	New-ADUser. This cmdlet is used to create the objects that have been imported from the Import-
		CSV cmdlet.
	1.	On LON-DC1, from Server Manager, open Active Directory Users and Computers, and under
		Adatum.com, create a new OU named Import Users.
	2.	Open E:\Labfiles\Mod04\ImportUsers.ps1 with Notepad. Examine the contents of the file.
	3.	Next to $impfile, change path and filename to csv to E:\Labfiles\Mod04\ImportUsers.csv, and
		then save the file.
	4.	Open the Active Directory Module for Windows PowerShell.
	5.	Type the following commands, and then press Enter after each command. When prompted to change
		the execution policy, press enter to accept the default option of Y:	USE

6.At the password prompt, type Pa$$w0rd. PROHIBITED

7.Open Active Directory Users and Computers, and verify that the user accounts have been imported into the Import Users OU.

8.Close all open windows on LON-DC1.

Administering Windows Server® 2012 4-7

	Lesson 2	MCT
	Configuring Password-Policy and User-Account Lockout
	Settings

As an administrator, you must ensure that the user accounts in your environment conform to the securityUSE settings established by your organization. Window Server 2012 uses account policies to configure security-related settings for user accounts. This module will help you to identify the settings available for configuring account security and the methods available to configure those settings.

Lesson Objectives

	After this lesson, you will be able to:		ONLY
	• Explain user-account policies.
	• Explain how to configure user-account policies.		.
	• Describe password settings objects.
	• Explain how to configure Password Settings Objects.
	Understanding User-Account Policies
	Account policies in AD DS define the default
			STUDENT
	settings for security-related attributes assigned
	to user objects. In AD DS, account policies are
	separated into two different groups of settings:
	password policy and account lockout. You can
	configure both groups of settings in the local
	policy settings for an individual Windows Server
	2012 server, or for the entire domain by using the
	Group Policy Management Console (GPMC) in
	AD DS. When settings between local policy and
	group policy conflict, group policy settings
	override local policy settings.
			USE
	In Group Policy Management within AD DS, most policy settings can be applied at different levels

•Enforce password history. This is the number of unique, new passwords that must be associated withPROHIBITED a user account before an old password can be reused. The default setting is 24 previous passwords.

When you use this setting with the minimum password-age setting, the enforce password history setting prevents constant reuse of the same password.

•Maximum password age. This is the number of days that a password can be used before the user must change it. Regularly changing passwords helps to prevent the compromise of passwords. However, you must balance this security consideration against the logistical considerations that result

from requiring users to change passwords too often. The default setting of 42 days is probably appropriate for most organizations.within the AD DS structure: domain, site, or OU. However, account policies can be applied only at one

	4-8 Managing		MCT
	• Minimum password age. This is the number of days that a password must be used before the user can
	change it. The default value is one day, which is appropriate if you also enforce password history. You
	can restrict the constant use of the same password if you use this setting in conjunction with a short		USE
	setting to enforce password history.
	• Minimum password length. This is the minimum number of characters that a user’s password must
	contain. The default value is seven. This default is a widely used minimum, but you should consider
	increasing the password length to at least 10 to enhance security.
	• Complexity requirements. Windows Server includes a default password filter that is enabled by		.ONLY
	default, and you should not disable it. The filter requires that a password have the following
	characteristics:
	o Does not contain your name or your user name
	o Contains at least six characters
	o Contains characters from three of the following four groups:
		Uppercase letters [A…Z]
		Lowercase letters [a…z]	STUDENT
		Numerals [0…9]
	 Special, nonalphanumeric characters, such as !@#)(*&^%
	• Account lockout duration. Defines the number of minutes that a locked account remains locked.
	After the specified number of minutes, the account is unlocked automatically. To specify that an
	administrator must unlock the account, set the value to 0. Consider using fine-grained password		USE
	policies to require administrators to unlock high security accounts, and then configuring this setting
	to 30 minutes for normal users.
	• Account lockout threshold. Determines the number of failed logon attempts that are allowed before
	a user account is locked out. A value of 0 means that the account is never locked out. You should set
	this value high enough to allow for users who mistype their password, but low enough to help ensure
	that brute force attempts to guess the password fail. Common values for this setting range from three
	to five.		PROHIBITED

• Reset account lockout counter after. Determines how many minutes must elapse after a failed logon attempt before the bad logon counter is reset to 0. This setting applies when a user has typed in their password incorrectly, but they have not exceeded the account lockout threshold. Consider setting this value to 30 minutes.

Note: If settings conflict between the account policy settings in the Local Security Policy and the account policy settings in the Default Domain Policy GPO, the Default Domain Policy settings take precedence.

Question: Why would you use secpol.msc to configure local account policy settings for a Windows Server 2012 computer instead of using domainbased Group Policy account-policy settings?

The settings found within the Account Policies node are the same settings found in the Local Security Policy, with the addition of the Kerberos Policy settings that apply to domain authentication.

Local Policy Settings with Secpol.msc

Each individual Windows Server 2012 computer has its own set of account policies, which apply to accounts created and managed on the local computer. To configure these policy settings, open the Local Security Policy console by running secpol.msc from the command prompt. The password-policy and account-policy settings can be located within the Local Security Policy

Console by expanding Security Settings, and then expanding Account Policies.

Group Policy with Group Policy Management

Configuring User Account Policies

There are several options available for configuring user-account policies when administering an

AD DS environment.

Administering Windows Server® 2012 4MCT-9

ONLY USE

the Policies node, expanding the under the Windows Settings node, expanding the Security Settings node, and then expanding the Account Policies node.

In the AD DS domain environment, domain-wide account policy settings are configured within the Group.STUDENT Policy Management Console. The settings can be found in the Computer Configuration, by expanding

The Group Policy Account Policy settings exist in the template of every Group Policy Object (GPO) created in the GPMC). However, you can apply an account policy only once in a domain and in only one GPO. This is the Default Domain Policy, and it links to the root of the AD DS domain. As such, the Account Policy settings in the Default Domain Policy apply to every computer that is joined to the domain.

PROHIBITED USE

4-10 Managing User and Service Accounts

What Are Password Settings Objects?

Starting with Windows Server 2008, administrators can define more than one password policy in a single domain by implementing fine-grained password policies. These enable you to have more granular control over user password requirements, and you can have different password requirements for different users or groups.

To support the fine-grained password policy feature, AD DS in Windows Server 2008 and newer versions includes two object types:

•Password Setting Container. Windows Server creates this container by default, and you can

view it in the domain’s System container. The container stores the Password Settings Objects that you create and link to global security groups or to users.

•Password Settings Objects. Members of the Domain Admins group create Password Settings Objects, and then define the specific password and account-lockout settings to be linked to a specific security group or user.

Fine-grained password policies apply only to user objects (or to inetOrgPerson objects, if you use those instead of user objects) and to global security groups. By linking a Password Settings Objects to a user or a group, you’re modifying an attribute called msDS-PSOApplied, which is empty by default. This approach now treats password and account-lockout settings not as domain-wide requirements, but as attributes to a specific user or a group.

For example, to configure a strict password policy for administrative accounts, create a global security group, add the administrative user accounts as members, and link a Password Settings Object to the group. Applying fine-grained password policies to a group in this manner is more manageable than applying the policies to each individual user account. If you create a new service account, you simply add it to the group, and the account becomes managed by the Password Settings Object.

By default, only members of the Domain Admins group can set fine-grained password policies. However, you also can delegate the ability to set these policies to other users.

Applying Fine-Grained Password Policies

You cannot apply a fine-grained password policy to an OU directly. To apply a fine-grained password policy to users of an OU, you can use a shadow group. A shadow group is a global security group that maps logically to an OU, and enforces a fine-grained password policy. You can add an OU’s users as members of the newly created shadow group, and then apply the fine-grained password policy to this shadow group. If you move a user from one OU to another, you must update the membership of the corresponding shadow groups.

The settings managed by fine-grained password policy are identical to those in the Password Policy and Accounts Policy nodes of a GPO. However, fine-grained password policies are neither implemented as part of Group Policy nor are they applied as part of a GPO. Instead, there is a separate class of object in Active Directory that maintains the settings for fine-grained password policy—the PSO.

You can create one or more PSOs in your domain. Each contains a complete set of password and lockout policy settings. A Password Settings Object is applied by linking the Password Settings Object to one or more global security groups or users.

PROHIBITED USE STUDENT .ONLY USE MCT