A rather distraught software developer was accused of stealing data from his previous employers. The company claimed he circumvented the USB monitoring system when copying files to a flash drive because IT couldn’t find any evidence in the logs that the files had been transferred to the removable drive. As a software developer, he had admin rights on his PC and the company is now threatening legal action.

I don’t know whether the company has any legal basis on which to make such threats, but as has been said many times before, giving users administrative rights unleashes the potential to override Group Policy, Windows security and any other defensive measures you decide to put in place on your systems.

It’s in everyone’s interest to work with the minimum privileges required to carry out the job at hand, especially if users want to avoid being held responsible for a major security incident. The likelihood of inadvertently causing a devastating virus outbreak, installing unlicensed software or otherwise circumventing security policy is significantly greater if running with admin rights. As the risks are not usually taken seriously, it can help to illustrate what the consequences of a virus attack or other security incident might be, not only for the company but also the employee.

Someone who pressures the IT department to run with admin rights without good reason and then infects the network with a virus, not only causes downtime for themselves, but makes extra work for the IT department and frequently the consequences are felt by other employees, who see their own machines infected or network services become unavailable. You could compare it to calling the doctor when the symptoms are nothing more than a minor sniffle, wasting valuable resources and denying those who are really ill the vital help they need.

It’s important to communicate the effect that computer misadventures can have. Pose the question: Do you really want to be responsible for downtime that brings the organization to a standstill? Teach users to be good corporate citizens by giving real-life analogies of IT security problems and examples of the possible consequences should something go awry.

64-bit Windows 7 fares better than its 32-bit counterpart in part due to the inclusion of kernel patch protection, a technology only available in 64-bit Windows 7 that protects the kernel from unauthorized changes. Windows 7 is less likely to be infected overall because of User Account Control (UAC), an umbrella term for a set of technologies that make the OS easier to work with as a standard user or specially protected administrator account (Protected Administrator).

The results reported in SIR v10 for Windows 7 would have been even better if more home users didn’t disable UAC, which is likely what many tech-savvy home and business users do considering the number of articles on the Internet about the evils of UAC and how to turn it off; and hence goes the old adage that people don’t always know what’s good for them. If your users currently run as protected administrators on Windows 7, configure UAC in Group Policy to make it a little harder for them to disable UAC – though it’s worth bearing in mind that if a user has admin rights, Group Policy settings can be circumvented with enough will.

While UAC has some benefits in enterprise computing, it is a user-driven technology. UAC elevation prompts require users to give consent, or provide an admin username and password, to perform administrative tasks, resulting in decisions being made by unqualified staff that affect the integrity and security of the OS.

UAC Protected Administrator accounts provide a lot of flexibility, with a limited degree of security, that wasn’t possible in Windows XP. Once you move to standard user accounts in Windows 7, users can no longer elevate privileges; and all tasks, anticipated or otherwise, must be made to work as a standard user, or IT will have to intervene and provide administrator credentials.

Predicting users’ every move and requirement isn’t possible, so if it’s not acceptable to restrict the computing experience with a standard user account, you’ll either need to leave the default user-driven UAC experience in place or deploy Avecto’s enterprise rights management solution – Privilege Guard.

As well as the ability to assign privileges to individual applications and tasks, Avecto’s software can be configured to allow users to run any process with administrative privileges. UAC prompts can be replaced with custom corporate messages and users can be prompted to provide a valid reason before elevation. An audit trail of privilege elevation events allows administrators to keep track of how privileges are used. Privilege Guard helps companies strike the right balance between the flexibility of user-driven UAC and policy-based IT controls, making Windows 7 more secure and mitigating unnecessary risks.

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.

WMI queries are composed using the WMI Query Language (WQL), which is a SQL-like language. Queries can be combined with logical operators and each query is executed against a particular WMI namespace. When you create a query, you must specify the namespace. The default namespace is root\CIMv2, which is appropriate for most WMI queries.

The WMI filter is a separate object from the GPO in the directory. To apply a WMI filter to a GPO, you link the filter to the GPO, which is shown in the WMI filtering section on the scope tab of a GPO in GPMC. A GPO can only have a single WMI filter, but the same WMI filter can be linked to multiple GPOs. WMI filters are evaluated on the target computer and applied whenever a Group Policy update is triggered.

Example 1 – Checking the Operating System Version

The Win32_OperatingSystem class is used to query operating system information. For instance, the following query can be used to check the operating system is Windows 7 or above:

Select * from Win32_OperatingSystem where Version >= 6.1

The above query will also include Windows Server 2008 R2, but we can refine this query and check the ProductType to restrict the query to desktop operating systems:

Select * from Win32_OperatingSystem where Version >= 6.1 and ProductType = 1

ProductType Values

Example 2 – Checking the System Type

The Win32_ComputerSystem class is used to query the system type. For instance, the following query can be used to check for a mobile system:

Select * from Win32_ComputerSystem where PCSystemType = 2

PCSystemType Values

AppLocker can ensure that users are only allowed to run authorized executables, installer packages and scripts. It provides a good selection of rules, including filename, publisher and file hash. In addition, it is possible to identify applications based on their file properties, such as product name and version, although this capability is restricted to signed applications.

The lack of support for management consoles and control panel applets, introduces a slight security concern, as unauthorized snap-ins and applets may be launched by the user. Other areas of Group Policy can be configured to hide control panel applets, but this does not stop a rogue control panel applet from actually running. Management console snap-ins can also be controlled through Group Policy settings, and although this does go further than superficial hiding of snap-ins, the whitelisting of third party snap-ins could prove challenging, so it’s a shame that AppLocker can’t control snap-ins through the restriction of msc files.

Although AppLocker can handle software installation packages, a high proportion of software installers will require local admin rights to install. Granting local admin rights to a user will make any attempt to control application execution a futile undertaking, as the user will effectively have complete control over their desktop, and so the white listing of software packages with AppLocker is severely limited.

Where AppLocker really disappoints is in its end user experience. The end user message that is displayed when an application is blocked can’t be configured, and so the IT department are not able to convey a meaningful message to their user base when an application is blocked. This is further compounded by the lack of any method for a user to request access to an unauthorized application. It’s highly unlikely that the IT department will get application control policies configured correctly first time, and so the lack of informative messaging and a user feedback mechanism will make the ongoing fine tuning and maintenance of policies more challenging.

The application of AppLocker to more advanced users, such as technical users or laptop users, could prove problematic, as applications can only be blocked, which may prove too restrictive and lead to productivity issues. The ability to warn and audit, as opposed to blocking, would have made it possible to apply AppLocker policies to a much broader range of users, but this capability is sadly lacking.

As with most of Microsoft’s built-in system management tools, AppLocker provides no reporting capabilities, which could make it difficult to fully assess the impact of the applied policies.

There is no doubting that AppLocker is a big improvement over Software Restriction Policies, but it still falls short in a number of areas, which may restrict its adoption to smaller implementations of task based workers, where users require little flexibility in their job role. As a user’s requirements become more complex, AppLocker could prove difficult to apply without severely compromising an end user’s productivity and creating a burden on the IT department to constantly update policies.

1. Implement Least Privilege

If you are serious about desktop lockdown then you really need to adopt least privilege. If users are logging on with admin rights (or power user rights) then locking down the desktop becomes an almost impossible and thankless task.

If the only thing stopping you from implementing least privilege is that users need to run problem applications, perform basic admin tasks, such as connecting printers, or install approved software, then consider a privilege management solution. Privilege management solutions enable individual applications to be elevated under a standard user account, making it possible to remove admin rights from users.

2. Review and Secure Access Control Lists (ACLs)

The access control lists (ACLs) on files and registry settings should be addressed before you get too concerned with applying the various group policy settings that can be used to lockdown the desktop. Many of the group policy settings simply hide features in the explorer shell and other applications, and are not necessarily securing the underlying desktop build.

Assuming you have implemented least privilege, you should ensure that users only have read and execute access to the operating system files and installed applications. If any applications run from the network then make sure that write access is also restricted on the relevant network shares.

The modification of ACLs on files and registry settings can be centralized through group policy security settings. 

3. Restrict Software Installation

Probably one of the biggest security and stability threats to the desktop build is the installation of unapproved software. Implementing least privilege will remove a large percentage of unapproved software installations, as most will require admin rights to install.

However, this still leaves you with a couple of potential problems. Firstly, how do you eliminate unapproved software that doesn’t require admin rights to install? Secondly, how do you allow a user to install approved software under a standard user account? The first of these problems can be solved with an application control solution, which I will cover in the next tip. The second problem requires a privilege management solution, which I covered in the first tip, implement least privilege.

If you decide to invest in a privilege management solution then ensure that this solution can handle elevated software installations and the installation of ActiveX controls in Internet Explorer.

4. Implement Application Control

Many unapproved applications can run as standalone executables or install with standard user rights. In order to eliminate these applications from the desktop build you will need to consider an application control tool.

If you are looking for an application control tool for Windows 7 then you should seriously consider AppLocker, as this is a standard part of Windows 7 and may be managed centrally through group policy. If your desktops are running Windows XP or Windows Vista, or you have a mixed environment, then consider Software Restriction Policies (SRP), although it lacks the flexibility of AppLocker and is more difficult to manage.

If you find that SRP or AppLocker are not adequate then there a number of third party solutions available that provide flexible application control. Some privilege management solutions also include application control, which will enable you to utilize a single solution to control the applications that run and the privileges assigned to them.

5. Audit and Refine Lockdown Policies

In addition to compliance, auditing is crucial to refining lockdown policies. You are unlikely to implement a perfect set of lockdown policies on your first attempt, but don’t let this discourage you.

Ensure that the solutions you use for privilege management and application control have comprehensive auditing capabilities. Understanding which applications have run with elevated rights and those that have been blocked from running will enable you to fine tune your lockdown policies.

Look for solutions that provide good end user messaging, as this will eliminate end user confusion, when a user has been prevented from running a privileged or unapproved application. In addition, mechanisms that allow a user to provide a reason for requiring access to a blocked application can help to remove the end user frustration that may result from inadvertently over-locking a user.

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.