After digging around I’ve finally cracked how GPO’s work!!
As many of us know ActiveDirectory is just LDAP with a DNS server, and kerberos domain controller built in (plus a few extras that microsoft puts in to the directory tree, schema, and uses NTLM auth by default). Which works in tangent with a smb/cifs server.
For the longest of times most have avoided Global Policy Objects or GPOs. With all google searches going back to MSD or some random form where a JR engineer/SME that advises to “just use .NET or x product” who can blame them?! Well I could but only on a stoic level simply because GPO and LDAP was not invented by microsoft. That came from Big iron UNIX guys Bell Labs, IBM and SUN.
So its only natural to leverage GPOs within a Heterogeneous network for a wide range of applications.
Below is the extracted GPO for installing Avast on the DMS network:
dn: CN=e9c3bbfe-3375-48c0-b758-9949797a4383,CN=Packages,CN=Class Store,CN=Machin
e,CN={03573FCB-A852-42C4-82E9-6E055D76D839},CN=Policies,CN=System,DC=dms,DC=loc
al
objectClass: top
objectClass: packageRegistration
cn: e9c3bbfe-3375-48c0-b758-9949797a4383
distinguishedName: CN=e9c3bbfe-3375-48c0-b758-9949797a4383,CN=Packages,CN=Class
Store,CN=Machine,CN={03573FCB-A852-42C4-82E9-6E055D76D839},CN=Policies,CN=Syste
m,DC=dms,DC=local
instanceType: 4
whenCreated: 20170310152106.0Z
whenChanged: 20170310152106.0Z
displayName: Avast for Business
uSNCreated: 4033022
uSNChanged: 4033022
showInAdvancedViewOnly: TRUE
name: e9c3bbfe-3375-48c0-b758-9949797a4383
objectGUID:: {{BASE64 value redacted}}
msiScriptPath: \\dms.local\SysVol\dms.local\Policies\{03573FCB-A852-42C4-82E9-6E
055D76D839}\Machine\Applications\{E41D8EAA-A137-4A85-9F22-2D4656942D82}.aas
cOMClassID: 00000000-0000-0000-0000-000000000000:0
localeID: 1033
machineArchitecture: 1282
revision: 0
packageType: 5
packageName: Avast for Business
packageFlags: -1610593168
versionNumberHi: 12
versionNumberLo: 3
lastUpdateSequence: 20170310152106
msiFileList: 0:\\dms.local\SYSVOL\dms.local\scripts\avast_business_antivirus_set
up_online.msi
objectCategory: CN=Package-Registration,CN=Schema,CN=Configuration,DC=dms,DC=loc
al
upgradeProductCode:: {{BASE64 value redacted}}
productCode:: {{BASE64 value redacted}}
msiScriptName: A
installUiLevel: 5
dSCorePropagationData: 16010101000000.0Z
Some of the key points here are:
| attribute | usage |
|---|---|
| objectClass: packageRegistration | this is an GPO |
| objectClass: top | this is the top level object so all things below it inherited this object |
| displayName and packageName | name of the GPO |
| msiScriptPath | HTTP/CIFS Path too the automation script used by the os agent (like gpupdate or rpm/apt linux) |
| msiFileList | Enumeration of HTTP/CIFS Path to the actual installer (think rpm/apt package in linux) indexed by {num}:{path} |
| objectCategory | the DN for the GPO schema |
In our case all objects that live under CN=Policies,CN=System,DC=dms,DC=local get stored as a GPO on the domain while the dn defines two locations the first the GPO and the second the link CN=Packages,CN=Class Store,CN=Machine. Note that there is two UUID values in the DN where the first is the linked location (of which there can be many) the second is the absolute location where the record lives (from where its linked from).
Other attributes define how this object is handled by gpupdate or other consumers of the record. One should look at teh schema for further details: https://msdn.microsoft.com/en-us/library/ms683890(v=vs.85).aspx