About GPOs (Group Policy Objects)

The GPO is a method for managing the configuration of workstations and servers. They allow you to define a target security and installation configuration for the entire system.

The operation of GPOs is mainly based on the GPO client which runs on all Windows machines, user workstation or server. The Active Directory server only serves as storage for GPOs. This is why it is possible to define any Windows GPO on a Samba-AD, because the Samba-AD only stores them, a bit like a file server would do.

There are very partial implementations of GPO clients for Linux environments. However, most of the GPO models that are offered in the Group Policy Management console will not be supported by Linux GPO clients. If a GPO is assigned to a client that cannot interpret it, then the GPO will be ignored.

The Samba-AD domain controller does not take into account any GPOs that may be assigned to it. Instead, it takes into account the PSO objects that define password strategies.

From a Windows administrator’s point of view, GPOs with Samba-AD behave the same way tey would with an MS-AD domain controller. The Group Policy Management console starts identically on the administrator’s computer, and the GPOs apply identically on all Windows computers in the domain.

Anatomy of a GPO

A GPO consists of three components:

A GPO LDAP entry located under CN=Policies,CN=System,DC=ad,DC=tranquil,DC=it in the main partition of the AD, which contains the name, the GUID, as well as the editing rights of the GPO (especially if there is a delegation of rights). Basically this is the administrative information;
The contents of the GPO in the SYSVOL share, which contains in a directory named GUID, several instruction files. This is basically what the GPO will do.
A gPLink attribute assigned to an OU, or to an AD site, which defines which objects the GPO will apply to.

The rights to the files contained in the SYSVOL share are very important for the GPO client to accept and apply the GPO. If the rights are not correct, the GPO client will refuse to apply it.

User GPOs and machine GPOs

Each GPO consists of two separate parts that apply to two different types of objects. Thus with a GPO you can configure:

Machine parameters that will only apply to machines.
User settings that will only apply to users.

To simplify the administrator’s work, it is advisable not to mix user configurations and machine configurations in the same GPO.

Client Side Extension

There are lots of different types of GPOs, some for modifying registry keys, some for installing a MSI, some for modifying local groups on the machine, etc. These different types of GPOs are implemented through the CSE mechanism. The GPO contains a text or binary file containing the desired settings, it also defines the GUID of the CSE engine which must interpret the configuration files. There is for example the extension {35378EAC-683F-11D2-A89A-00C04FBBCFA2} which corresponds to the modification of a registry key.

It is possible to install additional CSEs, such as CSE for LAPS to automatically and regularly change the local administrator password of user workstations.

Default Domain GPOs

Two GPOs are created by default for the domain:

Default domain policy, GUID {31B2F340-016D-11D2-945F-00C04FB984F9}.
Default Domain Controller Policy, GUID {6AC1786C-016E-11D2-945E-00C04FB984F9}.

It is preferable NOT to modify these GPOs. They should NOT* be deleted either.

WMI Filters

When defining a GPO, it can be interesting to restrict it to certain types of workstations or users, for example a GPO that will only apply to Windows 7 workstations. For this, Microsoft proposes to use WMI filters to filter the GPO only on objects that respect certain conditions.

Be careful with WMI filters as the filter calculation can consume CPU and take time.

Delegating GPOs

It is possible to delegate control of an GPO to a person or group of persons. This allows administrators to make changes to GPOs that will apply to their scope of responsibility. However, it will still be necessary to ask an Administrator with the rights to create a new GPO, i.e. either a member of the Domain Admins group or a member of the Group Policy Owner group to create the new GPO and delegate it to the right group.

There is also an AD group present by default, Group Policy Owner, that can create and modify all GPOs. The ability to modify any GPO makes it easy in practice to take control of IT administrators’ jobs, so this right is ultimately similar to that of a domain administrator. This is why we recommend not to apply this group to people who are not themselves Domain Admins.

Limitation of GPOs

GPOs were imagined in the 90’s as the ultimate solution to all fleet management problems, whether it be installation, configuration, security, user session configuration, etc.

In practice there are a lot of things, such as software installation, that do not adapt well to the functioning of GPOs. Besides, Microsoft advises not to use GPOs for application deployment.

In addition, there is no reporting integrated into the GPO system. If you want to be sure that everything went well, it is necessary to launch locally on the computer the command gpresult /Z to have a report on the state of application of the GPO. If you don’t run the command on the workstation, you can get a remote report as long as the workstation can be reached from the IT administrator’s workstation, and the administrative shares are accessible. Moreover this information is not centralized and it will then be necessary to connect to all the machines of the park, one by one, to have an exhaustive return of the state of application of the GPO.

The use of WMI filters or the use of too many GPOs can slow down the starting up of a machine or the opening of a user’s session.

Recommendations in relation to GPOs

As mentioned earlier, the two default GPOs for the domain should not be changed. You should also be careful when applying GPOs not to apply them too high in the tree structure. Indeed a GPO linked to the AD root will also apply to system objects such as the Administrator account, the Domain Admins group, etc. and could have dangerous consequences.

It is therefore preferable to create a root OU for the Organization and to put all the objects underneath, this makes it possible to assign GPOs which will be valid for the whole structure without having any unexpected effect by applying onto system objects.