Category Archives: Active Directory

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.

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:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall

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.

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. (https://www.cisa.gov/uscert/ncas/current-activity/2022/09/29/vmware-releases-guidance-virtualpita-virtualpie-and-virtualgate)

Mandiant released a blog yesterday on “Investigating Novel Malware Persistence Within ESXi Hypervisors” (https://www.mandiant.com/resources/blog/esxi-hypervisors-malware-persistence)

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.

Steps:

  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.
https://github.com/microsoft/New-KrbtgtKeys.ps1/blob/master/New-KrbtgtKeys.ps1

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).

Forcing ADFS 3.0 to run TLS 1.2

If you haven’t already forced ADFS to run on TLS 1.2 you are behind the curve. Activating TLS 1.2 on ADFS and turning off all other vulnerable services is relatively easy.

Step 1: Disable SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, RC4 & Enable Strong Auth for .NET

The first step that always goes unsaid is to snapshot your Virtual Machines or get a solid backup state before making any changes to a running production environment. The next unsaid step is to perform these activities on a test/dev environment before taking down Production!

SSL 2.0 and SSL 3.0 should already be disabled, if they are not disable them immediately! The following link from Microsoft provides the registry keys and powershell needed to disable all of these services. Make sure these changes are being made on all Web Application Proxies (WAPs) and ADFS servers.

  • Disable SSL 2.0
  • Disable SSL 3.0
  • Disable TLS 1.0
  • Disable TLS 1.1
  • Disable RC4
  • Enable Strong Authentication for .NET Applications

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs

Step 2: Reboot all Virtual Machines / Servers

This step is pretty self explanatory.

Step 3: ADFS is Br0ken, Oh Noes!!

Disabling TLS 1.0 will break ADFS 3.0, more specifically it breaks the connection between the WAPs and the ADFS servers. This is easy to fix though.

Following this article on re-establishing the trust: https://blog.rmilne.ca/2021/11/16/ad-fs-web-application-proxy-re-establish-proxy-trust/

Quick Recap: Change this registry value on the primary Web Application Proxy:

HKLM\Software\Microsoft\ADFS\ProxyConfigurationStatus –> 1

This value normally has a value of 2 (which means configured), change it back to 1, and this change does not even require a reboot.

Open up Server Manager and launch “Remote Access Manager”, select “Web Application Proxy” and put in the required information to re-establish the trust.

You may need to reboot the WAPs one more time, I had to.

Step 4: Verify SSL Services are Correct

Once all services come back up, it would be a good time to verify that all the services you think you turned off are actually off. A SSL Server Test tool would be great for that, like the one by SSL Labs: https://www.ssllabs.com/ssltest/

Step 5: You may need to correct internal .NET Applications pointing to ADFS

Internal .NET Applications may start failing. If you start to receive error messages like “Authentication failed because the remote party has closed the transport stream”, it just means you are not specifying TLS 1.2.

There is a great article on Microsoft Docs here that explains the situation and the fix: https://docs.microsoft.com/en-us/answers/questions/400152/authentication-failed-because-the-remote-party-has.html

The developers will just need to specify the SecurityProtocol in their application.

Monitoring Domain Controller Windows Firewall Logs (Part of Active Directory Hardening Series)

The first step before you can monitor the local DC firewall logs is to make sure you have properly setup your domain controllers to log firewall activity. If you have not already turned on firewall logging and increased the log size to the maximum you can configure that by looking at my prior post: https://paularquette.com/lock-down-your-active-directory-domain-controllers-internet-access-part-of-my-active-directory-hardening-series/

I have shared a new script on GitHub to do some basic monitoring of dropped traffic on your Domain Controllers. https://github.com/paularquette/Active-Directory/blob/main/AD_Monitor_DC_Firewall_Logs.ps1

I currently run this script every hour and I get plenty of overlap for logs. The logs roll relatively quick but not that quick. I’m also logging all allows and I may change that in the future to only log drops.

In order to see dropped traffic outbound you would have to have outgoing firewall rules in place. By default traffic is not blocked going out. You can reference my previous post linked above.

In the example below you can see I’m limiting all TCP/UDP outbound traffic on Non HTTP ports to a certain subset of IP ranges:

If this Domain Controller tries to send any NON-HTTP(s) traffic outside of the organization it will show up in the DC firewall logs.

Example of HTML Report:

If your IT Security group has the hardware firewalls super locked down you may not see much if any traffic being dropped on the local DCs, but it still isn’t a bad idea to have another layer of security around such a high profile service!

Changing vCenter Authentication [AD over LDAP(s)]

**EDIT** If you log into vcenter with an Active Directory account you should be able to modify an already existing Identity Source. I had been logging in with local administrator account.

For reference we already had our linked vCenter talking to Active Directory over LDAPS. However, we are currently in the process of migrating all of our VMs over to new hardware. When we tried to move the main Active Directory server providing authentication to vCenter, lets just say it was not happy.

Upon trying to enter into the Identity Sources and update the server(s) manually on the Identity Source that was already being used we received the following message: “Check the network settings and make sure you have network access to the identity source”.

It was not found until after doing some Googling that you have to remove your current running Identity Source in order to make changes. In other words delete the current identity source and add a “new” one in order to make the changes you want to make.

This just seems bad.

However, after doing a lot of testing in our TEST environment I could not seem to run into any snags. If you login with [email protected] and delete and then immediately re-add the identity source back with the same domain name, alias, etc, there does not seem to be any issues. All of your permissions on objects defined with AD groups will remain.

I used the method listed in this VMware KB for grabbing the certificates I needed for both the Primary and Secondary Active Directory Servers. (https://kb.vmware.com/s/article/2041378).

Lock down your Active Directory Domain Controllers internet access! (Part of my Active Directory Hardening Series)

If you want to follow the Security Technical Implementation Guide (STIG) for Active Directory you will come across V-53727, AD.0015, stating that internet access should be restricted. If you ask Microsoft what you should do, they also state internet access should be restricted but provide no clear mechanism to do so.

(https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack#blocking-internet-access-for-domain-controllers)

What is the best way to turn off browsing the internet on Domain Controllers that doesn’t involve contacting your Information Security team? I’m glad you asked. I’m going to walk you through the process I’ve put forward to implement locked down Windows Firewall rules on the Domain Controllers.

There may be criticism here that things could be locked down even more, and I DO NOT disagree with you. This article is more about getting started on locking down your Domain Controllers not the solve-all be-all guide. This write-up is one of many I hope to include in a Domain Controller Hardening Series.

NOTE: These Firewall Rules May Not Work For Your Organization! We are not running DHCP, WINS, or Integrated AD DNS. We also have RPC dynamic ports locked to 1,000 ports.

For changing RPC ports on the Domain Controllers, I followed this article:

https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-rpc-dynamic-port-allocation-with-firewalls

Create Group Policy and link it to Domain Controllers OU for Firewall Rules
(Set the scope to one DC if you are worried)

In this Group Policy, open it up and edit it and navigate to the following area:

  1. Computer Configuration
  2. Policies
  3. Windows Settings
  4. Security Settings
  5. Windows Firewall with Advanced Security

If you are implementing changes like this in a TEST environment which I highly recommend first and you happen to be connected to one of the DCs to do this work you will want to perform the following things first to prevent being disconnected.

These Domain Controllers should be behind a hardware firewall, so leaving all remote addresses set to ANY while you configure, you should still have protection from your hardware firewall until you can go through rule-by-rule and lock them down. I’m not providing any guidance here as all organizations are different.

Go to Inbound Rules and create your base ruleset.

Rule NameProtocolLocal Port
Active Directory Web ServicesTCP9389
NetBIOS Session ServiceTCP139
ICMPv4ICMPv4ANY
ICMPv6ICMPv6ANY
KerberosTCP88
KerberosUDP88
Kerberos Password ChangeTCP464
Kerberos Password ChangeUDP464
LDAPTCP389
LDAPUDP389
LDAP Global CatalogTCP3268
LDAPSTCP636
LDAPS Global CatalogTCP3269
NetBIOS Name ServiceTCP137
NetBIOS Name ServiceUDP137
NetBIOS Datagram ServiceUDP138
NTPUDP123
Remote Desktop ProtocolTCP3389
Remote Desktop ProtocolUDP3389
RPC Endpoint MapperTCP135
RPC Dynamically Assigned PortsTCP Example: 50000-51000
SMBTCP445
Windows Remote Management (WinRM)TCP5985-5986
These are created on ALL profiles

Go to Outbound Rules and create your base ruleset.

Rule NameRemote AddressProtocolLocal PortRemote Port
Allow ICMPv4, ICMPv6 OutboundAnyICMPv4/ICMPv6ANYANY
Allow All Traffic Outbound (TCP)AnyTCPANY1-79,81-442,444-65535
Allow All Traffic Outbound (UDP)AnyUDPANY1-79,81-442,444-65535
Allow Outbound Web Traffic Exceptions<IPs> Crowdstrike, PKI, etc.TCPANY80, 443
Allow Outbound Web Traffic Exceptions<IPs> Crowdstrike, PKI, etc.UDPANY80, 443
These are created on ALL profiles

By default Windows Firewall will allow all traffic outbound. These outbound rules are needed because I’m going to change the behavior to block traffic outbound by default and then put in an exception to most traffic out.

This is done to stop web traffic outbound on ports 80/443, except for the IPs we know are OK (for example Crowdstrike, or PKI services). You could and should argue that outbound traffic should be limited to your workplace but I’m not covering that level of specifics in this guide.

Right-Click “Windows Firewall with Advanced Security – LDAP://…” and click Properties.

Make sure the Firewall State is “On”, and Inbound Connections are set to “Block (default)” and Outbound Connections are set to “Block”. Verify these settings for all three Domain Profiles (Domain, Private, Public).

Next, while still in this dialog box under “Domain Profile” click Customize under Settings. I have turned off displaying a notification when a program is blocked. I have also disallowed rule merging. By turning off Rule Merging you will remove a lot of the “garbage” Microsoft Firewall Rules that are created by default. This will allow you full control of the Windows Firewall.

Next, click “Customize” under Logging, on the Domain Profile tab. Here, I’m using the default log location:
%systemroot%\system32\logfiles\firewall\pfirewall.log

I’ve also maximized the firewall log to 32MB, and I’m logging dropped packets and successful connections, this is needed for troubleshooting later.

Once this is complete you should be able to to run “gpupdate /force” on one of your Domain Controllers and launch Windows Firewall. The Windows Firewall current rules that are being enforced are found under “Monitoring -> Firewall”

You should see all of the rules that you setup enforced and you can now begin to lock down things potentially even more-so than the hardware firewall depending on your IT Security team.

This should be enough to get you started on your journey. If you have a close relationship with your IT Security Team, it would also be good to reach out to them and get their rule-set for your Domain Controllers. You may find that you can help IT Security lock down the hardware firewall even more!

PrintNightmare – [0Day] Windows Critical Vulnerability

I had been watching Twitter all day yesterday and amongst all the #infosecbikini photos filling up InfoSec Twitter there was mention of this critical Windows vulnerability. At first it sounded like the June patches would protect you, then Twitter seemed to lose faith that was the case.

The US Cybersecurity & Infrastructure Security Agency (CISA) released the following notice the evening of June 30, 2021. (https://us-cert.cisa.gov/ncas/current-activity/2021/06/30/printnightmare-critical-windows-print-spooler-vulnerability)

It has been recommended to disable the Windows Print spooler service on Domain Controllers and any systems that do not print.

EDIT: As of writing this entry the best workaround I have been able to find if you need to keep print services running is here: https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675-exploit-to-keep-your-print-servers-running-while-a-patch-is-not-available/

EDIT 2: Microsoft has finally responded: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527

EDIT 3: CISA put out emergency directive: https://cyber.dhs.gov/ed/21-04/

For your meme viewing pleasure: