Export (0) Print
Expand All

How Autoenrollment Works

Updated: January 1, 2003

Applies To: Windows Server 2003 with SP1

This section discusses how autoenrollment works, including autoenrollment and Winlogon, an analysis of the components of the autoenrollment process, and working with certification authority interfaces.

Key Points

Autoenrollment works best in a Windows Server 2003 Enterprise environment where the Windows XP client is integrated with Active Directory.

Only domain-joined machines can use certificate autoenrollment. Although the autoenrollment process does not explicitly look for domain-joined machines, the Winlogon process will not activate userinit.exe unless the machine/user is part of a domain.

Autoenrollment Timing

The autoenrollment process is normally triggered by the Winlogon process, and is designed to be activated and managed by a domain-based Group Policy. Both machine-based and user-based Group Policy can activate autoenrollment for machines and users. By default, the Group Policy is applied at reboot for machines, or at logon for users, and is refreshed every eight hours. The refresh interval can be configured using Group Policy. Autoenrollment is also triggered by an internal timer that activates every eight hours after the last time autoenrollment was activated.

For additional information, see Updating Group Policy.

Unlocking the workstation does not trigger autoenrollmentonly a full interactive logon or a Group Policy refresh will initiate the Winlogon trigger.

The Autoenrollment Process

The autoenrollment feature handles all aspects of certificate enrollment, renewal, and certificate housekeepingexcept in the case where user interaction is explicitly defined on a certificate template in Active Directory. When the autoenrollment process is triggered by Winlogon or a Group Policy refresh interval, the operating system queries Active Directory to download the appropriate certificate stores into the local store on the client machine; for example, root CA certificates, cross-certificates, and the NTAuth container. The autoenrollment process also downloads certificate templates from the forest and caches the list in the registry at the same time. The last step performed by autoenrollment is user-object cleanup (userCertificate attribute) in Active Directory. Revoked, expired, and superseded certificates are removed from the user object automatically; however, expired certificates are not removed unless a new valid certificate is issued at the same time. Certificates in the local user profile or on the user object in Active Directory are only managed if the certificate corresponds to a certificate template in Active Directory. Foreign certificates and certificates that do not contain the template extension are not managed. This is a transparent activity that is processed asynchronously.

Requirements List

The autoenrollment process will then process the list of templates and create a requirements list for any templates that have an autoenroll access control entry (ACE) set on the template for the current machine or user. The machine and/or user must also have the Read ACE set on the template or the template will not be enumerated. The users or machines MY (personal) store will also be processed at this time to look for revoked certificates, certificates without private keys, time invalid certificates and so on, and add these certificates to the requirements list. For more information about certificate stores, refer to the Microsoft Platform SDK: http://go.microsoft.com/fwlink/?LinkID=116205

It is very possible that a user may have a certificate in the MY store but not have permissions set on a template access control list (ACL) in Active Directory. These will be processed and added to the list, but enrollment will most likely fail due to the fact that the template permissions do not allow enrollment/renewal at the updated point in time.

Items in the requirements list may be removed if an appropriate valid certificate is found in the MY store. If a certificate template is marked to check Active Directory for an existing certificate, Active Directory will be queried for an existing duplicate certificate on the userCertificate attribute of the user object and the requirement will be removed from the list, if successful.

Checking Active Directory for the presence of an existing certificate associated with the user or machine object can affect performance and may delay autoenrollment processing due to the network and directory requirements for performing this operation. This is because the actual certificates in the userCertificate attribute will be downloaded and examined. When this happens, the directory cannot be queried via Light Weight Directory Access Protocol (LDAP) to simply respond whether a given certificate type exists without downloading and processing the certificates locally.

Autoenrollment also manages the CryptoAPI REQUEST store for the user. This process enumerates each pending request in the store and then installs the pending certificate, if possible, from the issuing CA. If a certificate is to be archived or deleted, based on the certificate template rule, it will be processed as follows:

  • If a request already exists in the REQUEST store, this certificate will be removed from the summarized requirements list.

  • If a request has been pending for more than 60 days, the request will be deleted and the requirements list will remain as-is.

Autoenrollment can be used to retrieve pending requests only for certificates with template information, for example, an initial request involving a certificate template. The autoenroll ACL on the certificate template is not necessary for the autoenrollment process to retrieve a pending certificate request. If the user enrolls via a Web page and the certificate request is pending, autoenrollment will retrieve the pending request for the user.

Template supersede rules will be evaluated and appropriate additions and deletions will be processed for the requirements list. For example, if the template says "X supersedes Y ", it means that if you have been told to enroll for X and Y, you really only need X. If you only have Y, you still must get X. This is the last step in rule processing. After it is done, the requirements list is complete.

For each template that does not require user interaction, the autoenrollment process will create the requests in the background and submit them to a CA. Once this is done, the requirements list is updated.

Autoenrollment always performs a revocation check of the entire certificate chain starting with the issuing certification authority to ensure that the CA offering enrollment services is not revoked before performing enrollment. If the CA is revoked, autoenrollment will not send requests to that certification authority. However, autoenrollment will ignore revocation errors if a CDP (CRL Distribution Point) extension does not exist in the CA certificate or if the revocation status is offline.

If a certificate is issued from the CA, it is installed in the users or machines MY store. If the certificate is pended [specified by the CA Manager approval check box in the Certificate Template Microsoft Management Console (MMC) snap-in], the request information is saved in the REQUEST store.

Balloon User Interface

For each request that requires user interaction as per the certificate template, the balloon user interface (UI) is invoked.

  • Approximately 60 seconds after logon, the balloon UI is displayed. If no user interaction is explicitly defined on the certificate template, no UI will be displayed to the user. This delay is incorporated to allow for speedy application and shell response times during the logon and booting of the client machine.

  • If the 60-second delay is not desired, the following registry key may be added on a per-user basis.


