Export (0) Print
Expand All

Certificate Autoenrollment in Windows Server 2003

Windows Server 2003

Certificate Autoenrollment in Windows Server 2003

Published: April 1, 2003
*
On This Page
Introduction Introduction
How Autoenrollment Works How Autoenrollment Works
Configuring an Enterprise CA Configuring an Enterprise CA
Configuring Group Policy Configuring Group Policy
User Autoenrollment User Autoenrollment
Certificate Renewal Certificate Renewal
Autoenrollment Functions Autoenrollment Functions
Updating Group Policy Updating Group Policy
Advanced Features Advanced Features
Supported Hardware Supported Hardware
Troubleshooting Troubleshooting
Summary Summary
Related Links Related Links

Introduction

Microsoft Windows Server 2003, Enterprise Edition introduces the capability to automatically enroll users and computers for certificatesincluding smart cardbased certificates.

Using the autoenrollment feature, organizations can manage the certificate lifecycle for users, which includes:

•

Certificate renewal

•

Superseding of certificates

•

Multiple signature requirements

Certificate autoenrollment is based on the combination of Group Policy settings and version 2 certificate templates. This combination allows the Windows XP Professional or Windows Server 2003 client to enroll users when they log on to their domain, or a machine when it boots, and keeps them periodically updated between these events.

Automatic enrollment of user certificates provides a quick and simple way to issue certificates to users and to enable public key infrastructure (PKI) applications, such as smart card logon, Encrypting File System (EFS), Secure Sockets Layer (SSL), Secure/Multipurpose Internet Mail Extension (S/MIME), and others, within an Active Directory directory service environment. User autoenrollment minimizes the high cost of normal PKI deployments and reduces the total cost of ownership (TCO) for a PKI implementation when Windows XP Professional clients are configured to use Active Directory.

Supports Pending Certificate Requests and Certificate Renewal

User autoenrollment in Windows XP Professional and Windows Server 2003 supports both pending certificate requests and renewal features.

Requesting a Certificate

You can manually or automatically request a certificate from a Windows Server 2003 certificate authority (CA). This request is held until administrative approval is received or the verification process is completed. Once the certificate has been approved or issued, the autoenrollment process completes and installs your certificate automatically.

Renewing a Certificate

The process for renewing an expired user certificate also takes advantage of the autoenrollment mechanism. Certificates are automatically renewed on behalf of the userdependent on the specifications in the certificate template.

Dependencies

The autoenrollment feature has several infrastructure requirements. These include:

•

Windows Server 2003 schema and Group Policy updates

•

Windows 2000 Server domain controllers running Service Pack 3 or later

•

Windows XP Professional or Windows Server 2003 clients

•

Windows Server 2003, Enterprise Edition or Datacenter Edition running as an Enterprise CA

Note: Autoenrollment Group Policy settings may only be applied when using a Windows XP Professional or Windows Server 2003 computer.

Topics Covered

•

How Autoenrollment Works

•

Configuring Certificate Templates

•

Configuring an Enterprise CA

•

Configuring Group Policy

•

User Autoenrollment

•

Certificate Renewal

•

Autoenrollment Functions

•

Updating Group Policy

•

Advanced Features

•

Supported Hardware

•

Troubleshooting

How Autoenrollment Works

This section discusses how autoenrollment works, including autoenrollment and Winlogon, an analysis of the components of the autoenrollment process, and working with certificate 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.

Note: 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 on certificate stores, refer to the Microsoft Platform SDK: http://msdn.microsoft.com/library/en-us/security/security/managing_certificates_with_certificate_stores.asp

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.

Note: 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 certificate 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 certificate 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.

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEExpress

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

Important: 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 system tray 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 Certificate 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 certificate 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.

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

Note: 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 certificate 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.

Note: 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.

Note: 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.

Figure 1: Creating a New Template for Autoenrollment of a Smart Card

Figure 1: Creating a New Template for Autoenrollment of a Smart Card
See full-sized image.

11.

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

Figure 2: Naming the Template

Figure 2: Naming the Template
See full-sized image.

Note: 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.

Figure 3: Defining How the Certificate Request Should Be Processed

Figure 3: Defining How the Certificate Request Should Be Processed
See full-sized image.

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.

13.

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

Important: 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.

Note: 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.

Note: 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. Important: 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.

Configuring an Enterprise CA

This section shows how a Microsoft Enterprise CA must be configured to issue a certificate template after it has been created.

How to Configure an Enterprise CA

To configure an Enterprise CA

1.

On the Administrative Tools menu on a Windows Server 2003 console, open the Certification Authority snap-in.

2.

In the console tree, expand the Certification Authority, and then click Certificate Templates (Figure 4).

Figure 4: Selecting Certificate Templates

Figure 4: Selecting Certificate Templates
See full-sized image.

3.

Right-click Certificate Templates, click New, and then click Certificate Template to Issue.

4.

In the Enable Certificate Templates dialog box (Figure 5), click Auto Enroll Smartcard User (this is the certificate template name that was created previously), and then click OK.

(See Creating a New Template for the Autoenrollment of a Smart Card.)

Figure 5: Enabling a Certificate Template on a CA

Figure 5: Enabling a Certificate Template on a CA
See full-sized image.

Note: Due to replication latency and template caching in the registry, a certificate authority may not be able to issue a certificate template immediately. The timing of issuance is dependent on replication latency between domain controllers.

5.

Close the Certification Authority MMC snap-in.

Configuring Group Policy

This section shows how to configure the Group Policy settings for a site, domain, or organizational unit (OU).

How to Configure Group Policy

Group Policy settings for a site, domain, or OU must be configured to enable certificate autoenrollment in a domain.

To configure Group Policy

1.

Open the Active Directory Users and Computers MMC snap-in.

2.

Right-click the site, domain, or OU that you want to configure Group Policy for, and then click Properties.

3.

Click the Group Policy tab, and then click Edit (Figure 6).

Figure 6: Selecting Group Policy Configuration Options

Figure 6: Selecting Group Policy Configuration Options
See full-sized image.

Note: Machine policy for automatic enrollment of machine and domain controller certificates is configured identically, even though it is controlled through the machine policy of a Group Policy object.

4.

Click User Configuration, Windows Settings, Security Settings, and finally Public Key Policies. In Object Type, right-click Autoenrollment Settings (Figure 7), and then click Properties.

Figure 7: Selecting Autoenrollment Settings

Figure 7: Selecting Autoenrollment Settings
See full-sized image.

5.

Ensure that Enroll certificates automatically is selected as well as the two check boxes under this option (Figure 8). Automatic renewal, certificate cleanup, and publishing in Active Directory are only enabled with all options selected.

Note: Both machine and user policy must be configured to enable certificate enrollment for both types.

Figure 8: Selecting Autoenrollment Settings

Figure 8: Selecting Autoenrollment Settings
See full-sized image.

6.

Click OK.

Autoenrollment is now enabled.

User Autoenrollment

This section illustrates manually pulsing autoenrollment and smart card enrollment.

Key Points

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 Group Policy pulse interval (default of eight hours) or at the next logon.

Manually Pulsing Autoenrollment

Autoenrollment may be pulsed manually through the Certificates MMC snap-in.

To manually trigger autoenrollment

1.

Log on to the domain with the appropriate user account.

2.

Click the Start button, and then click Run.

3.

Type mmc.exe, and press ENTER.

An empty MMC shell starts.

4.

Select the File menu, and then select Add/Remove Snap-In.

A dialog box appears with a list of the snap-ins that have been added to the MMC shell.

5.

Click Add.

A list of the registered snap-ins on the current machine appears.

6.

Double-click the Certificates snap-in, select My User Account, and then click Finish. If enrolling the machine for a certificate, such as a domain controller or a Web server, select Computer account.

7.

Click Next.

8.

Select Local Computer, and then click Finish.

9.

In the Add Standalone Snap-in dialog box, click Close. In the Add/Remove Snap-in dialog box, click OK.

The MMC now contains the personal certificate store for the user.

10.

Right-click the top of the tree on CertificateCurrent User, select All Tasks on the context menu, and then select Automatically Enroll Certificates (Figure 9).

Figure 9: Automatically Enrolling Certificates

Figure 9: Automatically Enrolling Certificates
See full-sized image.

Note: 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.)

Smart Card Enrollment

1.

Click the balloon or the corresponding certificate icon in the system tray once the Certificate Enrollment balloon is displayed. After a short period of time, the balloon will automatically disappear, and only the icon in the system tray will remain. After clicking the balloon, the Autoenrollment UI will start.

Note: The certificate enrollment balloon and wizard are not only for smart card enrollment but also for self-registration authority.

2.

Click the Start button (Figure 10).

The wizard will begin. (The Remind Me Later button will cause the Certificate Enrollment balloon to re-appear at the next Group Policy pulse interval or the next interactive logon.)

Figure 10: Begin Enrolling Certificates

Figure 10: Begin Enrolling Certificates
See full-sized image.

3.

If a smart card with the required CSP on the certificate is not inserted in the smart card reader, the user will be prompted to insert a smart card. Insert the smart card and click OK.

Note: If the certificate template on the users machine contains more than one CSP, the user may have to cycle through the wizard to reach the desired smart card CSP.

4.

