Troubleshooting (Certificate Autoenrollment in Windows Server 2003)
Updated: January 1, 2003
Applies To: Windows Server 2003 with SP1
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
- Open the specified template in the Certificate Templates MMC snap-in.
- Click the Request Handling tab.
- 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.
1سپاس
LinkBack URL
About LinkBacks
نوشته اصلی توسط imannami
