Chapter 6. Creating and managing Group Policy

Group Policy is a mechanism for controlling and deploying operating system settings to computers all over your network. Group Policy consists of user and computer settings for the various Microsoft Windows operating systems, which the systems implement during computer startup and shutdown and user logon and logoff. You can configure one or more Group Policy Objects (GPOs) and then use a process called linking to associate them with specific Active Directory Domain Services (AD DS) objects. When you link a GPO to a container object, all the objects in that container receive the settings you configured in the GPO. You can link multiple GPOs to a single AD DS container or link one GPO to multiple containers throughout the AD DS hierarchy.

This chapter covers some of the fundamental tasks that administrators perform to create and deploy Group Policy settings.

Objectives in this chapter:

Objective 6.1: Create Group Policy Objects

Although the name Group Policy Object implies that policies are linked directly to groups, this is not the case. GPOs can be linked to sites, domains, and organizational units (OUs) to apply settings to all users and computers within AD DS containers. However, an advanced technique named security filtering enables you to apply GPO settings to one or more users or groups within a container by selectively granting the Apply Group Policy and Read permissions to one or more users or security groups.

The administrative benefits of GPOs are probably their greatest contribution to network efficiency. Administrators find that Group Policy implementation helps them achieve centralized management. The following list identifies administrative benefits to Group Policy implementation:

Note

This objective covers how to:

GPOs contain all the Group Policy settings that administrators wish to deploy to user and computer objects within a domain, site, or OU. To deploy a GPO, an administrator must associate it with a container. This association is achieved by linking the GPO to the desired AD DS domain, site, or OU object. Administrative tasks for Group Policy include creating GPOs, specifying where to store them, and managing the AD DS links.

There are three types of GPOs: local GPOs, nonlocal GPOs, and starter GPOs.

All Windows operating systems have support for local GPOs, sometimes known as LGPOs. Windows versions since Windows Server 2008 R2 and Windows Vista can support multiple local GPOs. This support enables administrators to specify a different local GPO for administrators and to create specific GPO settings for one or more local users configured on a workstation. This ability is particularly valuable for computers in public locations such as libraries and kiosks, when they are not part of an Active Directory infrastructure. Older Windows releases can support only one local GPO and the settings in that local GPO apply to all users who log on to the computer.

Local GPOs contain fewer options than domain GPOs. They do not support folder redirection or Group Policy software installation. Fewer security settings are available. When a local and a nonlocal (Active Directory–based) GPO have conflicting settings, the nonlocal GPO settings overwrite the local GPO settings.

Nonlocal GPOs are created in AD DS and linked to sites, domains, and OUs. Once linked to a container, the settings in the GPO are applied to all users and computers within that container by default.

Starter GPOs were introduced in Windows Server 2008. A starter GPO is essentially a template for the creation of domain GPOs based on a standard collection of settings. When you create a new GPO from a starter GPO, all the settings in the starter GPO are automatically copied to the new GPO as its default settings.

In Windows Server 2008 and Windows Vista, Microsoft replaced the token-based administrative template (ADM) files used with previous versions of Group Policy with an XML-based file format (ADMX). Administrative templates are the files defining the registry-based settings that appear in GPOs.

Earlier Windows versions created a copy of the ADM files for each GPO administrators created and placed them in the SYSVOL volume of a domain controller. A large Active Directory installation could easily have dozens of GPOs and each copy of the ADM files required 4 MB of storage. The result was a condition called SYSVOL bloat, in which there were hundreds of megabytes of redundant information stored on SYSVOL volumes, which had to be replicated to all the domain controllers for the domain.

To address this problem, Group Policy tools can now access the ADMX files from a Central Store, a single copy of the ADMX files stored on domain controllers. To use a Central Store, you must create the appropriate folder in the SYSVOL volume on a domain controller.

By default, tools such as the Group Policy Management Console (GPMC) save the ADMX files to the \%systemroot%\PolicyDefinitions folder, which on most computers is C:\Windows\PolicyDefinitions. To create a Central Store, you must copy the entire PolicyDefinitions folder to the same location as the Group Policy templates; that is, %systemroot%\SYSVOL\sysvol\<domain name>\Policies, on a domain controller, or, in universal naming convention (UNC) notation, \\< domain name >\SYSVOL\< domain name >\Policies.

The Group Policy Management Console is the Microsoft Management Console (MMC) snap-in that administrators use to create GPOs and manage their deployment to AD DS objects. The Group Policy Management Editor is a separate snap-in that opens GPOs and enables you to modify their settings.

There are several different ways of working with these two tools, depending on what you want to accomplish. You can create a GPO and then link it to a domain, site, or OU, or you can create and link a GPO in a single step. Windows Server 2012 R2 implements the tools as the Group Policy Management feature and installs them automatically with the AD DS role. You can install the feature manually on a member server by using the Add Roles And Features Wizard in Server Manager. The Group Policy Management tools are also included in the Remote Server Administration Tools package for Windows workstations.

If you decide to leave the default Windows GPOs unaltered, the first steps in deploying your own customized Group Policy settings are to create one or more new GPOs and link them to appropriate AD DS objects.

To use the Group Policy Management Console to create a new GPO and link it to an OU object in AD DS, use the following procedure.

  1. Open the Active Directory Administrative Center and create an OU called Sales in your domain.

  2. In Server Manager, from the Tools menu, select Group Policy Management. The Group Policy Management Console appears, as shown in Figure 6-1.

    The Group Policy Management Console
    Figure 6-1. The Group Policy Management Console

  3. Expand the forest container and browse to your domain. Then expand the domain container and select the Group Policy Objects folder. The GPOs that currently exist in the domain appear on the Contents tab.

  4. Right-click the Group Policy Objects folder and, from the shortcut menu, select New. The New GPO dialog box appears.

  5. In the Name text box, type a name for the new GPO and click OK. The new GPO appears in the Contents list.

  6. In the left pane, right-click the domain, site, or OU object to which you want to link the new GPO and, from the shortcut menu, select Link An Existing GPO. The Select GPO dialog box appears.

  7. Select the GPO you want to link to the object and click OK. The GPO appears on the object’s Linked Group Policy Objects tab, as shown in Figure 6-2.

    The Linked Group Policy Objects tab
    Figure 6-2. The Linked Group Policy Objects tab

  8. Close the Group Policy Management Console.

You can also create and link a GPO to an Active Directory container in a single step, by right-clicking an object and selecting Create A GPO In This Domain And Link It Here from the shortcut menu.

If you link a GPO to a domain object, it applies to all users and computers in the domain. On a larger scale, if you link a GPO to a site that contains multiple domains, the Group Policy settings are applied to all the domains and the child objects beneath them. This process is referred to as GPO inheritance.

Linking a GPO to a container causes all the users and computers in that container to receive the GPO settings by default. This is because creating the link grants the Read and Apply Group Policy permissions for the GPO to the users and computers in the container.

More precisely, the system grants the permissions to the Authenticated Users special identity, which includes all the users and computers in the domain. However, by using a technique named security filtering, you can modify the default permission assignments so that only certain users and computers receive the permissions and, consequently, the settings in the GPO.

To modify the default security filtering configuration for a GPO, select it in the left pane of the Group Policy Management Console, as shown in Figure 6-3. In the Security Filtering area, you can use the Add button or the Remove button to replace the Authenticated Users special identity with specific user, computer, or group objects. Of the users and computers in the container to which the GPO is linked, only those you select in the Security Filtering pane will receive the settings from the GPO.

Security filtering in the Group Policy Management Console
Figure 6-3. Security filtering in the Group Policy Management Console

Starter GPOs are essentially templates that you can use to create multiple GPOs with the same set of baseline Administrative Templates settings. You create and edit starter GPOs just as you would any other GPO. In the Group Policy Management Console, you right-click the Starter GPOs folder and, from the shortcut menu, select New to create a blank starter GPO. You can then open the starter GPO in the Group Policy Management Editor and configure any settings you want to carry over to the new GPOs you create from it.

Using Starter GPOs

When you view the Starter GPOs node in the Group Policy Management Console for the first time, a message appears, prompting you to create the Starter GPOs folder by clicking a button.

Once you have created and edited your starter GPOs, you can create new GPOs from them in multiple ways. You can right-click a starter GPO and select New GPO From Starter GPO from the shortcut menu, or you can create a new GPO in the usual manner described earlier and select the starter GPO you want to use in the Source Starter GPO drop-down list. You can also use the New-GPO cmdlet in Windows PowerShell. This copies the settings from the starter GPO to the new GPO, which you can continue to edit from there.

Group Policy settings enable you to customize the configuration of a user’s desktop, environment, and security settings. The settings are divided into two subcategories: Computer Configuration and User Configuration. The subcategories are referred to as Group Policy nodes. A node is just a parent structure that holds all related settings. In this case, the node is specific to computer configurations and user configurations.

Group Policy nodes provide a way to organize the settings according to where they are applied. The settings you define in a GPO can be applied to client computers, users, or member servers and domain controllers. The application of the settings depends on the container to which you link the GPO. By default, all objects within the container to which you link the GPO are affected by the GPO’s settings.

