Michael Waterman

Monitoring Windows Firewall logs with Azure Monitor

April 21, 2026 / Michael Waterman / 0 Comments

In a previous blog, “On-prem Conditional Access You Never Knew You Had” I explored how the built-in Windows Firewall can be used as a powerful control mechanism to restrict access to systems, effectively bringing conditional access concepts to on-premises environments. The response to that post was overwhelming, with over 23,000 views on Reddit alone. Clearly, many organizations are interested in rethinking how they use the Windows Firewall beyond its default, often permissive configuration, and so should you/ But before you can confidently start restricting access, there is a fundamental question you need to answer:

What is actually being used in your environment?

In many cases, firewall rules have grown organically over time. Ports are opened “temporarily,” (read: we forget, so they will be open forever) exceptions are made for specific systems, and over the years, the rule set becomes difficult to understand, let alone control or optimize. Tightening those rules without proper insight is risky and can easily break critical services.

On-prem conditional access you never knew you had

April 17, 2026 / Michael Waterman / 2 Comments

We often associate Conditional Access with Entra ID, Cloud apps, and Zero Trust.
But long before cloud-native policy engines existed, Windows already had a way to enforce identity-based access between endpoints, and I mean really long ago. I would make the claim that we could go back to February of the year 2000, when Windows 2000 saw the light of day. Years later in the era of Windows Vista and Windows 7, we got the Windows Advanced Firewall and that can do so much more than just block or allow a port, I think it’s a really cool piece of software. The combination of Windows Firewall, Kerberos and IPsec effectively gives you on-prem Conditional Access for east-west traffic. In this post I’ll tell you a bit of history, which problems my blog solves and why you want to start using it. And for the folks that see the word “IPsec”, trust me, I’ll make it easy to use, promise!

Let’s dive in!

Trust me bro, chain validation

April 12, 2026 / Michael Waterman / 0 Comments

Recently I was working on a side project involving Windows AppLocker, or whatever the marketing people decided to call the tool this week. Same engine, different sticker.

Gone in a cipher, wiping deleted data the native windows way

April 5, 2026 / Michael Waterman / 1 Comment

Deleting a file in Windows rarely means the data is actually gone. In most cases, the file system simply removes the reference to the file while the underlying data remains untouched in unallocated space until it is overwritten. That is exactly why forensic tools can often recover deleted photos, documents, and other files long after a user believes they are gone.

When organizations need to prepare systems for redeployment, decommissioning, or internal reuse, many immediately look at commercial wiping solutions. What is often overlooked is that Windows already includes a native tool capable of securely overwriting deleted data: cipher.

And yes, it’s been there for a really long time.

The Case of the Missing Custom Templates

March 13, 2026 / Michael Waterman / 2 Comments

So, this turned out to be an interesting quest. I had reinstalled my lab Enterprise (issuing) CA, configured the server, issued new CA certificates, and created a new Remote Desktop certificate template. The next step should have been simple: publish the template.

Except it wasn’t. When I tried to publish the template, it didn’t show up.

Exploring the AD CS Database

March 11, 2026 / Michael Waterman / 5 Comments

I know, I know, last time I promised that this blog post would be about renewing the issuing CA certificate, but I have something cool today as well. I ran into an issue with my lab CA that made me dive into a rabbit hole filled with advanced certutil commands and direct access to the database. Instead of treating this as an incident and forget all the commands I’ve used to view and alter information I thought I would share the information.

When working with Active Directory Certificate Services (AD CS), most people interact with the Certification Authority through the MMC console. It provides a clear view of issued certificates, pending requests, and revoked certificates. It’s the easiest way. However, behind that interface sits a database that’s per default located in the directory: “C:\WINDOWS\system32\CertLog” and has the name of your CA, in my case “Corp-Enterprise-CA.edb“.

Renewing a Root CA Before Expiration

March 7, 2026 / Michael Waterman / 0 Comments

It was that time again. My Root CA had reached about 60% of its certificate lifetime, which means it was time to renew the certificate, a.k.a the dreaded ADCS Root CA Renewal (plays dramatic music). As I mentioned in a previous blog, if you’re going through the effort of renewing the certificate anyway, it’s generally a good idea to renew the key pair as well. However, there are a few gotchas that come with doing that, and that’s exactly what I want to cover in this week’s post.

Along the way I ran into a couple of things that are worth knowing before you start this process yourself. Nothing too dramatic, but definitely the kind of details that can come back to bite you later if you’re not aware of them.

PKI Certificate Lifetimes, from a Risk-Based Approach

February 23, 2026 / Michael Waterman / 0 Comments

In a few recent discussions about Public Key Infrastructure (PKI), certificate lifetimes are often treated as fixed best practices. A commonly cited example is a 10-year lifetime for a root Certification Authority (CA) and a 5-year lifetime for issuing CAs. More recently, some practitioners argue that such models are outdated and should be replaced with fully synchronized lifecycles or significantly shorter validity periods. At first glance, these claims appear to challenge long-standing PKI design principles. In practice, however, they often introduce more confusion than clarity. The discussion typically focuses on specific numbers, such as 10/5 or 10/10, without addressing the underlying assumptions means or operational context in which these values are applied.

The reality is that different PKI environments operate under fundamentally different constraints. Traditional enterprise infrastructures, highly automated cloud platforms, and hybrid environments each have distinct operational capabilities, threat models, and trust distribution challenges. As a result, lifecycle strategies that are appropriate in one environment may introduce unnecessary risk or complexity in another.

Proxmox Meets Enterprise PKI

February 18, 2026 / Michael Waterman / 0 Comments

Over the past few months, I’ve been writing extensively about building and configuring Microsoft Enterprise PKI (AD CS). And if you’re anything like me, you probably run some kind of home lab where you test ideas before deploying them at work.

At the same time, there’s a noticeable shift happening in the industry. Proxmox is showing up more and more, not just in home labs, but increasingly in enterprise environments as well. The same applies to my own setup. I’ve been running Proxmox for over two years now and I genuinely like the platform.

One thing that has been bothering me for a while, however, is that it uses a self-signed certificate for its management web interface. While the connection itself is still encrypted and protected (contrary to popular belief), it simply isn’t how things should be in a properly managed environment. So let’s fix that.

Top 10 PKI Recommendations by a former Microsoft Security Engineer

February 15, 2026 / Michael Waterman / 1 Comment

One of my recent posts about installing a two-tier Public Key Infrastructure did remarkably well, even got mentioned for the third time in the Microsoft Entra Newsletter! After publications I got many offline questions so I decided to do a follow-up blog on what’s recommended when designing a PKI infrastructure, it’s all stuck in my head anyway, so why not write it down. This post is not meant to be a theoretical PKI handbook. It is a practical overview of PKI best practices and common mistakes seen in real-world environments and a bit of my own experiences.