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:
Built-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.
Post your comment:
Comments: