Chapter 4: Creating and Maintaining Active Directory Objects

Computers, users, printers, groups, organizational units (OU), group policy objects (GPO)… Rather than trying to list all of the things you can create and store in an Active Directory Domain Services (AD DS) directory perhaps we should try to think of a few things you cannot! Theoretically you could create whatever kinds of objects you wanted by editing the schema, however, with regards to the exam the list is indeed finite and particular focus is placed on managing users and group policy. This chapter introduces you to the classes of objects built into AD DS and the management tasks associated with each. In this chapter you will learn about the following:

  • Automate creation of Active Directory accounts.
  • Maintain Active Directory accounts.
  • Create and apply Group Policy objects (GPOs).
  • Configure GPO templates
  • Configure software deployment GPOs.
  • Configure account policies.
  • Configure audit policy by using GPOs.

 Creating and Maintaining Accounts

There are several different kinds of accounts available in AD DS: user accounts, inetOrgPerson objects, computer accounts, and groups. Yes, groups are accounts too, like the others groups have security identifiers (SID). The differences are that groups don’t authenticate but that users and computers inherit a group’s SID by belonging to the group. Support for inetOrgPerson objects is provided for interoperability with other directory services technologies. Another kind of object has no SID because its not a security principal: the contact object, which is typically only used for email.

Creating User Accounts

Manually creating new user accounts is easy with Active Directory Users and Computers, navigate to the container where you want to locate the user, right-click, select New, and select User. Then fill in the appropriate information for the new account with the New Object – User wizard. The only required fields are last name, logon name, and password. You can right-click a user and select Properties to define many other attributes. You add new users from a command prompt using dsadd, enter dsadd user /? to see the complete list of parameters available, at a minimum you need to enter the following:

dsadd user <user distinguished name> -pwd {<password>|*}

If you specify * for the password you will be prompted to provide a password for the new account. Oddly, while you are forced to specify a last name when using the wizard you are not when using dsadd. While you could create scripts with dsadd to automatically create large numbers of accounts it may be easier to do so using the ldifde utility introduced in Configuring Additional Active Directory Server Roles. If you are considering VBScript and ADSI for bulk account management examine the Create, Put, PutEx and SetInfo methods.

I don’t think you need to become a scripting guru for the exam but you should understand the capabilities of dsadd and ldifde. Ldifde reads LDIF formatted files, an entry to add myself to my own test lab would look like this in the file:

dn: CN=KurtDillard,OU=corp,DC=dillard,DC=test

changetype: add

cn: KurtDillard

objectClass: user

samAccountName: Kurt

givenName: Kurt

sn: Dillard

I would need to recreate this section for each additional user, providing their unique data. Assuming I named it new.ldf, I would enter the following command:

ldifde –i –f new.ldf –s dc1

Creating Group Accounts

Domain groups have three possible scopes: domain local, global, and universal. The group scope limits what its membership can include and what it can be used for, as summarized in table 1.

Scope

Can be a member

Can be used for

Domain local

Users from anywhere in the forest and trusted forests

Permissions on local domain resources

 

Global and universal groups from anywhere in the forest and trusted forests

On systems running Windows 2000 and above

 

Nested domain local groups from the same domain

 

Global

Users from the same domain

Permissions on resources anywhere in the forest and trusted forests

 

Nested global groups from the same domain

Any Windows systems including those running Windows NT

Universal

Users from anywhere in the forest

Permissions on resources anywhere in the forest and trusted forests

 

Global groups from anywhere in the forest

On systems running Windows 2000 and above

 

Nested universal groups from anywhere in the forest

 

Table 1: Group Scopes

There are also four types of groups: security and distribution are what systems administrators usually manage. The other two types, application basic groups and LDAP query groups, are used by Authorization Manager-enabled applications. A security group is a security principal with a SID and it can be used when defining permissions on network resources such as shared printers and folders. A distribution group has no SID, they are used for sending email to all of the members of the group.

Creating groups is similar to creating user accounts. Open Active Directory Users and Computers, navigate to the container where you want to locate the user, right-click, select New, and select User. Then fill in the appropriate information for the new account with the New Object – Group wizard, as shown in figure 1.

Figure 1: Creating a New Group.

You can use dsadd from a command prompt to add groups too, you must specify both the group scope and type:

dsadd group <GroupDN> -samid<SAMName> -secgrp {yes|no} -scope {l|g|u}

Where <GroupDN> is the distinguished name of the group, <SAMName> is the unique SAM account name for the group, {yes|no} specifies whether it’s a security group, and {l|g|u} define the scope (l = domain local, g = global, and u = universal). Once created you can modify group membership and other properties by right-clicking on it in Active Directory Users and Computers.

Creating Computer Accounts

Computers have domain accounts too, they authenticate to a domain controller (DC) during the boot up process using a password  that is automatically changed every thirty days by default. A computer account is created automatically when you use the System tool in Control Panel to add a computer to the domain. By default standard users are allowed to add up to ten computers to their domain and members of the Domain Admins group can add an unlimited number. New member computers are placed in the Computers container by default, however you will probably want to move them to an OU based on their geographic location or business unit. You can create new computer accounts ahead of time in specific OUs using Active Directory Users and Computers or dsadd so that you do not have to move them later.

Tip: You can simplify logons and administration in large enterprises by implementing alternative user principal names (UPN). When properly configured users can log onto any domain in the forest without having to specify their domain. The Domain Name System (DNS) name for the domain is the UPN suffix by default, you can specify additional ones for each domain in your organization using Active Directory Domains and Trusts. Right-click on Active Directory Domains and Trusts in the navigation tree and select Properties, then enter the alternative UPN suffixes you would like to enable. A simple example may help to illustrate how this is useful. Assume my external email address is kurt@dillard.test, my account name is kurt, and I belong to the domain called corp.americas.dillard.test. With the UPN suffix dillard.test enabled I could long on using my email address rather than my default UPN of kurt@corp.americas.dillard.test or having to use the domain drop-down list in the logon dialog box.

Maintaining Accounts

With each of the objects discussed so far you can right-click on it and use the menu that appears to perform a variety of management tasks such as resetting user passwords or editing attributes. This section will focus on using the graphical management tools, however, in addition to dsadd there are several other command line utilities that you may find useful. To see the syntax and possible parameters for each enter the tool name followed by /? at a command prompt:

  • Dsget – Used to view properties of directory objects.
  • dsmod – Modifies objects such as computers, users, groups, and contacts.
  • dsmove – Moves and renames objects within a single domain.
  • dsquery – Locates objects within the directory.
  • dsrm – Removes objects and containers from the directory.

Note: Windows Server 2008 includes a feature called Protected Administrator. This feature is intended to lower the risk of being exploited by malicious software (malware) while logged in with administrative privileges. Similar to User Account Control (UAC), this feature causes most applications to execute with a special restricted token that limits their access. This means that if you accidentally execute an application that includes malware the potential impact on the operating system is significantly reduced. While it could damage your user profile, it should not be able to make global changes to the computer by writing to the HKEY_LOCAL_MACHINE portion of the registry or the system folder of the hard drive. The only applications that execute without having this restricted token attached to their process tree are those that specifically allowed to do so. One way to add an application to the list of trusted ones is to digitally sign its installation manifest. Many of the management tools included with Windows Server 2008 are already marked in this way.

Adding Accounts to Groups

As you have seen in previous chapters, even within a single management tool there are often several ways to accomplish a particular task, for example, there are three ways to add an account to a group using Active Directory Users and Computers. In the first way, you right-click on the group and select Properties, as shown in figure 2.

Figure 2: Opening the Properties Dialog Box of a Group

  1. Next , select the Members tab and click Add.
  2. Type the name or portion of the name of the user in the Enter the object names to select box.
  3. Click Check Names, the full account name will be displayed, as shown in figure 3.
  4. Click OK two times to close the two dialog boxes.

Figure 3: Adding a User to a Group by Selecting the User.

The second way is to right-click on the user and select Add to a group, as shown in figure 4.

Figure 4: Opening the Select Groups Dialog Box.

  1. Type the name or portion of the name of the gropu in the Enter the object names to select box.
  2. Click Check Names, the full group name will be displayed, as shown in figure 5.
  3. Click OK close the dialog boxe.

Figure 5: Adding a User to a Group by Selecting the Group.

  1. The third way is to right-click on the user and select Properties.
  2. Next , select the Member of tab and click Add.
  3. Type the name or portion of the name of the gropu in the Enter the object names to select box.
  4. Click Check Names, the full group name will be displayed, as shown in figure 6.
  5. Click OK two times to close the two dialog boxes.

Figure 6: Adding a User to a Group by Selecting the Group.

When using the Select Users, Contacts Computers, or Groups and the Select Groups dialog boxes you can specify accounts from other domains by clicking Locations and selecting the domain where the account resides. You can remove accounts from groups using the Properties dialog box for the user, selecting the group on the Members Of tab, and clicking Remove; or using the Properties dialog box for the group, selecting the user on the Members tab, and clicking Remove.

Resetting a User’s Password

If a user forgets their password you can reset it by right-clicking on the account and selecting Reset Password. Enter the password twice in the Reset Password dialog box, as shown in figure 7. It is a good idea to force the user to specify a new password the next time the log on by enabling the User must change password at next logon checkbox. If account lockout is enforced and the user has locked their account because they have repeatedly entered an incorrect password while trying to log on you can unlock the account by enabling the Unlock the user’s account checkbox.Click OK to close the dialog box.

Figure 7: Resetting a User’s Password.

Deprovisioning Users

As all good things must come to an end, people leave organizations. You should have documented procedures for how the accounts of departing employees are processed; variations for specific circumstances should be included. For example, how a planned departure is handled will be different than an unexpected one. There will also be differences depending upon the employee’s role and the sensitivity of the information she can access. The process of creating accounts for new employees is referred to as provisioning, and deprovisioning is the process of disabling and deleting accounts for employees who leave. Although its possible to simply delete the user’s account, that may not be the best way because each user will have access to various network resources and deleting the account may inadvertently cause some resources to be accessible to nobody. What most organizations usually do is disable the account or reset the password so that the former employee can no longer access the network, then ensure that other people are able to assume control of everything that she had been managing. Only after everything has been transferred to other people is the account deleted. This approach is particularly important for people with administrative access to servers or the domain, and for users who have encrypted data using BitLocker or the Encrypting File System (EFS).

Using Security Groups Efficiently

Two acronyms that you might encounter on the exam are AGDLP and AGUDLP. These refer to recommended methods of using accounts and groups to manage permissions on shared resources. These methods are much easier to implement and manage then trying to grant individual users permissions on each network resource. AGDLP refers to placing user accounts (A) into global groups (G), add global groups into domain local groups (DL), and then assigning permissions (P) to the domain local group on the shared resource. Variations on this approach have been used since the introduction of Windows NT and Windows-based domains, although prior to Windows 2000 local groups on servers were used instead of domain local groups. Universal groups have been available for a long time now and they provide an additional layer of abstraction, adding them to the first acronym results in: AGUDLP where you place domain user accounts (A) into global groups (G), add global groups into universal groups (U), add universal groups into domain local groups (DL), and then assigning permissions (P) to the domain local group on the shared resource.

You can use universal groups as you see fit, but you should be consistent in choosing when to use a universal group versus a global group. There are some situations where you have to use universal groups, such as when using mail-enabled groups for Exchange which include users from more than one domain.

Important: Do not confuse domain local groups with local groups or domain accounts with local accounts. Domains can host user accounts and the various types of groups discussed in this chapter, all of these are stored in the AD DS database. Each member computer in the domain, including DCs, also has a local account database which can only host two types of objects: user accounts and local groups. This database is referred to as the Security Account Manager (SAM) database. The SAM database on DCs is not visible in any of the graphical management tools. While you can add domain groups to local groups you cannot add any local accounts to groups at the domain level.

Creating Organizational Units and Delegating Administration

AD DS includes a few containers by default such as Computers and Users, where new computer accounts and user accounts are placed by default. Most organizations use organizational units (OU) rather than containers to segregate accounts and groups based on their geographic location, business unit, or role because you can link group policy objects (GPO) to an OU but not to a container. Its very easy to create a new OU using Active Directory Users and Computers, simply right-click on the location where you want to locate the OU, select New, then select Organizational Unit. You can also drag and drop OUs to reorganize their structure, rename them, and delete them. Delegating control of an OU and all of its child objects and containers is also easy: launch the Delegation of Control Wizard by right-clicking the OU and selecting Delegate control. The wizard allows you to select domain groups and grant them the ability to perform specific management tasks such as resetting passwords or managing groups. While performing these tasks is easy, preparing to do so in a production environment requires careful planning. Figure 8 shows a four tier hierarchy of OUs, the first tier for geographic location, the second for business unit within that location, and the last two tiers segregate computers and users based upon their role. For detailed guidance on creating OU designs look at the suggested readings in the References section at the end of the chapter.

Figure 8: An OU Design Based on Business Units and Roles

Creating and Maintaining Group Policy Objects

Group policy objects (GPO), referred to as group policy when discussing the AD DS feature, contain configuration information for many settings that affect the appearance and behavior of the Windows operating systems; its components such as Media Player and Internet Explorer; and other applications such as Outlook and Excel. GPOs can include settings for users and computers, they are linked to OUs and affect all objects within that OU and its child containers. OUs can be filtered using access control lists (ACL) and Windows Management Interface (WMI) values such as operating system version.

There are a few tools involved in managing group policy which are examined in this chapter. The Group Policy Management Console (GPMC) is the primary tool for managing group policy. Prior to the GPMC most group policy management was undertaken in Active Directory Users and Computers. There’s also the Group Policy Editor which can be launched from within the GPMC or by entering gpedit.msc at the Search prompt on the Start Menu. Finally, there are a couple of command prompt tools gpresult and gpupdate.

Note: Microsoft published the GPMC months after the release of Windows Server 2003, the GPMC is now built into Windows Server 2008. Prior to the GPMC most group policy management was undertaken in Active Directory Users and Computers.

How Group Policy Objects Work

There are several criteria that determine whether or not a computer or user will be affected by a GPO located in their domain. First, the account must be within the GPOs scope of management (SOM), which means that the GPO is linked same site as the account, to the root of the domain or to an OU that is part of the account’s hierarchy. Second, the account must have read permissions on the GPO. Third, the user or machine portion, whichever corresponds to the type of account, the GPO must be enabled. Fourth, if the policy has a WMI filter the target object must meet the requirements of the filter.

The order in which GPOs take precedent over one another is also important to understand. In essence, the group policy engine lays one policy on top of the other, when settings conflict the GPO with greater precedence overwrites the other. When all policies have been processed the resulting collection of settings is applied to the computer or user. The order of precedence is as follows, with GPOs higher on the list overwriting lower ones, as shown in figure 9. The Mail server is located in the site named Austin, and its placed in the Mail OU.

  1. The OUs in the same hierarchy, the OUs closer to the account take precedence over those that are more distant. If multiple GPOs are linked to the same OU then the GPOs higher on the list take precedence over lower ones.
  2. Domain root, those higher on the list of the GPOs linked to the domain take precedence.
  3. Site GPOs, those higher on the list of the GPOs linked to the site take precedence.
  4. Local GPO (LGPO).

Figure 9: GPO Order of Precedence

