Training Guide Administering Windows Server 2012 R2 (2014)
Chapter 2. Managing account policies and service accounts
If you don’t force users to update their passwords, they are likely to keep the same ones indefinitely. The longer a person uses the same password, however, the more likely it is that other people will learn it and be able to gain access to that user’s account. Password policies enable you to ensure that users update their passwords on a regular basis. Account lockout policies enable you to specify what happens when a user enters an incorrect password in succession. They give you the option of locking accounts out for a limited or indefinite amount of time. In this chapter, you learn about password and account lockout policies, as well as fine–grained password policies and Group Managed Service Accounts (GMSAs). By implementing appropriate policies, you ensure that account passwords in your organization are managed in a secure and efficient manner.
Lessons in this chapter:
Lesson 1: Implementing domain password and lockout policies
Lesson 2: Using fine–grained password policies
Lesson 3: Mastering Group Managed Service Accounts
Before you begin
To complete the practice exercises in this chapter, you need to have deployed computers SYD-DC, MEL-DC, and ADL-DC, as described in the Introduction using the evaluation edition of Windows Server 2012 R2.
Lesson 1: Implementing domain password and lockout policies
Although some organizations use smart cards and biometrics for authentication, the majority of organizations use passwords consisting of alphanumeric characters and symbols as a way to verify a user’s identity. The properties of these passwords and the way those properties are enforced have a direct relationship on how effective those passwords are as a security mechanism. You use password policies to specify the properties of the passwords used in your environment. These policies include how long those passwords are, how often users have to change their passwords, how many previous passwords are remembered by Active Directory, and whether a user account is locked after the user enters an incorrect password a specific number of times.
After this lesson, you will be able to:
Configure domain user password policy.
Configure local user password policy.
Configure account lockout settings.
Estimated lesson time: 60 minutes
Domain user password policies
Most of the accounts used in your organization will be domain-based rather than local accounts. Except for the occasional local account, users, services, and computers authenticate against Active Directory Domain Services (AD DS). By using password policies, administrators can specify the rules for allowable passwords. They determine how long and how complicated passwords must be, as well as how often they must be changed, how often they can be changed, and whether previously used passwords can be used again.
Unless you take special steps, the properties of passwords used with domain accounts are determined through domain-based password policies. You configure password policies by editing Group Policy Objects (GPOs) linked at the domain level. This fact is important, and although you can set password policies at GPOs linked at the organizational unit (OU) and site level, these policies have no effect on the properties of user passwords.
Remember that you can have only one set of domain password policies configured through Group Policy. The GPO order at the domain level determines the domain password policy. In Figure 2-1, the password policy settings in the default domain policy would override any password policies configured in other GPOs. The exceptions to the rule about one password policy per domain is fine–grained password policies, which are not configured directly through Group Policy and are covered in Lesson 2, “Using fine–grained password policies.”
FIGURE 2-1 Multiple GPOs linked to domain
Real World: Default Domain Policy
Most organizations configure password policy using the Default Domain Policy GPO. Although you can link other policies at the domain level, using the Default Domain Policy GPO simplifies the process of locating and making changes to a domain password policy.
Password policies are located in the Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies node of a GPO, as shown in Figure 2-2. Although most administrators think of password policy and account lockout policy as parts of the same whole, they are actually separate. Windows Server 2012 and Windows Server 2012 R2 ship with a default password policy, but account lockout policy is not enabled. This part of the lesson focuses on the policies related to password settings, with account lockout policy covered later.
FIGURE 2-2 Password policy location
Quick check
At which level of Active Directory do you apply password policies through Group Policy?
Quick check answer
Password policies are applied at the domain level. Policies applied at the site and OU level are ignored when password policy is determined.
Password policy items
The following list shows five main password policies that you are likely to use when configuring a password policy for your organization—and one that you probably won’t use. These password policies are the following (and shown in Figure 2-3):
Enforce password history This policy means that the configured number of previously used passwords is stored within Active Directory. It stops users from using the same set of small passwords. The default and maximum value is 24 remembered passwords.
Maximum password age This policy specifies the maximum length of time that can elapse before a password must be changed. The default value is 42 days. You can set it to 999 days. Setting the value to 0 days means that there is no maximum password age.
Minimum password age You use this policy to restrict users from changing their password instantly. This policy exists because some users spend a couple of minutes repeatedly changing their password until they have exhausted the password history and return to using their original password. Users can change their password after the specified period has elapsed. The default value is 1 day.
Minimum password length This policy sets the minimum number of characters in a password. Longer passwords are more secure than shorter ones. Windows Server 2012 and Windows Server 2012 R2 support passwords up to 128 characters long when changed using GUI tools, and 256 when modified using Windows PowerShell.
Password must meet complexity requirements This policy ensures that passwords use a mix of numerals, symbols, and uppercase and lowercase alphabet characters. When enabled, it also stops users from using their account name in the password.
FIGURE 2-3 Five password policies to use
Real World: Pass phrases
People often forget that they can use the space character in passwords and that passwords can be up to 128 characters long. Using sentences rather than short, complex, hard-to-remember strings of characters enables passwords to be both memorable and secure.
Real World: The Store Passwords Using Reversible Encryption policy not needed
You are unlikely to need the Store Passwords Using Reversible Encryption policy, shown in Figure 2-3. This policy has been available in most previous versions of the Windows Server operating system. It provides backward compatibility for applications that could not access passwords stored in Active Directory using the native method of encryption. Unless your organization is running some software that was written back when Windows NT 4.0 was the Windows Server operating system, you probably won’t need to enable this policy.
Establishing balanced password policies
Password policies require balance, and a password policy that is too strict can be as detrimental as one that is not strict enough. For example, some organizations that implement strict password policies find that users write complicated passwords down because they can’t remember them. By increasing the severity of their password policies, the IT department may prompt users to behave in a way that makes the organization less secure.
When considering password policies, keep the following in mind:
Users dislike changing their password. Many want to log on and get to work rather than coming up with a new password to remember that also meets the requirements of the password policy.
Users are more likely to forget a new password than one they have been using for some time. Users who constantly forget passwords tend to do things that decrease security such as writing those passwords on notes taped to their monitors.
If you increase the minimum password length, forcing users to use pass phrases, you can also increase the maximum time before the password expires. Increasing password length increases security by making the password less guessable. Although increasing maximum password age reduces password security, this decrease is not as significant as the improvement achieved by increasing password length.
Remember that each call to the service desk costs the organization money and time. You should aim to minimize the number of password reset requests without decreasing password security.
Account lockout settings
An account lockout policy determines what happens when a person enters an incorrect password a certain number of times. The default Windows Server 2012 and Windows Server 2012 R2 settings do not have account lockout policy configured, so users can keep entering incorrect passwords until they give up in frustration. Unfortunately, enabling users to keep entering incorrect passwords is a security risk because it allows “dictionary attacks,” in which an automated system keeps entering passwords from a list until it locates the correct one. Account lockout policies are shown in Figure 2-4.
FIGURE 2-4 Account Lockout Policy
These policies enable you to do the following:
Account Lockout Duration Use this policy to specify how long an account is locked out. When enabled, this setting defaults to 30 minutes. If you set this policy to 0, the account is locked out until someone with the appropriate privileges can unlock it.
Account Lockout Threshold Use this policy to specify the number of invalid logon attempts that trigger an account lockout. When enabled, the default value is 5, but you can set it to 999. The number of invalid logons must occur within the period specified in the Reset Account Lockout Counter After policy. A value of 0 will mean that account lockout will not be triggered.
Reset Account Lockout Counter After Use this policy to specify the amount of time in which the number of invalid logon attempts must occur. When enabled, this policy defaults to a value of 30 minutes. If the defaults are used and a user enters an incorrect password three times in 30 minutes, the account is locked out for 30 minutes. If a user enters an incorrect password three times in 31 minutes, however, the account is not locked out.
Real World: Account lockout
You have to consider balance when configuring lockout policies. How many failed attempts suggest that users won’t remember their password? For the average user, a lockout of 30 minutes is functionally equivalent to a lockout that never expires. Even if you explain to users a thousand times that they have to wait 30 minutes and try again, they will still ring the help desk within moments of being locked out. Consider a 1-minute lockout and mention it using the logon disclaimer Group Policy item. It enables you to protect against dictionary attacks and probably minimize calls to the service desk.
Account management tasks
Having a set of account policies in place is only the first step in a comprehensive account management strategy. Administrators must regularly check the status of user accounts to determine how well account policies are functioning, as well as locate any accounts in which there is suspicious activity.
Accounts with non-expiring passwords
You can configure an account so that the password never expires. When you do this, the user associated with the account never has to change the password. Password policies don’t override accounts that have been explicitly configured so that their passwords do not expire. Configuring the Password Never Expires setting, as shown in Figure 2-5, exempts an account from any password-expiration policies.
FIGURE 2-5 Password Never Expires setting
To configure an account so that password policies apply, you need to remove the Password Never Expires option. You should also force the user to change the password at the next logon as if the password were configured not to expire because it is reasonable to assume that the user hasn’t changed it recently. You can figure out which accounts have been configured not to expire using the Active Directory Administrative Center, and performing a query to find all accounts that have been configured with no expiration date, as shown in Figure 2-6.
FIGURE 2-6 Locate accounts with no password expiration
You can then modify the properties of these accounts by selecting them all and checking the Password Never Expires option in the Multiple User Account properties dialog box, as shown in Figure 2-7. This dialog box is available when you view the properties of multiple selected accounts in the Active Directory Administrative Center. When performing this task, you should also force users to change their passwords on their next logon, which ensures that password policies apply in the future.
FIGURE 2-7 Multiple account properties
Real World: Administrator passwords
Many systems administrators have the bad habit of configuring their passwords not to expire simply because they realize how annoying it is to have to change passwords constantly. Given that systems administrator accounts are usually the most powerful in the organization, it is a bad idea to enable them to exempt themselves from an organizational password policy. If anything, systems administrators should be subject to more stringent password policies than ordinary users.
Locked-out accounts
As you learned earlier, the length of time an account is locked out depends on account lockout policies. Many organizations that permanently lock out accounts when a user enters incorrect passwords in succession wait for the locked-out user to ring the service desk to request a password reset. Although most users contact the service desk quickly when their user account is locked out, there are situations in which this does not occur, such as when someone attempts to gain access to a coworker’s account while that coworker is on leave. You can use the Active Directory Administrative Center Global Search option, shown in Figure 2-8, to locate users with enabled, but locked-out accounts. You should further investigate locked accounts when the user associated with the account has not contacted the service desk.
FIGURE 2-8 Locate locked-out user accounts
Inactive accounts
Although the IT department is often notified when a person new to the organization needs a new user account, the IT department is not always notified when people leave the organization. As a result, most organizations have a number of inactive user accounts that are associated with people no longer directly associated with the organization. There can be good reasons for the inactivity; for example, a person may be on maternity or long service leave. As an administrator, you should frequently search for accounts in which the user has not signed on for a good length of time. You can disable user accounts associated with users who have temporarily departed the organization. This gives you the option of reenabling the account when the user returns. You can later remove user accounts associated with users who have left the organization.
Real World: Disable or delete?
Disabling an account allows you to reactivate the account if it is necessary to access resources to which the departed user had access. Some organizations have a special “Disabled User Accounts” OU to store these accounts. Deleting an account is a more permanent option. Although it is possible to recover deleted items if backups are available, it gets increasingly difficult once the tombstone lifetime expires.
You can locate inactive accounts by using the Global Search function in the Active Directory Administrative Center to search for users with enabled accounts who have not signed on for more than a given number of days. The value you choose here will depend upon the nature of your environment, but you should definitely investigate any active enabled accounts in which a logon has not occurred for more than 50 days.
Lesson summary
You configure password and account lockout policies by editing GPOs linked at the domain level.
Password and account lockout policies linked at the site or OU level have no effect.
Accounts configured with non-expiring passwords ignore password expiration policy.
You can locate accounts that are configured not to expire, accounts in which a user has not signed on in a specific period, and accounts that are locked out in the Active Directory Administrative Center.
Lesson review
Answer the following questions to test your knowledge of the information in this lesson. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. You want to ensure that users can’t have a password shorter than 10 characters and must keep any new password for a week. Which of the following Group Policy items should you configure to accomplish this goal? (Choose all that apply.)
A. Enforce Password History
B. Minimum Password Length
C. Minimum Password Age
D. Maximum Password Age
2. You want to ensure that users change their passwords every 4 weeks and don’t use any of their 10 previous passwords. Which of the following policies should you configure to accomplish this goal? (Choose all that apply.)
A. Maximum Password Age
B. Minimum Password Age
C. Minimum Password Length
D. Enforce Password History
3. You want to ensure that users cannot use part of their user name as part of their password. Which of the following policies must you configure to accomplish this goal? (Choose all that apply.)
A. Minimum Password Age
B. Passwords Must Meet Complexity Requirements
C. Enforce Password History
D. Minimum Password Length
4. You want to ensure that users who enter five incorrect passwords in succession in a 2-hour period have their account locked out. Five incorrect passwords in succession entered in a 125-minute period should not trigger an account lockout. Which of the following Group Policy items must you configure to accomplish this goal? (Choose all that apply.)
A. Password Policy\Minimum Password Length
B. Account Lockout Policy\Account Lockout Duration
C. Account Lockout Policy\Account Lockout Threshold
D. Account Lockout Policy\Reset Account Lockout Counter After
5. Your organization has a single AD DS domain forest, and its domain name is contoso.internal. There is one site named Melbourne. All user accounts are located in a special OU named User_Accounts. All computer accounts are located in a special OU named Computer_Accounts. You want to apply a password and account lockout policy to all user accounts in the domain. Which of the following steps should you take to accomplish that goal? (Choose all that apply.)
A. Apply a GPO with a password and an account lockout policy to the User_Accounts OU.
B. Apply a GPO with a password and an account lockout policy to the Computer_Accounts OU.
C. Apply a GPO with a password and an account lockout policy to the Melbourne site.
D. Configure the password and account lockout policies in the contoso.internal Default Domain GPO.
Lesson 2: Using fine–grained password policies
With fine–grained password policies, you can configure password policies on the group or even the individual user level. Without fine–grained password policies, a single password policy applies to all user accounts in the organization. Fine–grained password policies provide administrators with flexibility, enabling them to subject sensitive accounts to more stringent password policies than regular user accounts. Any setting that can be configured through password or account lockout policy in an Active Directory GPO can be configured. Fine–grained password policies can be applied to global security groups or individual user accounts.
After this lesson, you will be able to:
Delegate password permissions.
Configure Password Settings Objects (PSO).
Manage fine–grained password policies.
Estimated lesson time: 60 minutes
Delegate password settings permissions
People tend to be good at remembering passwords that they have used for a long time. They tend not to be so good at remembering new passwords, especially if those passwords contain a mix of numbers, letters, and symbols. Users who frequently have to change their passwords are more likely to end up forgetting those passwords. If an account lockout policy is enforced, users are more likely to end up calling the service desk to get their password reset. The stricter an organization’s password policy is, the more time the service desk has to spend untangling users from forgotten passwords.
Instead of having users call the service desk to have their password reset, you can delegate the ability to reset user passwords to someone in the user’s own department, such as an administrative assistant or office manager. Taking this step can increase security because someone in the user’s own department can more easily verify the user’s identity than a service desk technician can. It also shifts work away from the service desk, which enables service desk technicians to concentrate on other tasks.
Real World: Increased security
Having someone who directly knows the user, be responsible for resetting a password, minimizes the likelihood of a successful social engineering attack. In organizations without a policy that verifies a caller’s identity before resetting a password, it is possible for a nefarious third party to call the service desk, claiming to be a user and getting a password reset. If the person with the ability to reset passwords actually knows the user in question, this type of attack is less likely to succeed.
The default Active Directory settings give members of the Account Operators, Domain Admins, or Enterprise Admins Active Directory groups the right to change user passwords. You can delegate the ability to manage password settings on a per-OU basis through the delegation of a control wizard. When you do this, you move user accounts into specific OUs that match your administrative requirements. For example, you can move all user accounts of people who work in the research department to the Research OU, and then delegate the right to reset passwords and force password change at the next logon to the research department’s departmental manager. You can also delegate the ability to manage password settings at the domain level, though most organizations do this by adding users to the Account Operators, Domain Admins, or Enterprise Admins groups.
To delegate the right to reset passwords and force password changes at the next logon, run the Delegation Of Control Wizard. You can access this wizard by right-clicking an OU in Active Directory Users And Computers and then clicking Delegate Control. You should be careful to select only the Reset User Passwords And Force Password Change At Next Logon task, as shown in Figure 2-9, not grant non-IT department users the right to perform other tasks.
FIGURE 2-9 Delegate password reset
More Info: Delegating administration of account OUs
To learn more about delegating administration of account OUs, consult the following TechNet article at http://technet.microsoft.com/en-us/library/cc771454(WS.10).aspx.
Larger organizations should consider providing a self–service password reset portal. Self–service password reset portals enable users to reset their Active Directory user account passwords after performing a series of tasks that verify their identity. This process provides users with a quick method of resetting forgotten passwords and reduces the number of password reset requests for service desk technicians. You can implement self–service password reset with Microsoft Forefront Identity Manager 2010 R2, which integrates with Active Directory Domain Services to enable this functionality.
More Info: Self–service password reset
To learn more about self–service password reset, consult the following TechNet article at http://technet.microsoft.com/en-us/library/hh824694(WS.10).aspx.
Fine–grained password policies
Fine–grained password policies enable you to have separate password policies within a single domain. For example, with fine–grained password policies you can have a password policy that applies to general users and have a stricter set of policies that apply to users with sensitive accounts, such as members of the IT department. Unlike Group Policy-based password policies, which apply at the domain level, you apply fine–grained password policies to global security groups or individual user accounts. This means that multiple fine–grained password policies might apply to a single account. In this situation, use precedence settings to ensure that the appropriate policy always applies. (Precedence is covered later in this lesson.) Fine–grained password policies can’t be applied to domain local or universal security groups, only to global security groups.
The Active Directory domain must be at the Windows Server 2008 or later functional level before you can use fine–grained password policies. You can configure or verify the current domain functional level from the Active Directory Administrative Center Console by selecting the domain and clicking Raise Domain Functional Level, as shown in Figure 2-10. You can also perform this task from the Active Directory Domains And Trusts console and the Active Directory Users And Computers console. You can also configure the domain functional level using the Set-ADDomainMode Windows PowerShell cmdlet.
FIGURE 2-10 Domain functional level
For example, to raise the domain functional level of the contoso.com domain to Windows Server 2008 from the Windows Server 2003 functional level, issue the following command.
Set-ADDomainMode –Identity contoso.com –DomainMode 3
You should plan modifications to domain functional levels carefully. You can’t lower the domain functional level once it has been set, and the domain functional level determines which operating systems you can use to host Active Directory domain controllers. You’ll learn more about domain functional levels in Chapter 4, “Administering Active Directory.”
Real World: Much easier
In previous versions of the Windows Server operating system, you had to perform a complicated set of steps using ADSIEdit to configure fine–grained password policies. Although many administrators appreciated the functionality that fine–grained password policies offered, many considered the configuration process too cumbersome to implement in their own environment. By simplifying the process of configuring fine–grained password policies, Microsoft makes them far more likely to be adopted by systems administrators who want to leverage this functionality.
Managing fine–grained password policies
You create and manage fine–grained password policies through the Active Directory Administrative Center. To create a new Password Settings Object (PSO), open the Active Directory Administrative Center and navigate to the Password Settings Container (PSC), which is located in the System Container of the domain, as shown in Figure 2-11. From the Tasks menu, click New, and then click Password Settings. The PSC enables you to view the precedence of PSOs. Password settings with lower precedence values override password settings with higher precedence values. When you apply PSOs to the user and the groups that the user belongs to, the group based PSOs will be ignored and only the PSOs that apply to the user’s account will be checked for precedence.
FIGURE 2-11 Password Settings Container
Quick check
PSO Alpha has a precedence value of 100. PSO Beta has a precedence value of 10. A user account is a member of groups to which both PSO Alpha and Beta apply. Which PSO settings apply to the user account?
Quick check answer
The settings in PSO Beta apply to the user account because the value of 10 overrides the value of 100.
Configuring Password Settings Objects
A Password Settings Object (PSO), shown in Figure 2-12, contains settings for both password policy and account lockout policy. A PSO applies to the groups and users specified in the Directly Applies To area. If a PSO applies to a user account, either directly or indirectly through group membership, that PSO overrides the existing password and account lockout policies configured at the domain level.
FIGURE 2-12 Password Settings Object
PSOs contain the following options:
Name Enables you to configure a name for the PSO.
Precedence When multiple PSOs apply to an account, the PSO with the lowest precedence value has priority.
Enforce Minimum Password Length Minimum password length that can be used by users subject to the policy.
Enforce Password History The number of passwords remembered by Active Directory. Remembered passwords can’t be reused.
Password Must Meet Complexity Requirements A password must contain a mix of numbers, symbols, and uppercase and lowercase letters.
Store Password Using Reversible Encryption Provides backward compatibility with older software and is rarely used in Windows Server 2012 environments.
Protect From Accidental Deletion The user account can’t be accidentally deleted. Although this setting is not available in Group Policy password or account lockout settings, you can edit an object directly to configure it.
Enforce Minimum Password Age The minimum length of time users must have a password before they are eligible to change it.
Enforce Maximum Password Age The maximum number of days that users can go without changing their password.
Enforce Account Lockout Policy You can configure the following three policies with this policy enabled:
Number Of Failed Logon Attempts Allowed The number of incorrect password entries that can be made in succession before a lockout is triggered.
Reset Failed Logon Attempts Count After The period of time in which the incorrect password entries must be made.
Account Will Be Locked Out Can be set either to a specific number of minutes or to a setting for which the administrator must manually unlock the account.
More Info: Fine–grained password policies
To learn more about fine–grained password policies, consult the following TechNet article at http://technet.microsoft.com/en-us/library/jj574144.aspx#BKMK_FGPP.
Determining password settings
If your organization uses a number of fine–grained password policies, it might be difficult to determine, at a glance, which password policy applies to a particular user because PSOs can be applied to multiple groups and users, and users can be members of multiple groups. Rather than work everything out manually, the Active Directory Administrative Center’s Global Search function provides the following criteria to determine which fine–grained password policy applies to a specific user or group:
Directly Applied Password Settings For A Specific User You can determine which PSOs directly apply to a specific user account. PSOs that apply to security groups of which the user account is a member are not listed.
Directly Applied Password Settings For A Specific Global Security Group You can determine which PSOs directly apply to a specific security group.
Resultant Password Settings For A Specific User You can determine which PSO applies to a specific user account based upon directly applied PSOs as well as PSOs that apply indirectly through group membership. The results of this query are shown in Figure 2-13.
FIGURE 2-13 Resultant set of password policies
Lesson summary
You delegate the ability to reset passwords using the Delegation Of Control Wizard. You can perform this task at the domain or OU level.
You can create and manage PSOs by using the Active Directory Administrative Center.
PSOs can apply to global security groups or individual user accounts.
PSOs enable you to apply all password and account policy settings available in Group Policy. You can also protect accounts from deletion.
PSOs with lower numerical precedence numbers override PSOs with higher numerical precedence numbers.
You can use the Active Directory Administrative Center to determine which PSO has precedence when multiple PSOs apply directly and indirectly to an account.
Lesson review
Answer the following questions to test your knowledge of the information in this lesson. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. You want to configure a separate password policy for members of the systems administration team. The user accounts of all members of the systems administration team are located in the Systems_Administration OU. Which of the following steps can you take to accomplish this goal? (Choose all that apply.)
A. Create a security group named Systems_Administrators. Place all the user accounts of the systems administration team in this security group.
B. Create a PSO and apply it to the Systems_Administration OU.
C. Create a PSO and apply it to the Systems_Administrators security group.
D. Configure a GPO and apply it to the Systems_Administration OU.
2. Your organization has three sites: the cities of Melbourne, Sydney, and Brisbane. You want to configure a separate password policy for all users in the Brisbane site. Users in the Melbourne and Sydney sites should use the default domain password policy. Which of the following steps can you take to accomplish this goal? (Choose all that apply.)
A. Apply a GPO that contains the settings for the appropriate password policy to the Brisbane site.
B. Apply a GPO that contains the settings for the appropriate password policy to a security group containing the user accounts of all users at the Brisbane site.
C. Apply a PSO containing the appropriate password settings to a security group containing the user accounts of all users at the Brisbane site.
D. Apply a PSO to the Brisbane site.
3. Which of the following tools can you use to configure fine–grained password policies? (Choose all that apply.)
A. Group Policy Management Console
B. Active Directory Administrative Center
C. Active Directory Users And Computers
D. Active Directory Sites And Services
4. Rooslan and Oksana are part of the IT department, and all members of the department have user accounts that are members of the IT_Staff security group. All user accounts for members of the IT department are stored in the IT_Dept OU. You want members of the IT department to be subjected to a separate password policy from the rest of the organization. Rooslan and Oksana in turn need to be subject to a password policy that is different from both the organizational password policy and the password policy applied to the rest of the IT department. No policies are currently in place. Which of the following steps should you take to accomplish this goal? (Choose all that apply.)
A. Edit the Default Domain Policy and configure the password policy for the organization.
B. Create a PSO that applies to the IT_Staff security group, which reflects the password policy that must be applied to the IT department. Assign this PSO a precedence of 20.
C. Create a PSO that reflects the password policy that should apply to Oksana and Rooslan and apply it to their user accounts. Assign this PSO a precedence of 30.
D. Create a PSO that reflects the password policy that should apply to Oksana and Rooslan and apply it to their user accounts. Assign this PSO a precedence of 10.
5. Which of the following domain functional levels are the minimum at which fine–grained password policies are supported? (Choose all that apply.)
A. Windows Server 2003
B. Windows Server 2008
C. Windows Server 2008 R2
D. Windows Server 2012
Lesson 3: Mastering Group Managed Service Accounts
A Group Managed Service Account (GMSA) is a special account type that you can use with services on computers running Windows Server 2012 and Windows Server 2012 R2. When you use a GMSA, the password of the account is automatically updated on a regular basis. When you use GMSAs, you don’t have to manually update the account password in Active Directory or any services configured to use the GMSA.
After this lesson, you will be able to:
Create GMSAs.
Install GMSAs.
Perform Kerberos delegation.
Estimated lesson time: 45 minutes
Password policies require users to change their passwords periodically as a method of increasing security because the longer the same password is used, the more likely it is that an unauthorized person may learn it. Service accounts are a special type of account that gives a service an identity, and many systems administrators don’t want to deal with them. Like user accounts, service accounts have passwords; and like other accounts, the passwords of service accounts should be changed on a regular basis.
GMSAs
Managed Service Accounts were introduced with Windows Server 2008 R2. These accounts functioned in a manner similar to GMSAs except that you could not use a single Managed Service Account across multiple servers. If you wanted to use Managed Service Accounts for the same service on two different servers, you needed to create two separate Managed Service Accounts, one for each server. If an administrator wanted to use the same Managed Service Account across multiple servers, something required for many applications that require high availability, they needed to configure a user account to perform this role.
GMSAs enable you to use the same Managed Service Account across multiple servers. You can use GMSAs only on computers running the Windows Server 2012 and later operating systems. GMSAs used with computers running Windows Server 2008 R2 must function as non-GMSAs and are limited to being installed on a single server.
GMSAs are stored in the Managed Service Account Container. This container is visible by default in Active Directory Administrative Center, as shown in Figure 2-14, and is visible if you enabled the Advanced Features view option in Active Directory Users And Computers.
FIGURE 2-14 Managed Service Accounts Container
GMSA requirements
GMSAs require that .NET Framework 3.5.x is installed on the local server. You can use GMSAs without extending the Active Directory Schema if the domain is running at the Windows Server 2008 R2 or higher functional level. If the domain is not running at this functional level and is instead running at the Windows Server 2003 or Windows Server 2008 levels, you can extend the schema so that it supports GMSAs. To use GMSAs, at least one domain controller in the domain must be running Windows Server 2012 or later.
Before creating the first GMSA in an organization, it is necessary to create a key distribution services root key with the Add-KDSRootKey cmdlet. You can do this with the following command.
Add-KdsRootKey -EffectiveImmediately
With some versions of PowerShell, the created key becomes operational only 10 hours after the command is issued. If you want to use GMSAs immediately, you must configure the time to be 10 hours prior to the current time by using the following command.
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
Creating GMSAs
After you create the key distribution services root key, you can then create GMSAs using the New-ADServiceAccount cmdlet. For example, to create a new GMSA named GMSA-Alpha using the Windows Server 2012 domain controller SYD-DC.contoso.com, execute this command.
New-ADServiceAccount –Name GMSA-Alpha –DNSHostname SYD-DC.contoso.com
You can configure the computers that use the GMSA by using the Set-ADServiceAccount cmdlet. When you specify accounts, use their Security Account Manager (SAM) names. For example, to configure the GMSAs GMSA-Alpha to be used by servers MEL-DC and ADL-DC, issue this command.
Set-ADServiceAccount –Identity GMSA-Alpha -PrincipalsAllowedToRetrieveManagedPassword
MEL-DC$, ADL-DC$
Rather than specifying individual server accounts, you can also specify group names. Any computers that are members of this security group can use the GMSA. For example, to create a new GMSA named GMSA-Beta that can be used by computers that are members of the GMSA-Beta-Group, issue this command.
New-ADServiceAccount –Name GMSA-Beta –PrincipalsAllowedToRetrieveManagedPassword GMSA-
Beta-Group –DNSHostname SYD-DC.contoso.com
After the GMSA is created, you need to install it on each server before you can use it with services. You do this with the Install-ADServiceAccount cmdlet. This cmdlet is located in the Active Directory Windows PowerShell module, which you can add to a computer by installing the Remote Server Administration Tools (RSAT). For example, to install the GMSA GMSA-Alpha on the local server, execute this command.
Install-ADServiceAccount –Identity GMSA-Alpha
After the GMSA is created, you can configure a service to use the account. You do this by editing the properties of the service, clicking Browse on the Log On tab, and selecting the service account from the Entire Directory location, as shown in Figure 2-15. Although accounts that aren’t installed on the server are visible, you can use only accounts that have been installed on the server with the service.
FIGURE 2-15 Select service account
More Info: Group Managed Service Accounts
You can find out more about GMSAs at http://technet.microsoft.com/en-us/library/hh831782.aspx.
Quick check
Which Windows PowerShell cmdlet must you run before you create the first GMSA?
Quick check answer
You must run the Add-KdsRootKey cmdlet before you create the first GMSA.
Virtual accounts
A virtual account is a local version of a Managed Service Account that is used for local services running on the host computer. Virtual accounts can access resources on the network using the computer’s identity when the computer is a member of the domain. Virtual accounts are supported only on computers running Windows Server 2008 R2, Windows 7, Windows Server 2012, Windows Server 2012 R2, Windows 8, and Windows 8.1. You don’t need to run any special Windows PowerShell cmdlets to create the virtual service account, or configure a service to use that account. You just need to know the name of the service, which you can learn by using the Get-Service cmdlet. To configure a service to use a virtual service account, perform the following steps:
1. Open the Services console and edit the properties of the service that you want to configure to use the virtual service account.
2. On the Log On tab, click This Account.
3. In the This Account text box, type the service name as NT Service\servicename. Figure 2-16 shows the configuration of the Windows Update service with its associated service name. You should configure the service with a blank password when installing it. The operating system configures the service with a managed password when you restart the service.
FIGURE 2-16 Select service account
More Info: Virtual accounts
You can find out more about virtual accounts at http://technet.microsoft.com/en-us/library/dd548356(v=ws.10).aspx.
Kerberos delegation
Kerberos constrained delegation restricts how and where application services can act on a user’s behalf. You can configure accounts so that they can be used only for specific tasks. For example, Figure 2-17 shows configuring delegation of the account for computer SYD-B, for delegation through Kerberos, for the time service on computer SYD-A. Windows Server 2012 and Windows Server 2012 R2 enable constrained delegation to be performed where the front-end service and the resource service are located in separate domains. You can configure Kerberos delegation using the Set-ADComputer, Set-ADServiceAccount, and Set-ADUser cmdlets with the PrincipalsAllowedToDelegateAccount parameter.
FIGURE 2-17 Kerberos delegation
More Info: Kerberos constrained delegation
You can find out more about Kerberos delegation at http://technet.microsoft.com/en-us/library/jj553400.aspx.
Kerberos policies
Kerberos policies determine how the service and user tickets are used in the Authentication function in an Active Directory domain. Like password and account lockout policy, Kerberos policy is applied at the domain level. Kerberos policies applied at the site and organizational level have no effect on Kerberos policy. Kerberos policies are located in the Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies node, as shown in Figure 2-18.
FIGURE 2-18 Kerberos policies
Windows Server 2012 and Windows Server 2012 R2 enable you to configure the following Kerberos policies:
Enforce User Logon Restrictions Ensures that Kerberos checks every request for a session ticket, also known as a service ticket.
Maximum Lifetime For Service Ticket Configures the maximum lifetime of a service ticket, which is also known as a session ticket. The default value for this policy is 10 hours. The value of this policy must be less than or equal to the value specified in the Maximum Lifetime For User Ticket policy.
Maximum Lifetime For User Ticket Determines the maximum lifetime of a user ticket, also known as a Ticket Granting Ticket (TGT). The default value of this policy is 10 hours.
Maximum Lifetime For User Ticket Renewal Specifies the maximum TGT renewal period. The default is 7 days.
Maximum Tolerance For Computer Clock Synchronization Specifies how much drift there can be in domain controller clocks before ticket errors occur. The default setting is 5 minutes.
More Info: Kerberos policy
You can find out more about Kerberos policy at http://technet.microsoft.com/en-us/library/cc961968.aspx.
Service principal name management
Kerberos clients use a service principal name (SPN) to identify a unique instance of a service on a given computer. If there are multiple instances of the same service hosted on computers in a domain or forest, each service requires a unique SPN. Service instances can be configured with multiple SPNs, as long as those SPNs are unique.
You can use the SetSPN command-line utility to configure SPNs for computers running Windows Server 2012 and Windows Server 2012 R2. SetSPN uses this syntax: setspn serviceclass/host:portnumber servicename. You can use SetSPN /? to see a list of all SPN switches. For example, to register the HTTP service using the standard port on a computer named MEL-DC in the contoso.com domain using a GMSA named SYD-SRVC, issue this command.
Setpspn –s http/MEL-DC.contoso.com CONTOSO\SYD-SRVC
More Info: Service principal names
You can find out more about SPNs at http://social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spns-setspn-syntax-setspn-exe.aspx.
Lesson summary
You must create a key distribution services key before you can create GMSAs.
You use the New-ADServiceAccount cmdlet to create a new GMSA.
You use the Set-AdServiceAccount cmdlet to configure a new GMSA.
You use the Install-ADServiceAccount cmdlet to install an account on a new computer.
Kerberos constrained delegation enables you to configure what services and accounts can be used for when delegated using Kerberos.
Lesson review
Answer the following questions to test your knowledge of the information in this lesson. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Which of the following operating systems supports virtual service accounts?
A. Windows Server 2008
B. Windows Server 2012
C. Windows Server 2008 R2
D. Windows Server 2003 R2
2. You want to deploy GMSAs in your new Windows Server 2012 R2 environment. Which of the following Windows PowerShell cmdlets must you run first?
A. New-AdServiceAccount
B. Install-ADServiceAccount
C. Set-ADServiceAccount
D. Add-KdsRootKey
3. You want to configure an existing GMSA to be used by additional computers. Which of the following Windows PowerShell cmdlets do you use to accomplish this goal?
A. Install-ADServiceAccount
B. Add-KdsRootKey
C. New-AdServiceAccount
D. Set-ADServiceAccount
4. You want to use a particular GMSA on a computer running the Windows Server 2012 operating system. You have created and configured the GMSA in Active Directory. Which of the following commands must you run on the computer before you can configure a service to use the account?
A. Set-ADServiceAccount
B. Add-KdsRootKey
C. Install-ADServiceAccount
D. New-AdServiceAccount
5. Which of the following policies should you configure at the domain level to ensure that the clocks of domain controllers must be synchronized within 2 minutes of one another for Kerberos to function correctly?
A. Maximum Lifetime Of A Service Ticket
B. Maximum Lifetime For User Ticket Renewal
C. Maximum Tolerance For Computer Clock Synchronization
D. Maximum Lifetime For User Ticket
Practice exercises
The goal of this section is to provide you with hands-on practice with the following:
Configure password and account lockout policies
Create fine–grained password policies
Create and configure GMSAs
To perform the exercises in this section, you need access to an evaluation version of Windows Server 2012Windows Server 2012 R2. You should also have access to virtual machines SYD-DC, MEL-DC, CBR-DC, and ADL-DC, the setup instructions for which are described in the Introduction. You should ensure that you have a snapshot checkpoint of these virtual machines that you can revert to at the end of the practice exercises. You should revert the virtual machines to this initial state prior to beginning these exercises.
Exercise 1: Configure password and account lockout policies
In this exercise, you configure the password policy and account lockout policy in an AD DS domain. You also use Active Directory Administrative Center to locate accounts that are configured with passwords that never expire. To complete this exercise, perform the following steps:
1. Sign on to SYD-DC as Contoso\Administrator.
2. From the Tools menu of the Server menu, click Group Policy Management.
3. On the Group Policy Management Console (GPMC), expand the Forest: Contoso.com, Domains, contoso.com\Group Policy Objects node and click Default Domain Policy, as shown in Figure 2-19.
FIGURE 2-19 Default Domain Policy
4. On the Action menu, click Edit.
5. In the Group Policy Management Editor, expand the Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy node.
6. Right-click Enforce Password History, and click Properties.
7. In the Enforce Password History Properties dialog box, ensure that Define This Policy Setting is enabled, set the Keep Password History For setting to 20 Passwords Remembered (as shown in Figure 2-20), and click OK.
FIGURE 2-20 Password history
8. Click the Maximum Password Age policy. On the Action menu, click Properties.
9. In the Maximum Password Age Properties dialog box, ensure that Define This Policy Setting is enabled. Set the Password Will Expire In Value to 88 days, as shown in Figure 2-21, and click OK.
FIGURE 2-21 Maximum Password Age
10. Click the Minimum Password Age policy. On the Action menu, click Properties.
11. In the Minimum Password Age Properties dialog box, ensure that Define This Policy Setting is selected. Configure the Password Can Be Changed After value to 12 days, as shown in Figure 2-22, and click OK.
FIGURE 2-22 Minimum Password Age
12. In the Group Policy Management Editor, click Minimum Password Length. On the Action menu, click Properties.
13. In the Minimum Password Length Properties dialog box, ensure that Define This Policy Setting check box is selected. Set the Password Must Be At Least to 10 characters, as shown in Figure 2-23, and then click OK.
FIGURE 2-23 Minimum Password Length
14. In the Group Policy Management Editor, click the Password Must Meet Complexity Requirements policy. On the Action menu, click Properties.
15. In the Password Must Meet Complexity Requirements Properties dialog box, ensure that Define This Policy Setting check box is selected. Ensure that the policy setting is configured as Enabled, as shown in Figure 2-24, and then click OK.
FIGURE 2-24 Password must meet complexity requirements
16. Close the Group Policy Management Editor.
Exercise 2: Configure account lockout policies
In this exercise, you configure account lockout policy in an AD DS domain. To complete this exercise, perform the following steps:
1. In the GPMC, expand the Forest: Contoso.com, Domains, Contoso.com\Group Policy objects node, and click Default Domain Policy.
2. On the Action menu, click Edit.
3. In the Group Policy Management Editor, expand the Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Account Lockout Policy node.
4. Click the Account Lockout Duration policy. On the Action menu, click Properties.
5. In the Account Location Duration Properties dialog box, click Define This Policy Setting. Configure the number of minutes to 120, as shown in Figure 2-25, and then click OK.
FIGURE 2-25 Account Lockout Duration
6. In the Suggested Value Changes dialog box, shown in Figure 2-26, click OK.
FIGURE 2-26 Suggested Value Changes
7. Click the Account Lockout Threshold policy. On the Action menu, click Properties.
8. In the Account Lockout Threshold Properties dialog box, ensure that the Define This Policy Setting check box is selected. Set the Account Will Lock Out After value to 3 Invalid Logon Attempts, as shown in Figure 2-27, and click OK.
FIGURE 2-27 Account Lockout Threshold
9. In the Group Policy Management Editor, click Reset Account Lockout Counter After. On the Action menu, click Properties.
10. In the Reset Account Lockout Counter After Properties dialog box, ensure that Define This Policy Setting is selected. Set the Reset Account Lockout Counter After value to 2400 minutes, as shown in Figure 2-28, and click OK.
FIGURE 2-28 Reset account lockout counter
11. In the Suggested Value Changes dialog box, click OK.
12. Close the Group Policy Management Editor.
13. Configure the following account lockout policy settings:
Account Lockout Duration: 2400 minutes
Account Lockout Threshold: 3 invalid logon attempts
Reset Account Lockout Counter After: 2400 minutes
Exercise 3: Group Policy Modeling
In this exercise, you use the Active Directory Administrative Center to locate accounts that are configured with passwords that never expire. To complete this exercise, perform the following steps:
1. In the GPMC, expand the Forest: Contoso.com, and click Group Policy Modeling.
2. On the Action menu, click the Group Policy Modeling Wizard.
3. On the Welcome To The Group Policy Modeling Wizard page, click Next.
4. On the Domain Controller Selection page, click This Domain Controller and click SYD-DC.contoso.com, as shown in Figure 2-29. Click Next.
FIGURE 2-29 Domain Controller Selection
5. On the User And Computer Selection page of the Group Policy Modeling Wizard, click Browse next to Container in the User Information area.
6. In the Choose User Container dialog box, expand Contoso, click Users, and click OK.
7. On the User And Computer Selection page of the Group Policy Modeling Wizard, click Browse next to Container in the Computer Information area.
8. In the Choose Computer Container dialog box, expand Contoso, click Computers, and click OK.
9. Verify that the User And Computer Selection page matches Figure 2-30 and then click Next.
FIGURE 2-30 User And Computer Selection
10. On the Advanced Simulation Options page, click Next.
11. On the User Security Groups page, shown in Figure 2-31, click Authenticated Users, and then click Next.
FIGURE 2-31 User Security Groups selection
12. On the Computer Security Groups page, click Next.
13. On the WMI Filters For Users page, click Next.
14. On the WMI Filters For Computers page, click Next.
15. On the Summary Of Selections page, click Next.
16. On the Completing The Group Policy Modeling Wizard page, click Finish.
17. In the Internet Explorer dialog box, click Add.
18. In the Trusted Sites dialog box, click Add, and then click Close.
19. Click Contoso, and then click the Details page.
20. Click Show next to Security Settings.
21. Click Show next to Account Policies/Password Policy, and click show next to Account Policies/Account Lockout Policy.
22. Verify that the settings displayed match those shown in Figure 2-32.
FIGURE 2-32 Verify policy configuration
23. Close the GPMC.
Exercise 4: Locate non-expiring passwords
In this exercise, you use Active Directory Administrative Center to locate accounts that are configured with passwords that never expire. To complete this exercise, perform the following steps:
1. In Server Manager, click Active Directory Users And Computers on the Tools menu.
2. In Active Directory Users And Computers, click the Users container. Click the Action menu, click New, and click User.
3. In the New Object – User dialog box, type the following details, as shown in Figure 2-33, and then click Next:
First Name: Test
Last Name: User
Full Name: Test User
User Logon Name: Test_User
FIGURE 2-33 Creating a new user
4. In the New Object-User dialog box, type the password Pa$$w0rd twice. Remove the selection next to User Must Change Password At Next Logon. Select the Password Never Expires option, as shown in Figure 2-34, and click Next.
FIGURE 2-34 Password Never Expires option
5. In the New Object – User dialog box, click Finish.
6. In the Active Directory Domain Services dialog box, shown in Figure 2-35, review the message that explains why the password cannot be set, and click OK.
FIGURE 2-35 Password configuration error
7. Click Back. Type the following password twice: Pa$$w0rd!!, click Next, and click Finish.
8. Close Active Directory Users And Computers.
9. From the Tools menu, click Active Directory Administrative Center.
10. In the Active Directory Administrative Center, click Global Search.
11. Click the down arrow, and click Add Criteria.
12. Click Users Whose Password Has An Expiration Date/No Expiration Date, and click Add.
13. Click Search. Verify that the result of the query matches that shown in Figure 2-36 and that Test User is listed as a user with a non-expiring password.
FIGURE 2-36 Password expiration search
14. Close the Active Directory Administrative Center.
Exercise 5: Create fine–grained password policies
In this exercise, you create two different fine–grained password policies that apply to different security groups. To complete this exercise, perform the following steps:
1. In the Server Manager, click Active Directory Administrative Center from the Tools menu.
2. Click Contoso (Local) and then double-click Users.
3. On the Tasks pane, click New, and click User.
4. In the Create User dialog box, type the following details, as shown in Figure 2-37, and then click OK.
Full Name: Gabe Frost
User SamAccountName: contoso\Gabe_Frost
Password: Pa$$w0rd!!
Confirm Password: Pa$$w0rd!!
FIGURE 2-37 Creating user Gabe Frost
5. On the Tasks pane, click New, and click Group.
6. In the Create Group dialog box, type the group name as FG_PasswordPolicyOne and click OK.
7. On the Tasks pane, click New, and click Group.
8. In the Create Group dialog box, type the group name as FG_PasswordPolicyTwo, as shown in Figure 2-38, and click OK.
FIGURE 2-38 Create Security Group
9. In the Active Directory Administrative Center, right-click Don Funk, and click Add To Group.
10. In the Select Groups dialog box, type FG_PasswordPolicyOne; FG_PasswordPolicyTwo, as shown in Figure 2-39, click Check Names, and click OK.
FIGURE 2-39 Adding to Security Group
11. In the Active Directory Administrative Center, open the System Container, and then open the Password Settings Container.
12. On the Tasks menu in the Password Settings Container, click New, and click Password Settings.
13. In the Create Password Settings dialog box, type the following information, as shown in Figure 2-40, and click OK.
Name: FGPW_One
Precedence: 10
Enforce Minimum Password Length: 5
Enforce Minimum Password Age: 5
Enforce Password History: 10
Enforce Maximum Password Age: 21
Enforce Account Lockout Policy
Number Of Failed Logon Attempts Allowed: 3
Reset Failed Logon Attempts Count After (Minutes): 45
Account Will Be Locked Out: Until An Administrator Manually Unlocks The Account
Password Must Meet Complexity Requirements
Directly Applies To: FG_PasswordPolicyOne
FIGURE 2-40 Creating a fine–grained password policy
14. On the Tasks menu in the Password Settings Container, click New, and click Password Settings.
15. In the Create Password Settings dialog box, type the following information and click OK:
Name: FGPW_Two
Precedence: 20
Enforce Minimum Password Length: 10
Enforce Minimum Password Age: 14
Enforce Password History: 15
Enforce Maximum Password Age: 30
Enforce Account Lockout Policy
Number Of Failed Logon Attempts Allowed: 2
Reset Failed Logon Attempts Count After (Minutes): 60
Account Will Be Locked Out: Until An Administrator Manually Unlocks The Account
Password Must Meet Complexity Requirements
Directly Applies To: FG_PasswordPolicyTwo
16. In the Active Directory Administrative Center, navigate to the Users Container and click Gabe Frost.
17. On the Tasks pane, click View Resultant Password Settings.
Exercise 6: Prepare MEL-DC and ADL-DC
In this exercise, you prepare MEL-DC and ADL-DC for exercise 7. To complete this exercise, perform the following steps:
1. Start MEL-DC and sign in using the Administrator account with the password Pa$$w0rd.
2. Open the Windows PowerShell prompt and type the following commands.
Add-Computer -DomainName contoso.com
3. In the Windows PowerShell Credentials dialog box type don_funk@contoso.com and Pa$$w0rd, and click OK.
4. Type the following command in the Windows PowerShell prompt to restart the computer.
Restart-Computer
5. Start ADL-DC and sign in using the Administrator account with the password Pa$$w0rd.
6. Open the Windows PowerShell prompt and type the following commands.
Add-Computer -DomainName contoso.com
7. In the Windows PowerShell Credentials dialog box, type don_funk@contoso.com and Pa$$w0rd, and click OK.
8. Type the following command in the Windows PowerShell prompt to restart the computer.
Restart-Computer
Exercise 7: Create and configure GMSAs
In this exercise, you create and configure two GMSAs. To complete this exercise, perform the following steps:
1. On SYD-DC, click Windows PowerShell on the task bar.
2. Execute the following command to create a new key distribution services root key that you can use right after creating it, not 10 hours later.
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
3. Execute the following commands to create two new GMSAs named GMSA-Alpha and GMSA-Beta so that they can be used on servers MEL-DC and ADL-DC.
New-ADServiceAccount –Name GMSA-Alpha –PrincipalsAllowedToRetrieveManagedPassword
MEL-DC$, ADL-DC$ –DNSHostname SYD-DC.contoso.com
New-ADServiceAccount –Name GMSA-Beta –PrincipalsAllowedToRetrieveManagedPassword
MEL-DC$, ADL-DC$ –DNSHostname SYD-DC.contoso.com
4. Sign on to server MEL-DC with the Contoso\Administrator account.
5. In Windows PowerShell, execute the following command to install the account GMSA-Alpha.
Install-WindowsFeature RSAT-AD-PowerShell
Install-ADServiceAccount –Identity GMSA-Alpha
6. Open the Search charm and type Services. Click Services.
7. Right-click the Windows Update service, and click Properties.
8. On the Log On tab, select This Account, and click Browse.
9. Click Locations, click Entire Directory, and click OK.
10. Type the name Contoso\GMSA-Alpha, click Check Names, and click OK.
11. In the Windows Update Properties (Local Computer) dialog box shown in Figure 2-41, click OK.
FIGURE 2-41 Configure Group Managed Service Account
12. Repeat steps 4 through 11 to install and use GMSA-Beta as the service account for the Windows Update service on ADL-DC.
Suggested practice exercises
The following additional practice exercises are designed to give you more opportunities to practice what you’ve learned and to help you successfully master the lessons presented in this chapter.
Exercise 1 After configuring password policy and account lockout policies and enabling Group Policy to update, create a new administrator account by copying the built-in domain administrator account. Configure the account so that the account password must be changed the next time the user associated with the account signs on. Sign off and then sign on using the newly created account. Verify that the password length policy was applied. Verify that the account lockout policy functions by entering an incorrect password four times.
Exercise 2 Create two new user accounts. Add the first user account to the FG_PasswordPolicyOne security group. Add the second user account to both the FG_PasswordPolicyOne and FG_PasswordPolicyTwo security groups. Verify that password policy precedence was configured by testing minimum password length and account lockout thresholds.
Exercise 3 Create a security group named GMSA-Gamma-Group. Create a new Group Managed Service Account named GMSA-Gamma. Configure the Group Managed Service Account to be used by computers that are members of the GMSA-Gamma group.
Answers
This section contains the answers to the lesson review questions in this chapter.
Lesson 1
1. Correct answers: B and C
A. Incorrect. You configure the Enforce Password History policy when you want to ensure that users do not use an earlier password.
B. Correct. You configure the Minimum Password Length policy when you want to ensure that users use a password that has a minimum number of characters.
C. Correct. You configure the Minimum Password Age policy when you want to ensure that users use a password for a minimum length of time.
D. Incorrect. You configure the Maximum Password Age policy when you want to limit the maximum amount of time that a person can have the same password.
2. Correct answers: A and D
A. Correct. You configure the Maximum Password Age policy when you want to limit the maximum amount of time that a person can have the same password.
B. Incorrect. You configure the Minimum Password Age policy when you want to ensure that users use a password for a minimum length of time.
C. Incorrect. You configure the Minimum Password Length policy when you want to ensure that users use a password that has a minimum number of characters.
D. Correct. You configure the Enforce Password History policy when you want to ensure that users do not use an earlier password.
3. Correct answer: B
A. Incorrect. You configure the Minimum Password Age policy when you want to ensure that users use a password for a minimum length of time.
B. Correct. You configure the Passwords Must Meet Complexity Requirements policy to ensure that users must use passwords that contain a combination of numbers, symbols, and uppercase and lowercase characters. This policy also blocks users from using passwords that contain their names.
C. Incorrect. You configure the Enforce Password History policy when you want to ensure that users do not use an earlier password.
D. Incorrect. You configure the Minimum Password Length policy when you want to ensure that users use a password that has a minimum number of characters.
4. Correct answers: C and D
A. Incorrect. This policy determines the minimum length of a password, not the number of incorrectly entered passwords and period of time that will configure a lockout.
B. Incorrect. This policy determines how long an account is locked out. You don’t need to configure this policy to accomplish the specifics of your goal. You must configure the other two policies to accomplish the specifics of your goal.
C. Correct. This policy determines the number of incorrect passwords entered in succession to trigger a lockout.
D. Correct. This policy determines the period in which the number of incorrect passwords must be entered in succession.
5. Correct answer: D
A. Incorrect. You can apply GPO–based password policies only at the domain level.
B. Incorrect. You can apply GPO–based password policies only at the domain level.
C. Incorrect. You can apply GPO–based password policies only at the domain level.
D. Correct. You can apply GPO–based password policies only at the domain level.
Lesson 2
1. Correct answers: A and C
A. Correct. You can apply fine–grained password policies to security groups or user accounts. You need to collect the accounts of the system administrators together before you can apply fine–grained password policies to those accounts.
B. Incorrect. You can’t apply PSOs to OUs. You can apply PSOs only to user accounts and security groups.
C. Correct. You can apply PSOs to user accounts or security groups.
D. Incorrect. Although Group Policy can be applied at the OU level, password policy can be applied through Group Policy only at the domain level.
2. Correct answer: C
A. Incorrect. Group Policy-applied password settings can be applied only at the domain level.
B. Incorrect. GPOs can’t be applied to security groups.
C. Correct. You can create a security group that contains the user accounts of all users at the Brisbane site and then apply a PSO containing a custom password policy to this security group.
D. Incorrect. You can’t apply PSOs to sites. You can apply PSOs only to security accounts or security groups.
3. Correct answer: B
A. Incorrect. The GPMC enables you to manage GPOs. You need the Active Directory Administrative Center to manage fine–grained password policies.
B. Correct. You can manage fine–grained password policies using the Active Directory Administrative Center.
C. Incorrect. You can use Active Directory Users and Computers to manage user accounts and OUs. You can’t use Active Directory Users and Computers to manage fine–grained password policies.
D. Incorrect. You can use Active Directory Sites And Services to manage Active Directory sites and site links. You can’t use Active Directory Sites And Services to manage password policies.
4. Correct answers: A, B, and D
A. Correct. You must configure a policy at the domain level for all users in the organization.
B. Correct. You must create a fine–grained password policy and apply it to the IT_Staff security group. These users then have a different password policy from other users in the domain.
C. Incorrect. PSOs assigned with a lower numerical value override PSOs assigned with a higher numerical value. A value of 30 means that Rooslan and Oksana are subject to the PSO applied to the IT_Staff security group.
D. Correct. You must assign the PSO that applies to Rooslan and Oksana a lower numerical precedence than the one used with the PSO applied to the IT_Staff security group. Assigning a precedence of 10 means that this PSO overrides the one that applies to these accounts through the membership of the IT_Staff group.
5. Correct answer: B
A. Incorrect. Fine–grained password policies are supported at the Windows Server 2008 domain functional level.
B. Correct. Fine–grained password policies are supported at the Windows Server 2008 domain functional level.
C. Incorrect. Fine–grained password policies are supported at the Windows Server 2008 domain functional level.
D. Incorrect. Fine–grained password policies are supported at the Windows Server 2008 domain functional level.
Lesson 3
1. Correct answers: B and C
A. Incorrect. Windows Server 2008 does not support virtual service accounts.
B. Correct. Windows Server 2012 does support virtual service accounts.
C. Correct. Windows Server 2008 R2 does support virtual service accounts.
D. Incorrect. Windows Server 2008 does not support virtual service accounts.
2. Correct answer: D
A. Incorrect. Use this cmdlet to create a new Group Managed Service Account. You must create the key distribution services key before you can create Group Managed Service Accounts.
B. Incorrect. Use this cmdlet to install a Group Managed Service Account on a computer after it is created. You must create the key distribution services key before you can create group Managed Service Accounts.
C. Incorrect. This cmdlet configures the properties of a Group Managed Service Account. You must create the key distribution services key before you can create G Group Managed Service Accounts.
D. Correct. You must create the key distribution services key before you can create Group Managed Service Accounts.
3. Correct answer: D
A. Incorrect. Use this cmdlet to install a Group Managed Service Account on a computer after it is created. You must use the Set-ADServiceAccount cmdlet to configure an existing Group Managed Service Account so that it can be used by additional computers.
B. Incorrect. You use this cmdlet to create the key distribution services key before you can create Group Managed Service Accounts.
C. Incorrect. This cmdlet is used to create a new Group Managed Service Account. You must use the Set-ADServiceAccount cmdlet to configure an existing Group Managed Service Account so that it can be used by additional computers.
D. Correct. You use the Set-ADServiceAccount cmdlet to configure an existing Group Managed Service Account so that it can be used by additional computers.
4. Correct answer: C
A. Incorrect. You use the Set-ADServiceAccount cmdlet to configure an existing Group Managed Service Account so that it can be used by additional computers. You must use the Install-ADServiceAccount cmdlet before you can use a Group Managed Service Account on a computer.
B. Incorrect. You use this cmdlet to create the key distribution services key before you can create Group Managed Service Accounts. You must use the Install-ADServiceAccount cmdlet before you can use a Group Managed Service Account on a computer.
C. Correct. Use this cmdlet to install a Group Managed Service Account on a computer after it is created. You must use the Install-ADServiceAccount cmdlet before you can use a Group Managed Service Account on a computer.
D. Incorrect. This cmdlet is used to create a new Group Managed Service Account.
5. Correct answer: C
A. Incorrect. This policy determines maximum service ticket lifetime and is not related to domain controller clock drift.
B. Incorrect. This policy determines user ticket renewal lifetime and is not related to domain controller clock drift.
C. Correct. This policy defines how much drift there can be in computer clock synchronization between domain controllers before service and user ticket errors occur.
D. Incorrect. This policy specifies the maximum validity of a user ticket and is not related to domain controller clock drift.