Windows Insider

UPDATED: Active Directory Certificate Services: Don't Overthink It

• By Greg Shields
• 05/29/2015

Editor's note: Several experts had some key criticism of this month's Windows Insider column, which originally appeared in the June 2015 print edition of Redmond magazine. Columnist Greg Shields has written an addendum at the bottom of the column.

Authentication and the venerable domain controller have been inseparable concepts since the earliest days of the Windows Server OS. Logging into Windows? You're going to need a domain controller.

Yet our hyper-connected workplaces require ever more IT services that extend past the usual boundaries of Active Directory. It remains difficult to authen­ticate against an on-premises AD when accessing cloud-based applications.

We're long past the DC as the single authentication source for Windows environments. Long a mainstay of Web servers both public and private, the certificate in recent years has become fashionable as another method to authenticate services and encrypt network traffic. Yet for all the acceleration we see today in certificate requirements, I'm constantly surprised at how rare you find an AD Certificate Services (CS) infrastructure in operation.

If one of the greatest hurdles of AD CS is its complexity, why not kick-start your infrastructure into place by just simply ... starting one? Build yourself an AD CS server on a domain-joined machine. It'll let you begin issuing very simple computer certificates to all your servers and desktops.

Established best practices suggest starting with a minimum of two certificates -- an offline root certificate authority (CA) in a workgroup that issues a single certificate to an online enterprise subordinate CA that's a member of your AD domain. However, it's overcoming this initial complexity that trips up so many of us in ever getting an AD CS solution off the ground.

Even easier, install the AD CS role onto an existing domain-joined computer*. All you'll need is the Certificate Authority role service. Leave the other role services for another day. Install the role service as an enterprise root CA with a new private key and a reasonably long validity period. The default of five years is a good start. Leave the other settings unchanged.

Congratulations, you now have a certificate services infrastructure in your domain. In fact, you have slightly more than you might expect. Installing an enterprise root CA in this manner automatically begins distributing that CA's root certificate to domain-joined machines. With a few mouse clicks and a bit of time, every machine automatically trusts every certificate generated by your CA. This is a good start.

Then you should automate the deploy­ment of that computer certificate to machines in your domain. Whereas AD CS can deploy all manner of certificates for a variety of uses, this basic computer certificate is the foundation for numerous IT services. Even better, automatically deploying it everywhere is easy.

Launch the CA console and right-click to manage its certificate templates. Create a duplicate copy of the existing computer template and rename the template to something you'll remember. Under the General tab, check the box to publish the certificate in AD. Then, under the Security tab, grant the Domain Computers group the Read, Enroll and Autoenroll permissions. Exit the properties view and the Certificates Template Console, and then back in Certification Authority right-click Certificate Templates and select New | Certificate Template to Issue. Select the template you just created.

Whereas the automatic distribution of your CA's root certificate happens without additional configuration, you'll need to use Group Policy to configure auto-enrollment for the computer certificate. Create a new Group Policy Object and link it to either your domain or an Organization Unit of computer objects. Then, navigate to Computer Configuration | Windows Settings | Security Settings | Public Key Policies | Certificate Services Client – Auto-Enrollment and enable the configuration model. Check the boxes to renew expired certificates and update those with templates.

You've now accomplished the barest configuration for deploying certificates throughout your domain. As Group Policy refreshes, each computer will request and be issued a unique computer certificate for use in any client computer authentication requirements.

These simple steps can be repeated for other certificate requirements your IT services might need. Code signing certificates for use with Windows PowerShell, user certificates for smartcards, secure e-mail certificates for encryption, all of these begin with these simple steps.

Admittedly, yes, there's more to AD Certificate Services than one can offer in a one-page column. But, notwithstanding, if you're not employing an internal PKI out of concerns of complexity, it's entirely possible you're just overthinking it.

Update (June 3, 2015): The original article stated you should install the AD CS role onto an existing DC.

Addendum (June 4, 2015): Once again, thanks to everyone for the lively conversation. You're all correct that this column is, by no means, a best practice. For that, I apologize.

In the comments below, I think "Hannah IT" said it best by stating, "The mistake is this article." That mistake is one of intentions. I wrote this column (which originally appeared in the June 2015 print issue of Redmond magazine on page 31) with a singular goal: to incent the average, perhaps inexperienced, IT professional to just get started with AD CS.

I know one of the commenters, Brian Komar, a Microsoft security MVP and author of several books and guides on PKI for Windows. We've met a few times and Komar has even spoken at the TechMentor conference, which, like Redmond magazine, is produced by 1105 Media. I believe commenter Paul Adare, also a Microsoft security MVP, and I have shaken hands at least once. These two are experts at this technology, and I respect you (and everyone else) greatly for being so.

However, the comments below have succeeded in manifesting the opposite effect of what I had originally intended. My goal was to merely incent individuals to get started and to highlight a barest minimum of steps that might accomplish that -- even as those steps aren't, as y'all have stated, the very best ones.

I warned, perhaps not strongly enough, in my second-to-last sentence, "Admittedly, yes, there's more to AD Certificate Services than one can offer in a one-page column."  That statement was my nod to the fact that there's more to this process than I can cover in 650 words. In hindsight, I should have made that disclaimer more prominent.

There appears an unspoken assertion in these comments that the mere presence of this article presents something like a danger to society. But let's be rational adults here. Would any IT pro, experienced or no, seriously go about creating a PKI solution based solely on a handful of paragraphs in a trade magazine?  Likely not. 

Which takes me back to my original intent for this piece.

What that person might do as they're flipping through this magazine while eating lunch or on the bus to work is (I hope) to maybe, just maybe, get a tiny bit more excited at the prospect that they possibly could tackle this complex beast called PKI.

And if they turn to Brian's book,  Paul's community contributions or the body of PKI knowledge elsewhere, then I've accomplished my goal. The world is a slightly better place.