Introduction to Local Group Policy Objects: Part 2

In the first of this two part series, I gave an introduction on Local Group Policy Objects. I explained why you would want to configure a computer’s LGPO, especially if you are tasked with managing them in a unsecured or public location, and how how easily it can be done. Basically, if your computers are not joined to a Active Directory domain which provides centralized administration and you needed some way to lock down those systems, you most likely needed to work with Local Group Policy Objects. In this second article, I will be explaining the concept of Multiple Local Group Policy Objects (MLGPO) along with the why’s and the how’s. I highly suggest you read over part 1 before continuing on.

The Limiting Factor of LGPO

Beginning with Windows 2000 and ending with Windows XP, LGPO’s were very linear and inflexible in nature. Configure the LGPO and it basically applied to everyone using the system, regardless of whether the user had administrator privileges or not. If you were using the computer, the LGPO applied to you whether you liked it or not. This was evident in our example demonstrated in part 1. When I applied the “Prevent changing window color and appearance” policy setting in the LGPO, it immediately prevented me from changing the Window Color scheme in the Personalization applet. This is great and all from a security stand point but I am the administrator of that computer! There was no way for me, by default, to say, only have the setting apply to standard users and exempt administrators. This might not seem like a problem for standard users (as most of the policy settings are to restrict them) but if you are the administrator, you’ll quickly find that some policy settings restrict the way you manage the computer as well. Remember, a LGPO applies to everyone. Here is a very simple example. Let’s say I wanted to prevent users from utilizing the Run command box. I enable the policy titled “Remove Run menu from Start Menu”, which is located in User Configuration/Administrative Template/Start Menu and Taskbar. Now, all users including myself, the administrator, will not be able to open a Run command box along with not being able to type in UNC paths in Internet Explorer to access shares on other computers. Here is the error message I receive when I hit the Windows key + R and try to access my local computer via UNC format in Internet Explorer:

As you can see, the results is exactly what you want to see for standard users who you don’t want messing around with your computer but if you are the administrator, just this policy setting alone can cause a lot of frustration. Being able to use UNC paths to connect to network resources in your workgroup is very important for administrators. With these and other restrictions enabled, do you configure the LGPO to temporarily disable these settings, perform the work needed as a administrator and then re-enable those settings again? Or do you simply find a work around? Well, these were the problems and questions many administrators had to face during the Windows 2000 and Windows XP era when it came to configuring a local computer’s LGPO.

Until now.

Introducing Multiple Local Group Policy Objects

Beginning with Windows Vista, Microsoft introduced the idea of MLGPO for stand-alone workstations. The concept is very easy to grasp. Rather than just having one level of configuration for a given computer, you can now have well, multiple levels instead hence the name MLGPO! This allows for a more granular control over how you configure a workstation in your environment. With MLGPO, you now have 2 or 3 more levels of configuration, depending on how you look at it. I’ll explain them here beginning with the least granular to the most granular configuration level.

1. Standard LGPO. This is the configuration level I have so far been referring to in both articles. Every policy setting configured at this level will affect everyone who uses the workstation, regardless of user account status.

2. Administrator/Non-Administrator. This is the level where all the magic happens. As the name implies, you can now configure two separate LGPO’s. One LGPO can be applied only to user accounts with administrator privileges on the workstation and the other LGPO will be applied only to non-administrator user accounts. It is important to understand here that Non-Administrators basically means everybody else NOT in the built-in Administrators group. Even Backup Operators and Power Users are considered Non-Administrators in this scenario.

3. User specific. For the most granular control, you can now append a separate LGPO to any user account created on that workstation! For example, if a user falls somewhere between a administrator and a standard user (Power Users, for example), than configuring a user-specific LGPO for just this one user account is now possible.

There is a catch though, sorta. By using other configuration level OTHER than the default LGPO, you can only configure policy settings in the User Configuration section of the LGPO. The Computer Configuration section is removed (you will see an example of this later). However, this really can’t be considered a disadvantage because with the Computer Configuration portion, you usually configure security and account policies in general that apply to the computer as a whole anyways. For example, you would configure Account Policies (like password settings and account locout) along with Local Policies (User Account Control, auditing) which apply to the computer as a whole. It is in the User Configuration portion that holds most of the settings you’ll want to configure relating to user accounts (people who actually log in to the computer) in general because it is the most granular and provides the most control, especially in the Administrative Template folder. You will have a better understanding of this after learning about MLGPO precedence described next.

MLGPO Processing and Precedence Order

