Group policy oddities

Explanation: a lot of junk has been added to our Default Domain Policy & Default Domain Controller Policy. I was hoping to reset them with dcgpofix.exe. But obviously the first thing I did was (a) print them out, and (b) back them up. Obviously.

Except I couldn’t back up the DDC policy. Have 83 GPOs, and could only back up 82 successfully. Brilliantly, the error was “Backup of GPO failed. Error [Invalid pointer]”, which is hugely helpful.

This blog post – – got me pointed quite a long way in the right direction.

  1. Firstly, it’s the only place that seems to mention the fact that the group policy logging keys have to be DWORDs.
  2. Secondly it mentions that the cause could be erroneous user accounts/ SIDs (unlike which bangs on about DNS- my fix had nothing to do with DNS).
  3. Thirdly, the last line on moodjbow – “Search for lines including [WARNING] and google around for similar symptoms” – was precisely what led me to fix the issue once I’d got gpmgmt.log up and running.

The gpmgmt.log was reporting a couple of unresolvable SIDs and after hunting around pointlessly for SID convertion tools, I thought I’d have a dig about in some BUILTIN groups and lo and behold, there was a dodgy, legacy user in BUILTIN\Administrators. I deleted this, re-ran the backup and one of the warnings disappeared (tho’ the user has reappeared in BUILTIN\Administrators).

There was still one warning block left, which was:

“[3258.150c] 11/30/2017 13:57:30:243  [VERBOSE] ResolveTrustee(): Resolving account <DOMAIN\user> User Name <(null)>.
[3258.150c] 11/30/2017 13:57:30:259  [VERBOSE] ResolveTrustee(): Resolving account <S-1-5-21-1777476757-2052732148-4547331-26365> Domain Controller <(null)>.
[3258.150c] 11/30/2017 13:57:30:275  [VERBOSE] ResolveTrustee(): Account name is <user>
[3258.150c] 11/30/2017 13:57:30:290  [VERBOSE] CGPMBackupData::AddKnownSecurityPrincipal: SecurityPrincipal Added is DOMAIN\(null)
[3258.150c] 11/30/2017 13:57:30:306  [WARNING] CGPMBackupData::AddKnownSecurityPrincipal: GetFullAcctNameEx Failed with 0x80004003
[3258.150c] 11/30/2017 13:57:30:306  [WARNING] CGPMBackupData::PutSID: AddKnownSecurityPrincipal of S-1-5-21-1777476757-2052732148-4547331-26365 Failed with 0x80004003
[3258.150c] 11/30/2017 13:57:30:322  [WARNING] ProcessNameList: PutSID failed”

The user account in question had been disabled for ages withouth causing any apparent problems, so I just deleted it and the backup worked.

Time to fix? Actual remedial work was about 10 minutes, time spent digging around through Bing and Google was about 4 hours.



Having had this vulnerability flagged to us, we needed to figure out a way to run the detection tool against our estate. This is tricky because the tool is pretty much stand-alone; it can’t natively write to a centralised file or anything, so each PC generates its own isolated log file.

Having determined it’s quite hard to write the log files to a centralised store, I went old skool & set up a group policy that runs this batch file:

md C:\Support
md C:\Support\Scripts
copy \\domain.fqdn\netlogon\INTEL-SA-00086\INTEL-SA-00086.ps1 C:\Support\Scripts
%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\powershell.exe -File C:\Support\Scripts\INTEL-SA-00086.ps1

I’ve got this group policy attached to a WMI filter that negates Server OSs but it’s not necessary- servers can be just as vulnerable, but we did those manually and I’m reluctant to have junk copied automatically to all the servers without intervention.

Anyway, this creates a couple of folders at the root of C:\, copies a PowerShell script and runs it. The script is:

$result = Test-Path C:\Support\Intel\INTEL-SA-00086\$env:ComputerName.log

If($result -eq $false)
New-Item -Path "C:\" -Name "Support" -ItemType "directory" -ErrorAction SilentlyContinue
New-Item -Path "C:\Support" -Name "Intel" -ItemType "directory" -ErrorAction SilentlyContinue

Copy-Item -Path \\domain.fqdn\netlogon\INTEL-SA-00086 -Destination C:\Support\Intel -recurse -ErrorAction SilentlyContinue

Set-Location C:\Support\Intel\INTEL-SA-00086\DiscoveryTool

.\Intel-SA-00086-console.exe > C:\Support\Intel\INTEL-SA-00086\$env:ComputerName.log

$logFile = Get-Content C:\Support\Intel\INTEL-SA-00086\$env:ComputerName.log

$analysis = $logFile | Select-String "Based"

#Define hub transport server
$smtp_server = "smtp.server"

#Define email sender and recipient
$sender = "INTEL-SA-00086@primary.mail.domain"
$recipient = "user_1@primary.mail.domain","optional_user_2@primary.mail.domain"

#Define email subject and body
$msg_subject = "Analysis result of the SA-00086 detection tool on $env:ComputerName"
$msg_body_text = "Analysis result for $env:ComputerName is: $analysis`n`nThe script that generated this email is C:\Support\Intel\INTEL-SA-00086\INTEL-SA-00086.ps1"

#Send it
Send-MailMessage -to $recipient -from $sender -subject $msg_subject -body $msg_body_text -smtpserver $smtp_server -attachments C:\Support\Intel\INTEL-SA-00086\$env:ComputerName.log

And I’ve just noticed that the script uses PowerShell to create the same 2 folders the .cmd file creates. Oops. Anyway, the PS script:
* Initially checks to see if the log file it creates already exists;
* If it does, the script stops to avoid repeatedly sending the same data;
* It then creates a folder structure & copies the SA-00086 tool from a central location (netlogon is always handy) into this structure;
* It runs the tool & sends the output to a log file in the folder structure created above;
* It uses PowerShell to extract the contents of the log file, and identifies the string containing the analysis (vulnerable/ not vulnerable/ unsure);
* It puts this string into the body of the email & attaches the log file for completeness, then sends the email;
* The script uses $env:ComputerName throughout so each logfile is identified by the unique PC name;

That’s it- any collation of the data has to be done manually but you should end up with a vulnerability report from every device on your network, just once (hopefully).