Category: Automation (Page 1 of 2)

Part 4: Using Certificate Enrollment Services in Practice

August 8, 2026 / Michael Waterman / 0 Comments

In the previous parts of this series, I’ve looked at the architecture behind Microsoft Certificate Enrollment Services and built both the Certificate Enrollment Policy Web Service (CEP) and Certificate Enrollment Web Service (CES). At this point, all the server-side components are in place. But having a working CEP and CES infrastructure is only half the story. Ultimately, a client needs to know where to retrieve certificate enrollment policy, determine which certificate templates it is allowed to use, discover the appropriate enrollment service, and finally submit a certificate request. That’s what I will show you in this part.

I will configure Windows clients to use our CEP service in two different ways. First, I will use Group Policy, which is the obvious choice for centrally managed domain-joined systems. After that, I will configure the enrollment policy locally, which is useful for individual systems and becomes particularly interesting when working with devices that cannot rely on Active Directory Group Policy. I will then follow the complete process from policy discovery to certificate enrollment and look at what Windows is actually doing behind the scenes.

Part 3: Installing the Certificate Enrollment Web Service (CES)

August 3, 2026 / Michael Waterman / 0 Comments

In the previous article, we deployed the Certificate Enrollment Policy Web Service (CEP) and configured support for Kerberos, Username/Password, and Client Certificate authentication. Clients can now successfully retrieve certificate enrollment policies over HTTPS using the XCEP protocol. However, while the policy infrastructure is now in place, clients still have no way to request certificates.

In this article, I’ll complete the Microsoft Certificate Enrollment Services architecture by deploying the Certificate Enrollment Web Service (CES). I’ll prepare Active Directory, configure a dedicated Group Managed Service Account (gMSA), install IIS, deploy the CES role, configure the supported authentication methods, and validate the deployment using PowerShell. By the end of this article, you’ll have a fully operational Certificate Enrollment Web Service capable of securely processing certificate requests over HTTPS using the WSTEP protocol.

Part 2: Installing the Certificate Enrollment Policy Web Service (CEP)

August 3, 2026 / Michael Waterman / 0 Comments

In the first article of this series, I explored the architecture behind Microsoft Certificate Enrollment Services (CEP & CES) and discussed why Microsoft introduced these web services.I looked at the differences between traditional Active Directory Certificate Services enrollment and the HTTPS-based enrollment model, explained the XCEP and WSTEP protocols, and followed the complete certificate enrollment process from start to finish. Now it’s time to move from theory to implementation.

In this article, I’ll build a complete Certificate Enrollment Policy Web Service (CEP) from scratch using PowerShell. Rather than simply installing the Windows role, I’ll also prepare Active Directory, create the required security groups, configure a Group Managed Service Account (gMSA), install IIS, configure the supported authentication methods, and validate that the deployment is functioning correctly. By the end of this article, you’ll have a fully operational Certificate Enrollment Policy Web Service capable of serving enrollment policies over HTTPS using Kerberos, Username/Password, or Client Certificate authentication.

Building a Highly Available CRL and AIA Distribution Platform for AD CS

June 4, 2026 / Michael Waterman / 0 Comments

Last time I wrote about the why a Certificate Revocation List (CRL) should be available for the majority of services that make use of certificates. One of those prime examples is the use of smartcards. When revocation can’t be checked, you simply can not logon. Most Microsoft PKI deployments start with a single web server hosting the CRL Distribution Point (CDP) and Authority Information Access (AIA) locations. While this works well for smaller environments or labs, it introduces a single point of failure. If the web server becomes unavailable, certificate revocation checking may fail and certificate validation can be disrupted across the environment.

Building Windows images with Packer on Hyper-V

April 29, 2026 / Michael Waterman / 0 Comments

Back in December, I published a blog on building Windows images using Packer on Proxmox. That setup worked well, but like most things in infrastructure, you start tweaking, refining, and eventually rethinking parts of it. if you’re anything like me, this needs to work perfectly…. and that takes a lot of time. Over the past months, I’ve streamlined the entire workflow. Less friction, more consistency, and most importantly, something I can reuse across different Windows versions without thinking twice. And best of all, it’s now fully functional on Microsoft Hyper-V!

In this post, I’ll walk you through my current setup for building Windows Server images on Hyper-V using Packer. This is the version I actually use today as I moved back to Windows Hyper-V for my lab setup, not just something that works, but something that’s predictable and maintainable and was really fun to make.

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.

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.

Modernizing RDP Certificates

February 8, 2026 / Michael Waterman / 8 Comments

This post is a small (promise!) but practical addition to my PKI series.

I wrote this blog because I wanted my own version of “how to set up RDP certificates.” Mostly as personal documentation, I can’t remember everything off the top of my head anymore… getting old.

During my initial research, I was surprised to see that many blogs still recommend older practices, SHA1 signatures, legacy cryptographic providers, or RSA 2048-bit keys without much explanation. And to be clear, I’m not saying RSA 2048 is bad. It’s absolutely still secure and widely used.

Deep Dive: Active Directory LDAPS Certificate Selection

February 3, 2026 / Michael Waterman / 0 Comments

In my previous blog about LDAPS certificates, I briefly touched on a topic that often leads to confusion, how a Domain Controller actually decides which certificate to use for LDAPS. At the time, I promised to dive deeper into that specific mechanism, because understanding it is critical when troubleshooting seemingly “mysterious” LDAPS issues. This post is that promised deep dive.

Building High-Available LDAPS Architectures

January 31, 2026 / Michael Waterman / 7 Comments

If you’re running Active Directory, like I said in a previous blog, that’s the majority of readers, you’re almost certainly using LDAPS, the secure version of LDAP. Not just because it’s “best practice,” but because plaintext LDAP over port 389 is a really bad idea, furthermore Microsoft has blocked access when you’re trying to connect to just LDAP on port 389 without any form of security.

While Microsoft has not removed the ability to use LDAP on port 389, recent security hardening features (such as LDAP channel binding and LDAP signing) can be configured to reject simple bind operations that are not signed or encrypted. In practice, many organizations today do not support clear-text LDAP unless it is secured (for example, via LDAPS). That’s why enabling LDAPS and proper security policies is highly recommended.

Unfortunately most environments treat LDAPS like a checkbox: “Yeah, we enabled LDAPS, installed a certificate, moved on.”

And that’s fine… until it isn’t. If your LDAP clients, VPN gateways, firewalls, RADIUS/NPS servers, Linux services, identity proxies, SaaS connectors, security appliances (the list goes on) depend on LDAPS, then what happens when the one Domain Controller you pointed them at suddenly goes offline?