Posts on this page:
This is a third part of the Certificate Autoenrollment in Windows Server 2016 whitepaper. Other parts:
Autoenrollment configuration in general consist of three steps: configure autoenrollment policy, prepare certificate templates and prepare certificate issuers. Each configuration step is described in next sections.
The recommended way to configure autoenrollment policy is to use Group Policy feature. Group policy feature is available in both, domain and workgroups environments. This section provides information about autoenrollment configuration using Group Policy editor. It is recommended to turn on autoenrollment policy in both, user and computer configuration.
This is a second part of the Certificate Autoenrollment in Windows Server 2016 whitepaper. Other parts:
This section discusses the autoenrollment architecture, an analysis of the components of the autoenrollment process, and working with certificate authority interfaces.
Autoenrollment consist of several components installed on each computer. Depending on environment (Active Directory or workgroup) some components may present or not present. The following diagram outlines autoenrollment components and their high-level interactions in both environments:
The meaning of each component is provided in next sections.
This component is not available in workgroup environments.
Client module that is responsible for Group Policy retrieval and processing from domain controller, policy storage and policy maintenance on a local computer. Group Policy client updates local configuration with certificate enrollment policy (CEP) information.
System Registry storage that contains information about certificate enrollment policies (CEP). This information is then used to populate configuration for: Enrollment Policies, AE Options and Certificate Issuers components. Local configuration is stored in System Registry in HKLM and HKCU registry hives:
SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment\
Contains a collection of CEPs. In Active Directory environment, a LDAP domain policy is added by default. XCEP policies must be configured by an administrator in Group Policy on domain controllers (available only in Active Directory) and/or using local configuration tools. Each policy contains the following notable properties:
Hello, everyone! Today I’m starting a new community whitepaper publication on certificate autoenrollment in Windows 10 and Windows Server 2016. This is a deeply rewritten version of the whitepaper published 15 years ago by David B. Cross: Certificate Autoenrollment in Windows XP. Certificate enrollment and autoenrollment was significantly changed since original whitepaper publication. Unfortunately, no efforts were made by Microsoft or community to update the topic. So I put some efforts in exploring the subject and writing a brand-new whitepaper-style document that will cover and reflect all recent changes in certificate autoenrollment subject.
This whitepaper is a structured compilation of a large number of Microsoft official documents and articles from TechNet and MSDN sites. Full reference document list and full-featured printable PDF version will be provided in the last post of this series.
Whitepaper uses the following structure:
First post of the series will cover only general questions and certificate enrollment architecture. It is important to understand how certificate enrollment works in modern Windows operating systems, because autoenrollment heavily relies on this architecture. So, let’s start!
Hello everyone!
Yesterday I pushed new PSPKI release with version number v3.3.0. New version is even more stable and even more powerful. More technical change list is moved to dedicated article: Release notes for PSPKI v3.3.0. In this (and, possibly next) blog post I would like to outline major changes/improvements to this release.
I bet that ADCS database access is one of the most popular features people love in my module. And there are reasons: I put a lot of efforts to simplify access to CA database and provide flexible filter options. For example, get certificates that will expire in next 30 days:
Hello world! Last time (year or so) I was busy on anything else but my module. Now I’m happy to announce that the project isn’t died, it is alive and new version is published.
This version doesn’t bring new commands, nor deprecate any. I think, command list is well-established and I don’t see anything useful to add. People doesn’t ask either. However there are things to work with code: refactor, optimize, make it cleaner and so on. Let’s look at what I’ve done here:
PowerShell Gallery
Initially, project was hosted at CodePlex which is died now. I moved all my sources to GitHub, documentation to my web site and used CodePlex as module download place.
Since CodePlex is done, the only real option to ship binaries was to use PowerShell Gallery. It is something new to me (I never used it till today) and was a bit lost there. But it appeared more easier than I thought. Starting with v3.2.7, the module is available on PowerShell Gallery: PSPKI. Please, provide feedback on your experience with getting PowerShell PKI module from gallery.
In the past, I used MSI installer to ship the module. It is still very good option to do that, because you can use various tools, like group policies or ConfigMgr to deploy the module within organization. Thanks to Caphyon Advanced Installer and their free NFR license (as a part of my Microsoft MVP award) I was able to do that. And their tool was really great and easy to use. However, my MVP award options are uncertain and PowerShell Gallery is an acceptable tradeoff, so there is no big need in MSI anymore.
Fixed bugs