Successful Errors Installing Windows Server 2008 Certificate Authority
Oxymoron - a figure of speech by which a locution produces an incongruous, seemingly self-contradictory effect, as in “cruel kindness” or “succeeded with errors.”
Hi, Ken here. Recently I encountered an issue where the customer was trying to install certificate services on Windows Server 2008. They installed the Active Directory Certificate Services role using Server Manager. When the install completed they received the error “Installation succeeded with errors.” Sometimes “completed with errors” isn’t a big deal, but in this case it was really just “failed.”
So first off, let’s take a look in the Event Log to see if anything more informative than “Succeeded with Errors” has been recorded. In the event log I saw the following events:
Log Name: Application
Source: Microsoft-Windows-CertificationAuthority
Date: 6/25/2008 11:06:09 AM
Event ID: 5
Task Category: None
Level: Error
Keywords: Classic
User: SYSTEM
Computer: con-root-ca.contoso.com
Description:
Active Directory Certificate Services could not find required registry information.
The Active Directory Certificate Services may need to be reinstalled.
Log Name: System
Source: Service Control Manager
Date: 6/25/2008 11:50:57 AM
Event ID: 7023
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: con-root-ca.contoso.com
Description:
The Active Directory Certificate Services service terminated with the following
error:
Cannot complete this function.
Log Name: System
Source: Microsoft-Windows-DistributedCOM
Date: 6/25/2008 11:41:13 AM
Event ID: 10016
Task Category: None
Level: Error
Keywords: Classic
User: CONTOSOtestuser
Computer: con-root-ca.contoso.com
Description:
The application-specific permission settings do not grant Local Launch permission
for the COM Server application with CLSID
{D99E6E73-FC88-11D0-B498-00A0C90312F3}
to the user DOMAINusername SID (SID Value) from address LocalHost (Using LRPC).
This security permission can be modified using the Component Services
administrative tool.
So, from the event logs, we see some pretty serious issues. Certificate Services cannot find required registry information, and is causing the service to not start. When we try to start the service manually, we get the following error:
Cannot complete this function 0x3eb (win32:1003)
That’s a nice error, but it doesn’t tell us anything new. The other event referenced the registry, so, let’s go take a look in there. The keys for the Certificate Authority are located in the following location:
HKLMSYSTEMCurrentControlSetServicesCertSvcConfiguration<CA Name>
In the registry we see that the “Setupstatus” value is set to “0xc-“. This is not correct, if the installation was really successful, it should be set to “1”. We also see that the “Security” value is missing completely. The security value is a default binary value that is stamped in the registry during the Certificate Authority installation.
Setupstatus = 0xc –
Security= ?? – This value was missing completely
So now we know that the installation not only had errors, but actually did not complete. So, I then moved over to the Server Manager log, to see what it had to say. The Server Manager log contains details about operations performed by the Server Manager. The log can be found in %SystemRoot%logsServerManager.log.
In the ServerManager.log, I saw the following:
2124: 2008-07-01 14:05:50.494 [Provider] Error (Id=0) System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) at Microsoft.CertificateServices.Setup.Interop.CCertSrvSetupClass.Install()
at Microsoft.Windows.ServerManager.CertificateServer.CertificateServerRoleProvider.Configure(Object clientContext, String hostComputerName, XDocument guest, String guestIdentity)
So, in the Servermanager.log, we see a great big “Access is Denied”. That’s something I can understand, but it doesn’t tell us what it is trying to access. Well, we were installing Certificate Services, so I then moved over to the Certificate Services setup log. The setup log is helpful for troubleshooting in the event of errors. The setup log is located in %Systemroot%CertOCM.log.
In the CertOCM.log, I saw the following:
109.2552.443: Install Server: Access is denied. 0x80070005 (WIN32: 5)0.0.965: Message Box: EmergencyMessageBox: Fatal: 0x80004003 MsgId: 0x : Access is denied. 0x80070005 (WIN32: 5)
114.5848.949: End: CCertSrvSetup::Install: Access is denied. 0x80070005 (WIN32: 5)
So in the CertOCM.log, I see another “Access is Denied”. This is still not specific enough to determine the issue. I know that during the installation, we look in the Active Directory to load the templates. So I then moved over to the CertEnroll.log to see what we have in there. When an enrollment attempt is made, the information is recorded in the %Systemroot%CertEnroll.log.
In the CertEnroll.log, I saw the following error for all of the templates.Here is one of the entries I see, this one for the SmartcardLogon template:
808.4098.0: 0x32 (WIN32: 50)
808.4131.0: 0x32 (WIN32: 50)
429.2157.0: 0x32 (WIN32: 50): 00002098: SecErr: DSID-03150E8A, problem 4003
(INSUFF_ACCESS_RIGHTS), data 0
808.4138.0: 0x32 (WIN32: 50)
808.7585.0: 0x80072098 (WIN32: 8344): SmartcardLogon
I also saw the following error in the Certenroll.log:
202.5252.0: 0x80090016 (-214689380): Exception at
d:rtmdssecurityservicescafscryptocapicryptofactory.cpp(501):
CryptAcquireContext( &hProv, pszContainer, pszProvider, nProviderType, fAcquire)
HRESULT = 0x80090016
So this is something good. I was already sure that there is a permissions issue, but now we are seeing specifically, “INSUFF_ACCESS_RIGHTS”, when accessing the Certificate Templates in the Active Directory. So I then moved over to the AD, to see what kind of permissions we had on the templates. I did the following to check the permissions:
1. Using Adsiedit, I looked at the permissions on the templates under cn=public key services,cn=services,cn=configuration,dc=< Forest Root Domain> . The Enterprise Administrators group should have had Full Control on all of the certificate templates.
2. I also checked permissions for all the sub containers underneath Public Key Services. The account installing the CA should have had permissions. For example, Certificate Templates, OID, KRA containers.
Note : By default only the Enterprise Admins and the Domain Admins groups in the Forest Root Domain have enough permission to install and configure an Enterprise Certification Authority. If you have modified permissions, you may not have given yourself enough permission to do the install.
In this case, the permissions for Enterprise Administrators were set to Read-Only, or had been removed completely on some of the objects. Once we restored the Enterprise Admins back to the correct permissions, we were able to successfully install the Certificate Authority using the Microsoft CSP…and all was right in the World. :-)
Finally, here are a couple of links to some great information. The first is a Step by Step, complete with requirements and a lab setup to play with. The second is the Active Directory Certificate Services Portal site, loads of PKI goodness.
Windows Server Active Directory Certificate Services Step-by-Step Guide https://technet.microsoft.com/en-us/library/cc772393.aspx
Active Directory Certificate Services
https://technet.microsoft.com/en-us/library/cc534992.aspx
- Ken “The Beard” McMahan