Technical personnel sometimes require access to domain controllers, maybe to perform maintenance connected to backup, patching or a one-off task. This leaves security administrators with something of a quandary, as most of the work likely to be carried out requires full administrative access to the DC, and in turn the crown jewels – Active Directory.

Let’s make it simple and start off by saying that it’s not possible to separate AD and administrator permissions on a regular DC. If you need to grant a user domain administrator permissions to complete some work on a DC, you must trust that person with full access to the AD domain. Read-only domain controllers (RODCs) do exactly what they say on the tin and host a read-only copy of the Active Directory database. Wherever possible you should deploy RODCs, as any domain user can be given permission to install and manage the server without privileged access to Active Directory.

Windows IT professionals often assume that the built-in Server Operators group in AD gives the equivalent of local administrator access to DCs without elevated rights to Active Directory. This is not strictly true and any kind of administrative permission on a DC can result in the user gaining privileges to AD. All built-in AD groups that end in ‘Operators’ are legacy groups and shouldn’t be populated unless you have an application that requires it. For example, if you need to grant permission to perform backup duties, create a new group and assign rights as necessary.

One approach you could adopt to grant admin privileges to DCs is to issue a unique username and password each time access is requested. The credentials are assigned to a technician for a given period of time and for an agreed piece of work. This information is recorded and permissions revoked at the end of the allotted session. Setting up the user account and recording the necessary logon session details is often done manually, although can be automated. The person requesting access is responsible for anything that happens during their logon session. Nevertheless, you still need to trust that person with Active Directory.

Depending on the type of work being carried out, a 3rd-party solution, such as Avecto Privilege Guard, could be deployed to allow a standard user to run only pre-approved applications with elevated privileges, greatly reducing the risk involved. Even if a technician must perform a task regularly on a DC, think twice before granting permanent permissions to sensitive production systems and always make sure that all actions are audited.

Before we get to “What is the right amount of GPOs”, let’s start off with “Can I have too many GPOs?”

One of the problems with Group Policy, in general, is that there isn’t much “organization” inside the Group Policy Objects node within the GPMC. Simply, you get a flat list of GPO names – listed alphabetically. This isn’t ideal if you have, say, thousands of Group Policy Objects and are looking for one, in particular, needle in a haystack.

So, yes, when I see companies with thousands of GPOs, it’s likely (though not impossible) that means they have “too many GPOs”. If only for the reason that the list is very long and difficult to manage.

But then there’s the flip side to this question: Can I have “too few” GPOs. I’ve seen lots of environments with just this particular problem. Too few GPOs. What does “too few GPOs” look like?

First, it could mean that the organization has decided not to utilize Group Policy – a crying shame considering it has 39 “superpowers” in the box ready to deliver and manage your desktops. However, it also frequently means that administrators have tried to cram too many functions into one Group Policy Object. They’re mixing their policies and their preferences. They’re mixing their user side and their computer sides.

In short, they’re trying to cram as much stuff as they can into as few GPOs as possible. Not a good idea.

So, going back to the question of “What is the right amount of GPOs” – the answer will vary for each environment. However, my suggestion is only to put together items which make sense to be together, and create new GPOs for each unrelated set of items.

For instance, creating one GPO which handles “Firewall settings for Sales” could be 30 different settings inside one GPO. That’s a great use of putting things together (which are similar, and headed to manage the same type of resource).

However, creating a GPO which “Deploys WinZip, deletes U: Drive, and secures c:\Temp” is not a suggested way to have one GPO function. Instead break that GPO into different pieces so it becomes easier to troubleshoot if something goes wrong.

So – I tend to suggest more GPOs over less GPOs. The “penalty” might be slower login times if a client is set to receive lots of GPOs, but in my experience, even lots of GPOs applying to a client doesn’t significantly hinder login performance. As always, be sure to test this in your environment as different configurations could yield different results.

Note, that in no case can a client process more than 999 GPOs before the Group Policy engine gives up and dies.

And that’s definitely too many GPOs.

NetIQ GPA is an enterprise class change control solution that enables an organization to version control GPOs and edit them offline. The workflow within NetIQ GPA enables GPOs to be checked out, checked in, approved and then deployed to the live Active Directory. This avoids the problems that can occur when making live edits to GPOs and it enforces good practice by putting an approval process in place.

Privilege Guard Polices can be edited from within NetIQ GPA, in a similar manner to using Microsoft’s Group Policy Management Console (GPMC) in a live Active Directory.

To edit the Privilege Guard Policies in a version controlled GPO:

1. Launch NetIQ GPA.
2. Select the GPO that you would like to edit.
3. Select “Check Out” from the Action menu, which should launch the NetIQ Group Policy Management Editor (nqGPME).
4. Edit the Privilege Guard Policies in the Computer Configuration or User Configuration nodes in the same way you would in a live GPO in GPMC (see screenshot below).
5. Close the NetIQ GPME.
6. Select “Check In” from the Action menu in NetIQ GPA, which will check in the modified GPO.

Editing Privilege Guard Policies in NetIQ GPA

You are now in a position to approve and deploy the GPO to the live Active Directory using the “Approve Version” and “Export to AD” menu options respectively in NetIQ GPA.

In step 4, instead of editing the Privilege Guard Policies you could simply import the Privilege Guard Polices from an XML file that has previously been exported from a Privilege Guard console. Select the “Import Privilege Guard Policies…” menu option from the Privilege Guard Policies node to import policies from an XML file. You can also select “Export Privilege Guard Polices…” to export the policies to an XML file.

Even if you could build your own deployment mechanism that matched or even surpassed the features in Active Directory Group Policy, there would still be one over-riding reason not to do so … most organizations already have an Active Directory in place, and they have carefully designed and built an infrastructure that is suitable for their environment. So why provide them with a proprietary system for your product that requires additional servers and all of the dedicated training, management and support time that is required to set up and maintain this new infrastructure.

First of all, it’s worth dispelling a common misunderstanding at this point. Active Directory Group Policy does not mean that your product is limited to the registry based policy settings provided by ADM and ADMX files. Group Policy is completely extensible, and you can develop a management console that plugs directly into the Group Policy Editor, which can save data in any format to the Group Policy Template (GPT) portion of a Group Policy Object (GPO). The GPT is stored on SYSVOL and therefore requires no change to the Active Directory schema. Put simply, your product can save a structured set of policies in an XML file, or any other format that takes your fancy, as opposed to being restricted to simple registry based policy settings.

Another common concern is the efficiency of using Group Policy. Understanding a little more about the inner workings of Group Policy, helps to dispel this concern too. Group Policy is a “pull” technology, and each product must implement a Client Side Extension (CSE), which resides … yes, you guessed it, on the client computer. Each CSE is notified when there has been a change to one or more GPOs that are of interest to the client or logged on users. It is the CSE that is then responsible for downloading its policy settings from Active Directory, as GPOs are not just transferred in their entirety to the client computer. In other words, if a product’s CSE has not been installed on a client computer then the policy settings for that product will never be downloaded from Active Directory. It is an efficient mechanism, and the versioning of GPOs ensures that GPOs only need to be processed by a CSE when there has been a change to the policy settings or a change in the GPO precedence rules.

I should also point out that organizations who use Novell eDirectory need not feel left out either, as ZENworks supports Group Policy too, and for smaller companies with no directory services in place, there is always local Group Policy.