This is a third part of the Certificate Autoenrollment in Windows Server 2016 whitepaper. Other parts:
- Certificate Autoenrollment in Windows Server 2016 (part 1)
- Certificate Autoenrollment in Windows Server 2016 (part 2)
Configuring Autoenrollment
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.
Configuring autoenrollment policy
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.
- Start Group Policy editor. In Active Directory environment, use Group Policy Management Console (gpmc.msc). In workgroup environment, use Local Group Policy Editor (gpedit.msc);
- Expand
Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure; - Double-click on Certificate Services Client – Auto-enrollment;
- Set Configuration Model to Enabled;
- Configure the policy as shown below and save settings:
Figure 13: Configuring Autoenrollment policy in GPO - Repeat steps 2-5 for User Configuration node.
Configuration options on the dialog shown above have the following meaning:
- Configuration model
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
- Renew expired certificates, update pending certificates, and remove revoked certificates
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.
- Update certificates that use certificate templates
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.
Configuring certificate templates
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.
Default settings
The following are default settings:
- Both domain administrators from the root domain, and enterprise administrators for fresh installations of Windows Server 2003 (and newer) domains may configure templates.
- Certificate template ACLs are viewed in the Certificate Templates MMC snap-in.
- Certificate templates can be cloned or edited using the Certificate Templates MMC snap-in.
Creating a new template for the autoenrollment of a smart card
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:
- Log on to a computer where ADCS Remote Server Administration Tools (RSAT) are installed with Enterprise Admins permissions;
- Press Win+R key combination on the keyboard.
- In the Run dialog box, type certtmpl.msc, and then click Ok.
The Certificate Templates MMC snap-in may also be invoked using the Certification Authority MMC snap-in by selecting the Certificate Templates folder, right-clicking, and then selecting Manage. - In the console tree, click Certificate Templates.
- In the details pane, right-click the Smartcard User template, and then click Duplicate Template (Figure 14).
Figure 14: Creating a New Template for Autoenrollment of a Smart Card - The Compatibility tab of the new template properties dialog box appears. Configure compatibility settings to minimum OS version that will consume this template and minimum OS version of CA server that will issue certificates based on this template.
- Switch to General tab.
In the Template display name field, type a unique name for the template, for example Smartcard User V2 (Figure 15). Specify desired certificate validity and enable checkboxes: “Publish certificate in Active Directory” and “Do not automatically reenroll if a duplicate certificate exists in Active Directory”.
Figure 15: Configure certificate template’s general tab 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).
- Click the Request Handling tab (Figure 16). This tab is used to define how the certificate request should be processed. Use default settings in this tab and enable “For automatic renewal of smart card certificates, use the existing key if a new key cannot be created” checkbox.
Since the certificate is supposed to be stored on a smart card, the “Require user input” radiobutton must be selected. If the certificate template is not going to be used for smart cards or if it is not desired for the user to be prompted to enroll for certificates, this option is not required. Machine certificates should not have this enabled or machine autoenrollment will fail.
Note that “Delete revoked or expired certificate” checkbox is grayed out. This is because the purpose of the certificate contains encryption (Secure Email). In order to retain access to older mails which were encrypted with expired certificate, the certificate must not be removed.
Figure 16: Configuring certificate template’s Request Handling tab - Switch to Cryptography tab (Figure 17).
Figure 17: Configuring certificate template’s Cryptography settings - In this tab, you configure provider category (Legacy CSP or Key Storage Provider). Default is Legacy CSP. If your smart card provider supports key storage provider (KSP), you should use KSP instead. Specify the algorithm name, key length supported by smart card provider and provider name. It is recommended to explicitly specify provider.
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.
- Switch to Subject Name tab. This tab is used to define how the subject name and certificate properties will be built. It is recommended to use the default selections when enrolling for a smart card template.
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.
- Switch to Security tab. This tab is used to define which users or groups may enroll or autoenroll for a certificate template. A user or group must have the Read, Enroll, and Autoenroll permissions to automatically be enrolled for a certificate template. For more details about certificate template permissions, refer to next section.
- Click OK when finished.
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.
Certificate template permissions
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:
- Read permission allows the template to be discovered by the user;
- Write permission allows a user to modify the contents of a certificate template. Note that only version 2 certificates with a Windows Server 2003 (or newer) schema may be modified. Version 1 certificate templates only allow ACLs to be modified;
- Enroll permission is enforced by the Enterprise CA when a user requests a certificate for a selected template. The Enterprise CA must also have Read permissions on a template to enumerate the template in the directory and issue certificates based on that template. Normally, the Enterprise CA is included in the Authenticated Users group, which has Read permissions by default on a template;
- Autoenroll permission is set on a template when it is desired for a user or computer to automatically enroll for a selected certificate template. The Autoenroll permission is needed in addition to the Enroll permission for a user to enroll for a given certificate template. Only version 2 templates or newly created templates may have the Autoenroll ACE set;
- Full Control permission is given to enterprise administrators and the primary domain administrators group by default. The Full Control permission allows a user to set or modify the permissions on a selected template.
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.
Configuring an Enterprise CA
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
Configuring CA using MMC
The most convenient way to add certificate template to CA is to use Certification Authority MMC snap in:
- Log on to CA server or computer with Remote Server Administration Tools installed with CA Administrator permissions;
- Press Win+R key combination on the keyboard;
- In the Run… dialog, type “certsrv.msc”;
- If necessary, click on root node, then press Action menu and select Retarget Certification Authority to connect to desired CA server;
- When connected, expand CA node and select Certificate Templates folder. You will see certificate templates supported for issuance by this CA:
Figure 18: View certificate templates in Certification Authority MMC snap-in - In Action menu, select New and Certificate Template to Issue menu. In the opened dialog, select target template and press Ok to finish. Ensure that certificate template is listed in Certification Authority MMC console.
Configuring CA using certutil.exe
Built-in certutil.exe tool can be used to manage certificate templates on CA server locally or remotely:
- Log on to CA server or computer with Remote Server Administration Tools installed with CA Administrator permissions;
- Open elevated Command Prompt;
- If you are logged on CA server, type:
certutil -SetCaTemplates +<TemplateCommonName>
Replace<TemplateCommonName>with actual template’s common name. In a given example, it is SmartcardUserV2.
Figure 19: Enable Certificate Templates dialog - In order to add template to remote CA, specify remote CA location:
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”.
Configuring CA using Windows PowerShell
Starting with Windows 8 and Windows Server 2012, it is possible to use Windows PowerShell to manage certificate templates on CA server:
- Log on to CA server with CA Administrator permissions;
- Open elevated Windows PowerShell console;
- Run the following commands:
Import-Module ADCSAdministration Add-CATemplate -Name <TemplateCommonName>
Replace<TemplateCommonName>with actual template’s common name. In a given example, it is SmartcardUserV2. - Confirm operation if prompted.
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).
User Autoenrollment
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.
Manually pulsing autoenrollment
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:
- Log on to the computer with the appropriate user account.
- If Balloon User Interface appears in a system tray, double-click on a certificate image and proceed with next section. Otherwise, follow next steps to trigger autoenrollment feature;
- Press Win+R key combination on the keyboard;
- Type “certmgr.msc”, and press ENTER;
- Right-click the top of the tree on Certificate\Current User, select All Tasks on the context menu, and then select Automatically Enroll and Retrieve Certificates (Figure 20).
Figure 20: Automatic certificate enrollment in Certificates MMC snap-in
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.)
Smart card enrollment
- On the Before You Begin page, click Next;
- On the Request Certificates page, you will see the newly created template (Figure 21) and press Enroll button
Figure 21: Certificate enrollment wizard - When prompted (Figure 22), enter PIN to access the smart card and generate the key pair.
Figure 22: PIN prompt dialog - Follow smartcard specific dialogs (if any) provided by a smart card middleware to complete certificate enrollment.
- Ensure that certification installation succeeded and press Finish button to finish the process.
Figure 23: Certificate installation results
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?
Thanks.
Marius,
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.
Hi, Vadims.
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.
Hi,
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
Vadims,
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?
@Daniel Benway
Use credential roaming for such scenarios.
Hello Vladimis,
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!
@Fabio Teles,
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 ,
thanks
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?
no.
> Is there a setting that controls this?
most likely no.
Hi Vadmin,
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.
Hi Vadmin,
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
Hi Vadmin,
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?
Vadims,
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
Edgar
Hi Vadmin
hope you can shed some light for us.
im contacting you from a charity (happy to tell you which on via email)
our enviroment
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.
Hi Vadims
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 :)
Hi,
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?
Cheers,
Jeremy.
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.
Thanks!
@Thomas
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.
Post your comment:
Comments: