Successful Errors Installing Windows Server 2008 Certificate Authority

Successful Errors Installing Windows Server 2008 Certificate Authority

  • Comments 4
  • Likes

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: CONTOSO\testuser
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 DOMAIN\username 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:

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<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%\logs\ServerManager.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:\rtm\ds\security\services\ca\fs\crypto\capicryptofactory.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

  • Nice Post! I hate to complain...but it would be nice if those logs could all be found in the same location. What about "%Systemroot%\Logs"? :-) Christian Schindler

  • It's a good complaint, I agree. :) I'll poke some dev's about that as a Win8 request, thanks.

    - Ned

  • Great post, I have nearly the same incident, but the permissions are ok. I get a "file not found" when I try to install the CA (unfortunately a germn error message):

    ervices,CN=Services,CN=Configuration,DC=avat,DC=local

    202.2428.246: Sperrlisten-Verteilungspunktobjekt für Verzeichnisdienst erstellen202.3726.249: Zertifizierungsstelle im Verzeichnisdienst veröffentlichen

    109.1880.439: Zertifikat erstellen

    109.2552.443: Server installieren: Das System kann die angegebene Datei nicht finden

    (***this is file not found***)

    . 0x80070002 (WIN32: 2)

    0.0.965: Meldungsfeld: EmergencyMessageBox: Fatal: 0x80004003  MsgId: 0x       : Das System kann die angegebene Datei nicht finden. 0x80070002 (WIN32: 2)

    114.5848.949: Ende: CCertSrvSetup::Install: Das System kann die angegebene Datei nicht finden. 0x80070002 (WIN32: 2)

    I have tried all the stuff I found, but nothing works...

    Thomas

  • Hey Thomas,

    So we have seen this error before.

    I have a feeling that you probably either do not have the OID container object in your configuration partition or you do the have to OID container there but it is of the wrong objectClass type.

    Look at the following location using ADSIEdit.msc

    Public Key Services,Services,Configuration,dc=<AD Root Domain Name>

    The following containers should exist:

    AIA = ObjectClass of "top;container"

    CDP = ObjectClass of "top;container"

    Certificate Templates = ObjectClass of "top;container"

    Certification Authorities = ObjectClass of "top;container"

    Enrollment Services (May be not there until the CA is installed) = ObjectClass of "top;container"

    KRA = ObjectClass of "top;container"

    OID = ObjectClass of "top;msPKI-Enterprise-Oid"

    If the OID container is set to "top;Container" then you will need to delete it, then recreate it using the following steps:

    1. In ADSIEDIT.MSC, click on the CN=Public Key Services container.

    2. In the right hand pane, locate CN=OID.

    3. Now create a new object in the CN=Public Key Services container.

    4. Select the class: msPKI-Enterprise-OID. Click Next.

    5. Set the cn attribute to OID, and click Next.

    6. You don’t need to set any more attributes, so click Finish.

    I hope that this helps,

    Rob Greene