GPO Workflows with nimux

Overview

Group Policy is one of the most powerful control planes in an Active Directory environment. A GPO can configure local administrators, registry values, startup scripts, scheduled tasks, firewall rules, and many other settings. That power makes GPO testing valuable, but also sensitive.

nimux includes GPO workflows so authorized operators can discover, inspect, backup, and modify policy paths in a controlled way. The focus should always be reversibility. If a test changes policy state, the operator should know what changed and how to roll it back.

Start with discovery

Before making any change, enumerate existing policy containers.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --gpos

LDAP can also enumerate GPO objects:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --gpos

Discovery should answer:

• Which GPOs exist?
• Which domain or OU paths are linked?
• Which policies are default versus custom?
• Which policy names are relevant to the assessment?
• Which accounts have write rights?

Do not modify a GPO just because it is writable. First determine what systems it applies to and how often those systems refresh policy.

Inspect before write

Any write-capable workflow should start with inspection and rollback planning. List the GPO file tree before changing it.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --gpo --ls --name WorkstationPolicy

Inspect a specific path when you need to confirm policy files:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --gpo --ls --name WorkstationPolicy --remote 'Machine'

If you need to retain a specific remote policy file before changing it, download that file explicitly and store it with engagement evidence.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --gpo --get 'GPT.INI' --name WorkstationPolicy --local ./WorkstationPolicy-GPT.INI.before

This gives you a baseline for reporting what changed without claiming an unsupported full-policy backup command.

Dry run and rollback records

When a command supports --dry-run, use it before making a change. When a command supports --rollback-out, write rollback records.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --gpo --set --name WorkstationPolicy \
  --replace description='dry-run validation' \
  --dry-run \
  --rollback-out gpo-rollback.jsonl

Rollback records should be stored with engagement evidence. They are especially useful when multiple operators are working in the same environment.

Linking and scope

GPO impact depends on where it is linked. A policy linked at the domain root can affect far more systems than one linked to a test OU. When validating GPO write paths, prefer the smallest safe scope.

A safe workflow is:

1. Identify a test OU or lab system. 2. Create or select a policy with limited scope. 3. Backup the policy. 4. Apply the smallest change necessary. 5. Wait for refresh or trigger it in a controlled way. 6. Validate impact. 7. Roll back.

If the only available link target is broad, stop and confirm scope with the customer or lab owner before proceeding.

Startup script pattern

Startup scripts can demonstrate policy impact, but they should be simple and reversible. Keep the script content harmless, scoped, and easy to remove. The nimux workflow uploads the script into the selected GPO path and updates the policy metadata.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --gpo --startup --name ScopedValidationGPO \
  --put ./startup-marker.bat \
  --rollback-out gpo-rollback.jsonl

After deployment, validate only the expected marker:

nimux winrm workstation01.corp.local -d corp.local -u operator -p '<password>' \
  --cmd 'type C:\Windows\Temp\nimux-gpo-marker.txt'

Remove the marker after validation.

Scheduled task pattern

Scheduled task GPO paths are common in real environments. They are also high impact. Use harmless validation commands and avoid persistent or recurring tasks unless the engagement specifically requires them.

A controlled validation task should write a small marker and should be removed during rollback.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --gpo --schtask --name ScopedValidationGPO \
  --task-name ScopedValidationTask \
  --task-cmd 'cmd.exe' \
  --task-args '/c whoami > C:\Windows\Temp\nimux-gpo-task.txt' \
  --rollback-out gpo-rollback.jsonl

Then validate:

nimux winrm workstation01.corp.local -d corp.local -u operator -p '<password>' \
  --cmd 'type C:\Windows\Temp\nimux-gpo-task.txt'

The report should explain which account context executed the task and which systems received the policy.

Waiting for refresh

GPO changes are not always immediate. Depending on the environment, refresh can take minutes. Domain controllers, workstations, and servers may behave differently. Avoid repeatedly changing the policy because you do not see instant results.

Suggested validation sequence:

• Confirm the GPO object was modified.
• Confirm SYSVOL files exist.
• Confirm the GPO link exists.
• Wait for the normal refresh interval or trigger refresh only if allowed.
• Validate the target.
• Roll back.

This patience prevents unnecessary churn.

Two-principal GPO chain

Some real Active Directory paths are not a single permission on a single object. A useful pattern is a two-principal GPO chain:

• Principal A can create a new GPO under CN=Policies,CN=System.
• Principal B can write the gPLink property on a site, domain, or OU object.
• A policy file path exists in SYSVOL for the GPO GUID.
• The policy is weaponized or configured for a controlled validation.
• The operator waits for policy refresh and validates the target.

This matters because BloodHound or manual ACL review may show separate edges that only become powerful when combined. One user can create the GPO, another can link it, and a third context may be needed to edit SYSVOL or validate the result.

Checking GPO container rights

The GPO container lives under:

CN=Policies,CN=System,DC=corp,DC=local

The key permission for GPO creation is often CreateChild on that container. With nimux, keep the check inside the command surface by collecting GPO and ACL data:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --gpos --json > gpos.jsonl

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --bloodhound \
  --bloodhound-out bloodhound-output

The important finding is not simply that a GPO can be created. It is who can create it and where that new policy can later be linked.

Creating a policy object safely

A GPO is an LDAP object and a SYSVOL file structure. If the test requires creating a new GPO, use a clear name and record the generated GUID.

Use the built-in GPO command and produce rollback records:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --gpo --create-gpo --name ScopedValidationGPO \
  --dry-run \
  --rollback-out scoped-gpo-rollback.jsonl

If the workflow creates an object, the GUID should go into your notes immediately.

Linking the policy with nimux

Creating a GPO does not make it apply. A GPO becomes effective when linked to a site, domain, or OU. The link is stored in the gPLink attribute. If another principal has WriteProperty over the link target, that principal may be able to attach the policy.

Collect ACL context before linking:

nimux ldap dc01.corp.local -d corp.local -u linker -p '<password>' \
  --acl \
  --dn 'OU=ScopedWorkstations,DC=corp,DC=local' \
  --json

Then link only to the approved target:

nimux ldap dc01.corp.local -d corp.local -u linker -p '<password>' \
  --gpo --link ScopedValidationGPO \
  --target 'OU=ScopedWorkstations,DC=corp,DC=local' \
  --rollback-out gpo-link-rollback.jsonl

Use a site link only if the scope explicitly allows it. Site-linked GPOs can affect many systems. In most real engagements, a test OU is safer.

SYSVOL structure and versioning

The LDAP object alone is not enough. The policy must also have the expected SYSVOL structure.

Neutral path:

\\corp.local\SYSVOL\corp.local\Policies\{GUID}

Common directories include:

Machine\Microsoft\Windows NT\SecEdit
User

A minimal GPT.ini has a version number and display name:

[General]
Version=0
displayName=ScopedValidationGPO

When policy content changes, versioning matters. Many tools update the versionNumber attribute and GPT.ini so clients notice the change. If the GPO object exists but clients never apply it, check the SYSVOL path, GPT.ini, and version values before changing anything else.

With nimux, verify the GPO file tree and update versioning from the same command surface:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --gpo --ls --name ScopedValidationGPO --remote 'Machine'

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --gpo --set --name ScopedValidationGPO \
  --replace versionNumber=2 \
  --rollback-out gpo-version-rollback.jsonl

Local administrator validation pattern

One common controlled validation is adding a test principal to local Administrators on a scoped machine. This is powerful and should only be done with clear permission.

A safer validation pattern is:

1. Create or select a scoped GPO. 2. Link it only to a test OU or approved site. 3. Add a known test principal. 4. Wait for policy refresh. 5. Validate local admin membership or remote management. 6. Remove the principal from the policy. 7. Confirm rollback.

For validation after refresh:

nimux winrm workstation01.corp.local -d corp.local -u testadmin -p '<password>' \
  --cmd whoami

Or verify group membership with an approved command:

nimux winrm workstation01.corp.local -d corp.local -u operator -p '<password>' \
  --cmd 'net localgroup administrators'

If the result takes several minutes, that may be normal. Avoid repeated edits while waiting.

What the chain proves

The two-principal GPO chain proves more than “a GPO was modified.” It proves that separated permissions can combine into control over systems that process the policy.

The report should say:

> Principal A could create a GPO under the policy container. Principal B could link a GPO to the scoped target. After the SYSVOL structure and policy content were prepared, the linked policy applied to the target system after refresh. This combination demonstrates that separated directory permissions can produce local administrative impact on affected systems.

That statement is much stronger than a screenshot of a tool saying “Done.”

Reporting GPO abuse paths

A GPO finding should describe the control relationship. For example:

> The operator account could modify a GPO linked to the workstation OU. A controlled marker-file startup script confirmed policy application on a scoped test workstation. This demonstrates that the account can influence local system behavior for computers receiving that policy.

Good reporting includes:

• GPO name.
• GPO GUID if available.
• Link target.
• Principal with write rights.
• Systems in scope.
• Change made.
• Validation method.
• Rollback status.

Do not only report that a command ran. Explain the administrative path and the systems affected.

Common mistakes

Common GPO mistakes include:

• Editing default policies unnecessarily.
• Testing on a broad OU.
• Forgetting SYSVOL file changes.
• Not backing up before writing.
• Not waiting for policy refresh.
• Leaving marker files or scheduled tasks behind.
• Reporting the symptom without the access path.

The safest GPO work is slow, explicit, and reversible.

Final thoughts

GPO workflows are powerful because they operate through the same mechanism administrators use to manage systems. That makes them realistic and high impact. It also means every change should be scoped, backed up, documented, and rolled back.

nimux gives operators a command surface for that process. The professional value comes from using it with discipline.