The Computer Configuration and User Configuration nodes contain three subnodes, or extensions, that further organize the available Group Policy settings. Within the Computer Configuration and User Configuration nodes, the subnodes are as follows:

To work with Administrative Template settings, you must understand the three different states of each policy setting. These three states are as follows:

Understanding these states is critical when you are working with Group Policy inheritance and multiple GPOs. If a policy setting is disabled in the registry by default and you have a lower-priority GPO that explicitly enables that setting, you must configure a higher-priority GPO to disable the setting if you want to restore it to its default. Applying the Not Configured state will not change the setting, leaving it enabled.

Computers that are members of an AD DS domain benefit from a great deal of flexibility when it comes to Group Policy configuration. Standalone (non–AD DS) systems can achieve some of that flexibility as long as they are running at least Windows Vista or Windows Server 2008 R2. These operating systems enable administrators to create multiple local GPOs that provide different settings for users, based on their identities.

Windows systems supporting multiple local GPOs have three layers of Group Policy support, as follows:

Windows applies the local GPOs in the order listed here. The Local Group Policy settings are applied first, then either the Administrators GPO or the Non-Administrators GPO, and, finally, any user-specific GPOs. As with nonlocal GPOs, the settings processed later can overwrite any earlier settings with which they conflict.

In the case of a system that is also a member of a domain, the three layers of local GPO processing come first, followed by the standard order of nonlocal Group Policy application.

To create local GPOs, you use the Group Policy Object Editor, which is an MMC snap-in provided on all Windows computers specifically for the management of local GPOs, as in the following procedure.

  1. Open the Run dialog box and, in the Open text box, type mmc and click OK. An empty MMC console opens.

  2. Click File, Add/Remove Snap-In to open the Add Or Remove Snap-Ins dialog box.

  3. From the Available Snap-Ins list, select Group Policy Object Editor and click Add. The Select Group Policy Object page opens.

  4. To create the local Group Policy GPO, click Finish. To create a secondary or tertiary GPO, click Browse. The Browse For A Group Policy Object dialog box opens.

  5. Click the Users tab, as shown in Figure 6-4.

    The Users tab of the Browse For A Group Policy Object dialog box
    Figure 6-4. The Users tab of the Browse For A Group Policy Object dialog box

    Multiple Local GPOs

    Windows computers that do not support multiple local GPOs lack the Users tab in the Browse For A Group Policy Object dialog box. This includes domain controllers and computers running Windows versions prior to Windows Vista and Windows Server 2008 R2.

  6. To create a secondary GPO, select either Administrators or Non-Administrators and click OK. To create a tertiary GPO, select a user and click OK. The GPO appears on the Select Group Policy Object page.

  7. Click Finish. The snap-in appears in the Add Or Remove Snap-Ins dialog box.

  8. Click OK. The snap-in appears in the MMC console.

  9. Click File, Save As. A Save As combo box appears.

  10. Type a name for the console to save it in the Administrative Tools program group.

  11. Close the MMC console.

You can now open this console whenever you need to configure the settings in the GPO you created.

Thought experiment: Implementing Group Policy

In the following thought experiment, apply what you’ve learned about this objective to predict what steps you need to take. You can find answers to these questions in the Answers section at the end of this chapter.

After a recent incident in which an employee left the company with a substantial amount of confidential data, the IT director has given Alice the task of implementing Group Policy settings that prevent all users except administrators and members of the Executives group from installing any USB devices.

Alice creates a GPO called Device Restrictions for this purpose and links it to the company’s single domain object. The GPO contains the following settings from the Computer Configuration\Policies\Administrative Templates\System\Device Installation\Device Installation Restrictions folder:

  • Allow administrators to override Device Installation Restriction policies–Enabled

  • Prevent installation of devices not described by other policy settings–Enabled

What else must Alice do to satisfy the requirements of her assignment?

Objective summary

  • Group Policy consists of user and computer settings that can be implemented during computer startup and user logon. These settings can be used to customize the user environment, to implement security guidelines, and to assist in simplifying user and desktop administration.

  • In AD DS, Group Policies can be assigned to sites, domains, and OUs. By default, there is one local policy per computer. Local policy settings are overwritten by Active Directory policy settings.

  • The Group Policy Management console is the tool used to create and modify GPOs and their settings.

Objective review

Answer the following questions to test your knowledge of the information in this objective. 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 types of files do Group Policy tools access from a Central Store by default?

    1. ADM files

    2. ADMX files

    3. Group Policy Objects

    4. Security templates

  2. Which of the following local GPOs takes precedence on a system with multiple local GPOs?

    1. Local Group Policy

    2. Administrators Group Policy

    3. Non-Administrators Group Policy

    4. D. User-specific Group Policy

  3. Which of the following techniques can be used to apply GPO settings to a specific group of users in an OU?

    1. GPO linking

    2. B. Administrative templates

    3. C. Security filtering

    4. D. Starter GPOs

  4. Which of the following statements best describes the function of a starter GPO?

    1. A starter GPO functions as a template for the creation of new GPOs.

    2. A starter GPO is the first GPO applied by all Active Directory clients.

    3. A starter GPO uses a simplified interface for elementary users.

    4. A starter GPO contains all the settings found in the default Domain Policy GPO.

  5. When you apply a GPO with a value of Not Configured for a particular setting to a system on which that same setting is disabled, what is the result?

    1. The setting remains disabled.

    2. The setting is changed to Not Configured.

    3. The setting is changed to Enabled.

    4. The setting generates a conflict error.

Objective 6.2: Configure security policies

One of the primary aims of Group Policy is to provide centralized management of security settings for users and computers. Most of the settings that pertain to security are found in the Windows Settings folder within the Computer Configuration node of a GPO. You can use security settings to govern how users are authenticated to the network, the resources they are permitted to use, group membership policies, and events related to user and group actions recorded in the event logs. Policy settings in the Computer Configuration node apply to a computer; it does not matter who is logging on to it. There are more Computer Configuration security settings than settings you can apply to a specific user.

Note

This objective covers how to:

Local policies enable administrators to set user privileges on the local computer that govern what users can do on the computer and determine if the system should track user activities in an event log. Tracking events that take place on the local computer, a process referred to as auditing, is another important part of monitoring and managing activities on a computer running Windows Server 2012 R2.

The Local Policies node of a GPO, found under Security Settings, has three subordinate nodes: Audit Policy, User Rights Assignment, and Security Options. As discussed in each of the following sections, keep in mind that local policies are local to a computer. When they are part of a GPO in Active Directory, they affect the local security settings of computer accounts to which the GPO is applied.

The Audit Policy section of a GPO enables administrators to log successful and failed security events, such as logon events, account access, and object access. You can use auditing to track both user activities and system activities. Planning to audit requires that you determine the computers to be audited and the types of events you wish to track.

When you consider events to audit, such as account logon events, you must decide whether you wish to audit successful logon attempts, failed logon attempts, or both. Tracking successful events enables you to determine how often users access network resources. This information can be valuable when planning your resource usage and budgeting for new resources. Tracking failed events can help you determine when security breaches occur or are attempted. For example, if you notice frequent failed logon attempts for a specific user account, you might want to investigate further. The policy settings available for auditing are shown in Figure 6-5.

When an audited event occurs, Windows Server 2012 R2 writes an event to the security log on the domain controller or the computer where the event took place. If it is a logon attempt or other Active Directory–related event, the event is written to the domain controller. If it is a computer event, such as a floppy drive access, the event is written to the local computer’s event log.

Audit Policies in the default domain policy
Figure 6-5. Audit Policies in the default domain policy

You must decide which computers, resources, and events you want to audit. It is important to balance the need for auditing against the potential information overload that would be created if you audited every possible type of event. The following guidelines can help you to plan your audit policy:

Implementation of your plan requires that you specify the categories to be audited and, if necessary, configure objects for auditing. To configure an audit policy, use the following procedure.

  1. In Server Manager, on the Tools menu, select Group Policy Management to open the Group Policy Management console.

  2. Expand the forest container and browse to your domain. Then expand the domain container and select the Group Policy Objects folder. The GPOs that currently exist in the domain appear on the Contents tab.

  3. Right-click the Default Domain Policy GPO and click Edit. A Group Policy Management Editor window for this policy opens.

  4. Browse to the Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies node and select Audit Policy. The audit policy settings appear in the right pane.

  5. Double-click the Audit Policy setting you want to modify. The Properties sheet for the policy you chose opens, as shown in Figure 6-6.

    The Properties sheet for a policy setting
    Figure 6-6. The Properties sheet for a policy setting

  6. Select the Define These Policy Settings check box.

  7. Select the appropriate check boxes to audit Success, Failure, or both.

  8. Click OK to close the setting’s Properties sheet.

  9. Close the Group Policy Management Editor and the Group Policy Management console.

You have now configured an audit policy in the default domain policy GPO, which will be propagated to all the computers in the domain during the next policy refresh.

Configuring objects for auditing is necessary when you have configured either of the two following event categories:

Each of these event categories requires additional setup steps, in which you open the Properties sheet for the object to be audited and specify the security principals or the files and folders for which you want to audit access.

Auditing Options

Beginning in Windows Server 2008, new options became available for AD DS auditing that indicate that a change has occurred and provide the old value and the new value. For example, if you change a user’s description from Marketing to Training, the Directory Services Event Log will record two events containing the original value and the new value.

As shown in Figure 6-7, the User Rights Assignment settings in Windows Server 2012 R2 are extensive and include settings that pertain to rights users need to perform system-related tasks.

User Rights Assignment settings in a GPO
Figure 6-7. User Rights Assignment settings in a GPO

For example, a user logging on locally to a domain controller must have the Allow Log On Locally right assigned to his or her account or be a member of one of the following AD DS groups: Account Operators, Administrators, Backup Operators, Print Operators, or Server Operators.

These group memberships enable users to log on locally because Windows Server 2012 R2 assigns the Allow Log On Locally user right to those groups in the Default Domain Controllers Policy GPO by default.

Other similar settings included in this collection are related to user rights associated with system shutdown, taking ownership privileges of files or objects, restoring files and directories, and synchronizing directory service data.

The Security Options node in a GPO, shown in Figure 6-8, includes security settings related to interactive logon, digital signing of data, restrictions for access to floppy and CD-ROM drives, unsigned driver installation behavior, and logon dialog box behavior.

The Security Options node in a GPO
Figure 6-8. The Security Options node in a GPO

The Security Options category also includes options to configure authentication and communication security within Active Directory.

A security template is a collection of configuration settings stored as a text file with an .inf extension. Security templates can contain many of the same security parameters as GPOs. However, security templates present these parameters in a unified interface, enable you to save your configurations as files, and simplify the process of deploying them when and where they are needed.

The settings that you can deploy by using security templates include many of the security policies covered in this objective, including audit policies, user rights assignments, security options, event log policies, and restricted groups. By itself, a security template is a convenient way to configure the security of a single system. When you combine security templates with Group Policy or scripting, they enable administrators to maintain the security of networks consisting of hundreds or thousands of computers running various versions of Microsoft Windows.

By using these tools together, administrators can create complex security configurations and mix and match those configurations for each of the various roles computers serve in their organizations. When deployed across a network, security templates enable you to implement consistent, scalable, and reproducible security settings throughout the enterprise.

Security templates are plain text files that contain security settings in a variety of formats, depending on the nature of the individual settings. Although it is possible to work with security template files directly by using any text editor, Windows Server 2012 R2 provides a graphical interface that makes the job much easier.

To create and manage security templates, you use the Security Templates snap-in for MMC. You can also download and install the Security Compliance Manager (SCM) tool from the Microsoft website; this tool provides similar functionality plus a collection of system security baselines. By default, the Windows Server 2012 R2 Administrative Tools menu does not include an MMC containing the Security Templates snap-in, so you have to create one yourself by using the MMC Add Or Remove Snap-Ins dialog box. When you create a new template, the console provides an interface like the one shown in Figure 6-9.

The Security Templates snap-in
Figure 6-9. The Security Templates snap-in

The left pane of the Security Templates snap-in points to a default folder in which the console stores the template files you create by default. The snap-in interprets any file in this folder with an .inf extension as a security template, even though the extensions do not appear in the console.

When you create a new template in the console, you see a hierarchical display of the policies in the template and their current settings. Many of the policies are identical to those in a GPO, both in appearance and function. You can modify the policies in each template just as you would those in a GPO.

To create a new security template from scratch, use the following procedure.

  1. Open the Run dialog box and, in the Open text box, type mmc and click OK. An empty MMC appears.

  2. Click File, Add/Remove Snap-In to open the Add Or Remove Snap-Ins dialog box.

  3. From the Available Snap-Ins list, select Security Templates and click Add. The snap-in appears in the Add Or Remove Snap-Ins dialog box.

  4. Click OK. The snap-in appears in the MMC.

  5. Click File, Save As. A Save As combo box appears.

  6. Type a name for the console to save it in the Administrative Tools program group.

  7. Expand the Security Templates node.

  8. Right-click the security template search path and, from the shortcut menu, select New Template. A dialog box appears.

  9. In the Template name field, type a name for the template and click OK. The new template appears in the console. Leave the console open.

When you create a blank security template, there are no policies defined in it. Applying the blank template to a computer will have no effect on it.

Security templates contain many of the same settings as GPOs, so you are already familiar with some of the elements of a template. For example, security templates contain the same local policy settings described earlier in this chapter; the templates are just a different way to configure and deploy those policies. Security templates also provide a means for configuring the permissions associated with files, folders, registry entries, and services.

Security templates have more settings than Local Computer Policy, because a template includes options for both standalone computers and computers that are participating in a domain.

The simplest way to deploy a security template on multiple computers simultaneously is to import the template into a GPO. Once you import the template, the template settings become part of the GPO, and the network’s domain controllers deploy them to all the computers affected by that GPO. As with any Group Policy deployment, you can link a GPO to any domain, site, or OU object in the Active Directory tree. The settings in the GPO are then inherited by all the container and leaf objects subordinate to the object you selected.

To import a security template into a GPO, use the following procedure.

  1. In Server Manager, on the Tools menu, select Group Policy Management. The Group Policy Management console appears.

  2. Expand the forest container and browse to your domain. Then expand the domain container and select the Group Policy Objects folder. The GPOs that currently exist in the domain appear on the Contents tab.

  3. Right-click the GPO into which you want to import the template and click Edit. A Group Policy Management Editor window for this policy opens.

  4. Browse to the Computer Configuration\Policies\Windows Settings\Security Settings node. Right-click the Security Settings node and, from the shortcut menu, select Import Policy. The Import Policy From dialog box appears.

  5. Browse to the security template file you want to import and click Open. The policy settings in the template are copied to the GPO.

  6. Close the Group Policy Management Editor and Group Policy Management console.

Windows Server 2012 R2 provides two separate interfaces for creating and managing local user accounts: the User Accounts control panel and the Local Users and Groups snap-in for MMC, which is included in the Computer Management console. Both of these interfaces provide access to the same Security Account Manager (SAM) where the user and group information is stored, so any changes you make using one interface will appear in the other.

Microsoft designed the User Accounts control panel and the Local Users And Groups snap-in for computer users with different levels of expertise, and they provide different degrees of access to the SAM, as follows:

Windows Server 2012 R2 creates two local user accounts during the operating system installation process: the Administrator account and the Guest account. The setup program prompts the installer for an Administrator password during the installation, and the Guest account is disabled by default.

Once the installation process is completed, the system restarts. Because only the Administrator account is available, the computer logs on using that account. This account has administrative privileges, so at this point you can create additional user accounts or modify the existing ones.

Creating Local Users

You can only create new user accounts in the control panel on Windows Server 2012 R2 computers that are part of a workgroup. When you join a computer to an AD DS domain, you must use the Local Users And Groups snap-in to create new local user accounts. Domain controllers have no local user or group accounts.

By default, the User Accounts control panel creates standard accounts. To grant a local user administrative capabilities, you must change the account type by using the interface shown in Figure 6-10.

The Change Account Type window
Figure 6-10. The Change Account Type window

What the User Accounts control panel refers to as an account type is actually a group membership. Selecting the Standard option adds the user account to the local Users group, whereas selecting the Administrator option adds the account to the Administrators group.

By default, the Local Users And Groups snap-in is part of the Computer Management console. However, you can also load the snap-in by itself or create your own MMC with any combination of snap-ins you wish.

To create a local user account with the Local Users And Groups snap-in, use the following procedure.

  1. In Server Manager, on the Tools menu, select Computer Management to open the Computer Management console.

  2. Expand the Local Users And Groups node and click Users to view a list of the current local users.

  3. Right-click the Users folder and, from the shortcut menu, select New User. The New User dialog box opens, as shown in Figure 6-11.

    The New User dialog box
    Figure 6-11. The New User dialog box

  4. In the User Name text box, type the name you want to assign to the user account. This is the only required field in the dialog box.

  5. Specify a Full Name and a Description for the account if desired.

  6. In the Password text box and the Confirm Password text box, type a password for the account if desired.

  7. Select or clear the four check boxes to control the following functions:

  8. Click Create. The new account is added to the user list and the console clears the dialog box, leaving it ready for the creation of another user account.

  9. Click Close.

  10. Close the Computer Management console.

To create a local group with the Local Users And Groups snap-in, use the following procedure.

  1. In Server Manager, on the Tools menu, select Computer Management to open the Computer Management console.

  2. Expand the Local Users and Groups node and click Groups to display a list of local groups.

  3. Right-click the Groups folder and then, from the shortcut menu, select New Group. The New Group dialog box opens.

  4. In the Group Name text box, type the name you want to assign to the group. This is the only required field in the dialog box. If desired, specify a Description for the group.

  5. Click Add. The Select Users dialog box opens.

  6. In the text box, type the names of the users whom you want to add to the group, separated by semicolons and then click OK. The users are added to the Members list. You can also type part of a user name and click Check Names to complete the name or click Advanced to search for users.

  7. Click Create to create the group and populate it with the user(s) you specified. The console then clears the dialog box, leaving it ready for the creation of another group.

  8. Click Close.

  9. Close the Computer Management console.

