Windows Server 2019 – The power of Group Policy

Installing MySQL On CentOS 8

In a network that is based upon Windows Servers and Active Directory, it is almost always the case that the primary set of client computers are also based upon the Microsoft Windows operating systems, and that these machines are all domain-joined. Setting everything up this way not only makes sense from an organizational perspective inside Active Directory, but also allows centralized authentication across devices and applications, like we have already talked about. I know that in a couple of the examples I gave earlier in the book that I said something like, What about when a company has a security policy in place that… or Make sure your servers don’t get those existing security policies because… So what are these magical security policies anyway, and how do I set one up?

This is the power of Group Policy. It enables you to create Group Policy Objects (GPOs) that contain settings and configurations that you want to apply to either computers or users in your Active Directory domain. Once you have created and built out a GPO with a variety of settings, you then have the option to steer that GPO in whatever direction you choose. If you have a policy that you want applied to all desktop systems, you can point it at the appropriate OU or security group in Active Directory that houses all of your domain-joined desktop computers. Or maybe you created a GPO that only applies to your Windows 7 computers; you can filter it appropriately so that only those systems are receiving the policy. And the real magic is that the issuance of these settings happens automatically, simply by those computers being joined to your domain. You don’t have to touch the client systems at all in order to push settings to them via a GPO. You can tweak or lock down almost anything within the Windows operating system by using Group Policy.

So, once again, I’m looking in the list of available roles on my Windows Server 2019, and I am just not seeing one called Group Policy. Correct again: there isn’t one! In fact, if you have been following along with the lab setup in this book, you already have Group Policy fully functional in your network. Everything that Group Policy needs in order to work is part of Active Directory Domain Services. So, if you have a Domain Controller in your network, then you also have Group Policy on that same server, because all of the information Group Policy uses is stored inside the directory. Since the installation of the AD DS role is all we need in order to use Group Policy, and we have already done that on our Domain Controller, let’s jump right in and take a look at a few things that will enable you to start utilizing Group Policy in your environment right away. I have worked with many small businesses over the years that were running a Windows Server simply because that’s what everyone does, right? Whoever the IT guy or company was that set this server up for them certainly never showed them anything about GPOs, and so they have this powerful tool just sitting in the toolbox, unused and waiting to be unleashed. If you aren’t already using GPOs, I want you to open that box and give it a shot.

The Default Domain Policy

First, we need to figure out where we go on our Domain Controller so that we can create and manipulate Group Policy Objects. As is the case with any of the administrative tools on a Windows Server 2019, Server Manager is the central platform for opening up your console. Click on the Tools menu from inside Server Manager, and choose Group Policy Management.

Once the console has opened, expand your Forest name from the navigational tree on the left, and then also expand out Domains and choose your domain name. Inside, you will see some familiar-looking objects. This is a list of the organizational units that you created earlier and a couple of other folders alongside your OUs:

We will talk about why the list of OUs exists here shortly, but, for now, we want to focus on a particular GPO that is typically near the top of this list, immediately underneath the name of your domain. It is called Default Domain Policy. This GPO is plugged into Active Directory by default during installation, and it applies to every user and computer that is part of your domain directory. Since this GPO is completely enabled right off the bat and applies to everyone, it is a common place for companies to enforce global password policies or security rules that need to apply to everyone.

With any GPO that you see in the management console, if you right-click on that GPO and then choose Edit… you will see a new window open, and this GPO Editor contains all of the internals of that policy. This is where you make any settings or configurations that you want to be a part of that particular GPO. So, go ahead and edit your Default Domain Policy, and then navigate to Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies | Password Policy:

Here, you can see a list of the different options available to you for configuring the Password Policy within your domain. Double-clicking on any of these settings lets you modify them, and that change immediately starts to take effect on all of your domain-joined computers in the network. For example, you can see that the default Minimum password length is set to 7 characters. Many companies have already gone through much discussion about their own written policy on the standard length of passwords in the network, and in order to set up your new directory infrastructure to accept your decision, you simply modify this field. Changing the minimum password length to 12 characters here would immediately require the change be made for all user accounts the next time they reset their passwords.

If you look along the left-hand tree of the Group Policy Management Editor, you can see that there are an incredibly large amount of settings and configurations that can be pushed out via Group Policy. While the Default Domain Policy is a very quick and easy way to get some settings configured and pushed out to everyone, tread carefully when making changes to this default policy. Every time that you make a setting change in here, remember that it is going to affect everyone in your domain, including yourself. Many times you will be creating policies that do not need to apply to everyone, and in those cases, it is highly recommended that you stay away from the Default Domain Policy, and instead set up a brand new GPO for accomplishing whatever task it is that you are trying to put into place. In fact, some administrators recommend never touching the Default Domain Policy at all, and making sure to always utilize a new GPO whenever you have new settings to push into place. In practice, I see many companies using the built-in Default Domain Policy for password complexity requirements, but that’s it. All other changes or settings should be included in a new GPO.

Creating and linking a new GPO