WMI filtering allows you to refine the scope of computers that will be affected by a GPO. You define a filter using the WMI Query Language (WQL), you create one in GPMC by right-clicking on the WMI Filters container and selecting New. Enter a name and description for the filter, then click Add to enter one or more filters in WQL. Click Save. Now you apply the filter to a GPO link by selecting the link and choosing the desired filter from the dropdown list that is visible at the bottom of the window as shown in figure 10.

Figure 10: Choosing a WMI Filter

Tip: I doubt that the exam will include questions about WQL syntax, but WMI filters can be very useful in production deployments. For example, if you had a GPO that you only want to apply to computers running the release-to-manufacturing build of 32-bit version Windows Vista you would use the following WQL syntax: select * from win32_OperatingSystem where Version = "6.0.6000" AND OSArchitecture = "32-bit". Incrementing the version by one, to 6.0.6001, would cause the filter to only apply to Windows Vista with Service Pack 1. Microsoft published a useful tool with tips on creating WMI scripts several years ago called Scriptomatic. Using Scriptomatic and links to other resources included in the Scriptomatic documentation should give you a solid base for creating your own WMI filters.

Exceptions to processing order can be implemented using enforced, block inheritance, and loopback processing. To block inheritance for an OU right-click on it and then click Block Inheritance, this will cause GPOs from higher levels of the hierarchy to be ignored. To enforce a GPO link you right-click on it and then click Enforced. This causes the GPO to be applied regardless of how block inheritance is configured in child OUs.

Loopback processing is a little more complex. Normally a user’s policy settings are applied when they log into a computer, loopback processing forces the same settings to be applied to a computer regardless of who has logged on. To configure this open the GPO in the GPO editor by right-clicking on it in GPMC and selecting Edit Navigate to Computer Configuration\Policies\Policies\Administrative Templates\System\Group Policy and double-click user group policy loopback processing mode. Select Enabled, then specify which mode from the drop down list. Replace mode causes the user account GPOs to be completely disregarded while Merge mode causes the user account settings to be applied but overridden by and conflicting computer account settings. Loopback processing is designed to help lock-down special purpose computers such as publicly accessible kiosks or classroom systems.

Perhaps an example will help you to see how you can leverage these characteristics of group policy. Microsoft recommends that you configure users and computers based on role. Figure 11 shows how you might apply this in practice by looking at a portion of the hierarchy presented in figure 8. Note how unique GPOs are applied to the OUs for each type of server, and that those containers will also inherit policy settings from the parent OU, servers, and the root of the domain. Microsoft also recommends that you don’t modify either of the built-in GPOs, Default Domain Policy and Default Domain Controller Policy, but instead create new GPOs with higher precedence where you maintain your custom settings for the DC container and the root of the domain. With this approach you can recover from certain types of mistakes by disabling your custom GPO and allowing the default GPOs to be applied.

Figure 11: A Group Policy Design Based on Server Role

Creating and Applying Group Policy Objects

There are a couple of ways you can create a new GPO using GPMC. You can right-click on the container where you want to apply the GPO, such as the domain root or OU, and select Create a GPO in this domain, and link it here. Alternatively, you can right-click on the Group Policy Objects container and click New. In either case, you will be prompted to provide a name for the GPO, and a start GPO to use for creating the new one. You can link an existing GPO to one or more containers by right-clicking each container and selecting Link an Existing GPO. You are then able to select one or more GPOs from the list of available ones from the Select GPO dialog box. The GPMC interface has similarities to Active Directory Users and Computers in that a navigation tree with domains and OUs is visible on the left, but there are also important differences. By expanding containers you can see child containers and other objects. Figure 12 highlights several, for example: GPO links are represented by an unrolled scroll of paper with a small arrow on the lower left corner; GPOs are all visible in the Group Policy Objects container and they are represented by an unrolled scroll of paper. WMI filters are visible in the WMI filters container, they are represented by a scroll of paper passing through a funnel. You can also see links to Sites, Group Policy Modeling, and Group Policy Results in the navigation tree. You can make sites visible and link existing GPOs to a site using the Sites container. Right-click on Group Policy Modeling, and Group Policy Results to launch their respective wizards. The former allows you to do a ‘what if?’ analysis of group policy by testing what would happen if you change security filtering, group membership, and other characteristics. The later allows you to see what settings are actually in effect when a specific user logs onto a specific computer. If you specify a remote computer that computer has to available with the WMI service running.

Figure 12: Elements Visible in the GPMC Interface

Command Prompt Tools

Gpupdate is used to force a background refresh of policies on a computer, this is useful if you have just made changes to the GPOs that apply to a user or computer and you want to ensure the new settings are applied immediately. However, many user settings require the user to log off and log on again before they will take effect and many computer settings will not take effect until you reboot the computer. Gpupdate will ensure the settings are applied to the registry, but it is not able to guarantee that the components affected by the settings will implement them. This is why you may periodically see instructions relating to changing group policy that conclude with rebooting the target computer twice, the first time to download the updated GPOs and apply them to the registry, the second time to cause the new registry settings to take effect. This is the syntax for the tool:

GPUpdate [/Target:{Computer | User}] [/Force] [/Wait:<value>] [/Logoff] [/Boot] [/Sync]

All of the parameters are optional:

  • /Target:; {Computer | User} – Limits the refresh to only the user or computer settings, by default both are processed.
  • /Force – Reapplies all settings, by default only new or altered ones are applied./Wait:; {value} – Specifies how long to wait, in seconds, for processing to complete. The default is 600 seconds, when the limit is reached the command prompt returns but processing continues in the background.
  • /Logoff – Forces the user to logoff after the settings have been updated, which is useful if you want to ensure any changes to the user’s settings take effect immediately. This has no effect if no extensions that require a logoff have been changed. /Boot – Forces the computer to reboot after the settings have been updated. This has no effect if no extensions that require a reboot have been changed.
  • /Sync – Causes the next foreground policy application, that is, when the computer boots or a user logs on, to be performed synchronously

Gpresult displays the Resultant Set of Policy (RSoP) for the specified user and computer.

GPRESULT [/S system [/U username [/P [password]]]] [/SCOPE scope] [/USER targetusername] [/V | /Z]

All of the parameters are optional, if none are provided then the RSoP for the current user on the same computer are generated:

  • /S; system – Specifies a remote computer, otherwise the local computer is used.
  • /U; username – Specifies the account under which the command should run, otherwise the credentials of the currently logged on user are used.
  • /P; password – Specifies the password for the alternate account.
  • /SCOPE; USER, COMPUTER – Specifies whether to display the user or computer settings, otherwise both are presented.
  • /USER; targetusername – Specifies the user account for who to process RSoP, otherwise the currently logged on user is used.
  • /V – Forces the display of verbose information.
  • /Z – Forces the display of super-verbose information.

Dcgpofix is another command prompt utility, its purpose is very focused: regenerate the two default GPOs with their original settings. It cannot backup or restore GPOs, it simply replaces the current Default Domain Controller Policy and Default Controller Policy with new ones that contain the settings that were present immediately after the installation of the first DC in the domain. The syntax is simple, both parameters are optional:

DcGPOFix [/ignoreschema] [/Target: Domain | DC | BOTH]

/ignoreschema – Forces the utility to proceed even if the versions of the schema supported by the tool and present in the domain differ. By default the process fails when the schema versions do not match.

/Target:; Domain | DC | BOTH] – Allows you to specify which GPO to generate, by default both are processed.

Backing Up, Restoring, Copying, and Importing GPOs

GPMC includes backup and restore features because customers found performing authoritative restores too cumbersome when they merely wanted to undo mistakes made when editing group policies. Backing up allows you to save a copy of the settings and compontents contained within a GPO to the file system. Restoring allows you to restore a backed up GPO to the same domain. Copying allows you to copy a GPO from one domain to another when the domains can communicate directly. Importing allows you to copy a GPO from one domain to another when the two domains cannot communicate directly, which is useful when moving GPOs from a test and production environment to a production network.