Using this key in a normal production environment is not recommended. If it is used, it must be created on a per-user basis.

Machine certificates do not support user interaction and should not be configured to require this setting.

  • The balloon UI waits for the user to see the balloon and is activated by a mouse click. Note that after approximately 15 seconds, the balloon pop-up window is replaced in the notification area by a certificate icon that may be activated by a mouse click.

  • If no activation occurs within seven hours, the taskbar icon will disappear and the silent thread will re-activate at the next logon, machine reboot, or Group Policy refresh interval, whichever is first.

  • Once the user activates the UI, the REQUEST store is checked first for pending requests.

Issuing the Template

Once a certificate template with the proper ACE has been enumerated, the autoenrollment process will search for a Microsoft Enterprise Certification Authority in Active Directory that can issue the template. If more than one Enterprise CA is found, the client will try each CA in the list in random order (for load balancing) until a CA responds and is able to issue a certificate.

The client contacts a CA through a Distributed Component Object Model (DCOM) interface and supplies a security context through DCOM to provide an authenticated request. The default policy module of the Microsoft Enterprise CA enforces certificate profiles and enrollment security as defined by the templates.

If the certification authority is set to pend the request for an administrator or certificate manager to examine and approve, autoenrollment will periodically query the CA during every Group Policy refresh interval for approved requests. Autoenrollment will also re-enroll templates when Reenroll all certificate holders has been set in Group Policy. For more information, see Certificate Renewal.

Certification Authority Interfaces

The following methods are used by the autoenrollment process for contacting and enrolling against a Microsoft Enterprise CA.

  • GetCAProperty

  • Submit

  • GetLastStatus

  • GetRequestId

  • GetFullResponseProperty

  • GetCertificate

  • Release

  • RetrievePending

These methods can be found in the Platform SDK at http://msdn.microsoft.com/library/default.aspConfiguring the 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.

Key Point

A version 2 certificate template must first be created in Active Directory to enable autoenrollment.

Default Settings

The following are default settings.

  • Only root domain administrators or explicitly delegated users in Active Directory may configure templates in a domain that has been upgraded from Windows 2000 Server.

  • Both domain administrators from the root domain and enterprise administrators for fresh installations of Windows Server 2003 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.

Only a domain with the Windows Server 2003 schema will support version 2 templates, and only a Windows Server 2003, Enterprise Edition or Datacenter Edition certification authority may issue a version 2 template certificate.

Creating a New Template for the Autoenrollment of a Smart Card

To create a new template for autoenrollment of a smart card

  1. Log on as a domain administrator.

  2. Click the Start button, and then click Run.

  3. In the Run dialog box, in the Open box, type mmc.exe, and then click OK.

  4. On the File menu, click Add/Remove Snap-in.

  5. In the Add/Remove Snap-in dialog box, click Add.

  6. In the Add Standalone Snap-in dialog box, click Certificate Templates, and then click Add.

    The Certificate Templates MMC snap-in is available on the Server version of Windows Server 2003 or on Windows XP Professional through the Administration Tools Pack installation on the Server media.

  7. Click Close.

  8. 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.

  9. In the console tree, click Certificate Templates.

  10. In the details pane, right-click the Smartcard User template, and then click Duplicate Template (Figure 1).

    The General tab of the new template properties dialog box appears.

    Art ImageFigure 1: Creating a New Template for Autoenrollment of a Smart Card

  11. In the Template display name field, type a unique name for the template (Figure 2).

    Art ImageFigure 2: Naming the Template

    If the Do not automatically reenroll if a duplicate certificate exists in Active Directory is enabled, autoenrollment will not enroll a user for the certificate template, even if a certificate does not exist in the users MY 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 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).

  12. Click the Request Handling tab (Figure 3).

    This tab is used to define how the certificate request should be processed, including the cryptographic service providers (CSP) and minimum key sizes that will be used by the enrollment template.

    Art ImageFigure 3: Defining How the Certificate Request Should Be Processed

    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.

  13. Select the Prompt the user during enrollment check box (Figure 3). (Enrollment for smart card requires user input to succeed.)

    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.

  14. Click the 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.

  15. Click the Extensions tab.

    This tab is used to define how the various extensions will be added to this certificate template during enrollment. It is recommended that you use the default settings.

    Application Policies is a replacement for Extended Key Usage (EKU) in Windows Server 2003, although EKU is still supported for legacy applications and client operating systems.

  16. Click the 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.

  17. Click OK when finished.

    The Autoenrollment column should now show Allowed.

The Autoenrollment column will automatically indicate if a template is suitable for autoenrollment. The user will not be able to change the status. If a template has more than one registration authority (RA) signature required or if the subject is supplied by the requester, autoenrollment will not be allowed. The column does not reflect the state of the autoenroll ACL on the template.

A smart card that has been issued on Windows XP client or Windows XP Enrollment Station (RA) might only be compatible with a Windows XP client. The compatibility varies between various smart card and CSP vendors. If you need to be able to log on to both Windows 2000 and Windows XP, see your smart card and CSP vendor for additional information.

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. A user or computer must have both Enroll and Read permissions to enroll for a selected certificate template.

  • Read permission allows the template to be discovered by the user.

  • 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.

  • Full Control permission is given to enterprise administrators and the primary domain administrators group by default when installing a fresh Windows Server 2003 domain. If a domain has been upgraded from Windows 2000, enterprise administrators will not have this permission by default. The Full Control permission allows a user to set or modify the permissions on a selected 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.

  • Write permission allows a user to modify the contents of a certificate template. Note that only version 2 certificates with a Windows Server 2003 schema may be modified. Version 1 certificate templates only allow ACLs to be modified.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

© 2015 Microsoft