Local groups have no user-configurable attributes other than a description and a members list, so the only modifications you can make when you open an existing group are supplying a description and adding and removing members. As noted earlier in this lesson, local groups cannot have other local groups as members, but if the computer is a member of a Windows domain, a local group can have domain users and domain groups as members.

One of the most common Windows security problems arises from the fact that many users perform their everyday computing tasks with more system access than they actually need. Logging on as an Administrator or as a user who is a member of the Administrators group grants the user full access to all areas of the operating system. This degree of system access is not necessary to run many of the applications and perform many of the tasks users require every day; it is needed only for certain administrative functions, such as installing system-wide software and configuring system parameters.

For most users, logging on with administrative privileges all the time is just a matter of convenience. Microsoft recommends logging on as a standard user and using administrative privileges only when you need them. However, many technical specialists who do this frequently find themselves encountering situations in which they need administrative access. There is a surprisingly large number of common, and even mundane, Windows tasks that require administrative access, and the inability to perform those tasks can negatively affect a user’s productivity.

Microsoft decided to address this problem by keeping all Windows Server 2012 R2 users from accessing the system using administrative privileges unless those privileges are required to perform the task at hand. The mechanism that does this is called User Account Control (UAC).

When a user logs on to Windows Server 2012 R2, the system issues a token, which indicates the user’s access level. Whenever the system authorizes the user to perform a particular activity, it consults the token to see if the user has the required privileges.

In versions of Windows prior to Windows Server 2008 and Windows Vista, standard users received standard user tokens and members of the Administrators group received administrative tokens. Every activity performed by an administrative user was therefore authorized using the administrative token, resulting in the problems described earlier.

On a computer running Windows Server 2012 R2 with UAC, a standard user still receives a standard user token, but an administrative user receives two tokens: one for standard user access and one for administrative user access. By default, the standard and administrative users both run using the standard user token most of the time.

When a standard user attempts to perform a task that requires administrative privileges, the system displays a credential prompt, as shown in Figure 6-12, requesting that the user supplies the name and password for an account with administrative privileges.

A UAC credential prompt
Figure 6-12. A UAC credential prompt

When an administrator attempts to perform a task that requires administrative access, the system switches the account from the standard user token to the administrative token. This is known as Admin Approval Mode.

Before the system permits the user to employ the administrative token, it might require the user to confirm that he or she is actually trying to perform an administrative task. To do this, the system generates an elevation prompt, as shown in Figure 6-13. This confirmation prevents unauthorized processes, such as those initiated by malware, from accessing the system using administrative privileges.

A UAC elevation prompt
Figure 6-13. A UAC elevation prompt

By default, whenever Windows Server 2012 R2 displays an elevation prompt or a credential prompt, it does so by using the secure desktop.

The secure desktop is an alternative to the interactive user desktop that Windows normally displays. When Windows Server 2012 R2 generates an elevation or credential prompt, it switches to the secure desktop, suppressing the operation of all other desktop controls and permitting only Windows processes to interact with the prompt. The object of this is to prevent malware from automating a response to the elevation or credential prompt and bypassing the human reply.

Windows Server 2012 R2 enables UAC by default, but it is possible to configure its properties and even to disable it completely. In Windows Server 2012 R2, there are four UAC settings available through the Action Center in Control Panel, as shown in Figure 6-14. The four settings are as follows:

  • Always Notify Me

  • Notify Me Only When Apps Try To Make Changes To My Computer

  • Notify Me Only When Apps Try To Make Changes To My Computer (Do Not Dim My Desktop)

  • Never Notify Me

The User Account Control Settings dialog box
Figure 6-14. The User Account Control Settings dialog box

Although the Control Panel provides some control over UAC, the most granular control over UAC properties is through the Security Options node in Group Policy and Local Security Policy.

Thought experiment: Deploying security templates

In the following thought experiment, apply what you’ve learned about this objective to predict what steps you need to take. You can find answers to these questions in the Answers section at the end of this chapter.

You are a network administrator planning a security template deployment on a network that consists of 100 workstations. The workstations are all running various versions of Microsoft Windows, broken down as follows:

  • Windows 7: 30 workstations

  • Windows XP Professional: 40 workstations

  • Windows XP Home Edition: 20 workstations

  • Windows 2000 Professional: 10 workstations

In the past, some computers on the network have been compromised because end users modified their workstation security configurations. Your task is to deploy your security templates on the workstations in such a way that end users cannot modify them. To accomplish this goal, you decide to use Group Policy to deploy the templates to an AD DS OU object that contains all of the workstations.

Based on the information provided, answer the following questions.

  1. How many of the workstations cannot receive their security template settings from a GPO linked to an AD DS container?

  2. Which of the following methods can you use to deploy your security templates on the workstations that do not support Group Policy, while still accomplishing your assigned goals?

    • Upgrade all the computers that do not support Group Policy to Windows 7.

    • Run the Security Templates snap-in on each computer and load the appropriate security template.

    • Create a logon script that uses Secedit.exe to import the security template on each computer.

    • Run the Security Configuration and Analysis snap-in on each computer and use it to import the appropriate security template.

Objective summary

  • Most security-related settings are found within the Windows Settings node of the Computer Configuration node of a GPO.

  • Local policy settings govern the actions users can perform on a specific computer and determine if the actions are recorded in an event log.

  • Auditing can be configured to audit successes, failures, or both.

  • Administrators can use security templates to configure local policies, group memberships, event log settings, and other policies.

  • When a standard user attempts to perform a task that requires administrative privileges, the system displays a credential prompt, requesting that the user supply the name and password for an account with administrative privileges.

  • User Account Control is enabled by default in all Windows Server 2012 R2 installations, but it is possible to configure its properties and even to disable it completely.

Objective review

Answer the following questions to test your knowledge of the information in this objective. 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 tools are used to deploy the settings in a security template to all the computers in an AD DS domain?

    1. Active Directory Users and Computers

    2. Security Templates snap-in

    3. Group Policy Object Editor

    4. Group Policy Management console

  2. Which of the following are local groups to which you can add users with the Windows Control Panel? (Choose all that apply.)

    1. Users

    2. Power Users

    3. Administrators

    4. Non-Administrators

  3. Which of the following tools are used to modify the settings in a security template?

    1. Active Directory Users and Computers

    2. Security Templates snap-in

    3. Group Policy Object Editor

    4. Group Policy Management console

  4. The built-in local groups on a server running Windows Server 2012 R2 receive their special capabilities through which of the following mechanisms?

    1. Security options

    2. Windows Firewall rules

    3. NTFS permissions

    4. User rights

  5. After configuring and deploying the Audit Directory Service Access policy, what must you do before a computer running Windows Server 2012 R2 begins logging Active Directory access attempts?

    1. You must select the Active Directory objects you want to audit by using the Active Directory Users and Computer console.

    2. You must wait for the audit policy settings to propagate to all the domain controllers on the network.

    3. You must open the Audit Directory Service Access Properties sheet and select all the Active Directory objects you want to audit.

    4. You must add an underscore character to the name of every Active Directory object you want to audit.

Objective 6.3: Configure application restriction policies

The options in the Software Restriction Policies node provide organizations greater control in preventing potentially dangerous applications from running. Software restriction policies are designed to identify software and control its execution. In addition, administrators can control who will be affected by the policies.

Note

This objective covers how to:

The Software Restriction Policies node is found in the Windows Settings\Security Settings node of the User Configuration or the Computer Configuration node of a GPO. By default, the Software Restriction Policies folder is empty. When you create a new policy, two subfolders appear: Security Levels and Additional Rules. The Security Levels folder enables you to define the default behavior from which all rules will be created. The criteria for each executable program are defined in the Additional Rules folder.

In the following sections, you learn how to set the security level for a software restriction policy and how to define rules that will govern the execution of program files.

Prior to creating any rules that govern the restriction or allowance of executable files, it is important to understand how the rules work by default. If a policy does not enforce restrictions, executable files run based on the permissions that users or groups have in the NTFS file system.

When considering the use of software restriction policies, you must determine your approach to enforcing restrictions. There are three basic strategies for enforcing restrictions, as follows:

The approach you take depends on the needs of your particular organization. By default, the Software Restriction Policies area has an Unrestricted value in the Default Security Level setting.

For example, you might want to enable only specified applications to run in a high-security environment. In this case, you would set the Default Security Level to Disallowed. By contrast, in a less secure network, you might want to allow all executables to run unless you have specified otherwise. This would require you to leave the Default Security Level set as Unrestricted. In this case, you would have to create a rule to identify an application before you could disable it. You can modify the Default Security Level to reflect the Disallowed setting.

Because the Disallowed setting assumes that all programs will be denied unless a specific rule permits them to run, this setting can cause administrative headaches if not thoroughly tested. You should test all applications you wish to run to ensure that they will function properly.

