Question

try to find articles that deal with Active Directory Group Policies. Find articles that discuss the proper configurations or what happens when inherent policies override permissions.

Answer 1

Active Directory Group Policies

So far, this guide has provided an introduction to a directory service as well as many of the security considerations that you must manage to keep all objects secure. In addition, we have explored Microsoft AD, with all of its security control mechanisms. You should have a good understanding of the AD infrastructure areas that will require the most attention in order to protect your assets. The assets that need to be protected include user accounts, group accounts, data files, databases, and OS files.

In the previous chapter, we discussed the various methods that administrators have at their disposal to control these AD assets. We focused much of the discussion on delegation of administration, which allows administrators to offload many routine and mundane administrative tasks onto junior administrators, Help desk workers, and other employees of the company. GPOs are of particular interest for delegation, as they enable administrators to control the ability to create, link, edit, and view GPOs.

Before we dive into who will manage GPOs—we will tackle the details of controlling the management of GPOs in the next chapter—we must first establish a foundation of knowledge by exploring the basics of GPOs. One of the most important aspects of a GPO is its ability to control security for user and computer accounts in the domain. A GPO has almost 1000 policy settings. The security settings are spread throughout the structure of the GPO, so simply finding a specific GPO setting can be a daunting task. This chapter will lay out the structure of a GPO, indicating where the essential security policies reside, allowing you to efficiently find the settings that you need.

Once you're familiar with how a GPO is structured, it is important to understand how the GPOs interact with one another. This interaction follows routine inheritance rules, which is an aspect of GPOs that can be very frustrating as a result of the complexity. We will explore when, why, and how to use the tools that control inheritance of GPOs, tackling terms such as no override, block policy inheritance, security group filtering, and Windows Management Instrumentation (WMI) filtering.

As in the previous chapter, we will stress the point that AD, security, and GPOs must be designed. Failing to consider security and GPOs during the design of AD almost ensures disaster. The reason is the complexity that results from GPO implementation. Let's begin by defining policy-based security.

Policy-Based Security

When you think about policy-based security, you most likely consider terms such as consistency, reliability, uniformity, and standardization. In addition to these, you can also throw in customization, mandatory, and absolute. Policy-based security is provided through GPOs. Such has not always been the case with Microsoft OSs, but policy-based security is standard with Windows AD. When the first domain controller is installed in the first domain, tree, and forest, GPO security is in control. Even the default GPOs provide the structure for policy-based security, in the following manner:

• Consistency—The structure of a GPO provides consistency for all security settings by the way that the GPOs are applied. The intent of GPOs is to ensure that every time a computer starts or a user logs on, security is applied the same every time. This consistency is accomplished during authentication with the domain controllers, which are in control of the AD infrastructure. As long as the computer is a member of the domain and a user account from the domain is used for authentication, the security settings will always be applied.
• Reliability—Because GPOs are controlled by AD, DNS, and authentication, they are out of the hands of the user at logon. This setup ensures a reliable application of the GPOs, which provides a secure environment that is out of the control of any user or computer.
• Uniformity—GPOs are applied to OUs, the domain, or sites. This application typically will affect multiple objects (either user or computer accounts). Each object that is affected by the GPO will receive the same settings by default. This application provides for an easy way to ensure that multiple objects have uniform security settings applied to them.
• Standardization—The security settings that are built-in to GPOs are the common security settings that any environment will require. This commonality provides a standard that all GPOs begin with. If such were not the case, each GPO might have different settings and options, resulting in a confusing and irregular application of security throughout the domain.
• Customization—GPOs provide an almost endless interface for custom policy and security settings. From registry values to software installation, GPOs provide a method to customize settings for target computers. In addition, WMI filters allow GPOs to target computers with specific credentials for hardware, OSs, configurations, and more.
• Mandatory—When a GPO is applied to a target object, the setting is mandatory for that object. In most cases, the local GUI grays out, ensuring that it cannot be changed by the local user. If the setting is enabled to be changed locally, there are methods that enable you to change those settings back to the GPO settings as often as every couple of seconds.
• Absolute—With the ability for a GPO to mandate policy and security settings, then force the settings down to the target object, the GPO has the final, absolute say on any setting. This is comforting from an administrative standpoint, because many manual settings are only suggestive, allowing the local user to make changes that can only be changed back with another administrative manual alteration.

What Group Policies Control

If you are new to AD and GPOs, you might be wondering: What does a GPO control? First, consider Figure 3.1.

This figure represents the image that you should always conjure when you are asked what a GPO controls. The reason that this image is important is that it clearly answers the question. Notice that a GPO has two sections: Computer Configuration and User Configuration. These are the only two objects that GPOs can affect: computer and user accounts.

The next thing to consider when trying to answer this question is which object is being affected by the GPO policy that is configured. For this answer, you can also refer to Figure 3.1. If the policy that you set is under User Configuration, the policy will only affect user accounts. A policy that is set under the User Configuration section of the GPO can't affect a computer account. The same is true for the Computer Configuration section and policies in the GPO. These can only affect computer accounts.