To backup all of the GPOs in the domain right-click on Group Policy Objects in the navigation tree and select Back Up All. You will be prompted to provide a location and description for the backup. You must have read permissions on the GPOs and write permissions on the destination folder in order to complete the backup. To backup a single GPO right-click on it and select Back Up, you will be prompted to provide a location and description for the backup.

To restore a single GPO to a previous version right-click on the GPO in GPMC and select Restore from Backup. You will be prompted to provide the location of the backup, then you will be shown a list of GPO backups available in that location you can select any on the list and complete the wizard. To restore a deleted GPO right-click on Group Policy Objects, click Manage Backups, click Browse to navigate to the backup location, select the GPO to restore, and then click Restore.

To import settings from a GPO backed up in a different domain right-click on the GPO where you want to apply the settings and select Import Settings. Complete the Import Settings Wizard. To copy a GPO right-click on it, select Copy, and then do one of the following:

  • Right-click on Group Policy Objects in the same domain and click Paste. You will be prompted to specify whether to use the default permissions or retain the existing ones.
  • Right-click on Group Policy Objects in a different domain and click Paste. to complete the copy process.

Some of the data stored in a GPO is domain-specific, you can use a migration table to convert references from the original domain to values appropriate for the destination domain. To manage the migration tables right-click on Group Policy Objects, click Open Migration Table Editor, and enter source and destination pairs for each value that you want to convert. You can specify which migration table to use while completing the Import Settings Wizard or the copying wizard.

Introducing Group Policy Preferences

Windows Server 2008 includes support for a new feature called group policy preferences. Many new extensions are available that allow you to manage a much greater range of settings using GPOs including Control Panel settings, mapped drives, folder options, and Start menu settings. Another advantage of preferences is that while the system administrator can implement a setting users are still able to modify them, which gives you new flexibility in deciding what users are allowed to change on their computers.

You can learn more about preferences by reading the following Knowledge Base article that includes links to downloadable extensions for older versions of Windows: Information about new Group Policy preferences in Windows Server 2008. You can learn even more by reading Group Policy Preferences Overview.

Configuring Group Policy Settings

There are nearly 3,000 settings that you can configure in a Windows Server 2008 GPO. If you use group policy to manage the Office 2007 productivity suite there are 1,000 more settings. I do not think that you need to memorize the locations of all of these settings but you should be familiar where to find different types of settings. For example, look at figure 13, it shows the settings that are applied to computers. This interface probably looks overwhelming the first few times you edit a GPO, there are scores of containers in the navigation tree on the left, each of which includes child containers and up to several dozen configurable settings. Note some of the key sections that are likely to arise on the exam, starting at the top of the list: software settings section, account policies, local policies, restricted groups, and administrative templates.

Figure 13: Editing the Computer Configuration Section of a GPO

Now look at figure 14, which illustrates the settings that are applied to users. It is similar to the computer configuration section, but there are many differences. There are numerous settings that can only be applied to the computer itself, these settings are not visible in the user configuration section. There are many other settings that only make sense to apply to a user, these settings are only available in the user configuration section. The key sections are software settings and administrative templates.

Figure 14: Editing the User Configuration Section of a GPO

There is not enough space in this book to document every single setting, nor would it be a sensible investment of your study time to try to memorize all of them. Instead, you should be familiar with the way different classes of settings behave. You will encounter some odd language in the group policy editor, and some behavior that seems contradictory. The Microsoft team responsible for developing and supporting group policy has tried very hard to make the management tools more intuitive and easier to use but they have to build on top of technology that is nearly ten years old, and they have to maintain backwards compatibility. In other words, some of this strangeness can be traced back to before the release of Windows 2000, but rather the System Policy Editor tool available for Windows NT 4.0.

Configuring User Rights

User rights determine what privileges an account is able to perform on a computer. For example, the Allow log on locally right is required in order to be able to log on at the local console while the Deny log on through Terminal Services right can be granted to an account to ensure that it is unable to connect to the computer via Terminal Services or Remote Assistance regardless of what other privileges and permissions the account may have. To open the properties dialog box for a user right in a group policy navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights in the Group Policy Object Editor and double-click on the desired policy. To remove an account or group select it and click Remove. To add one click Add User or Group, enter the name in the Enter the object names to select and click OK. You can see information about the setting by clicking the Explain tab.

As you can see, configuring user rights is not complex, however some of the rights are critically important and you should understand what the implications of having or not having them are. Be sure to examine the explanation text as described above before modifying any user rights. Here’s a list of those that I think are the most important:

  • Access this computer from the network – If you fail to grant this right to legitimate users then they will not be able to access shared resources on the server. If this is misconfigured on the DC users will not be able to log onto the domain. On the other hand, granting this right too liberally could result in nefarious individuals gaining access to private information.
  • Allow log on locally – If you fail to grant this right to the appropriate users they will be unable to log onto the local console or to connect via Terminal Services, however, granting this right too liberally may enable malicious users to gain more access to systems than they should.
  • Bypass traverse checking – This right often confuses people, it allows users to browse through folders even if they don’t have read access to them. This makes it possible for users to access subdirectories on which they do have permissions even if the parent directories are inaccessible. This does not allow users to view the contents of the folders they are traversing. Removing this right will lead to all sorts of problems because Windows and many applications assume that users have this right.
  • Deny… – There are several ‘Deny…’ privileges that are useful when you want to be absolutely certain that specific users and groups cannot exercise a particular privilege, however granting these rights too aggressively will cause users to be unable to access resources that they require. I remember working with one customer who wanted to protect their DCs by granting Deny access to this computer from the network to the Domain Users group, even administrators were blocked from logging into the domain because the ‘Deny…’ user rights take precedence over all others.

Act as part of the operating system, Debug programs, Restore files and Directories, and Take ownership of files or other objects can all be used to take complete control of the computer, granting these rights to users is virtually the same as making them members of the Domain Admins group on DCs and the Administrators group on other systems. Other user rights can be abused to cause a denial-of-service condition or to gain access to data belonging to different users. Misconfiguring rights can make it impossible for users to access resources or undermine your efforts to protect your organization’s business information.

Tip: The properties dialog box for the rights that have the greatest potential to cause problems include a link to a Microsoft Knowledge Base article that can be very useful when troubleshooting issues related to user rights and other security settings. I was working at Microsoft five years ago when I was asked to help review and edit the article, its been expanded and improved upon since then. Its called Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments.

Configuring Security Options

To configure a security option in a group policy navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Option in the Group Policy Object Editor and double-click on the desired policy. Many of them are simple, you click the Define this policy setting and then select Enabled or Disabled. Some include a drop-down list from which you can select a value. Many require you to enable a checkbox and then enter a text string, for example, you must do this when you want to rename the guest or administrator accounts. The settings that most frequently lead to problems include a link to the Microsoft Knowledge Base article referred to in the Tip above. Some settings require you to enter a text string that might not be so simple, for example, consider DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax. The title alone should make you uncomfortable, and if you are one of the 12 people on Earth who actually know what SDDL is you are indeed terrified by the setting. Look at figure 15, what at first glance may appear to be encrypted information is SDDL, the language used to define permissions in security templates and many other places. Fortunately, you don’t need to learn SDDL to modify this setting, clicking the Edit Security button allows you to set permissions with an easily understood dialog box, which is converted to SDDL when you close that dialog box.

Figure 15: Configuring DCOM Security in Group Policy.

A couple have unique behavior in that they require you to first enable the Define this policy setting checkbox and then enable additional checkboxes in what looks like a text box, take a look at Network security: Minimum session security for NTLM SSP based (including secure RPC) clients to see what I mean. The most complex to configure are those that include a large text box where you enter data after enabling the setting, Network access: Remotely accessible registry paths and sub-paths is a good example, as shown in figure 16. If you do not properly format the text the setting will not be applied correctly. If you block access to paths that some applications use those applications may fail to operate as expected. When you enable the checkbox for this setting for the first time you can see the default values, but you may not have any idea what some of these registry paths are used for. Before you edit this or any other setting do some research and make sure you understand what it does, then test the behavior in a lab before implementing them in a production environment.

Figure 16: Configuring Remotely Accessible Registry Paths.

There are dozens of settings available in the Security Options section, I want to highlight a few:

Audit: Shut down system immediately if unable to log security audits – Enabling this setting is very risky because the computer will shut down and stay offline if the event logging subsystem fails for any reason. If you need to ensure that audit events are reliably recorded due to regulatory requirements its far better to use an enterprise management tool that automatically copies logs for managed servers to a central database.

Domain member: Require strong (Windows 2000 or later) session key and Domain member: Digitally encrypt or sign secure channel data (always) – Enabling either of these settings will break authentication with DCs and domain members running older versions of Windows and many third-party systems that rely on Windows authentication. However, if your computers will support these settings by all means use them as they help to protect communication between member computers and the DCs.

Microsoft network client: Digitally sign communications (always) and Microsoft network server: Digitally sign communications (always) – Enabling these two settings forces the Server Message Block (SMB) protocol to encrypt communications, SMB is the bases for network basic input/output system (NetBIOS), file sharing, and many other Windows features so enabling it may cause these features to fail with computers running very old versions of Windows as well as some third-party products. You should enable these settings if your environment supports them.

Network security: Do not store LAN Manager hash value on next password change – Ideally you will leave this setting enabled, LAN Manager hashes are not very secure and there are websites and downloadable tools that make identifying the original password by examining the hash easy. However, older versions of Windows and many non-Windows platforms require LAN Manager hashes for authentication.

Network security: Lan Manager authentication level – In my opinion, this is one of the most complicated security settings because there are six possible values and certain configurations will break authentication with down-level clients. The six values offer various combinations of three authentication levels. LAN Manager (LM) is a very old technology developed by IBM and supported in Windows for nearly 20 years, its no longer considered a secure authentication protocol and should be avoided. NTLM was introduced in Windows NT 3.5, although its more secure than its predecessor it too has documented issues. NTLM version 2 (NTLMv2) is the most secure of the three, it was introduced in Windows NT 4.0 Service Pack 4. Kerberos has been the primary authentication protocol since Windows 2000, however this setting comes into play when Kerberos is not used, such as wen the client authenticates to a server using an IP address, to a server in a different forest, to a server that isn’t in a domain, or when the network ports used by Kerberos are blocked by a firewall. Use the most secure value that your environment can support.

System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing – I find it tremendously frustrating that enabling this setting causes people so many problems. Enabling this setting forces Windows to use stronger encryption algorithms, however these publicly available algorithms have been around for many years. The problem is that many websites that require encrypted communications using Secure Socket Layers (SSL) and Secure Hypertext Transfer Protocol (HTTPS) do not have the protocols enabled. The more secure protocols are probably available on those web servers but the system administrator has not enabled support for them. Enable this setting if feasible, but be prepared for complaints from users who can no longer connect to their banking, gambling, and other secured websites.


A Brief History of Security Guidance for Windows

Various organizations have published security guidance for Windows over the past ten years. The first I encountered was a guide on locking down Windows NT 4.0 written by some brilliant people at the U.S. National Security Agency (NSA), we used it as a basis for locking down Windows-based web servers at a job I held before arriving at Microsoft. While working at Microsoft I helped to create the security guides for Windows 2000 Server, Windows XP, and Windows Server 2003. We collaborated with several U.S. agencies including the NSA, the Defense Information Systems Agency (DISA), and the National Institute of Standards and Technology (NIST), and the non-profit organization the Center for Internet Security (CIS). The goal was for Microsoft to help ensure that their guidance reflected what we knew about the platform and that ours included information that they had learned from helping the military and civilian branches of the government to deploy millions of computers around the world. The effort was beneficial to everyone.

Everyone shared information about problems caused by recommendations included in the current guidance as well as older ones. Some of the recommendations, including suggestions that I wrote, caused unpleasant and surprising side effects. When we learned about these issues we either changed the recommendation or clearly documented what the impact may be if you implement it. Many organizations from all over the world used and continue to use these security guides, when problems come up people tend to contact Microsoft so about four years ago we realized that a publicly available document summarizing the settings that tended to cause the most problems would help people to troubleshoot and resolve problems more quickly. We wrote a detailed article, Security configuration guidance support. The product support team at Microsoft periodically updates this article to ensure that remains accurate and relevant. If you decide to, or are required to implement security guidance you may also find this article to be helpful.


Configuring Restricted Groups

Restricted groups are often used to ensure that only authorized administrators are members of the local Administrators group. You can specify domain and local accounts when you define membership for a group, any changes made locally will be overwritten the next time group policy refreshes. To implement restricted groups do the following:

  1. Using the Group Policy Object Editor navigate to Computer Configuration\Policies\Windows Settings\Security Settings.
  2. Right-click Restricted Groups and select Add Group.
  3. Enter the name of the local group or click Browse to select a group, then click OK.
  4. Specify what users and groups are members of the group in the top half of the properties dialog box and specify what groups this group belongs to in the bottom half by clicking the appropriate Add button.
  5. Enter the name of the user or group; or click Browse to select them, then click OK twice.

Configuring Administrative Templates

There are both computer and user administrative templates, which appear in the Group Policy Object Editor at Computer Configuration\Policies\Administrative Templates and User Configuration\Administrative Templates. There are far too many settings to in these sections to examine them individually. You should browse through both of these sections to get an idea of what settings are available and how they are organized. The user interface for some settings is quite strange though, for example, navigate to Computer Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Internet Zone and double-click on Access data sources across domains as shown in figure 17. This setting illustrates a weird design decision, first there are three radio buttons, if you select Enabled you then can select Disabled, Enabled, or Prompt. What the heck does configuring it as enabled\disabled mean? The text available on the Explain tab doesn’t clarify what the difference is between disabled and enabled\disabled, in my experience, there is no difference. I believe that the decision to set up these settings in this manner was made by the Internet Explorer 6.0 development team though, no need to blame the group policy team!

Figure 17: Configuring Access data sources across domains.

Some settings are complex primarily because they are very flexible, navigate to Computer Configuration\Policies\Administrative Templates\Network\Network Connections\Windows Firewall\Domain Profile, double-click on Windows Firewall: Define Inbound port exceptions, click Enabled, then click Show. If you click Add you can enter any string of text you please, if you make a mistake you will not be warned, so you have to understand the syntax required for this data. The syntax is documented in the properties dialog box for the setting, if you understand TCP/IP and port filtering firewalls it shouldn’t be too difficult. By the way, the settings in this section only apply to the Windows XP version of the Windows Firewall, in order to configure the firewall built into Windows Vista and Windows Server 2003 you need to navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security. Although this may not be intuitive, it was necessary to establish a new location for managing the new firewall because it’s a fundamentally different piece of technology yet it was also necessary to retain the old group policy settings to enable management of Windows XP computers from systems running Windows Server 2008 and Windows Vista. Other settings offer several checkboxes or drop down lists when you enable them, for example, look at Registry policy processing under Computer Configuration\Policies\Administrative Templates\System\Group Policy.

Creating Starter Policies

