Production¶

The lab shows HGPM on a domain made for it. This page is the order to follow on a real domain: each step with what it does, who runs it, and how to check it. The roles are those of the security model: Tier 0 (the administrators of the domain and the approvers), Tier 1 and Tier 2 (the technicians, who create GPOs that wait for an approval).

Before you start¶

Keep the consoles of a domain on the same version of HGPM: the configuration of a newer one is left out by an older one.

The steps¶

The posture, each day¶

Test-PSGPOSecurityPosture says who can create, change and link GPOs outside of Tier 0 and the workflow (hardening). It only reads: plan it as an account of no group, each day, with -SystemLog; the SIEM alerts on the event 4001 (a High finding).

# Once, as an administrator of the domain
New-ADServiceAccount -Name hgpm-posture -DNSHostName hgpm-posture.contoso.com -PrincipalsAllowedToRetrieveManagedPassword 'ADMIN-SERVER$'
Install-ADServiceAccount hgpm-posture                                     # on ADMIN-SERVER
Register-PSGPOEventSource                                                 # on ADMIN-SERVER, as an administrator

# Each day, as the gMSA: -LogonType Password with no password, Windows gets it
$action = New-ScheduledTaskAction -Execute 'pwsh.exe' -Argument '-NoProfile -Command "Import-Module HGPM; Test-PSGPOSecurityPosture -SystemLog | Out-Null"'
$principal = New-ScheduledTaskPrincipal -UserId 'CONTOSO\hgpm-posture$' -LogonType Password
Register-ScheduledTask -TaskName 'HGPM posture' -Action $action -Principal $principal -Trigger (New-ScheduledTaskTrigger -Daily -At 6am)

# Once, on a domain controller of Samba, as root
samba-tool user add hgpm-posture --random-password
samba-tool domain exportkeytab /root/hgpm-posture.keytab --principal=hgpm-posture
# Copied to the computer of the check, for the account hgpm only
sudo install -o hgpm -g hgpm -m 600 hgpm-posture.keytab /etc/hgpm/hgpm-posture.keytab

# Each day
echo '0 6 * * * hgpm kinit -k -t /etc/hgpm/hgpm-posture.keytab hgpm-posture && pwsh -NoProfile -Command "Import-Module HGPM; Test-PSGPOSecurityPosture -Server dc.contoso.com -SystemLog | Out-Null"' | sudo tee /etc/cron.d/hgpm-posture

The acceptance test¶

Before the technicians use it, as in the lab:

1. A technician of Tier 1 creates a GPO on an OU of its tier: it waits for an approval, applies to nobody, and the approver sees it in Waiting for approval.
2. The approver approves it with its security filtering groups: Domain Admins owns it, the technician reads it only (or edits its settings with EditSettings).
3. The technician tries an OU of Tier 2: it is greyed, the link is refused.
4. The Audit Log tool shows the changes, Verified; the SIEM receives the events of source HGPM.

Hardening the deployment¶

• Only Tier 0 writes SYSVOL\<domain>\PSGPOTools: the configuration decides the roles.
• Keep Workflow.Creators and Workflow.Approvers apart; never a group of every account.
• Give the approvers, Domain Admins and the purgers no other use: they are Tier 0.
• Plan with a gMSA or a dedicated account and its keytab (mode 600), never the password of a Domain Admin in a scheduled task.
• Check the posture each day (above): a right given beside the workflow, and forgotten, gives the domain controllers to an account outside of Tier 0.
• Audit the domain controllers too (Windows and Samba): a change made with another tool than HGPM is in their logs, not in its own.
• Send the log of the system to the SIEM: it keeps a copy of each change out of reach of the technicians.

Rollback¶

The GPOs, their links and their approvals stay as they are: they are the domain's, as GPMC leaves them.