If a GPO can only affect computer and user accounts, then what about the other objects? Can a GPO apply to an OU? Not exactly. An OU is an object that contains other objects, such as user and computer accounts. GPOs are linked to OUs; GPOs don't apply to OUs. A GPO linked to an OU will have an affect on all of the computer and user accounts in the OU and child OUs, but not to the OU itself. The same case can be made for the domain node and sites. GPOs are linked to these objects, they don't apply to these objects.

To make sure that this is clear, we will explore scenarios that will help you remember what GPOs apply to. All of the following scenarios will use the OU structure that Figure 3.2 shows.

Figure 3.2: OU structure for scenarios.

All of the scenarios will also use the following GPOs and links listed in Table 3.1.

GPO Name	Linked To	GPO Policy	Section
No Run Option	Users OU	Remove Run menu from Start Menu	User Configuration
Legal Notice	Client_comps	Legal Notice Caption Legal Notice Text	Computer Configuration

Table 3.1: GPOs used in the example scenarios.

The scenarios will use the accounts and the account locations that Table 3.2 shows.

Account name	Account type	Location
TomT	User	Users OU
james	User	Users OU
irving	User	Admin OU
diljeet_PC	Computer	Client_comps OU
jijo_PC	Computer	Client_comps OU
Server4	Computer	Servers OU
Employees	Group	Users OU

Table 3.2: User and group accounts used in the scenarios.

These are the permissions

Permissions

Override permissions with overridden permission highlighted

There are four settings for each permission capability:

Inherit

The default setting. If a capability is set to inherit, the user's permissions remain the same as they are in a less specific context, or another role where the capability is defined. For example, if a student is allowed to attempt quiz questions at the course level, their role in a specific quiz will inherit this setting. Ultimately, if permission is never allowed at any level, then the user will have no permission for that capability.

Allow

This enables a user to use a capability in a given context. This permission applies for the context that the role gets assigned plus all lower contexts. For example, if a user is assigned the role of student in a course, they will be able to start new discussions in all forums in that course (unless a forum contains an override with a prevent or prohibit value for the capability).

Prevent

By choosing this you are removing permission for this capability (only for this role), even if the users with this role were allowed that permission in a higher context. If any other role allows the same capability, even for a higher or lower context, this prevent will have no effect.

Prohibit

This is rarely needed, but occasionally you might want to completely deny permissions to a role in a way that can NOT be overridden at any lower context or by another role. An example of when you might need this is when an admin wants to prohibit one person from starting new discussions in any forum on the whole system. In this case they can create a role with that capability set to "Prohibit" and then assign it to that user in the system context.

Ability to override permissions

Users who have the capability moodle/role:override allowed or the capability moodle/role:safeoverride allowed) can override permissions for selected roles (as set in Allow role overrides).

The default manager role has the capability moodle/role:override allowed, and can override permissions for all other roles.

The default teacher role has the capability moodle/role:safeoverride allowed, and can override permissions for the roles of non-editing teacher, student and guest.

1. Moderating Access to Control Panel

Setting limits on a computers’ Control Panel creates a safer business environment. Through Control Panel, you can control all aspects of your computer. So, by moderating who has access to the computer, you can keep data and other resources safe. Perform the following steps:

1. In Group Policy Management Editor (opened for a user-created GPO), navigate to “User Configuration” “Administrative Templates” “Control Panel”.
2. In the right pane, double-click “Prohibit access to Control Panel and PC settings” policy in to open its properties.
3. Select “Enabled” from the three options.
4. Click “Apply” and “OK”.

Figure 1: Configuring Control panel settings through GPO

2. Prevent Windows from Storing LAN Manager Hash

Windows generates and stores user account passwords in “hashes.” Windows generates both a LAN Manager hash (LM hash) and a Windows NT hash (NT hash) of passwords. It stores them in the local Security Accounts Manager (SAM) database or Active Directory.

The LM hash is weak and prone to hacking. Therefore, you should prevent Windows from storing an LM hash of your passwords. Perform the following steps to do so:

1. In Group Policy Management Editor window (opened for a custom GPO), go to “Computer Configuration” “Windows Settings” “Security Settings” “Local Policies” “Security Options”.
2. In the right pane, double-click “Network security: Do not store LAN Manager hash value on next password change” policy.
3. Select “Define this policy setting” checkbox and click “Enabled.
4. Click “Apply” and “OK”.

Figure 2: Configuring policy to not store LAN Manager hash value policy

3. Control Access to Command Prompt

Command Prompts can be used to run commands that give high-level access to users and evade other restrictions on the system. So, to ensure system resources’ security, it’s wise to disable Command Prompt.

After you have disabled Command Prompt and someone tries to open a command window, the system will display a message stating that some settings are preventing this action. Perform the following steps:

1. In the window of Group Policy Management Editor (opened for a custom GPO), go to “User Configuration” “Windows Settings” “Policies” “Administrative Templates” “System”.
2. In the right pane, double-click “Prevent access to the command prompt” policy.
3. Click “Enabled” to apply the policy.
4. Click “Apply” and “OK”.

Figure 3: Prevent access to the command prompt window

4. Disable Forced System Restarts

Forced system restarts are common. For example, you may face a situation where you were working on your computer and Windows displays a message stating that your system needs to restart because of a security update.

In many cases, if you fail to notice the message or take some time to respond, the computer restarts automatically, and you lose important, unsaved work. To disable forced restart through GPO, perform the following steps:

1. In “Group Policy Management Editor” window (opened for a custom GPO), go to “Computer Configuration” “Administrative Templates” “Windows Component” “Windows Update”.
2. In the right pane, double-click “No auto-restart with logged on users for scheduled automatic updates installations” policy.
3. Click “Enabled” to enable the policy.
4. Click “Apply” and “OK”.

Figure 4: No system auto-restart with logged on users

5. Disallow Removable Media Drives, DVDs, CDs, and Floppy Drives

Removable media drives are very prone to infection, and they may also contain a virus or malware. If a user plugs an infected drive to a network computer, it can affect the entire network. Similarly, DVDs, CDs and Floppy Drives are prone to infection.

It is therefore best to disable all these drives entirely. Perform the following steps to do so:

1. In Group Policy Management Editor window (opened for a custom GPO), go to “User Configuration” “Policies” “Administrative Templates” “System” “Removable Storage Access”.
2. In the right pane, double-click “All removable storage classes: Deny all accesses” policy
3. Click “Enabled” to enable the policy.
4. Click “Apply” and “OK”.

Figure 5: Deny access to all removable storage classes

6. Restrict Software Installations

When you give users the freedom to install software, they may install unwanted apps that compromise your system. System admins will usually have to routinely do maintenance and cleaning of such systems. To be on the safe side, it’s advisable to prevent software installations through Group Policy:

1. In Group Policy Management Editor (opened for a custom GPO), go to “Computer Configuration” “Administrative Templates” “Windows Component” “Windows Installer”.
2. In the right pane, double-click “Prohibit User Install” policy.
3. Click “Enabled” to enable the policy
4. Click “Apply” and “OK”.

Figure 6: Restricting software installations

7. Disable Guest Account

Through a Guest Account, users can get access to sensitive data. Such accounts grant access to a Windows computer and do not require a password. Enabling this account means anyone can misuse and abuse access to your systems.

Thankfully, these accounts are disabled by default. It’s best to check that this is the case in your IT environment as, if this account is enabled in your domain, disabling it will prevent people from abusing access:

1. In Group Policy Management Editor (opened for a custom GPO), go to “Computer Configuration” “Windows Settings” “Security Settings” “Local Policies” “Security Options”.
2. In the right pane, double-click “Accounts: Guest Account Status” policy.
3. Select “Define this policy setting” checkbox and click “Disabled”.
4. Click “Apply” and “OK”.

Figure 7: Disabling guest account

8. Set Minimum Password Length to Higher Limits

Set the minimum password length to higher limits. For example, for elevated accounts, passwords should be set to at least 15 characters, and for regular accounts at least 12 characters. Setting a lower value for minimum password length creates unnecessary risk. The default setting is “zero” characters, so you will have to specify a number:

1. In Group Policy Management Editor window (opened for a custom GPO), go to “Computer Configuration” “Windows Settings” “Security Settings” “Account Policies” “Password Policy”.
2. In the right pane, double-click “Minimum password length” policy, select “Define this policy setting” checkbox.
3. Specify a value for the password length.
4. Click “Apply” and “OK”.

Figure 8: Configuring minimum password age policy setting

9. Set Maximum Password Age to Lower Limits

If you set the password expiration age to a lengthy period of time, users will not have to change it very frequently, which means it’s more likely a password could get stolen. Shorter password expiration periods are always preferred.

Windows’ default maximum password age is set to 42 days. The following screenshot shows the policy setting used for configuring “Maximum Password Age”. Perform the following steps:

1. In Group Policy Management Editor window (opened for a custom GPO), go to “Computer Configuration” “Windows Settings” “Security Settings” “Account Policies” “Password Policy”.
2. In the right pane, double-click “Maximum password age” policy.
3. Select “Define this policy setting” checkbox and specify a value.
4. Click “Apply” and “OK”.

Figure 9: Configuring maximum password age policy setting

10. Disable Anonymous SID Enumeration

Active Directory assigns a unique number to all security objects in Active Directory; including Users, Groups and others, called Security Identifiers (SID) numbers. In older Windows versions, users could query the SIDs to identify important users and groups. This provision can be exploited by hackers to get unauthorized access to data. By default, this setting is disabled, ensure that it remains that way. Perform the following steps:

1. In Group Policy Management Editor window, go to “Computer Configuration” “Policies” “Windows Settings” “Security Settings” “Local Policies” “Security Options”.
2. In the right pane, double-click “Network Access: Do not allow anonymous enumeration of SAM accounts and shares” policy setting.
3. Choose ‘Enabled’ and then click ‘Apply’ and ‘OK’ to save your settings.

If you get these Group Policy settings correct, your organization’s security will automatically be in a better state. Please make sure to apply the modified Group Policy Object to everyone and update the Group Policies to reflect them on all domain controllers in your environment.