Daily Technotips: How to Implement Group Policy Security Filtering?

The most misleading thing about Group Policy is its name—Group Policy is simply not a way of applying policies to groups! Instead, Group Policy is applied to individual user accounts and computer accounts by linking Group Policy Objects (GPOs), which are collections of policy settings, to Active Directory containers (usually OUs but also domains and sites) where these user and computer accounts reside. So the newbie’s question concerning Group Policy is usually, “How can I get this GPO to apply to this group?” The answer to this question is: by implementing security filtering.

Understanding Security Filtering

Security filtering is based on the fact that GPOs have access control lists (ACLs) associated with them. These ACLs contain a series of ACEs for different security principals (user accounts, computer accounts, security groups and built-in special identities), and you can view the default ACL on a typical GPO as follows:

1. Open the Group Policy Management Console (GPMC)
2. Expand the console tree until you see the Group Policy Objects node.
3. Select a particular GPO under the Group Policy Objects node.
4. Select the Delegation tab in the right-hand pane (see Figure 1).

Figure 1: Viewing the ACL for the Vancouver GPO using the Delegation tab

For a more detailed view of the ACEs in this GPO ACL, click the Advanced button to display the familiar ACL Editor (Figure 2):

Figure 2: Viewing the ACL for the Vancouver GPO using the ACL Editor

An obvious difference between these two views is that the ACL Editor displays the Apply Group Policy permission while the Delegation tab doesn’t. This is because the Delegation tab only displays ACEs for security principles that actually process the GPO, and that implicitly means those security principals have the Apply Group Policy permission set to Allow. More specifically, if you want a GPO to be processed by a security principal in a container linked to the GPO, the security principal requires at a minimum the following permissions:

• Allow Read
• Allow Apply Group Policy

The actual details of the default ACEs for a newly created GPO are somewhat complex if you include advanced permissions, but here are the essentials as far as security filtering is concerned:

Security Principal	Read	Apply Group Policy
Authenticated Users	Allow	Allow
CREATOR OWNER	Allow (implicit)
Domain Admins	Allow
Enterprise Admins	Allow
ENTERPRISE DOMAIN CONTROLLERS	Allow
SYSTEM	Allow

Note that Domain Admins, Enterprise Admins and the SYSTEM built-in identity have additional permissions (Write, Create, Delete) that let these users create and manage the GPO. But since these additional permissions are not relevant as far as security filtering is concerned, we’ll ignore them for now.

The fact that Authenticated Users have both Read and Apply Group Policy permission means that the settings in the GPO are applied to them when the GPO is processed, that is, if they reside in a container to which the GPO is linked. But who exactly are Authenticated Users? The membership of this special identity is all security principals that have been authenticated by Active Directory. In other words, Authenticated Users includes all domain user accounts and computer accounts that have been authenticated by a domain controller on the network. So what this means is that by default the settings in a GPO apply to all user and computer accounts residing in the container linked to the GPO.

Using Security Filtering

Let’s now look at a simple scenario where you might use security filtering to resolve an issue in Group Policy design. Figure 3 below shows an OU structure I developed in a previous article. Note that the Vancouver top-level OU has three departments under it defined as second-level OUs, with user and computer accounts stored below these departments in third-level OUs:

Figure 3: Sample OU structure for Vancouver office

Let’s say that of the fifteen users who work in the Sales and Marketing Department in Vancouver, three of them are senior people who have special requirements, for example access to certain software that other people in the department shouldn’t have access to. Such software could be provided to them by publishing it in Add or Remove Programs using a user policy-based software installation GPO. The trouble is, if you link this GPO to the Sales and Marketing Users OU then all fifteen users in the department will have access to it through Add or Remove Programs. But you only want this special group of three users to be able to access the software, so what do you do? 

You could create another OU beneath the Sales and Marketing Users OU and call this new OU the Senior Sales and Marketing Users OU. Then you could move the user accounts for the three senior employees to this new OU and create your software installation GPO and link it to the new OU. While this approach will work, it has several disadvantages:

• It makes your OU structure deeper and more complicated, making it harder to understand.
• It disperses user accounts into more containers making them more difficult to manage.

A better solution is to leave your existing OU structure intact and all fifteen Sales and Marketing users in the Sales and Marketing Users OU, create your software installation GPO and link it to the Sales and Marketing Users OU (see Figure 4), and then use security filtering to configure the ACL on the software installation GPO to ensure that only the three senior users receive the policy.

Figure 4: Senior Sales and Marketing Users Software Installation GPO

To filter the software installation GPO so that only users Bob Smith, Mary Jones, and Tom Lee receive it during policy processing, let’s first use Active Directory Users and Computers to create a global group called Senior Sales and Marketing Users that has only these three users as members (see Figure 5):

Figure 5: Membership of the Senior Sales and Marketing Users global group

Note that you can store this security group in any container in the domain, but for simplicity you’ll probably want to store it in the Sales and Marketing Users GPO since that’s where its members reside.