If the best practice in general is to build a new GPO when we need to apply some settings, we’d better take a minute and cover that process. For this example, we are going to create a new GPO that plugs a list of trusted sites into Internet Explorer on our desktop computers. If you run a web application in your network that needs to run JavaScript or ActiveX controls, or something like that, it may be required that the website is part of the trusted sites list inside Internet Explorer in order for it to run properly. You could print off an instructions page for the helpdesk on how to do this on each computer, and have them spend the time doing it for every user who calls in because they cannot access the application. Or you could simply create a GPO that makes these changes for you automatically on every workstation, and save all of those phone calls. This is just one tiny example of the power that Group Policy possesses, but it’s a good example because it is something useful, and is a setting that is sort of buried way down in the GPO settings, so that you can get a feel for just how deep these capabilities go.

Inside the Group Policy Management console, right-click on the folder called Group Policy Objects, and choose New. Name your new GPO—mine is called Adding Trusted Sites—and then click on OK. Your new GPO now shows up in the list of available GPOs, but it is not yet applying to anyone or any computers. Before we assign this new GPO to anyone, let’s plug in that list of trusted sites so that the policy contains our configuration information. We have a new policy, but it’s currently void of any settings.

Right-click on the new GPO, and choose Edit…. Now navigate to Computer Configuration | Policies | Administrative Templates | Windows Components | Internet Explorer | Internet Control Panel | Security Page. See, I told you it was buried in there!

Now, double-click on Site to Zone Assignment List, and set it to Enabled. This allows you to click on the Show… button, within which you can enter websites and give them zone assignments. Each GPO setting has a nice descriptive text to accompany it, telling you exactly what that particular setting is for and what the options mean. As you can see in the text for this one, in order to set my websites to be trusted sites, I need to give them a zone assignment value of 2. And, just for fun, I also added in a site that I do not want to be accessible to my users, and gave it a zone value of 4 so that is a member of the restricted sites zone on all of my desktop computers. Here is my completed list:

Are we done? Almost. As soon as I click on the OK button, these settings are now stored in my Group Policy Object and are ready to be deployed, but at this point in time I have not assigned my new GPO to anything, so it is just sitting around waiting to be used.

Back inside the Group Policy Management console, find the location to which you want to link this new GPO. You can link a GPO to the top of the domain similar to the way that the Default Domain Policy works, and it would then apply to everything below that link. So, in effect, it would start applying to every machine in your domain network. For this particular example, we don’t want the Trusted Site’s settings to be quite so global, so we are going to create our link to a particular OU instead. That way, this new GPO will only apply to the machines that are stored inside that OU. I want to assign this GPO to my Accounting Desktops OU that I created earlier. So I simply find that OU, right-click on it, and then choose Link an Existing GPO…:

I now see a list of the GPOs that are available for linking. Choose the new Adding Trusted Sites GPO, and click on OK, and that’s it! The new GPO is now linked to the Desktop Computers OU, and will apply those settings to all machines that I place inside that OU.

You can link a GPO to more than one OU. Just follow the same process again, this time choosing a different OU where you want to make the link, and that GPO will now apply to both OUs that have active links. You can also remove individual links by clicking on the Group Policy Object itself in order to view its properties.

Filtering GPOs to particular devices

Now that you have created a GPO and linked it to particular OU, you have enough information in order to really start using Group Policy in your environment. Using links to determine what machines or users get what policies is the most common method that I see admins use, but there are many circumstances where you might want to take it a step further. What if you had a new GPO and had it linked to an OU that contained all of your desktop computers, but then decided that some of those machines needed the policy and some did not? It would be a headache to have to split those machines up into two separate OUs just for the purpose of this policy that you are building. This is where GPO Security Filtering comes into play.

Security filtering is the ability to filter a GPO down to particular Active Directory objects. On any given GPO in your directory, you can set filters so that the GPO only applies to particular users, particular computers, or even particular groups of users or computers. I find that using groups is especially useful. So, for our preceding example, where we have a policy that needs to apply only to some desktop computers, we could create a new Security Group inside Active Directory and add only those computers into the group. Once the GPO has been configured with that group listed in the filtering section, that policy would only apply to machines that are part of that group. In the future, if you needed to pull that policy away from some computers or add it to new computers, you simply add or remove machines from the group itself, and you don’t have to modify the GPO at all.

The Security Filtering section is displayed when you click on any GPO from inside the Group Policy Management console. Go ahead and open GPMC, and simply click once on one of your GPOs. On the right-hand side, you see the Scope open for that policy. The section on top shows you what Links are currently active on the policy, and the bottom half of the screen displays the Security Filtering section. You can see here that I have linked my GPO to the Accounting Desktops OU, but I have set an additional security filter so that only machines that are part of the Accounting – Trusted Sites group will actually receive the settings from my GPO:

Another cool feature that is just a click away is the Settings tab on this same screen. Click on that tab, and it will display all of the configurations currently set inside your GPO. This is very useful for checking over GPOs that someone else may have created, to see what settings are being modified.

As I mentioned earlier, you could take any one of these management consoles or topics regarding the core infrastructure services inside Windows Server and turn that topic into its own book. I actually had the opportunity to do exactly that with Group Policy. If you are interested in discovering more about Group Policy and all of the ways that it can be used to secure your infrastructure, check out Packt’s Mastering Windows Group Policy (

Comments are closed.