Windows Server 2008 supports Starter GPOs, these are analogous to a document template that you might use in a word processor. You can define administrative template policy settings in a starter GPO, when you create a new GPO you can select one of your starter GPOs as the foundation. To use this feature select Starter GPOs in the navigation pane of the GPMC, then click Create Starter GPO folder. Now right-click on Starter GPOs and select New. Specify a name and description then click OK Now you can edit your new starter GPO in the same way you edit other GPOs, with the limitation of only being able to define administrative template policy settings.

Managing Storage of GPO Data Files

Versions of Windows prior to Windows Vista used several administrative template (ADM) files to expose registry settings in the Group Policy Editor. ADM files are stored in the SYSVOL folder and replicated between all of the DCs. Each GPO is about 2 megabytes in size, most of this due to the inclusion of the ADM files. These have been replaced with XML-based ADMX files that, by default, are stored in %systemroot%\PolicyDefinitions. For each ADMX file there is a corresponding ADML file in %systemroot%\PolicyDefinitions\%locale%, these are language-specific files that contain localized text for the setting name and explanation next. Windows Vista or Windows Server 2008 can use a Central Store to store the ADMX files, rather than store copies of them in each GPO. To enable this capability open the following folder in Windows Explorer while logged into the PDC emulator: \\FQDN\SYSVOL\FQDN\policies. Create a new folder called PolicyDefintions. Copy all of the files and the subdirectory from %systemroot%\PolicyDefinitions to the new folder. If you need to support additional locales not enabled on the PDC copy the appropriate subdirectories from %systemroot%\PolicyDefinitions on systems running Windows Vista or Windows Server 2008 that have those locales enabled to this new folder on SYSVOL..

Note: Group policies store the settings you define in the Administrative Templates and many other sections in .pol files. Some settings are defined in .inf files, typically referred to as Security Templates. Security Templates have been around since Windows NT 4.0, and they are fundamentally different from Administrative Templates. They continue to be supported for backwards compatibility, and some developers find it easier to implement a setting using the Security Templates portion of group policy. Account policy, audit policy, user rights, security options, restricted groups, event log settings, system service settings, file system permissions, and registry permissions are all stored in Security Templates. The appearance of these portions of the Group Policy Editor are partially hard-coded into the application, but most are defined with a series of registry keys located at: HKLM\Software\Microsoft\Windows NT\CurrentVersion\SeCEdit\Reg Values.

Using Group Policy to Deploy Software

You can leverage group policy to automatically distribute and install software packages to specific users and computers. This method typically relies on the Windows Installer, and applications are packaged as a Microsoft software installation package file (.msi file). Applications can be published or assigned to users and assigned to computers. Publishing a package advertises it to a user at their next logon. Assigning an application to a user means the application will be automatically installed, however you have some control under what conditions the installation occurs. Assigning an application to a computer means that the application is fully installed the next time the computer boots. You should copy the installation packages to a network share accessible to the users and computers that will be receiving them such as the SYSVOL share. To add a package using the Group Policy Editor do the following:

  1. Navigate to User Configuration\Policies\Software Settings, if you were creating a package for computers you would navigate to Computer Configuration\Policies\Software Settings.
  2. Right-click on Software installation, select New, then select Package.
  3. Use the File selection dialog box to select the installation package and click Open.
  4. You can select Published, Assigned, or Advanced, in this case select Published and click OK. If the package were targeted at computers Published would not be available.
  5. Right-click on the new package and select Properties.
  6. Click on the Deployment tab, you should see a dialog box similar to figure 18.

Figure 18: Specifying Deployment Options for an Installation Package.

  1. You can change the Deployment type from Published to Assigned, if the package were targeted at computers then Published would not be available.
  2. You can change the Deployment options by selecting and deselecting one or more of the options.
    1. Auto-install this application by file extension activation means that the application installation will commence when the user opens a file with an extension supported by that application. This option is automatically enabled when an application is assigned to either a user or computer.
    2. Uninstall this application when it falls out of the scope of management forces the application to be removed if something happens to take the user or computer out of scope of the group policy.
    3. Do not display this package in the Add/Remove Programs control panel hides the application from the Programs and Features tool in Control Panel. Why the naming discrepancy? I think somebody forgot to update the dialog box in group policy. This option is not available when applications are assigned to computers.
    4. Install this application at logon forces the application to install the next time the user logs on. This option is only available when the application is assigned, its not available when applications are assigned to computers.
  3. The Upgrades tab is only relevant when you are updating an existing package, you can create a link from the new version to the older package.
  4. The Modifications tab is only relevant if you are creating custom packages using a transform file (.mst file). The easiest way to do this is with a software packaging tool.
  5. You can uninstall software from managed clients by removing them from the scope of the GPO if you enabled Uninstall this application when it falls out of the scope of management. You can also remove software as a preliminary step when deploying a newer version. Finally, you can right-click on a package, select All Tasks, then select Remove. You will be asked to specify whether to immediately uninstall the package or to allow users to continue to use it but prevent additional installations.

Note: While many vendors provide installation packages in this format you will probably have to repackage software yourself using a software packaging tool. Acquiring and using such tools is beyond the scope of the exam and this book.

Configuring Account Policies

Setting account and password policies is quite easy, in the Group Policy Editor navigate to Computer Configuration\Policies\Windows Settings\Security Settings and then open either the Password Policy or Account Lockout Policy folder. There are only 9 settings total, how easy can it get? Well, I am disregarding the Kerberos Policy folder because most of us will never have to change the default values. The account policies are domain-wide, if you want to change the default settings for a domain you should create a new GPO, link it to the domain root, and give it higher precedence than the Default Domain Controller Policy. Wait, what about fine-grained password and account lockout policies? I’ll get to that in a moment.

You should understand what the purpose is of each of the six password policy settings. You should also recognize that some of these settings are impacted by others, for example, the Maximum password age must be greater than the minimum. Also, enabling Password must meet complexity requirements means that passwords must be at least 6 characters long, even if the minimum password length is not configure, or set to a value lower than 6. Although not necessary for the exam, you should also think about your users before implementing tougher password policies, if the minimum length is very long most users will have trouble remembering their passwords and they may resort to writing them down. Forcing them to change their passwords more than once every few weeks also tends to upset users.

Account lockout policy allows you to temporarily disable an account when the user has repeatedly provided an incorrect password. This is helpful when it comes to keeping malicious users from guessing user passwords, but configuring these settings too restrictively will annoy users and generate additional support calls. If you enable account lockouts you should also enable Reset account lockout counter after so that users can eventually log on even if there is no support personnel available to assist them. If you are very concerned about attackers guessing passwords you should automatically monitor failed logon attempts using an enterprise management tools so that an administrator can dynamically respond to the situation.

AD DS domains running at a Windows Server 2008 functional level support what Microsoft calls fine-grained password and account lockout policy. Two new types of objects are available: the Password Settings Container (PSC) and Password Settings Objects (PSO). The PSC is created in the system container for the domain automatically, however you create PSOs using ADSI Edit or by importing LDIF files. To create a PSO using ADSI Edit do the following:

  1. Navigate to DC=<domain_name>\CN =System\ CN=Password Settings Container.
  2. Right-click on CN=Password Settings Container, select New, then select Object.
  3. Verify that msDS-PasswordSettings is selected in the Create Object box, click Next.
  4. Enter the name for the PSO and define each of the values that you wish to implement, as defined in Table 2.
  5. The PSO will apply to users and global groups specified for the msDS-PSOAppliesTo variable, as a list of distinguished names.

Name

Description

Valid values

msDS-PasswordSettingsPrecedence

PSO precedence

Greater than 0

msDS-PasswordReversibleEncryptionEnabled

Specifies reversible encryption for passwords

FALSE / TRUE (Recommended: FALSE)

msDS-PasswordHistoryLength

Password history length