Now go back to the GPMC with the software installation GPO selected in the left-hand pane, and on the Scope tab of the right-hand pane, remove the Authenticated Users special identity from the Security Filtering section and then add the Senior Sales and Marketing Users global group (Figure 6):

Figure 6: Filtering the GPO so it only targets the Senior Sales and Marketing Users group

That’s it, we’re done! Now when policy is processed for a user account residing in the Sales and Marketing Users OU, the Group Policy engine on the client will first determine which GPOs need to be applied to the user. If the user is a member of the Senior Sales and Marketing Users security group, the following GPOs will be applied in the following order (assuming we haven’t used blocking or enforcement anywhere):

1. Default Domain Policy
2. Vancouver GPO
3. Sales and Marketing GPO
4. Sales and Marketing Users GPO
5. Senior Sales and Marketing Users GPO

The Power of Security Filtering

The power of security filtering is that it allows us to simplify our OU structure while still ensuring that Group Policy is processed as designed. For example, in my original OU structure for Vancouver (see Figure 3 above) I created separate OUs for three departments in that location, namely the IT Department, Management, and Sales and Marketing. In Toronto however I could have taken a different approach and lump all my users and computers together like this (Figure 7):

Figure 7: Toronto has a simpler OU structure than Vancouver

Then I could group user and computer accounts in Toronto into global groups like this:

• IT Department Users
• IT Department Computers
• Management Users
• Management Computers
• Sales and Marketing Users
• Sales and Marketing Computers

I could then create GPOs for each group of users and computers in Toronto, link these GPOs to the appropriate container, and use security filtering to ensure they are applied only to the desired security principals (Figure 8):

Figure 8: Using Group Policy to manage users in Toronto

The main downside of this approach is that as you flatten your OU structure you can end up with lots of GPOs linked to each OU, which can make it harder at first glance to figure out which policies are processed by each user or computer unless you examine in detail the security filtering setup

http://dailytechnotips.blogspot.in/

How To Disable AutoRun / AutoPlay In Windows 7 & Windows 8

Disable AutoRun / AutoPlay Using Local Group Policy Editor

Step 1: Pull up the Run dialog box (Win + R) and type gpedit.msc. Hit Enter to launch the Local Group Policy Editor.

Step 2: Within Group Policy Editor, navigate to this location:

Computer Configuration > Administrative Templates > Windows Components > AutoPlay Policies

Step 3: Double-click the Turn off Autoplay option to edit its settings, select Enabled, and then select All drives in the options panel below. Hit Apply when done.

Step 4: Restart your computer.

That’s it; the AutoRun feature has been completely disabled for all users, and for all drives that connect to your machine.

Disable AutoRun / AutoPlay Using Registry Editor

Should you have a version of Windows that doesn’t ship with Local Group Policy Editor, follow these instructions.

Step 1: In the Run dialog, type regedit to launch the Registry Editor.

Step 2: Depending on whether you want to disable AutoRun for all users or just for the current one, navigate to either of these registry keys (the first one is for all users):

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\policies\Explorer\

Step 3: Within this subkey, locate the setting labeled “NoDriveTypeAutoRun”. If it doesn’t exist, create a new 32-bit DWORD with this name and assign it the hexadecimal value 000000FF(Decimal 255).

Step 4: Restart the computer.

The DWORD defined above will disable AutoRun for all drives and devices, and will have the same effect that you would’ve gotten through Local Group Policy Editor.

Should you want to restore AutoPlay ever again, just reverse the changes that you made in these steps, and you should be good to go.

I am sharing this tech update from :

http://www.redmondpie.com/how-to-disable-autorun-autoplay-in-windows-7-and-windows-8/#

Advanced Group Policy Management - Editing Controlled GPOs

Editing a Controlled GPO

In the previous article of this series, Jacky Chen, an AGPM Editor, proposed creating a new controlled GPO named New York Computers – Power GPO. Karen Berg, an AGPM Approver, received Jacky's request and approved it. Karen then deployed the new GPO into the CONTOSO production environment and linked it to the New York Computers OU so the policy settings configured in the GPO would be applied to computers in that OU. However, the New York Computers – Power GPO was deployed in a pristine state, that is, with no policy settings configured. In line with company policy, Jacky now proposes that the active power plan for New York computers be changed to Power Saver.

Jacky begins by logging on to his administrator workstation and opens the Group Policy Management Console (GPMC). He selects the Change Control node and then on the Controlled tab as shown here:

Figure 1: Step 1 of editing the controlled GPO.

Before Jacky can edit the controlled GPO, he must first check the GPO out of the AGPM archive. Checking a GPO out of the archive prevents any other AGPM Editor from making changes to the GPO until Jacky finishes working with it. To check out the New York Computers – Power GPO, Jacky right-clicks on it and selects Check Out as shown here:

Figure 2: Step 2 of editing the controlled GPO.

In the Check Out GPO dialog that displays next, Jacky enters a comment to help track the history of all changes made to the GPO:

Figure 3: Step 3 of editing the controlled GPO.

After clicking OK, the checked out GPO is displayed with a red icon on the Controlled tab:

Figure 4: Step 4 of editing the controlled GPO.

The checked out GPO can now be edited, so Jacky right-clicks on the GPO and selects Edit from the context menu:

Figure 5: Step 5 of editing the controlled GPO.

Doing this opens the New York Computers – Power GPO in the Group Policy Management Editor for editing. Jacky navigates to the Select An Active Power Plan policy setting as shown next:

Figure 6: Step 6 of editing the controlled GPO.

Jacky double-clicks on the Select An Active Power Plan policy setting to open it for editing. He then enables the policy setting and selects Power Saver as the Active Power Plan:

Figure 7: Step 7 of editing the controlled GPO.

After clicking OK to close the policy setting and then closing the Group Policy Management Editor, Jacky returns to the Change Control node of the GPMC. He then right-clicks on the New York Computers – Power GPO on the Controlled tab and selects Check In to check the modified GPO back into the AGPM archive:

Figure 8: Step 8 of editing the controlled GPO.

In the Check In GPO dialog that is displayed next, Jacky enters a comment so the history of changes made to this GPO can be more easily tracked in the future:

Figure 9: Step 9 of editing the controlled GPO.

The New York Computers – Power GPO has now been configured, but only on the copy that is stored in the AGPM archive. The copy of this controlled GPO that exists in the CONTOSO production environment (i.e. in SYSVOL) has not been changed at this point, but Jacky is confident that he's configured the right policy changes so he decides to request redeployment of the GPO he has just modified. To do this, Jacky again right-clicks on the New York Computers – Power GPO and this time he selects Deploy from the shortcut menu:

Figure 10: Jacky requests redeployment of the controlled GPO he just modified.

Jacky adds his comment to the Submit Deploy Request as shown below:

Figure 11: Jacky's request for redeploying the controlled GPO to production.

Once Karen receives Jacky's Submit Deploy Request email via AGPM, it's up to her to review the changes and decide whether the modified GPO should be rolled out production. That's what we'll look at next.

Reviewing and Redeploying the Modified GPO

Karen, who as an AGPM Approver also holds the AGPM Reviewer role, is now going to review the changes that Jacky has made to the archived copy of the New York Computers – Power GPO and then redeploy the modified GPO into the production environment. To begin doing this, Karen logs on to her administrator workstation, opens the GPMC, selects the Change Control node, selects the Controlled tab, right-clicks on the New York Computers – Power GPO and selects History from the shortcut menu:

Figure 12: Step 1 of reviewing and redeploying a controlled GPO that has been modified.

In the History For dialog that displays next, the All States tab provides more information that Karen needs at he moment concerning the change history of the New York Computers – Power GPO:

Figure 13: Step 2 of reviewing and redeploying a controlled GPO that has been modified.

So Karen selects the Unique Versions tab and sees that the most recent change version was checked in by Jacky and is ready for her review:

Figure 14: Step 3 of reviewing and redeploying a controlled GPO that has been modified.

Karen then clicks the Differences button at the bottom left of the History For dialog shown above. Doing this opens Internet Explorer and displays any differences between the selected version of the controlled GPO (the version labeled "Checked in" in Figure 14 above) and the previous version of the same controlled GPO (the version labeled "Created" in Figure 14 above). The Difference Report shows that the only change Jacky made to the GPO was to enable the Active Power Plan policy setting and set it to Power Saver:

Figure 15: Step 4 of reviewing and redeploying a controlled GPO that has been modified.

Karen decides that the changes Jacky has made to the New York Computers – Power GPO are OK, so she closes Internet Explorer and clicks the Close button in the History For dialog shown in Figure 14 previously. Doing this displays the Approve Pending Operation dialog shown here:

Figure 16: Step 5 of reviewing and redeploying a controlled GPO that has been modified.

After typing her comment into the above dialog, Karen clicks Advanced to make sure the modified GPO will be redeployed properly. Clicking the Advanced button opens the GPO Links For Selected GPOs dialog, and Karen notes that redeploying the New York Computers – Power GPO will re-link it to the New York Computers OU as expected:

Figure 17: Step 6 of reviewing and redeploying a controlled GPO that has been modified.

Karen clicks OK to close the GPO Links For Selected GPOs dialog. Then she clicks OK in the Approve Pending Operation dialog shown previously in Figure 16. A progress bar indicates when the modified New York Computers – Power GPO has been redeployed into production:

Figure 18: Step 7 of reviewing and redeploying a controlled GPO that has been modified.

The modified GPO will now be applied to computers in New York according the usual Group Policy processing mechanisms.

Conclusion

In this article we've learned how to modify a controlled GPO, review changes made, and redeploy the modified GPO into your production environment. In the next article we'll examine how to roll back changes and perform other tasks with controlled GPOs using AGPM.