Processing group policy with GP Extension

Question

I created a Group Policy extension that implements ProcessGroupPolicyEx. I sucesfully am notified when I receive a group policy.

I am however at a loss to how to read the policy from inside the GPO. The example stops at looping through GPOs:

 for( pCurGPO = pChangedGPOList; pCurGPO; pCurGPO = pCurGPO->pNext )
   {
       if( *pbAbort )
       {
           // Abort.
           break;
       }
       // ...
   }

That is fine, but how do I get the policy (the actual settings) inside the pCurGPO? I need to get either the settings that this GPO contains, or the registry key where it stores them. This is because I created multiple ADMX templates that target my extension, so I need to tell them apart.

So far, I've found some samples, but they assume that the extension knows what registries will be changed, in advance. However, in my case, I do not want the extension to make this assumption, I want it to check the updated GPO and determine exactly what is being changed.

Any pointers would be greatly appreciated.

Gladisgladney

if the ask is how to parse GPO struct msdn.microsoft.com/en-us/library/aa374173(v=vs.85).aspx why isn't this helpful? Aah I misread it. You're well past that. – Obmutescence

That tells me how to get information about the goo. However I cannot get information about what the GPO contains. For example, in my extension, I want to check if the GOP modified a particular subkey. – Gladisgladney

Yes I understand in my current setup I don't have an ability to help you with this one directly, but chrome has a bit of code that parses and figures out Group policy you can have a look? chromium.googlesource.com/experimental/chromium/src/+/… – Obmutescence

Answer 1

So after squirreling through the Chromium code (per amritanshu comment), I found one way which seems to work, however I am not yet understanding what exceptions there may be (if any):

1. get lpFileSysPath field of the pCurObj which will be a UNC path.
2. Append "\Registry.pol" to the path.
3. Read and parse the resulting file, which will be a PReg file.

The PReg file is documented here: https://msdn.microsoft.com/en-us/library/aa374407(v=vs.85).aspx

If anyone sees anything wrong with this approach, or knows of any exceptions for this algorithm, please let me know.

EDIT: Also found this blog with a better written, though similar explanation: https://redsigil.weebly.com/home/group-policy-callbacks-the-missing-documentation

Gladisgladney