0 through 1024

msDS-PasswordComplexityEnabled

Specifies password complexity

FALSE / TRUE (Recommended: TRUE)

msDS-MinimumPasswordLength

Minimum password length

0 through 255

msDS-MinimumPasswordAge

Minimum password age

·         (None)

·         00:00:00:00 through msDS-MaximumPasswordAge value

msDS-MaximumPasswordAge

Maximum password age

·         (Never)

·         msDS-MinimumPasswordAge value through (Never)

·         msDS-MaximumPasswordAge cannot be set to zero

msDS-LockoutThreshold

Account lockout threshold

0 through 65535

msDS-LockoutObservationWindow

Observation Window for lockout

·         (None)

·         00:00:00:01 through msDS-LockoutDuration value

msDS-LockoutDuration

Lockout duration for locked out accounts

·         (None)

·         (Never)

·         msDS-LockoutObservationWindow value through (Never)

msDS-PSOAppliesTo

Links to objects that this password settings object applies to (forward link)

Distinguished names of users or global security groups

Table 2: Valid PSO parameters.

Once created you can also configure the PSO in Active Directory Users and Computers:

  1. Open the View menu and make sure that the Advanced Features option is enabled.
  2. Navigate to \%domain_name%\System\Password Settings Container, right-click on the PSO and select Properties.
  3. Click the Attribute Editor tab, select an attribute from the list, and click Edit to change it.
  4. Click OK when finished.

Configuring Audit Policies

You can configure audit policies the same way you did in Windows Server 2003, enabling auditing for various classes of events and objects. Every large government agency or commercial enterprise I spoke to the last 4 years I was at Microsoft asked for the ability to fine tune auditing, they did not want their security event log to be full of useless information but only the events that were important to their organization. There were other problems with the pre-Vista event logging subsystem too, it loaded all of the logs into physical RAM, and if there wasn’t enough RAM data was lost without any indication that there was a problem. In Windows Vista and Windows Serer 2008 the entire system was rewritten from the ground up, its faster and more scalable by far. The latest versions of Windows also support more refined settings for security auditing, we will take a look at how you can implement them with a command prompt tool called auditpol.

Since audited events are logged to the event logs you should know how to configure group policies relating to the event logs. To modify event log settings for a GPO in the Group Policy Editor navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Event Log. There are four settings for each of the three logs: application, security, and system. You can specify a size for the logs by double-clicking Maximum log_name log size. There is no optimum size for every system, what is best for a particular server will depend upon how many events are logged per day, whether events are forwarded to an enterprise management system, and other factors. The Prevent local guests group from access… settings are only relevant to pre-Vista versions of Windows. The other two settings are interdependent. If you configure Retain log_name then you need to configure the corresponding Retention method for log_name log to Overwrite events by Days. Most organizations configure the retention method to Overwrite events as needed, which allows the logging subsystem to overwrite the oldest events with the newest when the maximum log size is reached. The potential issue with this configuration is that important information may be lost, yet another reason to collect event log data centrally. The last option for retention is Do not overwrite events, some organizations use this configuration because they can be certain that old events will not be lost, however there is still risk of losing data because new events will not be recorded if the maximum size is reached. If you choose this configuration is extremely important that you implement an effective process to clear the logs periodically.

To modify audit settings for a GPO in the Group Policy Editor navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy. There are nine classes of events, you can enable failure and success logging for each. Be prudent when enabling auditing beyond the default settings, if you turn on too many classes of events your security log will be full of useless information and it will be very difficult to focus on what is important.

  • Audit account logon events – Determines whether to record an event each time the computer authenticates an account that is logging onto or off of another computer. This occurs when a user logs onto a domain, this event will be recorded on the DC that validates the user’s credentials.
  • Audit account management – Determines whether to record an event on each occurrence of account management. This means every time an account is created, changed, deleted, disabled, enabled, or has its password changed.
  • Audit directory service access – Determines whether to record an event when a user accessing an AD DS object that has its system access control list (SACL) specified. This event will only be recorded on DCs.
  • Audit logon events – Determines whether to record an event each time a user logs onto or off of the computer.
  • Audit object access – Determines whether to record an event when a user accessing file system, registry or other object that has its system access control list (SACL) specified.
  • Audit policy change – Determines whether to record an event each time there is a change to user rights assignment, audit policies, or trust policies.
  • Audit privilege use – Determines whether to record an event each time a user exercises one of their user rights. Several rights will not generate events even if this is enabled: bypass traverse checking, debug programs, create a token object, replace process level token, generate security audits, backup files and directories, and restore files and directories.
  • Audit process tracking – Determines whether to record an event when things such as program activation, process exit, handle duplication, and indirect object access occur.
  • Audit system events – Determines whether to record an event when the computer starts up, shuts down, or some other system-wide event occurs.

Tip: A word about SACLs is warranted. If you are an experienced Windows systems administrator then you understand that after enabling either Audit object access or Audit directory access you then have to configure audit settings on the objects you want to monitor. You do this by right-clicking on the object, selecting the Security tab, clicking Advanced, then clicking the Auditing tab on the Advanced Security Settings dialog box. Then you click the Edit button followed by the Add button to select accounts and groups. Finally, you are presented with a list of access events that you can monitor, both for successful and failed attempts to access the object.

Auditpol was introduced in Windows Vista, it’s a command line tool for tuning what events are logged at a much more refined level than what you can do with the group policy settings described above. There are many options available, an in-depth look at the syntax would consume many pages and its beyond the scope of the exam and this book. Nevertheless, you may find it valuable to learn how to use this tool and to start using it in your own enterprise. Although these fine-grained audit settings are not configurable through group policy, you could write scripts using auditpol and distribute them via group policy. To get a taste of its potential enter Auditpol /get /category:* at a command prompt, you will see a complete list of all of the subcategories that you can control with this utility. For example, you can more precisely control what types of logon/logoff events are recorded by disabling auditing for IPSec events or other subcategories.

Summary

This chapter presented you with about creating and managing AD DS objects including computer accounts, user accounts, groups, OUs, and GPOs. Creating an OU hierarchy to support organizing and managing objects was briefly discussed. A lot of detail about using group policies to configure settings and deploy software was also provided. Group policy is such a large subject that I strongly encourage you to thoroughly explore the GPMC and the Group Policy Editor, experimenting with various settings and seeing what the impact is on users.

Chapter Review

This section presents a list of review questions designed to help reinforce the knowledge presented earlier in the chapter. To persuade you to explore the management tools more deeply a few questions may require you to examine those tools further rather than rereading the chapter.

Questions

  1. Which of the following is a task that you cannot delegate using the Delegation of Control Wizard?
    1. Managing user accounts.
    2. Resetting user passwords.
    3. Managing a group.
    4. Managing group policy links.
    5. Managing the schema.
  2. Which of the following is not a valid distinguished name?
    1. cn=AppCategories,cn=Default Domain Policy,CN=System,DC=Dillard,DC=test
    2. cn=Eric,dc=dillard,dc=test
    3. cn=Kristin, ou=corp, dc=dillard, dc=test
    4. cn=files,cn=servers,dc=dillard,dc=test
    5. cn=Kurt Dillard,OU=HQ,dc=dillard,dc=test
  3. After successfully creating Tony’s account using the command shown in the previous question he tells you that he’s unable to log onto the  network. Why would that be the case?
    1. Tony’s password was marked as expired when the account was created, you will have to set a new password for him.
    2. Tony must have exceeded the account lockout threshold and caused his account to be locked by AD DS.
    3. Since the account was recently created Tony needs to reboot his client computer so that the computer can refresh its cached accounts list from the DC.
    4. You forgot to specify a password using the pwd parameter with dsadd, when you do this the account is created by automatically disabled.
    5. Tony is probably trying to log into the wrong domain.
  4. You create a new group using the following command, yet after doing so you are unable to assign permissions to this group on a member server. When you attempt to assign permissions to this group you receive a “Name not found” error message, why?