To modify the Default Security Level setting to Disallowed, use the following procedure.

  1. In Server Manager, on the Tools menu, select Group Policy Management to open the Group Policy Management console.

  2. Expand the forest container and browse to your domain. Then expand the domain container and select the Group Policy Objects folder. The GPOs that currently exist in the domain appear on the Contents tab.

  3. Right-click a GPO and select Edit. A Group Policy Management Editor window opens.

  4. Browse to the Software Restriction Policies node under either Computer Configuration or User Configuration.

  5. Right-click Software Restriction Policies and select New Software Restriction Policies. The folders containing the new policies appear.

  6. In the details pane, double-click Security Levels. Note the check mark on the Unrestricted icon, which is the default setting.

  7. Right-click the Disallowed security level and, from the shortcut menu, select Set As Default. A Software Restriction Policies message box appears, warning you of your action.

  8. Click Yes, and then close the Group Policy Management Editor and Group Policy Management consoles.

You have now modified the Default Security Level for a software restriction policy.

The functionality of software restriction policies depends first on the rules that identify software and then by the rules that govern its usage. When you create a new software restriction policy, the Additional Rules subfolder appears. This folder enables you to create rules that specify the conditions under which programs can be executed or denied. These rules can override the Default Security Level setting when necessary.

You create new rules of your own in the Additional Rules folder using a dialog box like the one shown in Figure 6-15.

The New Path Rule dialog box
Figure 6-15. The New Path Rule dialog box

There are four types of software restriction rules that you can use to specify which programs can or cannot run on your network:

There is also a fifth type of rule—the default rule—that applies when an application does not match any of the other rules you have created. To configure the default rule, select one of the policies in the Security Levels folder and, on its Properties sheet, click Set As Default.

The functions of the four rule types are explained in the following sections.

A hash is a series of bytes with a fixed length that uniquely identifies a program or file. A hash value is generated by an algorithm that essentially creates a fingerprint of the file, making it nearly impossible for another program to have the same hash. If you create a hash rule and a user attempts to run a program affected by the rule, the system checks the hash value of the executable file and compares it with the hash value stored in the software restriction policy. If the two match, the policy settings will apply. Therefore, creating a hash rule for an application executable prevents the application from running if the hash value is not correct. Because the hash value is based on the file itself, the file will continue to function if you move it from one location to another. If the executable file is altered in any way, for example, if it is modified or replaced by a worm or virus, the hash rule in the software restriction policy prevents the file from running.

A certificate rule uses the digital certificate associated with an application to confirm its legitimacy. You can use certificate rules to enable software from a trusted source to run or to prevent software that does not come from a trusted source from running. You can also use certificate rules to run programs in disallowed areas of the operating system.

A path rule identifies software by specifying the directory path where the application is stored in the file system. You can use path rules to create exceptions that allow an application to execute when the Default Security Level for software restriction policies is set to Disallowed, or you can use them to prevent an application from executing when the Default Security Level for software restriction policies is set to Unrestricted.

Path rules can specify either a location in the file system where application files are located or a registry path setting. Registry path rules provide assurance that the application executables will be found. For example, if an administrator uses a path rule to define a file system location for an application, and the application is moved to a new location, such as during a network restructuring, the original path in the path rule would no longer be valid. If the rule specifies that the application should not function unless it is located in a particular path, the program would not be able to run from its new location. This could cause a significant security breach opportunity if the program references confidential information.

In contrast, if you create a path rule using a registry key location, any change to the location of the application files will not affect the outcome of the rule. This is because when you relocate an application, the registry key that points to the application’s files is updated automatically.

Network zone rules apply only to Windows Installer packages that attempt to install from a specified zone, such as a local computer, a local intranet, trusted sites, restricted sites, or the Internet. You can configure this type of rule to enable Windows Installer packages to be installed only if they come from a trusted area of the network. For example, an Internet zone rule could restrict Windows Installer packages from being downloaded and installed from the Internet or other network locations.

You can define a software restriction policy by using multiple rule types to allow and disallow program execution. By using multiple rule types, it is possible to have a variety of security levels. For example, you might want to specify a path rule that prevents programs from running from the \\Server1\Accounting shared folder and a path rule that enables programs to run from the \\Server1\Application shared folder. You can also choose to incorporate certificate rules and hash rules into your policy. When implementing multiple rule types, systems apply the rules in the following order of precedence:

  1. Hash rules

  2. Certificate rules

  3. Network zone rules

  4. Path rules

When a conflict occurs between rule types, such as between a hash rule and a path rule, the hash rule prevails because it is higher in the order of preference. If a conflict occurs between two rules of the same type with the same identification settings, such as two path rules that identify software from the same directory, the more restrictive setting will apply. In this case, if one of the path rules were set to Unrestricted and the other to Disallowed, the policy would enforce the Disallowed setting.

Within the Software Restriction Policies folder, you can configure three specific properties to provide additional settings that apply to all policies when implemented: Enforcement, Designated File Types, and Trusted Publishers.

As shown in Figure 6-16, the Enforcement properties enable you to determine whether the policies apply to all files or whether library files, such as dynamic link library (DLL) files, are excluded. Excluding DLLs is the default. This is the most practical method of enforcement. For example, if the Default Security Level for the policy is set to Disallowed and the Enforcement properties are set to All Software Files, you would have to create a rule that checked every DLL before the program could be allowed or denied. By contrast, excluding DLL files by using the default Enforcement property does not require an administrator to define individual rules for each DLL file.

Configuring Enforcement properties
Figure 6-16. Configuring Enforcement properties

The Designated File Types properties within the Software Restriction Policies folder, as shown in Figure 6-17, specify file types that are considered executable. File types that are designated as executable or program files are shared by all rules, although you can specify a list for a computer policy that is different from one that is specified for a user policy.

Configuring Designated File Types properties
Figure 6-17. Configuring Designated File Types properties

Finally, the Trusted Publishers properties enable an administrator to control how systems handle certificate rules. In the Properties dialog box for Trusted Publishers, shown in Figure 6-18, the first setting enables you to specify which users are permitted to manage trusted certificate sources. By default, local computer administrators have the right to specify trusted publishers on the local computer and enterprise administrators have the right to specify trusted publishers in an OU. From a security standpoint, in a high-security network, users should not be allowed to determine the sources from which certificates can be obtained.

The Trusted Publisher Properties sheet also lets you decide if you wish to verify that a certificate has not been revoked. If a certificate has been revoked, the user should not be permitted access to network resources. You have the option of checking either the publisher or the time stamp of the certificate to determine if it has been revoked.

Configuring Trusted Publishers properties
Figure 6-18. Configuring Trusted Publishers properties

Software restriction policies can be a powerful tool, but they can also require a great deal of administrative overhead. If you elect to disallow all applications except those matching the rules you create, there are many programs in Windows Server 2012 R2 itself that need rules, in addition to the applications you want to install. Administrators must create the rules manually, which can be an onerous chore.

AppLocker, also known as application control policies, is a Windows feature that is essentially an updated version of the concept implemented in software restriction policies. AppLocker also uses rules, which administrators must manage, but the process of creating the rules is much easier, thanks to a wizard-based interface.

AppLocker is also more flexible than software restriction policies. You can apply AppLocker rules to specific users and groups and also create rules that support all future versions of an application. The primary disadvantage of AppLocker is that you can apply the policies only to computers running Windows 7 and Windows Server 2008 R2 or later.

The AppLocker settings are located in GPOs in the Computer Configuration\Windows Settings\Security Settings\Application Control Policies\AppLocker container, as shown in Figure 6-19.

The AppLocker container in a GPO
Figure 6-19. The AppLocker container in a GPO

In the AppLocker container, there are four nodes that contain the basic rule types:

Each of the rules you create in each of these containers can allow or block access to specific resources, based on one of the following criteria:

When enabled, AppLocker blocks all executables, installer packages, and scripts (except for those specified in Allow rules) by default. Therefore, to use AppLocker you must create rules that enable users to access the files needed for Windows and the system’s installed applications to run. The simplest way to do this is to right-click each of the four rules containers and select Create Default Rules from the shortcut menu.

The default rules for each container are standard rules that you can replicate, modify, or delete as necessary. You can also create your own rules, as long as you are careful to provide access to all the resources the computer needs to run Windows.

Applying Applocker Policies

To use AppLocker, the Application Identity service must be running. By default, this service uses the manual startup type, so you must start it yourself in the Services console before Windows can apply the AppLocker policies.

The greatest advantage of AppLocker over software restriction policies is the ability to create rules automatically. When you right-click one of the rules containers and select Automatically Generate Rules from the shortcut menu, the Automatically Generate Rules Wizard starts.

After specifying the folder to be analyzed and the users or groups to which the rules should apply, you will see a Rule Preferences page, enabling you to specify the types of rules you want to create. The wizard then displays a summary of its results on the Review Rules page and adds the rules to the container.

In addition to creating rules automatically, you can do it manually by using a wizard-based interface you activate by selecting Create New Rule from the shortcut menu for one of the rule containers.

The wizard prompts you for the following information:

Thought experiment: Using AppLocker

