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
http://technet.microsoft.com/en-us/library/cc772393.aspx
Active Directory Certificate Services
http://technet.microsoft.com/en-us/library/cc534992.aspx
- Ken “The Beard” McMahan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.