dsadd group cn=Exec,cn=users,dc=dillard,dc=test -samid Exec -secgrp no -scope g

    1. The data for the new group has not replicated throughout the domain yet.
    2. You created a distribution group which means the group has no security identifier associated with it and therefore cannot be used to assign permissions. You need to create a security group instead, or convert the group to a security group.
    3. You created a global group but only local groups can be used to assign permissions on member servers.
    4. You created a global group but only domain local groups and local groups can be used to assign permissions on member servers.
    5. You created the group in the users container but it needs to be in the same organizational unit as the server.
  1. Which of the following is the recommended method for assigning permissions to resources?
    1. Place user accounts into global groups and then assign permissions to the global groups on the shared resources.
    2. Place user accounts into global groups, add global groups into domain local groups, and then assign permissions to the domain local group on the shared resources.
    3. Place user accounts into global groups, add global groups into universal groups, and then assign permissions to the universal groups on the shared resources.
    4. Place user accounts into universal groups, add universal groups into global groups, and then assign permissions to the global groups on the shared resources.
    5. Place user accounts into universal groups and assign permissions to the universal groups on the shared resources.
  2. What would be the easiest way to make sure that a GPO only applied to computers running Windows XP with Service Pack 2 if the computers were located in an OU with computers running other versions of Windows?
    1. Create a WMI filter for Windows XP with SP2 and apply it to an OU so that only computers running Windows XP with SP 2 will be placed in the OU.
    2. Write a script that checks the version of Windows on each computer in the OU and adds those running Windows XP with SP 2 to a global group, configure permissions on the GPO so that it only applies to that global group and link the GPO to the OU containing the computers.
    3. Create a WMI filter for Windows XP with SP 2 and apply it to the GPO, link the GPO to the OU containing the computers.
    4. Create a WMI filter for Windows XP with SP 2 and apply it to a global group so that only computers running Windows XP with SP 2 will belong to the group, configure permissions on the GPO so that it only applies to that global group and link the GPO to the OU containing the computers.
  3. Look at figure 19, which container would you expand in order to configure user rights assignment in this GPO?

Figure 19: GPMC Navigation Tree

    1. Account Policies
    2. Local Policies
    3. Registry
    4. System
    5. Windows Components
  1. A GPO can be linked to more than one OU.
    1. True
    2. False
  2. You have deployed two AD DS forests running at the Windows Server 2008 functional level. One forest is your production environment, the other is your development and testing environment. Both are located on the same routable network. Which is the best way to copy completed GPOs from the test forest to the production forest?
    1. Establish a two-way trust between the forests and use GPMC to copy the GPOs directly from test to production with the Cross-domain Copying Wizard.
    2. Use the GPMC to backup the GPOs in the test environment, copy the backups to a location accessible from the production environment, and then use the Restore from Backup command to copy them into the production forest.
    3. Use the GPMC to backup the GPOs in the test environment, copy the backups to a location accessible from the production environment, and then use the Import Settings command to copy them into the production forest.
    4. Use the GPMC to backup the GPOs in the test environment, copy the backups to a location accessible from the production environment, and then use the Migration Tables feature to copy them into the production forest.
    5. Copy the GPOs from the SYSVOL share in the test environment to the SYSVOL share in the production environment.
  3. Which of the following is not a difference between ADM and ADMX files?
    1. ADM files contain localized test for setting names and explanation text, ADMX files do not.
    2. ADMX files are new to Windows Vista and Windows Server 2008, ADM files are available in Windows 2000, Windows XP, and Windows Server 2003.
    3. ADM files define how the group policy editor renders the administrative templates container of the computer configuration portion of group policy while ADMX files define how templates container of the user configuration portion is rendered.
    4. ADMX files can be placed in a central store to reduce disk space usage and replication traffic on DCs whereas ADM files cannot.
  4. Figure 20 shows the properties dialog box for an installation package, why is the deployment type Published greyed out?

Figure 20: Properties of a software installation package.

    1. Because the GPO that this package is from is linked to a container rather than an OU.
    2. Because the package was created in the computer configuration portion of the GPO.
    3. Because this is an upgrade package, not a package for installing a new application.
    4. Because the administrator editing the GPO does not have sufficient permissions to make changes to the installation package.
    5. Because the installation package is for a 32-bit X86 application.
  1. Which tool do you use to create a Password Settings Object (PSO)?
    1. Active Directory Users and Computers
    2. Group Policy Management Console
    3. ADSI Edit
    4. GPresult
    5. DSAdd
  2. Several settings in a Password Settings Object (PSO), including msDS-MinimumPasswordAge and msDS-MaximumPasswordAge, require a time value be provided. Which is a valid format for defining time in a PSO?
    1. 14 days
    2. 2400 hours
    3. 8
    4. 604800
  3. 12:05:00:00

Answers

  1. E is the correct answer. Even if you don’t remember all of the options available in the wizard you should understand that modifying the schema is an extremely sensitive operation that can only be performed by members of the Schema Admins group. All of the other tasks can be delegated.
  2. C is correct, the elements of a distinguished name are delimited by commas without spaces.
  3. D is the correct answer. AD DS automatically disables accounts created with dsadd if no password is specified.
  4. B is correct, the value provided for the –secgrp parameter was no, which means you created a distribution group rather than a security group.
  5. B is correct, remember the AGDLP and AGUDLP acronyms. Since the release of Windows Server 2003 there’s little difference between universal groups and global groups so you can use them interchangeably within your organization, however Microsoft does suggest that you use them in a consistent manner to reduce confusion.
  6. A is the correct answer, WMI filters can only be applied to GPOs, not OUs or groups. B is feasible, but more difficult to implement.
  7. B is correct, the User Rights Assignment container is a child of Local Policies. While I doubt that you will not encounter questions requiring you to memorize the entire structure of the navigation tree in the GPMC certain emphasis has been placed on Software Settings, Account Policies, Local Policies, Restricted Groups and their child containers specifically and Administrative Templates in a more general way.
  8. A is correct. When you create a new GPO using the GPMC you can link it to an OU immediately by right-clicking on the desired OU and selecting Create a GPO in this domain, and Link it here. After you have created it you can link it to as many other containers as you wish by right-clicking on the container and selecting Link an Existing GPO.
  9. C is the correct answer. While A would work, establishing trusts between test and production environments increases the risk of something going wrong. B will not work because the backups are from a different domain. D is incorrect, however using migration tables while importing the backed up GPOs will save time when correcting domain-specific references that differ between the environments. E is completely made up, who knows what sort of exciting problems might arise if you attempt it!
  10. C is correct.
  11. B is correct, you can only publish packages to users, when deploying packages to computers your only option is to assign them.
  12. C is correct, you can also create a new PSO by importing LDIF with the ldifde tool. After creating a PSO you can modify its properties in Active Directory Users and Computers if you have enabled the Advanced Features view.
  13. E is correct, the required format is 00:00:00:00 where the first two digits are the number of days, followed by hours, minutes, and seconds.

References

Step-by-Step Guide to Bulk Import and Export to Active Directory.

Planning and Deploying Group Policy. This document also includes guidance on OU design.

Creating an Organizational Unit Design.

A spreadsheet containing detailed information about all of the group policy settings available in Windows Vista and Windows Server 2008.

The Group Policy Team Blog includes links to the latest resources for understanding how to most effectively manage and troubleshoot group policy.

Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration.

Auditpol command line reference.

Here are links to several security guides from Microsoft for recent versions of Windows. While there is no need to study them for the exam you may find them helpful when deploying Windows in your organization: