Author Archives: paularquette

Managing Windows Server Core Firewall with Group Policy

As I’m migrating Domain Controllers over to Server Core one of the major issues I’ve run into is managing the Windows Firewall Rules. On a GUI version of Windows Server it is very easy to see what firewall rules are applied, in core… not so much, especially if you are pushing them with GPO (Group Policy).

All of the PowerShell cmdlets and netsh advfirewall commands all seem to return the local firewall rules and not any of the Group Policy pushed firewall rules. Moreover I could not find an easy way to see what the current firewall rules are that are applied via GPO.

As I have disabled all of the built-in firewall rules as to lock down the Domain Controller Firewall Rules as tightly as possible, even with RPC open and the dynamic RPC range locked to specific ports but open the Windows Firewall MMC would not open. I was seeing no blocked traffic in the Windows Firewall Logs.

I received the following error message:

“There was an error opening the Windows Firewall with Advanced Security snap-in”

“The specified computer could not be remotely managed. Ensure that you are not trying to connect to a remote computer with an earlier version of Windows…..”

My solution to this problem was to enable the built-in Firewall Rules for Remote Firewall Management so you can use MMC console:

Windows Firewall Remote Management (RPC)
Windows Firewall Remote Management (RPC-EPMAP)

These firewall rules seem to have some special magic to them that I haven’t put my finger on yet that allow the Remote MMC Firewall snap-in to work. You can of course lock these rules down to remote IPs as well.

Windows Server Core Cheat Sheet

I’m putting together a blog post for easy access to Windows Server Core tasks.

View Installed Programs (PowerShell):

Get-WMIObject Win32_SoftwareFeature|Select ProductName,Caption,Version|FT

Request New Certificate (PowerShell):

Get-Certificate -Template “_TEMPLATENAME” -SubjectName “CN = SERVERNAME.domain.suffix” -CertStoreLocation cert:\LocalMachine\My

Force Create Windows Firewall Log with Group Policy

In my previous blog ( I mentioned that simply turning on Group Policy for the Windows Firewall doesn’t actually create the firewall logs.

In order to force create the windows firewall logs for servers that are already out there in the wild I have created a batch script that can be ran in Group Policy as a startup script.

The script is located on my github but I’ve listed here as well because it is a small script. For the latest updates though please visit github as it is unlikely I will individually update this blog post.

rem Batch Script to Create Firewall Log Files
rem Written By: Paul Arquette
rem Last Modified: Oct 24, 2022
rem Last Modified For: Github

if exist C:\Windows\System32\LogFiles\firewall\pfirewall.log (
  echo file exists
) else (
  netsh advfirewall set allprofiles logging filename %systemroot%\System32\LogFiles\firewall\pfirewall.log
  netsh advfirewall set allprofiles logging maxfilesize 32767
  netsh advfirewall set allprofiles logging droppedconnections enable
  netsh advfirewall set allprofiles logging allowedconnections enable

Override Group Policy for the Windows Firewall

Did you apply a Windows Firewall Policy that blocks the ability to talk to Active Directory and get Group Policies? We all make mistakes….


You can no longer login to this box with Active Directory Credentials…..
You try to login as a local administrator and see that everything is grayed out?

On top of that you also turned off the ability to apply local firewall rules?

Don’t fear! There is a way to fix this as long as you have Local Admin rights on the box. Open up the Registry Editor and navigate to:

Right-Click the WindowsFirewall key and delete it and all sub-keys and reboot.

This should fix the issue and you will pull down the corrected Group Policy on reboot.

Windows Server Firewall Logging via GPO – Log File Not Created

When you try to enable Windows Firewall Logging via Group Policy you will notice that the Log Files are not created / do not exist.

You configure the GPO to setup logging:
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security (Right-Click -> Properties)

However, no matter how many “gpupdate /force” you run or reboots of the server you do, the “LogFiles” directory still does not contain a “firewall” folder, let alone the actual log files.

How do we fix this?

One thing you could do if are deploying from a template is configure the template so these files are created. However, this only fixes new server deployments going forward, doesn’t do much for the servers already out there running.

The good news is, the same commands that can be used to fix the template can also fix all the servers that are currently running out there in the wild.

The Fix

In order to make a blog that will work for Server GUI or Server Core I’m going to use netsh firewall commands, run these from an elevated “Administrator” command prompt or PowerShell window.

The first command will actually create the folder and files necessary, and group policy should be able to configure everything else.

These commands will create the folder/files, set the maximum file size for the log file to the maximum size allowed by windows, log dropped packets, and allowed packets.

netsh advfirewall set allprofiles logging filename %systemroot%\system32\LogFiles\firewall\pfirewall.log
netsh advfirewall set allprofiles logging maxfilesize 32767
netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

CISA, VMware, and Mandiant, Oh My!

CISA released an alert yesterday regarding VMware’s recommendations for threat hunting and securing your VMware environments from Malware due to Mandiant’s report. (

Mandiant released a blog yesterday on “Investigating Novel Malware Persistence Within ESXi Hypervisors” (

So what does this all mean for you?

First, don’t go running down the street with your hands in the air as Mandiant has not uncovered any vulnerabilities that were exploited to gain access to ESXi. Threat actors would still need the proper rights (root) on ESXi to install backdoor VIBs. However, since many people use central authentication systems like Active Directory though, it may be easier for threat actors to pivot into your environment if Active Directory is compromised.

The CISA link above provides all of VMware’s important links to make sure you are secured as possible. I’d highly recommend reading through all of the material here that VMware has put out.

The best thing you can do is setup Defense in Depth.

Resetting Domain Controller Computer Object Passwords Twice

There are times when you may need to reset the Domain Controller computer object passwords.

NOTE: You will have to move the PDC role to another DC in order to perform this task on the DC that currently holds this FSMO role.


  1. Logon to a Domain Controller as a Domain Admin with an interactive session.
  2. Temporarily Stop the “Kerberos Key Distribution Center” Service and set it’s Startup to Manual
  3. Run the following command:
    “netdom resetpwd /s:DC01 /ud:DOMAIN\DomAdmin /pd:*
    1. Enter the password the account specified above
  4. Restart the “Kerberos Key Distribution Center” Service and set it’s Startup to Automatic

You can pull the pwdLastSet field of the Domain Controllers to verify that the password did actually update.

In certain instances dealing with Cybersecurity & Incident Response you may need to perform this action twice on all Domain Controllers.

“Double-Tap” reset of the krbtgt account

We recently ran a “double-tap” reset of the krbtgt account in our Active Directory and ran into very few problems. We have the default 10 hour Kerberos ticket lifetime configured.

EDIT: The biggest issue was an internal .NET Portal that was federated with ADFS, it needed to be restarted

We ran the script that is out on Microsoft’s github repository.

We ran this first in our test environment and then scheduled the run for our Production environment a week night evening at 10pm to make sure people would be around if there were issues the following morning.

The recommended way to run this script is using the following modes:

  1. Mode 1 – Informational Run Only
  2. Mode 8 – Create bogus krbtgt test account
  3. Mode 2 – Simulation Run to verify replication
  4. Mode 3 – Simuation Run to verify replication and password reset of bogus krbtgt
  5. Mode 4 – Real Run, Modifying Real krbtgt Account
  6. Mode 9 – Cleanup bogus krbtgt test account

We ran Mode 3 and Mode 4 twice, on the second run of Mode 4 you will see some warning text that there could be a major domain impact.

The only major impact that was noticed in our environment was that remote desktop to many of our servers stopped working if using the fully qualified name. A workaround to this would be to use the IP which will use NTLM authentication.

However, after our 10 hour ticket time all machines were back to working as expected.

This script should be run a couple times a year depending on who you ask for only a single-tap reset of the account. I’ve heard recommendations from every 90 days to every 180 days. It should also be run anytime someone who can forge golden tickets leaves the environment (Twice if there is concern).