In the following thought experiment, apply what you’ve learned about this objective to predict what steps you need to take. You can find answers to these questions in the Answers section at the end of this chapter.

Sophie is planning on using AppLocker to control access to applications on a new network she has constructed for the Research and Development department at a major aerospace firm. The software developers in the department have recently deployed a new application called Virtual Wind Tunnel, which is based on government project research and is therefore classified. All of the full-time personnel have sufficient clearance to use the application, but the interns in the department do not. Sophie has placed the user accounts for everyone in the department into a security group called ResDev. The interns are also members of a group called RDint.

How can Sophie use AppLocker to provide everyone in the department with access to the Virtual Wind Tunnel application without changing the group memberships and without having to apply policies to individual users?

Objective summary

  • Software restriction policies enable the software’s executable code to be identified and either allowed or disallowed on the network.

  • The three Default Security Levels within software restriction policies are Unrestricted, which means all applications function based on user permissions; Disallowed, which means all applications are denied execution regardless of the user permissions; and Basic User, which enables only executables to be run that can be run by normal users.

  • Four rule types can be defined within a software restriction policy. They include, in order of precedence, hash, certificate, network zone, and path rules. The security level set on a specific rule supersedes the Default Security Level of the policy.

  • Software restriction policies are Group Policy settings that enable administrators to specify the programs that are allowed to run on workstations by creating rules of various types.

  • AppLocker enables administrators to create application restriction rules much more easily than was previously possible.

Objective review

Answer the following questions to test your knowledge of the information in this objective. 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 is not one of the software restriction rule types supported by Windows Server 2012 R2?

    1. Hash rules

    2. Certificate rules

    3. Path rules

    4. Firewall rules

  2. Which of the following strategies for enforcing software restrictions will prevent any executable from running except for those that have been specifically allowed by an administrator?

    1. Basic user

    2. Disallowed

    3. Power user

    4. Unrestricted

  3. Under which of the following conditions will a hash rule in a software restriction policy cease to function? (Choose all that apply.)

    1. When you move the file on which the hash is based to a different folder

    2. When you update the file on which the hash is based to a new version

    3. When the file on which the hash is based is modified by a virus

    4. When you change the permissions for the file on which the hash is based

  4. Which of the following rule types applies to files with an .msi extension?

    1. Executable rules

    2. Windows Installer rules

    3. Script rules

    4. Packaged app rules

  5. Which of the following services must you manually start before Windows can apply AppLocker policies?

    1. Application Identity

    2. Application Management

    3. Credential Manager

    4. Network Connectivity Assistant

Objective 6.4: Configure Windows Firewall

You might have locked the door to the computer center in which the servers are located, but the computers remain connected to the network. A network is another type of door, or rather a series of doors, that can allow data in or out. To provide services to your users, some of those doors must be open at least some of the time, but server administrators must make sure that only the right doors are left open.

A firewall is a software program that protects a computer or a network by allowing certain types of network traffic in and out of the system while blocking others. A firewall is essentially a series of filters that examine the contents of packets and the traffic patterns to and from the network to determine which packets they should allow to pass through.

The object of a firewall is to permit all of the traffic that legitimate users need to perform their assigned tasks yet block everything else. Note that when you are working with firewalls, you are not concerned with subjects like authentication and authorization. Those are mechanisms that control who is able to get through the server’s open doors. The firewall determines which doors are left open and which are shut tight.

Note

This objective covers how to:

Windows Server 2012 R2 includes a firewall program called Windows Firewall, which is activated by default on all systems. In its default configuration, Windows Firewall blocks most network traffic from entering the computer. Firewalls work by examining the contents of each packet entering and leaving the computer and comparing the information they find to a series of rules, which specify which packets are allowed to pass through the firewall and which are blocked.

The Transmission Control Protocol/Internet Protocol (TCP/IP) is used by Windows systems to communicate functions by packaging application data using a series of layered protocols that define where the data comes from and where it is going. The three most important criteria that firewalls can use in their rules are as follows:

Firewall rules can function in two ways, as follows:

Generally, blocking all traffic by default is the more secure arrangement. From the server administrator’s standpoint, you start with a completely blocked system, and then begin testing your applications. When an application fails to function properly because network access is blocked, you create a rule that opens up the ports the application needs to communicate.

This is the method that Windows Firewall uses by default for incoming network traffic. There are default rules preconfigured into the firewall that are designed to admit the traffic used by standard Windows networking functions, such as file and printer sharing. For outgoing network traffic, Windows Firewall uses the other method, allowing all traffic to pass the firewall except that which conforms to a rule.

Windows Firewall is a single program with one set of rules, but there are two distinct interfaces you can use to manage and monitor it. The Windows Firewall control panel applet provides a simplified interface that enables administrators to avoid the details of rules and port numbers. If you just want to turn the firewall on or off (typically for testing or troubleshooting purposes) or work with the firewall settings for a specific Windows role or feature, you can do so by using just the control panel. For full access to firewall rules and more sophisticated functions, you must use the Windows Firewall With Advanced Security console, as discussed later in this objective.

In many cases, administrators never have to work directly with Windows Firewall. Many of the roles and features included in Windows Server 2012 R2 automatically open the appropriate firewall ports when you install them. In other situations, the system warns you of firewall issues.

For example, the first time you open File Explorer and try to access the network, a warning appears, informing you that Network Discovery and File Sharing are turned off, preventing you from browsing the network.

Network Discovery is just a set of firewall rules that regulate the ports Windows uses for network browsing, specifically ports 137, 138, 1900, 2869, 3702, 5355, 5357, and 5358. By default, Windows Server 2012 R2 disables the inbound rules associated with these ports, so the ports are closed, blocking all traffic through them. When you click the warning banner and choose Turn On Network Discovery And File Sharing from the shortcut menu, you are in effect activating these firewall rules, thereby opening the ports associated with them.

In addition to the menu commands accessible through the warning banner, you can control the Network Discovery and File Sharing rules in other ways. The Network and Sharing Center control panel, through its Advanced Sharing Settings page, provides options that you can use to turn Network Discovery, File Sharing, and other basic networking functions on and off.

The Windows Firewall control panel has an Allow An App Or Feature Through Windows Firewall link, which opens the Allowed Apps dialog box. The Network Discovery check box in this dialog box enables you to control the same set of rules as the Network Discovery control panel in the Network And Sharing Center.

Finally, you can access the individual Network Discovery rules directly by using the Windows Firewall With Advanced Security console. When you select the Inbound Rules node and scroll down in the list, you can see nine Network Discovery rules.

As you can see by examining the rules in the console, Network Discovery is a complex Windows function that would be difficult to control if you had to determine by trial and error which ports it uses. This is why Windows Firewall includes a large collection of rules that regulate the ports that the applications and services included with the operating system need to operate.

The Windows Firewall control panel applet provides the easiest and safest access to the firewall controls. These controls are usually sufficient for most server administrators, unless the system has special requirements or you are working with custom server applications.

When you open the Windows Firewall window from the control panel, as shown in Figure 6-20, you see the following information:

  • Whether the computer is connected to a domain, private, or public network

  • Whether the Windows Firewall service is turned on or off

  • Whether inbound and outbound connections are blocked

  • The name of the currently active network

  • Whether users are notified when a program is blocked

The Windows Firewall control panel
Figure 6-20. The Windows Firewall control panel

On the left side of the window is a series of links, which provide the following functions:

Several of the links in the Windows Firewall window point to the same place: a Customize Settings dialog box that contains controls for some of the most basic firewall functions.

The Customize Settings dialog box, shown in Figure 6-21, is organized according to three areas, corresponding to the three profiles on a Windows computer. Windows Firewall uses these profiles to represent the type of network to which the server is connected. The profiles are as follows:

  • Public. The public (or guest) profile is intended for servers that are accessible to unauthenticated or temporary users, such as computers in an open lab or kiosk.

  • Private. The private profile is intended for servers on an internal network that are not accessible by unauthorized users.

  • Domain. The domain profile is applied to servers that are members of an AD DS domain in which all users are identified and authenticated.

The Customize Settings dialog box for Windows Firewall
Figure 6-21. The Customize Settings dialog box for Windows Firewall

In Windows Firewall, the three profiles are essentially separate sets of rules that apply only to computers connected to the designated network type. Administrators can control the environment for each type of network by configuring separate rules and settings for each profile.

The Customize Settings dialog box has the following controls for each of the three network profiles:

There are times when administrators might be required to modify the firewall settings in other ways, typically because a specific application requires access to a port not anticipated by the firewall’s default rules.

To do this, you can use the Allowed Apps dialog box in the Windows Firewall control panel, as shown in Figure 6-22.

The Allowed Apps dialog box for Windows Firewall
Figure 6-22. The Allowed Apps dialog box for Windows Firewall

Opening up a port in a server’s firewall is an inherently dangerous activity. The more open doors you put in a wall, the greater the likelihood that intruders will get in. Windows Firewall provides two basic methods for opening a hole in your firewall: opening a port and allowing an application. Both are risky, but the latter is less so. This is because when you open a port by creating a rule in the Windows Firewall With Advanced Security console, the port stays open permanently. When you allow an application through the firewall by using the control panel, the specified port is open only while the program is running. When you terminate the program, the firewall closes the port.

Exam Tip

Previous versions of Windows refer to allowed applications as exceptions, meaning that they are exceptions to the general firewall rules closing off all the computer’s ports against intrusion. Exam candidates should be prepared to see questions containing either term.

The applications listed in the Allowed Apps dialog box are based on the roles and features installed on the server. Each listed application corresponds to one or more firewall rules, which the control panel activates and deactivates as needed.

Unlike earlier versions, the Windows Server 2012 R2 version of the Windows Firewall control panel does not provide direct access to port numbers. For more precise control over the firewall, you must use the Windows Firewall With Advanced Security console, which you can access by clicking Advanced Settings in the Windows Firewall control panel or by selecting it from the Tools menu in Server Manager.

The Windows Firewall control panel is designed to enable administrators and advanced users to manage basic firewall settings. For full access to the Windows Firewall configuration settings, you must use the Windows Firewall With Advanced Security snap-in for the MMC.

To open the console, open Server Manager and, from the Tools menu, select Windows Firewall With Advanced Security. The Windows Firewall With Advanced Security console opens, as shown in Figure 6-23.

The Windows Firewall With Advanced Security console
Figure 6-23. The Windows Firewall With Advanced Security console

At the top of the Windows Firewall With Advanced Security console’s middle pane, in the Overview section, there are status displays for the computer’s three network location profiles. If you connect the computer to a different network (which is admittedly not likely with a server), Windows Firewall can load a different profile and a different set of rules.

The default Windows Firewall configuration calls for the same basic settings for all three profiles, as follows:

You can change this default behavior by clicking the Windows Firewall Properties link, which displays the Windows Firewall With Advanced Security On Local Computer dialog box.

In this dialog box, each of the three network location profiles has a tab with identical controls which enable you to modify the default profile settings. You can, for example, configure the firewall to shut down completely when it is connected to a domain network and you can configure the firewall to turn on with its most protective settings when you connect the computer to a public network. You can also configure the firewall’s notification options, its logging behavior, and how it reacts when rules conflict.

The allowed applications that you can configure in the Windows Firewall control panel are a relatively friendly method for working with firewall rules. In the Windows Firewall With Advanced Security console, you can work with the rules in their raw form.

Selecting either Inbound Rules or Outbound Rules in the left pane displays a list of all the rules operating in that direction, as shown in Figure 6-24. The rules that are currently operational have a check mark in a green circle next to them; the rules not in force are unavailable.

The Inbound Rules list in the Windows Firewall With Advanced Security console
Figure 6-24. The Inbound Rules list in the Windows Firewall With Advanced Security console

Creating new rules by using this interface provides much more flexibility than the Windows Firewall control panel. When you right-click the Inbound Rules (or Outbound Rules) node and select New Rule from the shortcut menu, the New Inbound (or Outbound) Rule Wizard takes you through the process of configuring the following sets of parameters:

The rules you can create by using the wizards range from simple program rules, like those you can create in the Windows Firewall control panel, to highly complex and specific rules that block or allow only specific types of traffic between specific computers. The more complicated the rules become, however, the more you have to know about TCP/IP communications in general and the specific behavior of your applications. Modifying the default firewall settings to accommodate some special applications is relatively simple, but creating an entirely new firewall configuration is a formidable task.

The process of creating and modifying rules in the Windows Firewall With Advanced Security console can be time-consuming, and repeating the process on multiple computers even more so. Therefore, the console makes it possible for you to save the rules and settings you have created by exporting them to a policy file.

A policy file is a file with a .wfw extension that contains all the property settings in a Windows Firewall installation and all its rules, including the preconfigured rules and those you have created or modified. To create a policy file, select Export Policy from the Action menu in the Windows Firewall With Advanced Security console, and then specify a name and location for the file.

You can then duplicate the rules and settings on another computer by copying the file and using the Import Policy function to read in the contents.

Importing Policies

When you import policies from a file, the console warns you that all existing rules and settings will be overwritten. You must therefore be careful not to create custom rules on a computer and then expect to import other rules by using a policy file.

The Windows Firewall With Advanced Security console makes it possible to create complex firewall configurations, but Windows Firewall is still an application designed to protect a single computer from intrusion. If you have a large number of servers running Windows Server 2012 R2, manually creating a complex firewall configuration on each one can be a lengthy process. Therefore, as with most Windows configuration tasks, administrators can distribute firewall settings to computers throughout the network by using Group Policy.

When you edit a GPO and browse to the Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall With Advanced Security node, you see an interface that is nearly identical to the Windows Firewall With Advanced Security console.

You can configure Windows Firewall properties and create inbound, outbound, and connection security rules, just as you would in the console. The difference is that you can then deploy those settings to computers anywhere on the network by linking the GPO to an AD DS domain, site, or OU object.

When you open a new GPO, the Windows Firewall With Advanced Security node contains no rules. The preconfigured rules that you find on every computer running Windows Server 2012 R2 are not there. You can create new rules from scratch to deploy to the network, or you can import settings from a policy file, just as you can in the Windows Firewall With Advanced Security console.

Group Policy does not overwrite the entire Windows Firewall configuration like importing a policy file does. When you deploy firewall rules and settings by using Group Policy, the rules in the GPO are combined with the existing rules on the target computers. The only exception is when you deploy rules with the identical names as existing rules. In that case, the GPO settings overwrite those found on the target computers.

Windows Server 2012 R2 also includes a feature that incorporates IPsec data protection into the Windows Firewall. The IP Security (IPsec) standards are a collection of documents that define a method for securing data while it is in transit over a TCP/IP network. IPsec includes a connection establishment routine, during which computers authenticate each other before transmitting data, and a technique called tunneling, in which data packets are encapsulated within other packets for their protection.

In addition to inbound and outbound rules, the Windows Firewall With Advanced Security console enables you to create connection security rules by using the New Connection Security Rule Wizard. Connection security rules define the type of protection you want to apply to the communications that conform to Windows Firewall rules.

When you right-click the Connection Security Rules node and select New Rule from the shortcut menu, the New Connection Security Rule Wizard takes you through the process of configuring the following sets of parameters, as follows:

Thought experiment: Configuring Windows Firewall

In the following thought experiment, apply what you’ve learned about this objective to predict what steps you need to take. You can find answers to these questions in the Answers section at the end of this chapter.

Ralph is a junior network administrator at Wingtip Toys. He has been left in change of the IT department while everyone else is out of town at a conference. Ralph receives a call from the company’s best customer, reporting that the customer is unable to place orders through the company’s website. Ralph examines the logs for the Windows web server and notices a huge amount of incoming traffic that began that morning.

Ralph suspects that the server is the target of a denial of service (DoS) attack, but he doesn’t have access to the network firewall and does not know anything about the firewall configuration his company uses. Ralph does have access to the Windows Firewall running on the web server, however. What temporary modifications can he make to that firewall to block the attack and allow the customer to submit orders as usual?

Objective summary

  • A firewall is a software program that protects a computer by allowing certain types of network traffic in and out of the system while blocking others.

  • A firewall is essentially a series of filters that examine the contents of packets and the traffic patterns to and from the network to determine which packets they should allow to pass through.

  • The default rules preconfigured into the firewall are designed to admit the traffic used by standard Windows networking functions, such as file and printer sharing. For outgoing network traffic, Windows Firewall allows all traffic to pass the firewall except that which conforms to a rule.

  • The Windows Firewall control panel is designed to enable administrators to perform basic firewall configuration tasks as needed.

  • For full access to the Windows Firewall configuration settings, you must use the Windows Firewall With Advanced Security snap-in for the MMC.

Objective review

Answer the following questions to test your knowledge of the information in this objective. 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 mechanisms is used most often in firewall rules to allow traffic onto the network?

    1. Hardware addresses

    2. IP addresses

    3. Protocol numbers

    4. Port numbers

  2. Connection security rules require that network traffic allowed through the firewall use which of the following security mechanisms?

    1. EFS

    2. IPsec

    3. UAC

    4. Kerberos

  3. Which of the following actions cannot be performed from the Windows Firewall control panel?

    1. Allowing an application through the firewall in all three profiles

    2. Blocking all incoming connections for any of the three profiles

    3. Creating firewall exceptions based on port numbers for all three profiles

    4. Turning Windows Firewall off for all three profiles

  4. Which of the following tools cannot enable and disable the Network Discovery firewall rules?

    1. File Explorer

    2. B. Network and Sharing Center

    3. Action Center

    4. Allowed Apps dialog box

  5. Which of the following statements about Windows Firewall are true? (Choose all that apply.)

    1. Applying firewall rules by using Group Policy overwrites all the firewall rules on the target computer.

    2. Applying firewall rules by using Group Policy combines the newly deployed rules with the ones already there.

    3. Importing firewall rules saved from another computer overwrites all the rules on the target system.

    4. Importing firewall rules saved from another computer combines both sets of settings.

Answers

This section contains the solutions to the thought experiments and answers to the objective review questions in this chapter.

Objective 6.1: Thought experiment

Alice must create another GPO containing the following setting, link it to the domain, and modify its Security Filtering by adding the Executives group and removing the Authenticated Users group. This GPO must take precedence over the Device Restrictions GPO.

  • Prevent installation of devices not described by other policy settings - Disabled

Objective 6.1: Review

  1. Correct answer: B

    1. Incorrect: Group Policy tools that use the older style administrative template (ADM) files do not look for them in the Central Store.

    2. Correct: Group Policy tools look for XML-based administrative template (ADMX) files in the Central Store by default.

    3. Incorrect: GPOs are stored in the Active Directory database, not the Central Store.

    4. Incorrect: Security templates are not found in the Central Store.

  2. Correct answer: D

    1. Incorrect: Local GPOs are applied first, before the administrators, nonadministrators, and user-specific local GPOs.

    2. Incorrect: Administrators local GPOs are applied after local GPOs and before user-specific local GPOs.

    3. Incorrect: Nonadministrators local GPOs are applied after local GPOs and before user-specific local GPOs.

    4. Correct: Of the local GPO types, user-specific local GPOs are applied last.

  3. Correct answer: C

    1. Incorrect: GPO linking applies Group Policy settings to the entire contents of an AD DS container.

    2. Incorrect: Administrative templates are the files defining the registry-based settings that appear in GPOs.

    3. Correct: Security filtering is a Group Policy feature that enables you to restrict the dissemination of Group Policy settings to specific users and groups within an AD DS container.

    4. Incorrect: Starter GPOs are templates used to create new GPOs.

  4. Correct answer: A

    1. Correct: Starter GPOs are templates that you can use to create multiple GPOs with the same set of baseline Administrative Templates settings.

    2. Incorrect: Starter GPOs are not applied by clients.

    3. Incorrect: Starter GPOs use the same interface as standard GPOs.

    4. Incorrect: Starter GPOs do not contain all the settings found in the default Domain Policy GPO.

  5. Correct answer: A

    1. Correct: A Not Configured policy setting has no effect on the existing setting of that policy.

    2. Incorrect: A Disabled setting remains disabled if you apply a GPO with a Not Configured value for the same setting.

    3. Incorrect: A Not Configured setting will not change a Disabled setting to Enabled.

    4. Incorrect: Policy setting conflicts result in overwritten settings but not errors.

Objective 6.2: Thought experiment

  1. 20. Of the workstation operating systems listed, only Windows 7, Windows XP Professional, and Windows 2000 Professional are able to use Group Policy.

  2. A. The only way to ensure that end users do not change the security settings on their computers is to deploy them by using Group Policy, which would require you to upgrade the operating system. Answers c and d would enable you to successfully deploy security templates on the computers, but the users would be able to modify the settings afterward.

Objective 6.2: Review

  1. Correct answer: C, D

    1. Incorrect: You cannot use Active Directory Users and Computers to apply a security template to a domain.

    2. Incorrect: You cannot use the Security Templates snap-in to apply a security template to a domain.

    3. Correct: You must use the Group Policy Object Editor to import a template into a GPO before you apply it to a domain.

    4. Correct. After importing the security template into a GPO, you can link it to a domain object and deploy the template settings.

  2. Correct answers: A, C

    1. Correct: By creating a standard user in Windows Control Panel, you are adding the account to the local Users group.

    2. Incorrect: You cannot add users to the Power Users group by using the Windows Control Panel.

    3. Correct: Granting a user administrative privileges in the Windows Control Panel adds the account to the local Administrators group.

    4. Incorrect: There is no Non-Administrators local group in Windows.

  3. Correct answer: B

    1. Incorrect: You cannot use Active Directory Users and Computers to modify the settings in a security template.

    2. Correct: You use the Security Templates snap-in to modify the settings in a security template.

    3. Incorrect: You cannot use the Group Policy Object Editor to modify the settings in a security template.

    4. Incorrect: You cannot use the Group Policy Management console to modify the settings in a security template.

  4. Correct answer: D

    1. Incorrect: Security options cannot provide the capabilities granted to the built-in local groups.

    2. Incorrect: Windows Firewall rules cannot provide the capabilities granted to the built-in local groups.

    3. Incorrect: NTFS permissions cannot provide the capabilities granted to the built-in local groups.

    4. Correct: Built-in local groups on a server running Windows Server 2012 R2 receive their special capabilities through user rights.

  5. Correct answer: A

    1. Correct: The Audit Directory Service Access policy audits only the objects you select in the Active Directory Users and Computers console.

    2. Incorrect: There is no need to wait for the policy settings to propagate to all the domain controllers.

    3. Incorrect: You configure the objects to be audited in the Active Directory Users and Computers console, not in the policy itself.

    4. Incorrect: Modifying the object names will have no effect.

Objective 6.3: Thought experiment

Sophie has to create two rules: an allow rule that grants the ResDev group access to the application and a deny rule that applies only to the RDint group. Because deny rules take precedence over allow rules in AppLocker, the interns will not be able to access the application.

Objective 6.3: Review

  1. Correct answer: D

    1. Incorrect: Hash rules is one of the software restriction rule types.

    2. Incorrect: Certificate rules is one of the software restriction rule types.

    3. Incorrect: Path rules is one of the software restriction rule types.

    4. Correct: Firewall rules is not one of the software restriction rule types.

  2. Correct answer: B

    1. Incorrect: The Basic User strategy prevents any application from running that requires administrative rights, but enables programs to run that only require resources that are accessible by normal users.

    2. Correct: The Disallowed strategy prevents all applications from running except those that are specifically allowed.

    3. Incorrect: There is no Power User strategy for enforcing software restrictions.

    4. Incorrect: The Unrestricted strategy enables all applications to run except those that are specifically excluded.

  3. Correct answers: B, C

    1. Incorrect: The hash is based on the file, not on its location, so moving it does not affect its functionality.

    2. Correct: Substituting a different version of the file renders the hash unusable.

    3. Correct: Modifying the file in any way renders the hash unusable.

    4. Incorrect: Changing the file’s permissions does not modify the file itself, so the hash remains functional.

  4. Correct answer: B

    1. Incorrect: Executable rules apply to files with .exe and .com extensions.

    2. Correct: Windows Installer rules apply to Windows Installer packages with .msi and .msp extensions.

    3. Incorrect: Script rules apply to script files with .ps1, .bat, .cmd, .vbs, and .js extensions.

    4. Incorrect: Packaged app rules apply to applications purchased through the Windows Store.

  5. Correct answer: A

    1. Correct: To use AppLocker, Windows Server 2012 R2 requires the Application Identity service to be running.

    2. Incorrect: The Application Management service is not necessary for Windows to apply AppLocker policies.

    3. Incorrect: The Credential Manager service is not necessary for Windows to apply AppLocker policies.

    4. Incorrect: The Network Connectivity Assistant service is not necessary for Windows to apply AppLocker policies.

Objective 6.4: Thought experiment

As a temporary measure, the administrator could create an IP address–based Windows Firewall rule that admits the traffic from the customer’s computer and blocks all other traffic. This would prevent the system from processing the DoS files.

Objective 6.4: Review

  1. Correct answer: D

    1. Incorrect: Firewalls can conceivably use hardware addresses to filter network traffic, but this is rarely a practical solution.

    2. Incorrect: Firewalls typically filter specific types of network traffic, not entire IP addresses.

    3. Incorrect: Filtering by protocol number typically does not provide the granularity needed to create an efficient firewall configuration.

    4. Correct: Firewalls typically use port numbers to allow traffic onto the network.

  2. Correct answer: B

    1. Incorrect: Encrypting File System only provides security for the storage medium, not for network traffic.

    2. Correct: Connection security rules require that network traffic allowed through the firewall use IPsec for security.

    3. Incorrect: User Account Control cannot restrict network traffic.

    4. Incorrect: Kerberos is an authentication protocol. It cannot restrict network traffic.

  3. Correct answer: C

    1. Incorrect: You can allow an application through the firewall for all three profiles by using the Windows Firewall control panel.

    2. Incorrect: You can use the Windows Firewall control panel to block all incoming connections for all three profiles.

    3. Correct: You cannot block traffic based on port numbers for all three profiles by using the Windows Firewall control panel.

    4. Incorrect: You can use the Windows Firewall control panel to turn the firewall on and off for any of the three profiles.

  4. Correct answer: C

    1. Incorrect: File Explorer displays a link that enables the Network Discovery rules.

    2. Incorrect: The Network and Sharing Center control panel contains a link that provides access to controls for the Network Discovery tools.

    3. Correct: The Action Center control panel does not contain Network Discovery controls.

    4. Incorrect: The Allowed Apps dialog box contains controls for the Network Discovery rules.

  5. Correct answers: B, C

    1. Incorrect: Firewall rules applied with Group Policy combine with the existing rules.

    2. Correct: Firewall rules applied with Group Policy combine with the existing rules.

    3. Correct: Importing Windows Firewall rules from another system overwrites all the existing rules.

    4. Incorrect: Importing rules overwrites the existing rules; it does not combine them.