Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 13 Source: AutoEnrollment

Automatic certificate enrollment for <user name> failed to enroll for one <template name> certificate (<error code>).<error description>
The Everyone group was missing from the CERTSVC_DCOM_ACCESS group. Clearly, because it is named IEDEREEN (Dutch) in our environment. Added this, and restarted the service. On the specific server, triggered the creation of a certificate by entering "certutil -pulse"
After promoting a 2008 R2 server to DC and replicating AD from 2003 DC I didn't have the groups mentioned in other posts. The fix for me was to add domain computers to "Builtin\distributed COM users" group. I believe this was a 2003 builtin group however replicated to the 2008 DC.

Once this was done I restarted the ADCS service and checked the security permissions on the templates. I checked issued certificates and the certificates were now being autoenrolled, I could also autoenroll through MMC except on the 2003 DC oddly enough.
- Error code 0x800706ba - This problem occurs when the client computer is configured to use multiple DNS suffixes. See ME939882 for a hotfix applicable to Windows Vista. Also, see ME947237 for additional information.
- Error code 0x80070005- This event can occur after you install Windows Server 2003 Service Pack 1. See ME903220 and ME927066.
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.
- 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 ME330238 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.

- 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/", 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.
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.
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.

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.
In my case, the CRL was expired. The "pkiview" tool (from the Resource Kit) was very helpful for me.
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).
- 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.
- 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 ME889250 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.
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.
- 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 ME903220 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.

- 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.
- 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”.
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.
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.
- 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.
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.
Error code 0x80070005 - If you receive an access denied error 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.
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.
- Error code 0x80040154 = "Class not registered"

Windows Event Log Analysis Splunk App

Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to



Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.