With the new capability to create more than one LGPO, processing them also takes a new turn. Before MLGPO showed up, a workstation needed to process just one LGPO and call it a day. However, with multiple LGPO’s in the picture, how does the processing method change as well? Very simple. It’s called precedence order. Basically, a LGPO have a link order value applied to it which the computer uses to determine which one to apply first, second, and so on. The LGPO that is least specific will have a link value higher than one’s that is more specific. When speaking of MLGPO, we have three LGPO link values to determine (the values basically stay the same so don’t worry there). We have the LGPO, the Administrator/Non-Administrator LGPO and the user specific LGPO. So, the link values for them will look like this:

User specific LGPO = Link value 1
Administrator/Non-Administrator LGPO = Link value 2
LGPO = Link value 3

First the LGPO will be applied because it is the least specific. Then, whether if you are an administrator or non-administrator and if you have a LGPO configured for that level, it will apply next. Lastly, if there is a LGPO configured specifically for a user account, then that will apply last. Precedence is important if you have more than one LGPO with same policies configured. However, this really shouldn’t be a problem when speaking of a stand-alone workstation. Unlike computers connected to a Active Directory domain in where dozens of GPOs can be applied to a computer or user account, here in a workgroup environment, you only have to worry about one or two at most. Policy conflicts occur when two different LGPO levels applying to the computer/user having the same policy settings configured but with different values. For example, if the LGPO has the policy setting to disallow changing of wallpaper enabled but the Non-Administrator LGPO (which the user logging in is a part of) has the policy setting set to disabled, than what happens? To solve this conflict, we go back to precedence order. The most specific LGPO will win the conflict. Because the Non-Administrator LGPO is more specific and has a lower link value, the policy setting will be set to Disabled and the user will be allowed to change the wallpaper. However, you’ll see soon that you really shouldn’t be dealing with policy setting conflicts in a small workgroup environment.

MLGPO Possibilities

Now that you have a better understanding of how MLGPO operates, let’s take a look at some of the possibilities of when you should use MLGPO:

A) Separating administrators from others. As written earlier, one of the biggest headache of configuring LGPO prior to Windows Vista was due to how it applied to everyone on the computer. With the introduction of the Administrators/Non-Administrators separate LGPO, most if not all of the problems disappeared just like that. In most small workgroup environments, you were either a administrator or you were a standard user. Because you wanted to only limit what standard users were able to do on the computer and not the administrators themselves, all you have to do now is simply configure the Non-Administrator LGPO and that would be it! The standard users will be restricted while you, the administrator, will still be able to log in and perform whatever administrative tasks needed because the Non-Administrators LGPO doesn’t apply to you.

B) Special users. Think of them as users that should have different policies applied to them, rather more restrictive or more relaxed than the rest. For example, let’s say you’ve configured a pretty restrictive LGPO for Non-Administrators. Bob, who is in the Power Users group, needs many of the restrictions taken off but some to remain because he doesn’t have the need to join the Administrators group just yet. In this case, you can configure a specific user LGPO for just Bob’s user account with the specific settings.

As you can see, these two scenarios match the two new LGPO levels introduced in Windows Vista. Although we have more granularity, LGPO is still limited in scope. However, that should be obvious because Microsoft needs to make money as well and providing centralized management in a workgroup environment doesn’t give much incentive for other smaller businesses to upgrade to a domain environment! But that’s a debate for another day and another article.

Configuring MLGPO

Alright, it’s time to get down to business and see how to actually configure the different levels of LGPO. As you’ll see, it’s not hard at all.

1. By default, opening the Local Group Policy Editor by typing in gpedit.msc into your Start menu’s search bar only allows you to configure the default LGPO (link value 3) of the computer. You know, the one that will apply to everyone. Here, you’ll usually want to configure settings only in the Computer Configuration section. Remember, both Administrator/Non-Administrator and User Specific LGPO only allows you to configure the User Configuration settings. The Security Setting’s policy portion is where you’ll mainly want to look in.

2. Now, we will be configuring the Administrators/Non-Administrators LGPO. What we need to do is open up a blank MMC (Microsoft Management Console). Simply hit your Start Menu and type in MMC in the search box. Once you have the blank console opened, hit File –> Add/Remove Snap-in. You will now be presented with all the available snap-in’s to add to your custom console.

Scroll through the list until you find the Group Policy Object Editor snap-in. Select it and hit the Add button. The Group Policy Editor wizard should then appear. Hit the Browse button. We need to instruct the snap-in to focus on a specific LGPO level. So, in the next window, select the Users tab. Here you’ll see a list of all the users on the local computer along with the Administrators and Non-Administrators group. In my example, I will add both the Non-Administrators group and the user account for my sister, Jennie. Hit OK and then Finish.

