Event ID: Event Source:

Event ID 13 Source AutoEnrollment

Event ID	13
Source	AutoEnrollment
Type	Error
Description	Automatic certificate enrollment for <user name> failed to enroll for one <template name> certificate (<error code>).<error description>
English, please!	This information is only available to subscribers. An example of English, please!
Concepts to understand	What is a certificate enrollment?
Comments	Mihai Andrei (Last update 5/4/2008): - Error code: 0x800706ba (Error code 0x800706ba) - This problem occurs when the client computer is configured to use multiple DNS suffixes. See M939882 for a hotfix applicable to Windows Vista. Also, see M947237 for additional information. - Error code: 0x80070005 (Error code 0x80070005) - This event can occur after you install Windows Server 2003 Service Pack 1. See M903220 and M927066. Anonymous (Last update 9/30/2007): In my case, it was not sufficient to add the "Domain Controllers" to the active directory group. I additionally had to add the group in the Security settings of the CA itself. Open CA management console from "Administrative Tools". Right-click the server name and select "Properties". Select security and add group "Domain Controllers". Select checkbox "Request Certificates" and click OK. Ionut Marin (Last update 8/2/2007): - Error code: 0x80092004 (Error code 0x80092004) = "Cannot find object or property" - If a user tries to enroll for certificates from a Windows Server 2003 Enterprise Edition certification authority (CA) and the Include e-mail name in subject name option is selected on the template, the user cannot enroll. This problem occurs because the e-mail address is not defined in the Active Directory account of the user who is trying to enroll. The LDAP mail attribute is missing from the Active Directory user account. See M330238 to fix this problem. From a newsgroup post: "Can you check what are the ACLs on the directory “%system drive%\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys”? Does it have just "Everyone"? If this is the only permission it has, then enrollment will fail. After creating the private key, enrollment removes the "Everyone" group from the permission on the private key (as it is bad to have that), however if "Everyone" is the only ACL on the key, this renders the key not accessible by anyone. You should have only “Administrators” and “System” able to access the machine private keys". As per Microsoft: "The autoenrollment component determined that a valid certificate is not available for the user or computer account. The user or computer account required a new certificate, a certificate was superseded, a certificate was revoked and requires replacement, or a certificate requires renewal". See MSW2KDB and the link to "Certificate Autoenrollment in Windows XP" for additional information on this event. Se the link to "Certificate Autoenrollment in Windows Server 2003" for additional information on this event. Andrej Ota (Last update 1/23/2007): - Error code: 0x80070005 - I have had just the same problem. I have a domain with two DCs and a separate CA server. CA auto-enrolled certificates for itself, but other domain servers, DCs and workstations (with an exception of two test Windows Vista Business workstations) just reported this error. I finally found an idea in TechNet article "Configuring and Troubleshooting Windows 2000 and Windows Server 2003 Certificate Services Web Enrollment" where invalid or missing SPN (service principal name) could cause authentication problems. Sure enough, the CA server had only one SPN registered: "HOST/CA". I used the setspn utility from support tools to add "HOST/CA.my.domain", rebooted the server, and voila, autoenrollment started working throughout the domain. The only interesting lesson from this incident was a fact that Vista had no problems auto-enrolling. It seems that it can find proper SPN from AD and successfully authenticate to the CA server. This does not seem to work for Windows 2003 servers and Windows XP SP2 workstations. Mårten Edelbrink (Last update 1/11/2007): We had this issue on all our domain controllers, except the one running Certificate Services. Adding the "Domain Controllers" group to the CERTSVC_DCOM_ACCESS security group, and added the correct permissions to the "\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA" folder, worked on 6 of 8 domain controllers. I could not get it to work on the last two and I have tried everything here and some tips I got from Internet. So far, I had not restarted any DC. I found a newsgroup post suggesting that you should restart the KDC services. So I tried that on the remaining DCs and it solved the problem. Why bother deciphering Event logs when GFI EventsManager can do everything for you? Free trial here! Anonymous (Last update 7/25/2006): The event 13 from Autoenrollment message may be related to the new DCOM security enhancement of Windows Server 2003 SP1. Windows Server 2003 Certificate Services provides enrollment and administration services by using the DCOM protocol. Certificate Services provides several DCOM interfaces to make these services available. For correct access and usage of these services, Certificate Services assumes that its DCOM interfaces are set to allow remote activation and access permissions. However, Windows Server 2003 SP1 introduces enhanced default security settings for the DCOM protocol. Specifically, SP1 introduces more precise rights that give an administrator independent control over local and remote permissions for launching, activating, and accessing COM servers. Therefore, because of the enhanced default security settings for DCOM that are introduced by SP1, you may have to update these security settings to make sure of the continued availability of these services after you install SP1. Suggestions: 1. Please check to ensure that a new security group, CERTSVC_DCOM_ACCESS, has been created after applied the SP1. 2. Please add the "Domain Users", "Domain Computers", "Domain Controllers" groups to the new CERTSVC_DCOM_ACCESS security group. 3. Then, we can have Certificate Services update the DCOM security settings by running the following commands: certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG net stop certsvc net start certsvc. Alexander (Last update 7/12/2006): In my case, the CRL was expired. The "pkiview" tool (from the Resource Kit) was very helpful for me. Matthew Wheeler (Last update 6/30/2006): In my case, the Certificate Authority domain controller had its OS upgraded from standard SP1 to enterprise server 2003 R2. To fix the problem we added the correct permissions to the “\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA” folder. We added full control for System and Administrators (found that System was not listed for access and Administrators was listed but with no access granted) and ran the following commands: certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG net stop certsvc net start certsvc The new member server in the domain was then able to auto enroll for Directory Email Replication, Enrollment Agent (Computer), IPSec and Domain Controller Authentication certificate(s). Russell C. (Last update 5/8/2006): - Error code: 0x80070005 - We were preparing our Domain for the addition of a Windows 2003 R2 domain controller. This addition required an update to the schema. We updated the schema, things looked great. I built the new R2 server, ran dcpromo, no problems. I ran through the event logs and ran across this error in the Application log. It turned out the certsvc on our root certificate authority (Windows 2000 DC) had stopped during the schema upgrade and did not restart on its own. I simply opened the certification authority MMC, and started the service. I rebooted the new R2 server to make a clean go of it and the problem was solved. Anonymous (Last update 5/4/2006): - Error code: 0x800706ba - In my case, the problem was originated by an Exchange member server with a certificate installed and later removed from the domain without revoking the certificates adequately. We used Step 6 from Microsoft article M889250 to remove CA objects from Active Directory. In the same time, you can use the PKView utility to remove the server who is causing the error. Important: In the system log you will see a DCOM error 10009 indicating which is the server that is not responding. Massimo Mattana (Last update 3/31/2006): I had this problem with Enterprise Root CA installed on Win2003 SP1. I resolved this by using the following commands: certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG net stop certsvc net start certsvc Then, I added the <childdomain>\<computer accounts> to the <root domain>\CERTSVC_DCOM_ACCESS group. What I needed was that the domain controllers in the child domain would receive a DC Certificate from RootCA, so in my case, <computer accounts> was the default "Domain Controllers" global group located in the child domain. Richard Bottroff (Last update 3/15/2006): - Error code: 0x80070005 (Error code 0x80070005) - After adding "Domain Controllers" to the "CERTSVC_DCOM_ACCESS" group the problem remained. Then, I found that the Administrators group and the System account did not have the proper permissions in the ACL on directory "%system drive%\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys". After making sure that both Administrators and System had Full Control permission, the problem still remained. Article M903220 provided the solution in my case. On the CA machine, I entered the following commands at the command prompt: certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG net stop certsvc net start certsvc The first time I ran the "setreg" command, it failed because of invalid data. I restarted my Domain Controller and re-entered the command with succes. My Domain Controller with the AutoEnrollment failure was then able to successfully renew the certificate. Anonymous (Last update 2/18/2006): - Error code: 0x80070005 (Error code 0x80070005) - This error will also occur if the client in question does not meet minimum supported CAs in Certificate Management. It happened here when trying to apply Domain Controller Authentication templates to my Domain controllers group when not all of my DCs are Enterprise Edition, thus not meeting the minimum CA. Ton (Last update 12/6/2005): - Error code: 0x80070005 (Error code 0x80070005) = "Access is denied" - In my case, the problem was the DCOM configuration, more precisely the DCOM was not running. To resolve this issue from a command prompt type DComcnfg, then click Component Services -> Computers -> right click My Computer and choose Properties. Choose tab Default Properties and check “Enable Distributed COM on this computer”. Why bother deciphering Event logs when GFI EventsManager can do everything for you? Free trial here! Anonymous (Last update 10/26/2005): In my case, the problem was that the certificate template for the Domain Controller had no autoenrollment permission enabled. To solve this problem, use certtmpl.msc to create a new certificate template based on the existing Domain Controller certificate, but with "publish to AD" checked and autoenrollment permission for Domain Controllers group. Roberto Boero (Last update 9/28/2005): To solve this problem add “Domain Controllers” to “CERTSVC_DCOM_ACCESS" along with any other computer or user groups that you wish to be able to request certificates. Windows Server 2003 SP1 changes the security for certificates and for some reason they did not populate the above group. Arnaud Bacchella (Last update 6/1/2005): - Error code: 0x80070005 (Error code 0x80070005) - I followed the instructions contributor Ionut Marin gave about checking what are the ACLs on the directory “C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys", and the problem has been fixed. Ben Blackmore (Last update 5/19/2005): I fixed this error by opening the certificate service web enrollment page (http://<ca server>/certsrv), adding the site to my trusted sites list, and then installing the CA certificate chain. Anonymous (Last update 5/3/2005): If you receive an access denied error (Error code 0x80070005) from AutoEnrollment on a DC after installing SP1 on W2k3, add the Domain Controller’s OU to the newly created CERTSVC_DCOM_ACCESS domain group in Active Directory and restart the MS-DTC service. This also applies to a secondary DC in a sub-domain as well. Umit Cakir (Last update 3/28/2005): APPLIES TO: Profile Maker 8.x SYMPTOMS: After installing Windows XP SP2 on client computers, executing Profile Maker with elevated permissions fails to run the configuration. CAUSE: Windows XP SP2 includes a new service called the Windows Firewall, which replaces the Internet Connection Firewall (ICF). The Windows Firewall is enabled by default on all interfaces and does not allow communications with the client that are initiated from an external source (any other computer). This causes access to the file and print sharing service, as well as many other services, to be blocked for all external computers. This can cause problems with some network applications. When Profile Maker is executed with elevated permissions (/a mode), it needs access to copy the client service down to the users computer and then start it up. This requires that the Secondary servers logon accounts have access to the File and Print services on systems where it will be running with elevated permissions. Since this connection is initiated from the Secondary Server, it is blocked with the default installation of Windows XP SP2. RESOLUTION: To allow the Profile Maker Secondary servers access to the File and Print services on the client computers while maintaining the computer security implemented by XP SP2, apply Windows Firewall Exceptions to the File and Print Sharing service. To enable this for your domain, use the new system.adm template shipped with Windows XP SP2. Add each of your Secondary server IP address separated by commas to the "Windows Firewall: Allow file and printer sharing exception" policy. This policy can be located under the Computer Configuration in the “Administrative Templates\Network\Network Connections\Windows Firewall\Domain Profile” folder. Adrian Grigorof (Last update 1/23/2004): - Error code: 0x80040154 = "Class not registered" - For generic information about this error code see Error code 0x80040154.
Links	M330238, M889250, M903220, M927066, M939882, M947237, Error code 0x80070005, Error code 0x800706ba, Error code 0x80040154, Error code 0x80092004, Certificate Autoenrollment in Windows XP, EventID 10009 from source DCOM, MSW2KDB, Configuring and Troubleshooting Windows 2000 and Windows Server 2003 Certificate Services Web Enrollment , Certificate Autoenrollment in Windows Server 2003
Search	Google Web - Microsoft Support - Bing - EventID.Net Queue - More links...
Custom search	The custom search information is available to subscribers only.
Feedback	Send comments - Notify me when updated
	Print version