If the displayed smart card CSP is not the desired CSP, click Cancel.

The next CSP listed in the certificate template will be displayed.

5.

After inserting an appropriate smart card, click OK.

The wizard will continue.

Note: If the smart card contains a private key and certificate in Slot0 (default container), the user will be warned about replacing the credentials on the smart card. Important: Due to limitations with the smart card CSPs, smart card logon with both Windows 2000 and Windows XP requires that Slot0, or the default container on the card, be used to hold the certificate and private key used for smart card logon. If the card contains multiple keys and certificates, the last generated key and certificate will be marked as the default container on the card.

6.

If it is desired to replace the credentials on the smart card, click Yes (Figure 11).

The wizard will continue (Figure 12).

(The following is only one example of the dialog box a user may see. The smart card UI varies depending on the CSP being used.)

Figure 11: Replacing Credentials Dialog Box

Figure 11: Replacing Credentials Dialog Box

Figure 12: Enrolling Certificates

Figure 12: Enrolling Certificates
See full-sized image.

7.

If a PIN is necessary for the smart card, a dialog box will be displayed. Enter the appropriate PIN and click Enter.

Enrollment completes.

Note: If you enter the PIN incorrectly, the number of times you can retry will be limited.

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 (Figure 13).

Figure 13: Notifying the User of Errors While Enrolling Certificates

Figure 13: Notifying the User of Errors While Enrolling Certificates
See full-sized image.

Note: Users are not prompted when enrollment succeeds.

Certificate Renewal

This section discusses renewal intervals, forced re-enrollment, and smart card renewal.

Renewal Intervals

Windows XP Professional or Windows Server 2003 clients, when combined with a Windows Server 2003, Enterprise Edition certificate authority, will perform automatic renewal of certificates as specified on a per-template basis. Renewal intervals are dictated by the certificate template, which is set to six weeks (before expiration) by default. When certificate renewal is performed, the old (previous) certificate enrollment is always archived automatically on the client machine, and the user directory object is updated.

Important certificate renewal criteria include the following:

•

Automatic certificate renewal will only occur when 80 percent of the certificate lifetime has passed, or when the renewal interval period specified on the template has been reachedwhichever timeframe is smaller.

•

If the renewal period is greater than 20 percent of the certificate lifetime, autoenrollment will not automatically attempt certificate renewal until the 80 percent threshold has been reached.

Forcing Re-Enrollment

An administrator may force all users to re-enroll for a given template by updating the major version number of the template. When Active Directory is queried during logon for required certificate templates, the version number is examined. If the version number has incremented, the certificate template is considered to be updated and the user must re-enroll for that template.

To manually force the template version to be updated (thereby forcing re-enrollment)

•

Right-click the template and select Reenroll All Certificate Holders (Figure 14).

Note: Templates are not updated automatically. By default, templates are updated at a minimum interval of 10 minutes.

Figure 14: Manually Forcing Certificate Re-Enrollment

Figure 14: Manually Forcing Certificate Re-Enrollment
See full-sized image.

Smart Card Renewal

The renewal behavior of a smart card may vary depending on the type of smart card CSP being used and the state of the card at the time of renewal. In general, if the smart card being used has available space for an additional enrollment and the CSP supports multiple keys on a single card, autoenrollment will request the card to generate a new key for enrollment. If this succeeds, the certificate is written to the card and the container is marked as default. The default container is the only container that the Winlogon process will enumerate for a smart card logon certificate and key. If the smart card or CSP cannot generate a new key on the card, the existing key will be reused and a new certificate will be forced onto the card. This action will generate an event in the machines application event log.

Note: Autoenrollment will always use a newly generated key for all enrollment and renewal requests. The only exception to this rule is in the case of some smart card CSPs that cannot support a new key due to storage limitations on the smart card. If a key is reused, an event will be entered in the Client application log.

Revoked Certificates and Renewal

Revoked certificates may not be renewed and may not be used to sign a renewal request. This scenario is explicitly blocked by autoenrollment. In this scenario, a user must perform a new manual enrollment request instead of renewal.

Autoenrollment Functions

This section discusses various functions performed by the autoenrollment process on Active Directory domain-joined machines.

Download of Active Directory Certificates and Trust Objects

Autoenrollment automatically downloads and manages trusted root certificates, cross-certificates, and NTAuth certificates from Active Directory into the local machine registry for domain-joined machines. All users who log on to the machine inherit the trust and downloaded certificates that are downloaded and managed by autoenrollment.

Deleting Expired and Revoked Certificates

Autoenrollment deletes expired and revoked certificates in the userCertificate attribute on the user object in Active Directory. This feature can be enabled through user or machine Group Policy to help ensure that only valid and active certificates are used for encryption operations.

The exit module on the Windows Server 2003 CA also helps to manage the user account in Active Directory, but only deletes expired certificatesit does not remove revoked certificates due to performance reasons. In general, there is no value in publishing a signing certificate to the user object in Active Directory, except for purposes of record-keeping.

Managing User Certificates in the CryptoAPI MY Store

Certificates in the users local MY certificate store may also be managed through the autoenrollment process. On a per-template basis, autoenrollment can be enabled to delete expired and revoked signature certificates. Encryption certificates and keys are never automatically deleted. However, autoenrollment only manages certificates that correspond to certificate templates defined in Active Directory that contain the certificate template extension. This feature is enabled by setting this policy on the Request Handling tab in the Properties of a given certificate template (Figure 15).

Figure 15: Managing Certificates

Figure 15: Managing Certificates
See full-sized image.

If the Delete revoked or expired certificates check box is not enabled, autoenrollment will archive all expired and revoked certificates in the users MY store. As mentioned previously, this setting does not affect the userCertificate attribute in Active Directory for the user object.

Note: This feature is only enabled with encryption keys, not signature key types, which are not normally published to Active Directory.

Updating Group Policy

This section discusses how to update User and Machine Group Policy.

User and Machine Group Policy

User autoenrollment is triggered by the Winlogon process (interactive logon with CTRL+ALT+DELETE keys) or at Group Policy refresh intervals. Normally, User Group Policy is refreshed at logon and Machine Group Policy is refreshed at machine reboot. Group Policy may be manually refreshed using the gpupdate.exe tool that is included in Windows XP.

Manually Forcing a Group Policy Update

To manually force a Group Policy update (for a user or a machine)

•

Run gpupdate.exe with the -Force option at the command line (Figure 16).

Figure 16: Forcing a Group Policy Update

Figure 16: Forcing a Group Policy Update
See full-sized image.

Advanced Features

This section discusses templates that require certificate manager approval, self-registration authority, and how to supersede a certificate template.

Requiring Certificate Manager Approval

A specific certificate template can require that a certificate manager (CA officer) approve the request prior to the CA actually signing and issuing the certificate. This advanced security feature works in conjunction with autoenrollment and is enabled on the Issuance Requirements tab of a given certificate template (

Figure 17). This setting overrides any pending setting on the CA itself.

Once certificate manager approval is required, all automatic enrollment requests are not issued until a certificate manager manually approves the request.

Figure 17: Setting the Requirement for Certificate Manager Approval

Figure 17: Setting the Requirement for Certificate Manager Approval
See full-sized image.

The autoenrollment process will periodically check the CA for approved requests and install the certificates automatically. Smart cards, user certificates, and machine certificates support pending requests. In the case of smart cards, the user will be prompted to insert the smart card when the certificate is issued so that the certificate may be written to the card.

Note: The autoenrollment process supports a maximum of one signature requirement on the template. This limitation exists to support the self-registration authority feature described in Self-Registration Authority. If multiple signatures are desired for a given certificate enrollment, manual enrollment should be used.

Self-Registration Authority

The self registration authority (Self RA) is an advanced feature of certificate enrollment that may be combined with the autoenrollment process.

Self RA refers to certificate enrollment based on the existence of a previously enrolled certificate in which the users private key is used to sign the new certificate request. The Certificate Management Messages over CMS (CMC) protocol provides for this feature where one or more signatures may be used or required for a given certificate enrollment. Self RA requirements are defined in a certificate template which may be managed using the Certificate Templates MMC snap-in.

•

To add an issuance (signature) requirement to a certificate template, open the template and click the Issuance Requirements tab.

To add a signature or issuance requirement, select the This number of authorized signatures check box and add the appropriate number in the following number field (Figure 18).

Now you may add specific requirements for the signing certificate.

Figure 18: Setting the Number of Authorized Signatures

Figure 18: Setting the Number of Authorized Signatures
See full-sized image.

The previous setting is a useful configuration for customers who want to manually enroll users for smart cards with an enrollment station. Then they can supersede the original template with a new template with the previous settings to allow automatic renewal through the autoenrollment process, which will require the user to sign the renewal request with the old certificate.

Additional Self RA Example: You could add the Application Policy for a smart card logon certificate that would be used to enroll for an EFS certificate. This would mandate that users sign their request for an autoenrolled EFS certificate with a valid smart card certificate. The user would then be prompted to insert a smart card and enter a PIN when autoenrollment was activated for the EFS certificate.

Superseding Certificate Templates

Certificate autoenrollment also supports the concept of superseding a template or a previously enrolled certificate. Superseding a template allows an administrator to re-enroll, change, or combine previously issued certificate enrollments into a new certificate enrollment. Autoenrollment always examines existing certificates in the users store and determines if the template used in the issued certificate has been superseded. If a certificate template has been superseded, the user will automatically be enrolled with the new template, and the old certificates will be deleted or archived depending on the template setting.

Benefits

Superseding certificate templates is especially useful in the following scenarios.

•

Changing certificate lifetime

•

Increasing key size

•

Adding extended key usage or application policies

•

Correcting enrollment policy errors

•

Updating users from version 1 templates to version 2 templates

To create or modify a template to supersede an existing certificate

1.

Open the Properties of the template to take precedence, click the Superseded Templates tab (Figure 20), and then click Add.

2.

Select the template you want to supersede (Figure 19), and then click OK.

Figure 19: Selecting a Template to Supersede

Figure 19: Selecting a Template to Supersede
See full-sized image.

3.

The template will be added to the Superseded Templates tab (Figure 20). If you wish to add additional templates that should be superseded with this new template, click Add and repeat. Otherwise, click OK.

Figure 20: Listing Superseded Templates

Figure 20: Listing Superseded Templates
See full-sized image.

Note: Superseding a certificate always generates a new private key for the user or machine.

Supported Hardware

This section lists the smart card readers and smart cards that are supported in the default installations of Windows 2000 and Windows Server 2003.

Table 1 Smart Card Readers

Name Type Common Name Windows 2000 Windows XP/Server 2003

BULL SmarTLP3

Serial

Yes

Yes

GEMPLUS GCR410P

Serial

GemPC410

Yes

Yes

GEMPLUS GPR400

PCMCIA

GemPC400

Yes

Yes

Litronic 220

Serial

Yes

Yes

Rainbow Technologies SCR3531

Serial

Yes

No

Schlumberger Reflex 20

PCMCIA

Yes

Yes

Schlumberger Reflex 72

Serial

Yes

Yes

SCM Microsystems SCR120

PCMCIA

Yes

Yes

SCM Microsystems SCR200

Serial

Yes

Yes

SCM Microsystems SCR300

USB

Yes

Yes

GEMPLUS GemPC430

USB

No

Yes

HP ProtectTools

Serial

No

Yes

Schlumberger Reflex Lite

Serial

No

Yes

SCM Microsystems SCR111

Serial

No

Yes

Systemneeds External

Serial

No

Yes

Omnikey AG CardMan 2020

USB

Utimaco CardMan

No

Yes

Omnikey AG CardMan 4000

PCMCIA

Utimaco CardMan

No

Yes

Omnikey AG CardMan 2010

Serial

Utimaco CardMan

No

Yes

Table 2 Smart Cards

Name Capacity Windows 2000 Windows XP/Server2003

Gemplus GemSAFE

4k

Yes

Yes

Schlumberger Cryptoflex

4k

Yes

Yes

Schlumberger Cryptoflex

8k

Yes

Yes

Gemplus GemSAFE

8k

No

Yes

Infineon (formerly Siemens)

No

Yes

Schlumberger Cyberflex Access

16k

No

Yes

Note: The GEMPLUS GemPC430 is not supported on Windows Server 2003.

Troubleshooting

This section outlines key scenarios that need to be considered when troubleshooting autoenrollment. It also covers how to prepare for autoenrollment failures and lists event logging messages.

Key Issues

The following key issues need to be considered when troubleshooting autoenrollment.

Infrastructure Requirements

Windows XP clients and Windows Server 2003 CAs will always request LDAP-signed communications with domain controllers as a security function. Before deploying autoenrollment or a Windows Server 2003 CA, all domain controllers running Windows 2000 should be upgraded to Service Pack 3 or greater.

Root and Cross-Certificate Download from Active Directory

Autoenrollment automatically downloads root certificates and cross-certificates from Active Directory whenever a change is detected in the directory or when a different domain controller is contacted. If a third-party root certificate or cross-certificate is deleted from the local machine store, autoenrollment will not download the certificates again until a change occurs in Active Directory or a new domain controller is contacted.

To manually force a new download, delete the following registry key and all subordinate keys on all affected machines. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache

EFS and Autoenrollment

EFS always attempts to enroll for the Basic EFS template by default. The EFS component driver generates an autoenrollment request that autoenrollment tries to fulfill. For customers who want to ensure that a specific template is used for EFS (such as to include key archival), the new template should supersede the Basic EFS template. The Basic EFS template should also be removed from any Enterprise CA. This will ensure that autoenrollment will not attempt enrollment for the Basic EFS template any more. For customers who wish to replace the Basic EFS template with a certificate and key that is archived through the Windows Server 2003, Enterprise Edition CA, the proper procedure is to supersede the Basic EFS template with a new version 2 certificate template.