You’ll have to re-add the snap-in and browse for the each target one by one. In the end though, they will all be present in that one console for you to configure. It’s a good idea to save the custom console so you don’t have to manually add the snap-in each time you need to configure the LGPO in the future.

3. It’s always easier to configure policy settings from least specific to most specific. So, I’ll go ahead and configure the Non-Administrators group first, which my sister’s user account is a part of. In this test, I’ll disable the ability for Non-Administrators to peek in the Programs Control panel. Basically, I don’t want them to view/uninstall/change/repair a program or the other abilities as listed in the description of the policy setting.

Since I am the administrator, this policy will not effect me. As evident, I can roam around in the Programs Control panel as if nothing changed.

Now, let’s head over to her account and see what happens.

As expected, she is denied access.

4. Now, let’s pretend I have many other standard users on the computer and I want all of them to be denied in the Programs Control panel except for my sister. I will now configure a specific LGPO linked to only her user account with the same setting as above, but set to Disabled this time around. If you haven’t already, you must first add the LGPO targeting the specific user in your MMC console by following the steps listed earlier. Once in the console, you drill down to the settings under the specific user portion of the LGPO. In my example, I will disable the setting. Keep in mind, I did not re-alter the Non-Administrators LGPO. The policy setting in that LGPO is still set to Enabled. Now, let’s log on to her account again and see what happens.

Once again, we got the desired results. Why? It all goes back to precedence order, remember? The most specific LGPO will win out against the least specific LGPO when there are conflicts.

Some Notes to Remember About LGPO

- Careful planning. As with all things, careful planning of LGPO implementation in your workgroup environment will on be to your benefit. You wouldn’t want to just randomly disable/enable a policy setting just because you have the power to do so. Think about each and every setting before making the final decision. If you have several computers that need the same LGPO configuration, it is best to keep some type of documentation on all the settings you have made. Because LGPO is ‘local’ to speak of, you will need to manually configure each and every LGPO on each workstation. This can be time consuming but once they are set, you really don’t have to touch it again unless changes need to be made.

- Keep it simple. Like mentioned earlier, most workgroup environments consists of just administrators and standard users. Therefore, in most cases, you’ll mostly want to restrict just standard user accounts and leave the administrators alone. By configuring just the Non-Administrators LGPO, you’ll have that accomplished. For other users that fall in between, you can consider configuring a user-specific LGPO. Remember that if you set restrictions for the Administrators group LGPO, other administrators configured on that same workstation can equally disable them if they have the knowledge. Therefore, take careful consideration in who you give full power to!

- Workarounds. Just because you’ve enabled some policy setting doesn’t mean it’s final. Some users are smart enough to actually find methods to bypass or work-around the restrictions you have put in place and it can hurt you if you don’t take them into consideration. For example, just because you enabled the policy to remove the Run box from the Start Menu doesn’t prevent someone from opening a command prompt to run the desired commands for them. Just because you removed the Programs Control panel doesn’t prevent users from uninstalling programs via the program’s uninstaller executable or from a third-party uninstaller application. Locking down Internet Explorer is a good practice but if you allow users to use other third party browsers like Firefox or Google Chrome, those settings will be worthless.

- Read the description. I can’t stress about this enough. Although we like to think we know everything, that’s usually not the case! Just because a policy setting seems simple enough by reading just the name of it, enabling it can have other effects as well. Using the remove Run menu from Start Menu policy setting again as an example, enabling this will also deny users the ability to type in UNC paths (\servershare) in Internet Explorer’s address bar. You certainly wouldn’t have figured that out just by reading the policy setting itself!

- Read the requirements. This is another huge point to remember when configuring LGPO. Each policy setting has a requirement in which operating system version(s) it can apply to. For example, the Remove Run Menu from Start Menu setting has a requirement of ‘At least Windows 2000′. Therefore, Windows 2000 and above operating systems (XP, Vista, 7) can have the setting be applied to it. However, policy settings in User Configuration/Administrative Templates/Control Panel/Add or Remove Programs mainly have settings that apply only to Windows Server 2003, XP, and Windows 2000. That means enabling these settings on a Windows Vista or Windows 7 machine will have no effect whatsoever.

 

In the End…

I hope everyone reading this 2 part article series on Local Group Policy Objects will get some sort of idea on how powerful (although limited in scope) it can be for workstations in a workgroup environment. Hey, not everyone has the money to dish out for a Windows Server 2003/2008 server and licensing. In fact, in certain scenarios, deploying one can actually do more harm than good. Sometimes, we just want something simple and effective in locking down systems. With the introduction of MLGPO configuration, local administrators have much more freedom in choosing how to lock down workstations they manage without being affected themselves on the same computer. What’s not to like about it?