Certificate Autoenrollment in Windows Server 2003
Published: April 1, 2003
By David B. Cross
On This Page
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. |
| 11. | In the Template display name field, type a unique name for
the template (Figure 2). 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. 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). |
| 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.) 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). 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. |
| 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. |
| 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). 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.) |
| 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.) .gif) Figure 11: Replacing Credentials Dialog
Box |
| 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). 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. |
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).
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). |
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.
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. |
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. |
| 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. |
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
| 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
| 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