Smartcard Renewal

The Smartcard Logon and Smartcard User version 1 templates may not be renewed through autoenrollment. To renew a version 1 Smartcard Logon or Smartcard User template, the proper procedure is to supersede these templates with a new version 2 template.

Autoenrollment always attempts to generate a new key when performing certificate renewal. For smart cards with limited space that do not support additional key generation, autoenrollment will attempt to reuse the key; however, additional space will still be required to install the new certificate. If no space is available on the card for these operations, the renewal through autoenrollment may fail.

Autoenrollment and Strong Private Key Protection

The version 2 certificate template properties on the Request Handling tab support the ability to require a user password when the private key is used by applications. This is set by selecting the Prompt the user during enrollment option and requires user input when the private key is used. It is important to never use this option for smart card certificates as smart card CSPs also do not support this capability. If this option is chosen, autoenrollment may fail.

Removal of Certificates on Domain Join/Change Domain

When a machine is removed from a domain or added to a new domain, all the downloaded certificates from Active Directory will be removed and refreshed if applicable. Certificates that were issued or autoenrolled from a previous forest will not be removed unless the machine is a domain controller. All client machines will automatically update certificates when the domain or machine information changes. When machines or users have certificates that are required for secure network communications, wireless communications, and so on, it may be necessary to delete the old certificates after joining a new domain or forest.

Autoenrollment Failures

Autoenrollment will warn the user with a warning dialog box when an autoenrollment failure occurs. This feature is only enabled when user interaction is required on the certificate template.

To enable the warning feature for an autoenrollment failure

1.

Open the specified template in the Certificate Templates MMC snap-in.

2.

Click the Request Handling tab.

3.

Click Prompt the user during enrollment on the Request Handling tab of the certificate template properties.

Re-Initialized Smart Cards

If enrollment for a certificate is based on the existence of a smart card certificate and if the smart card has been re-initialized, the smart card Insertion dialog box will ask the user to insert a smart card matching the key container identified by the old certificate. Since the key container has been deleted, the Insertion dialog box will continue to display despite the fact that the user has removed and inserted the card. The only choice is to click Cancel and fail the enrollment.

Enhanced Event Logging

By default, autoenrollment logs errors/failures and successful enrollments in the Application event log on the client machine.

To enable enhanced logging of autoenrollment processes to include warning and informational messages, the following registry values must be created.

User Autoenrollment

HKEY_CURRENT_USER\Software\Microsoft\Cryptography\Autoenrollment: Create a new DWORD value named AEEventLogLevel"; set value to 0.

Machine Autoenrollment

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Autoenrollment: Create a new DWORD value named "AEEventLogLevel", set value to 0.

Note: All failures and errors are automatically logged. It is not necessary to enable the registry key to turn on failure logging.

Event Log Messages

The following event log messages only appear when additional event logging is enabled.

Success Event Log Messages

The following are samples of successful event log messages.

Event Type:

Information

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

2

Date:

2/26/2001

Time:

12:52:02 PM

User:

N/A

Computer:

COMPUTER1

Description:

Automatic certificate enrollment for local system started.

For more information, see Help and Support Services at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Event Type:

Information

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

3

Date:

2/26/2001

Time:

12:52:10 PM

User:

N/A

Computer:

COMPUTER1

Description:

Automatic certificate enrollment for local system completed.

For more information, see Help and Support Services at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Event Type:

Information

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

27

Date:

2/26/2001

Time:

3:26:03 PM

User:

HAYBUV\USER1

Computer:

COMPUTER1

Description:

Automatic certificate enrollment for logged on user is cancelled.

For more information, see Help and Support Services at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Event Type:

None

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

28

Date:

6/25/2001

Time:

7:36:16 AM

User:

HAYBUV\USER1

Computer:

COMPUTER1

Description:

Automatic certificate enrollment for HAYBUV\User1 successfully installed one AutoEnrollSmart cardEmail certificate when retrieving pending requests. User interaction was required.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Event Type:

None

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

29

Date:

7/9/2001

Time:

6:39:29 AM

User:

HAYBUV\USER1

Computer:

COMPUTER1

Description:

Automatic certificate enrollment for HAYBUV\USER1 reused the private key when requesting one AutoEnrollSmart cardUser certificate.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Event Type:

None

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

20

Date:

7/9/2001

Time:

6:39:29 AM

User:

HAYBUV\USER1

Computer:

COMPUTER1

Description:

Automatic certificate enrollment for HAYBUV\USER1successfully renewed one AutoEnrollSmart cardUser certificate from certificate authority TestCA on Server1.haybuv.com.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Event Type:

None

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

29

Date:

7/17/2001

Time:

9:37:29 AM

User:

HAYBUV\user1

Computer:

TESTCA

Description:

Automatic certificate enrollment for HAYBUV\user1 reused the private key when requesting one Autoenroll Smart card User certificate.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: This event signifies the fact that the private key was reused during a certificate renewal.

Failed Event Log Messages

The following are samples of failed event log messages.

Event Type:

Error

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

15

Date:

7/8/2001

Time:

3:09:41 PM

User:

N/A

Computer:

TEST1

Description:

Automatic certificate enrollment for Haybuv\User1 failed to contact Active Directory (0x8007054b). The specified domain either does not exist or could not be contacted. Enrollment will not be performed.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: This error most often occurs when a user is logged on to a machine with cached credentials and is offline. Therefore, autoenrollment cannot continue and will be attempted later.

Event Type:

Error

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

15

Date:

2/24/2001

Time:

10:36:08 AM

User:

N/A

Computer:

TEST1

Description:

Automatic certificate enrollment for local system failed to contact a directory server (0x80072751). A socket operation was attempted to an unreachable host. Enrollment will not be performed.

For more information, see Help and Support Services at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: This error most often occurs when a domain controller is not available or is not accessible by the client. Common causes include network errors, network connectivity, and so on.

Event Type:

Error

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

13

Date:

7/5/2001

Time:

9:37:44 AM

User:

N/A

Computer:

TEST1

Description:

Automatic certificate enrollment for local system failed to enroll for one HAYBUV IPSEC certificate (0x800706ba). The RPC server is unavailable.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: This error typically occurs when the certificate authority is not available on the network or the service is stopped.

Event Type:

Error

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

13

Date:

7/5/2001

Time:

7:41:27 AM

User:

N/A

Computer:

TEST1

Description:

Automatic certificate enrollment for local system failed to enroll for one HAYBUV IPSEC certificate (0x8009400f). An attempt was made to open a certification authority database session, but there are already too many active sessions. The server may need to be configured to allow additional sessions.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: This is a rare event when the certificate authority is under heavy load and cannot respond to the request in a timely manner. Autoenrollment will automatically try again at a later time.

Event Type:

Error

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

16

Date:

7/5/2001

Time:

2:53:34 AM

User:

N/A

Computer:

TEST1

Description:

Automatic certificate enrollment for local system failed to renew one HAYBUV IPSEC certificate (0x8009400f). An attempt was made to open a Certification Authority database session, but there are already too many active sessions. The server may need to be configured to allow additional sessions.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: This is the same error as the previous one, but it involves a renewal.

Event Type:

Warning

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

7

Date:

7/24/2001

Time:

7:48:27 PM

User:

HAYBUV\USER1

Computer:

TEST1

Description:

Automatic certificate enrollment for HAYBUV\USER1 could not enroll for Key Recovery Agent certificate template due to one of the following situations.

•

Enrollment access is not allowed to this template.

•

Template subject name, signature, or hardware requirements cannot be met.

•

No valid certificate authority can be found to issue this template.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: This is an autoenrollment error that occurs when a user has a certificate and private key installed that corresponds to a given template that is now expiring. Autoenrollment attempts to automatically renew the certificate; however, the user does not have applicable permissions for this template and therefore autoenrollment fails. Autoenrollment is based on certificates in the store as well as certificate template settings.

Event Type:

Error

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

13

Date:

7/17/2001

Time:

9:22:10 AM

User:

HAYBUV\user1

Computer:

TESTCA

Description:

Automatic certificate enrollment for HAYBUV\user1 failed to enroll for one Autoenroll smart card user certificate (0x80094812). The e-mail name is unavailable and cannot be added to the Subject or Subject Alternate name.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: This error occurs when the user account in Active Directory does not have a valid e-mail address on the user property page in Active Directory Users and Computers MMC snap-in. Enrollment for certificate templates in Active Directory requires an e-mail address to exist prior to enrollment.

Event Log Tools

A new tool (script) is included on the Windows XP Professional and Windows Server 2003 client to query a local system for various events. This script can be used to identify autoenrollment errors on the client and perform appropriate actions. The command line help for this tool is noted and provided as follows:

Z:\>eventquery /?  
Microsoft (R) Windows Script Host Version 5.6  
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.  
----------------------------------------------------------------------  
EVENTQUERY.vbs [/S system [/U username [/P password]]] [/FI filter]  
        [/FO format] [/R range] [/NH] [/V] [/L logname | *]  
Description:  
  The EVENTQUERY.vbs script enables an administrator to list  
  the events and event properties from one or more event logs.  
Parameter List:  
  /S   system     Specifies the remote system to connect to.  
  /U   [domain\]user  Specifies the user context under which the  
              command should execute.  
  /P   password    Specifies the password for the given  
              user context.  
  /V           Specifies that the detailed information  
              should be displayed in the output.  
  /FI  filter     Specifies the types of events to  
              filter in or out of the query.  
  /FO  format     Specifies the format in which the output  
              is to be displayed.  
              Valid formats are "TABLE", "LIST", "CSV".  
  /R   range      Specifies the range of events to list.  
              Valid Values are:  
                'N' - Lists 'N' most recent events.  
               '-N' - Lists 'N' oldest events.  
              'N1-N2' - Lists the events N1 to N2.  
  /NH          Specifies that the "Column Header" should  
              not be displayed in the output.  
              Valid only for "TABLE" and "CSV" formats.  
  /L   logname     Specifies the log(s) to query.  
 /?           Displays this help/usage.  
  Valid Filters Operators allowed  Valid Values  
  ------------- ------------------ ------------  
  DATETIME    eq,ne,ge,le,gt,lt  mm/dd/yy(yyyy),hh:mm:ssAM(/PM)  
  TYPE      eq,ne        ERROR, INFORMATION, WARNING,  
                    SUCCESSAUDIT, FAILUREAUDIT  
  ID       eq,ne,ge,le,gt,lt  non-negative integer  
  USER      eq,ne        string  
  COMPUTER    eq,ne        string  
  SOURCE     eq,ne        string  
  CATEGORY    eq,ne        string  

Note: Filter "DATETIME" can be specified as "FromDate-ToDate"

   Only "eq" operator can be used for this format.  
Examples:  
  EVENTQUERY.vbs  
  EVENTQUERY.vbs /L system  
  EVENTQUERY.vbs /S system /U user /P password /V /L *  
  EVENTQUERY.vbs /R 10 /L Application /NH  
  EVENTQUERY.vbs /R -10 /FO LIST /L Security  
  EVENTQUERY.vbs /R 5-10 /L "DNS Server"  
  EVENTQUERY.vbs /FI "Type eq Error" /L Application  
  EVENTQUERY.vbs /L Application /FI "Datetime eq 06/25/00,03:15:00AM-06/25/00,03:15:00PM"  
  EVENTQUERY.vbs /FI "Datetime gt 08/03/00,06:20:00PM"           /FI "Id gt 700" /FI "Type eq warning" /L System  
  EVENTQUERY.vbs /FI "Type eq error OR Id gt 1000 "  

Summary

Windows Server 2003, Enterprise Edition through the Certificate Services component provides user certificate autoenrollment. This allows administrators to easily deploy certificates throughout the enterprise while requiring no user interaction. User certificate autoenrollment in the Windows XP Professional and Windows Server 2003 operating systems builds on Microsofts long-established reputation for shipping robust PKI components that have a low TCO. Since PKI is an integral part of the Windows XP Professional operating system, Windows Server 2003 PKI provides some distinct advantages over third-party add-in components. These advantages include:

•

No per-certificate fees or per-user PKI licenses

•

Centralized user security management

•

Integration with normal enterprise management tasks

•

Single sign-on capabilities to networks and applications

•

Managed trust capabilities

•

Support for all applications through CryptoAPI

Keep in mind that almost all third-party PKIs must be purchased separately, and require per-certificate license fees and increased management tasks.

Overall, certificate autoenrollment features in Windows Server 2003 should provide organizations and enterprises with the ability to effortlessly deploy digital certificates and PKI-enabled applications with little or no additional cost to a normal IT operations budget.

Related Links

•

Whats New in Security for Windows XP Professional and Windows XP Home Edition at http://www.microsoft.com/windowsxp/pro/techinfo/planning/security/whatsnew/default.asp

•

Windows XP and .NET: An Overview at http://www.microsoft.com/windowsxp/pro/techinfo/planning/dotnet/default.asp

•

CMC (Certificate Management Messages over CMS) at http://www.ietf.org/rfc/rfc2797.txt?number=2797

•

Data Protection and Recovery in Windows XP at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/default.mspx

•

Securing Mobile Computers with Windows XP Professional at http://www.microsoft.com/windowsxp/pro/techinfo/administration/mobile/default.asp

•

PKI Enhancements in Windows XP Professional and Windows Server 2003 at http://www.microsoft.com/technet/prodtechnol/winxppro/plan/default.mspx

•

For the latest information about Windows XP, see the Windows XP Web site at http://www.microsoft.com/windowsxp/default.asp

•

For the latest information about Windows Server 2003, see the Windows Server 2003 Web site at http://www.microsoft.com/windowsserver2003/default.mspx



Show:
© 2014 Microsoft