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.
Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure;
Configuration options on the dialog shown above have the following meaning:
Configuration model selects the state of autoenrollment policy. When the value is set to Disabled, autoenrollment will be effectively disabled. This means that autoenrollment will not be triggered automatically and will have no effect when triggered manually. If the value is set to Enabled, autoenrollment will be triggered automatically based on internal timers. If the value is set to Not Defined, the autoenrollment status is determined by local registry information located at the following path:
Key: SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment Value: AEPolicy Type: DWORD
When checked, autoenrollment will renew certificates when the certificate's templates are not set up for autoenrollment. Such templates are which require multiple signatures (require Enrollment Agent, for example) or which accept certificate subject information from request. In addition, this setting will retrieve pending requests which were placed in pending state for CA manager approval.
When unchecked, neither of these tasks will be performed during autoenrollment activation.
When checked, autoenrollment will enroll and renew certificates based on certificate templates that have been set up for autoenrollment. When unchecked, neither of these tasks will be performed during autoenrollment activation.
This section covers how to configure certificate templates and provides a step-by-step example of how to create a new template for the autoenrollment of a smart card. Certificate template permissions are also explained.
The following are default settings:
In this exercise we will create certificate template that will be intended for client authentication and secure email (SMIME). As the additional requirement, the certificate will be stored on a smart card. To create a new template for autoenrollment of a smart card:
The “Publish certificate in Active Directory” checkbox should be enabled only when certificate is consumed by users and intended for Secure Email and Encrypting File System. In all other cases, this checkbox must be cleared.
If the “Do not automatically reenroll if a duplicate certificate exists in Active Directory” checkbox is enabled, autoenrollment will not enroll a user for the certificate template, even if a certificate does not exist in the user’s Personal store. Active Directory is queried and determines if the user should be enrolled. This is an extremely valuable feature for users who do not have roaming profiles or when Credential Roaming feature is not enabled and log on to multiple machines. Without this setting and without roaming profiles, the user will automatically be enrolled on every machine that is logged on to (including servers).
It is a common misconception when it is assumed that Request hash setting specifies the signature used to sign the certificate. Request hash specifies the hash used to sign the request only. Actual certificate’s signature algorithm is selected by CA server.
Important: If more than one smart card CSP is made available on this tab, the user may be prompted for every CSP that is selected when enrolling for this template. The behavior may vary depending on the CSPs available on the client machine. If the user has only one smart card, the prompts for the unavailable CSPs will have to be cancelled. This behavior is by design. It is also important to select a minimum key size that is supported by the selected CSP; otherwise, enrollment will fail.
Starting with Windows 8 and Windows Server 2012, it is possible to supply subject along with request and use subject information in existing certificate for automatic renewal.
The XP Autoenrollment tab is hidden by default in Certificate Templates MMC snap-in and is obsolete as it may not reflect the correct template’s autoenrollment status for templates created with Windows 8 and Windows Server 2012 setting. However, if necessary, this tab can be added by enabling in View menu.
For a user or computer to enroll for a certificate template, it must have appropriate permissions (ACEs) set on the template in Active Directory. The following list describes certificate template permissions:
Note that computer certificate enrollment using
certreq.exe tool requires
-adminforcemachine switch to authenticate requester as computer. Otherwise, a current user account is used to authenticate on CA server during enrollment.
A user or computer must have both Read and Enroll permissions to enroll for a selected certificate template. Use security groups when granting permissions whenever possible. Avoid permission assignment to individual accounts. Use global or universal security groups when configuring permissions on certificate templates.
When certificate template is prepared for autoenrollment, it must be added to Enterprise CA server for issuance. This section will describe how to add certificate template to CA for issuance by using Certification Authority MMC snap-in, certutil.exe command-line tool and Windows PowerShell.
Standalone CA does not support certificate templates
The most convenient way to add certificate template to CA is to use Certification Authority MMC snap in:
certutil.exe tool can be used to manage certificate templates on CA server locally or remotely:
certutil -SetCaTemplates +<TemplateCommonName>Replace
<TemplateCommonName>with actual template’s common name. In a given example, it is SmartcardUserV2.
certutil -config <CaServerHostName>\<CaName> -SetCaTemplates +<TemplateCommonName>where
<CaServerHostName>is DNS name of CA server and
<caname>is name of CA certificate. For example, “ca01.company.com\Contoso Issuing CA”.
Starting with Windows 8 and Windows Server 2012, it is possible to use Windows PowerShell to manage certificate templates on CA server:
Import-Module ADCSAdministration Add-CATemplate -Name <TemplateCommonName>Replace
<TemplateCommonName>with actual template’s common name. In a given example, it is SmartcardUserV2.
Unlike certutil.exe tool, PowerShell cmdlet does not support remote CA management and must be executed on CA server in interactive session (i.e. locally or by using PowerShell Remoting capabilities).
This section illustrates manually pulsing autoenrollment and smart card enrollment. User autoenrollment for a smart card requires mandatory manual steps and user interaction, unlike other certificate types. Once autoenrollment has been enabled, the user will receive an informational balloon on the taskbar at the next autoenrollment trigger interval (default of eight hours) or at the next logon.
Autoenrollment may be pulsed manually through the Certificates MMC snap-in. Before you start, ensure that smart card is inserted in the reader and connected to computer. To manually trigger autoenrollment:
It will take approximately one minute for the Certificate Enrollment balloon to be displayed, unless the registry key mentioned previously has been set. (see Balloon User Interface section.)
The success or failure of the autoenrollment process will be logged in the Application event log on the local computer. Also, a summary dialog box will appear for failed certificate requests that involved user interaction. If a failure occurs during enrollment, the user will be notified of the failure. For example, Figure 24 shows autoenrollment failure for Secure Email certificate when E-mail Active Directory attribute of the user account is empty:
Hi Vadims, why is it recommended to turn autoenrollment for both the user and the computer configuration? What are the tradeoffs?
If autoenrollment is not enabled in User Configuration, then no user certificate autoenrollment will be available. Even if you do not plan to use autoenrollment for user accounts right now, this might change in future. You don't have to bother with GPO and focus on certificate templates. Enabling autoenrollment in User Configuration isn't harmful in any way as long as there are no user templates with Autoenroll permissions for users. Let's say it is just a convenience.
Ok, thanks, but if I only wnat to do user autoenrolment, why do I need to enable the GPO in Computer Configuration too? Thanks in advance,
Apart from actual autoenrollment, the feature is used to update certificate stores by downloading published certificates from AD to clients. Autoenrollment executed in user context will be able to update current user stores, but won't be able to update local machine stores if there is no autoenrollment policy in Computer Configuration. So I always recommend to enable autoenrollment for both configurations.
Hi Vadims, just to confirm I'm understanding correctly: If I have no certificate templates with autoenroll permision for a user, and I also have an enabled autoenrollment policy in the domain that has the "Update certificates that use certificate templates" option checked then the user will not be prompted for autoenrollment, is this correct?
Basically an autoenrollment policy with no templates that have autoenroll permission will have no effect, correct?
> Basically an autoenrollment policy with no templates that have autoenroll permission will have no effect, correct?
yes, it is correct. Certificate autoenrollment requires both, configured policy AND available templates with autoenroll permissions. If any is missing, the policy will have no effect.
Hi Vadims, while autoenrollment is working fine, I am seeing duplicate certificates being enrolled as soon as I switch from WCCE (Default Policy) to XCEP/WSTEP on CEP/CES.
- two Issuing CAs
- two CEP URIs configured (same weight) on dedicated servers
- on each enrollment server a pair of matching CES pointing back to the CAs
Those duplicate certificates are always issued from the same CA, even if a template is published on both CAs. When putting only one of the CEP endpoints into the GPO, everyting is working as expected - but the clients would only have one CEP path to choose from.
Am I missing someting or is this setup of multiple CEP paths on conjunction with autoenrollment not supported?
Many thanks for all your very helpul posts!
Raphael, please check "Initialize enrollment policies" section in part 2. In short, every CEP endpoint is a separate unit and every CEP is processed independently. The fact that both CEP endpoints provide same templates and same CAs doesn't mean anything and any matching is considered as a coincidence. As the result, autoenrollment client processes first CEP and acquires a certificate. The job is done, second CEP is queried: certificate is required, then autoenrollment acquires certificate from second CEP.
Hi Vadims, one short reply by you and everything makes perfect sense! Thank you so much.
This does rise a follow up question, though: So instead of having two independent, differently names CEPs, published, one would have to publish them unified via a load balancer in order to achieve fail-safety?
If yes; would the URIs and IDs of the CEP endpoints havo to match or wouldn't this matter as long as only single CEP URI (of the load balancer) is published via the GPO?
To answer my own question: publishing both CEPs with identical ID and URI plus pointing the URI at the load balancer's IP works seems to work very nicely even if one of the web enrollment servers gets stopped. So just a single CEP published in GPO and no duplicate certificates any longer.
Hi Vadims, could You provide best practices about publiscing sertificates to AD? It is not clear fom me, in which cases do I need to publish certificate to AD. I found, that this option should be enabled for encryption certificates. But maybe there is more cases when I need to publish certificate to AD?
No, there are no other cases I'm aware of. You only publish user encryption (EFS or email) certificates.
I have found your explanation about publishing certs to AD in some blog - "Authentication certificates (based on Administrator and/or User and some more templates) are configured for a certificate publication. This can be used for non-interactive logon (by using explicit mapping) like IIS integrated authentication, VPN, Wireless, etc. These authentication forms supports both implicit and explicit certificate mapping. In this case DC checks if a presented certificates is stored in the user's account properties."
I plan to use User and Computer certificates for 802.1x authentication. Do I need to publish certificates to AD in this case? Can you explain in which cases do I need publish authentication certificates to AD?
> by using explicit mapping
explicit mapping is not a general practice and must be carefully reviewed in each particular scenario. Generally, you should use implicit mapping whenever possible. This allows DCs to use default client authentication procedures based on UPN value.
Thank you for explanation. I understood that I do not understand certificate mapping process.
What about autoenrollment for non domain joined machine? Definetelly i should use CEP and CES, but what authentication to use? Certificate authentication, i assume. Otherwise it wouldn't be possible for computer account to automatically renew it's certificate?
> What about autoenrollment for non domain joined machine?
Check this article from AskDS: Enabling CEP and CES for enrolling non-domain joined computers for certificates
Hi Everyone, we use autoenrollment for our workstations where I work but I need to set up a second AD group policy to issue a customized cert with a different Subject.OrganizationalUnit value for a subset of workstations in one department. This will be used for Cisco ISE to apply a different policy to these workstations. Is there some way to do this with a Microsoft CA infrastructure?
Hi, I install enrollment agent certificate on my prsonal store. But I was having issues so I deleted the Enrollment agent certificate from my PC. Now when I am trying to get a certificate on behalf of other uses I don't see any certificate. I also revoke the certificate in CA. I am not able to unrevole it. How I can remove Enrollment agent certificate from my PC and reissue it ?
I would suggest to initiate manual certificate request.
I encountered this walk through, and it looks very informative. I am a PKI CA provider in a department, I am helping a client set up AE within his environment. For some reason there are lots of issues with it that other areas haven't had. Let's just say, I have got certificate templates, and a working CA.
I have done GPO for users and computers as you've suggested. I've applied permissions to my templates to Users, Computers, and DC's. However, only Users are able to see the templates (or enrol) when using the MMC snap-in. If I open the local computer cert store and try to make a request that way, I am not able to view the templates. Unless I select "show all templates" in which case I get the following error: The permissions on the certificate template do not allow the current user to enroll this type of certificate. You do not have permission to request this type of Certificate.
Can you think of anything that may cause this issue? Once again, wherever users have permissions, domain computers do too. I have tried adding independent computers as well to no avail. Checked permissions a thousand times so I'm really confident it's not template permissions
Thank you for all your hard work over the years!
Here is a scenario: a user template is duplicated and issued to a CA for autoenrollment, it is set to publish the user certs in AD, and it does not allow reenrollment if a duplicate cert exists in AD. Roaming user profiles have always been disabled. When a new user logs into a workstation, the user is autoenrolled for a new user cert, the cert gets published into the userCertificate attribute of that user’s account in AD, but the private key for that cert stays in the user's local profile on that workstation. When the user logs onto a different workstation, autoenrollment does not create a new cert because the user already has a cert in AD, but the user doesn’t have access the private key associated with that cert because the private key is only on the first workstation and roaming profiles are disabled. What is the solution to this?
Use credential roaming for such scenarios.
First of all thank you so much for this valuable information. I checked your answer regarding Publish Certificates to Active Directory and I have a question. I'm preparing a Always On VPN solution with user certificates. In this case, if I publish them on Active DIrectory does it work when the user has 2 computers (one desktop and one laptop). I'm just trying to avoid duplicated certificates, on machines that the user "own" but also when he connects to another computer for some specific reason.
Yes, I have the Email and EFS extension, and also cliente authentication. Is this best practice or, at least work? Any downsize?
Thank you in advance!
Client authentication doesn't require the presence of certificate in Active Directory. If user uses multiple computers, then user must have a copy of signing certificate on each computer, or use removable storage as smart card. In the case of smart card, you can have single copy of client authentication certificate to use on any supported deivce.
Hi, i have a question can we setup autoenrollment on specific OU list instead of doing it on Default domain , if yes how we can acheive that ,
You can link the autoenrollment GPO to desired OU instead of parent domain level.
Vadims thank you so much for sharing all your knowledge. I have read a number of your posts and they have helped alot however I wanted to ask if you could help me understand... if with Auto Enrollment enabled in Group Policy, If you created a new certificate template by duplicating a User or Computer template, then add that new certificate to the list of available templates, how does the Windows computer know to use these new templates and not the original default ones that are still enabled?
I have been reading up on NDES and apparently there are registry settings we can change to specify the template name so it won't use the default IPSEC template when a device (like a router) goes to request a certificate from it. I just can't seem to find any clear info on how the new User/Computer templates are being selected. The only thing I can assume is that Auto Enrollment just "magically" chooses the latest duplicated certificate? Any guidance would be greatly appreciated. Thank you.
When a client gets renamed does it request a new certificate under the new name? Is there a setting that controls this?
> When a client gets renamed does it request a new certificate under the new name?
> Is there a setting that controls this?
most likely no.
Hope you are doing good. Thank you for the sharing valuable info here. I have been working in PKI with AE - I have come across a weird use case - To enroll computer certificate based of Certificate template.
Certificate gets issued however the Subject atternative name attribute in the certificate details shows blank.
when I tested and mimic this behavior - I get the subject alternative name as example : CN: demo.testca.com.
In Certifcate template, Subject name: set as Common Name and also tried DNS. Still no luck.
question: how does ADCS uses certificate template for ENROLLMENT and from where does it prints CN in Subject alternative name in Issues Certificate.
ADSI shows the dnsHostname for the computer but no luck showing up on issued certificate.
any advise?? Thanks in Advance.
Hope you are doing good !
I am enabling autoenrollment for user and computers with credential roaming for 802.1x authentication. What is the impact on ActiveDirectory for 4k users and machine respectively? And how much will it grow eventually and is crendential roaming a best practise for 802.1x authentication?
> And how much will it grow eventually and is crendential roaming a best practise for 802.1x authentication?
in reality, it is about 2-3KB per certificate. For 4k users it will be about 10MB of roaming data. In future it will grow, when users get renewal certificates. Though, the growth isn't permanent, because expired tokens will be deleted. In other words, there will be an impact in AD size and replication bandwidth, but not in compute resources (CPU, memory, disks) even with entry level modern hardware.
For more details check the AskDS article: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/certs-on-wheels-understanding-credential-roaming/ba-p/395897
Thank you for this guide. I seem to be having an issue with Auto Enrollment. I am attempting to deploy a computer certificate under auto enrollment. I pretty much had what you described already from the certificate perspective, however I was unable to figure out how to configure the GPO. I followed your guide for this however when I launch the certlm for my local computer certificates and attempt to Automatically Entroll and Retreive certificates the template I created does not appear. There is nothing for me to select. What might I be doing wrong?
Sorry about the typo on your name, I was looking at a post above. My mistake.
Hi. I have the option to publish to Active directory on the template. The certificate enrolls and gets placed in the cert personal store which is fine. Problem is it does not get published to active directory. i know this as there should be a certificate in the Active directory User Object store. But its not.
Seems to be a permissions issue maybe. How do I give the CA permissions to pubish to users active directiory? Thanks in advance
hope you can shed some light for us.
im contacting you from a charity (happy to tell you which on via email)
Domain Controller : windows server 2016
Certificate Authority: windows server 2016
Servers on network: Windows server 2003 server
Current Domain Controller Authentication template (with Kerberos) > Compatibility settings "Certificate Authority: windows server 2003" & "Certificate Recipient: Windows XP/Windows 2003"
if we update the Compatibility settings "Certificate Authority: to Windows server 2016" and kept "Certificate Recipient: Windows XP/Windows 2003"
would this effect our 2003 servers?
> would this effect our 2003 servers?
no, it wouldn't. This only enables advanced features on CA side, but they are invisible to clients.
Can you please clarify the following regarding this blog post, you may have already answered the question above when you replied to others, but I just want to clarify something please, thanks
Above it says the following
The “Publish certificate in Active Directory” checkbox should be enabled only when the certificate is consumed by users and intended for Secure Email and Encrypting File System. In all other cases, this checkbox must be cleared.
I thought (and this is probably where my misunderstanding comes in) if I am authenticating to AD using a Smart Card, whereby the Private Key on the smart card is used to encrypt the Kerberos Pre-Authentication challenge from the Domain Controller (e.g. please encrypt this time stamp with your private key). In order for the DC to decrypted the challenge, it would need the public key (e.g. from the certificate held in the userCertificate attribute). Therefore no certificate in AD then no access to the public key to decrypt and no way to match the user (subject) to the public key e.g. does this user Bob really have the correct public key let's check the userCertificate (that is my current understanding)
If the certificate is not needed in AD (e.g. public key), for SmartCard authentication, how does the DC decrypt the challenge above? in order ascertain POP (proof of possession) of the private key, and at the same time marry this up to a particular user in AD (e.g. as their userCertiicate would have the correct public key to decrypt)
Thank you very much
> If the certificate is not needed in AD (e.g. public key), for SmartCard authentication, how does the DC decrypt the challenge above?
using client certificate supplied in PKINIT, there is no need for another copy installed in AD. When you do smart card authentication, a public part of client certificate is sent to KDC. KDC uses UPN value in SAN extension to perform "certificate <-> AD" account mapping and this certificate contains public key KDC will use to validate private key possession by client. KDC then performs other certificate validation checks, such as revocation, issuer permission to issue authentication certificates and other checks.
Thank you very much indeed for clearing that up for me Vadims :)
You mention in your article that the autoenrollment refresh interval of 8 hours can be configured with GPO. I have been unable to find this setting, are you able to provide a reference?
Hello, great infomation! So this means for CEP/CES deployment with workgroup clients:
If I want to use key based renewal, I am forced to put CA in renewal only mode. If CA is in renewal mode, I cannot request an auto enrolled "initial" certificate for the workgroup clients. If I have no auto enrolled "initial" cerftificate (just a manually enrolled one), the auto renewal process will never happen. So it ist just not possible to make auto enrollment (renewal) work with CES/CEP and workgroup clients?
Is this correct? I'd be happy if you could help me out here.
you will need two CEP and two CES instances, where one is configured with UserName/Password authentication for initial enrollment and second instance with certificate authentication and key-based renewal.
I have been fan for over 10 years.
I am still not clear on the need for CEP/CES.
If i have INTUNE for mobile devices.
2 AD forests with 2 way trust and multiple domains, is there really a need for CEP/CES?
The only need for CEP/CES would be other non domain members like linux or mac, correct?
> If i have INTUNE for mobile devices.
Intune covers several CEP/CES scenarios (though, not all) and it is not free. And non-domain computers would need CEP/CES to benefit from autoenrollment.
Post your comment: