none
ADCS Enterprise CA Role Installation: Enrollment Services object not created in AD?! RRS feed

  • Question

  • Hello all,

    We are in the process of migrating our Issuing CAs from WS2008R2 to WS2012R2.  We are having to move the CAs to brand new servers (as opposed to upgrading in-place).

    A problem we've run into sporadically is that after we've removed the ADCS role from the old CA server & then install/configure ADCS on the new server, the wizard complains that the Enrollment Services object is already existing and asks if we want to overwrite it.  We select "Yes" and the wizard completes as if everything is fine.

    Afterwards, the CA service starts up fine on the new server, but we're unable to assign any certificate templates to it.  The root cause of this, we found, was that there was no Enrollment Services object corresponding to that CA in Active Directory!

    The account we used to configure ADCS is a member of Enterprise Administrators, so permissions on the container shouldn't be an issue.  Also, I find it troubling that the wizard doesn't check/complain if it is unable to write the required object to AD.

    Any thoughts on how we can troubleshoot/resolve this?

    Wednesday, November 13, 2019 8:42 PM

Answers

  • Hello All,

    I believe I've determined the root cause of this issue and how to prevent it:

    Root Cause: We have many domain controllers geographically dispersed. When ADCS is removed from the old CA, as long as we perform that activity as an EA, the existing Enrollment Services object is removed, however, that change needs time to replicate to all DCs. 

    The implication of this is that some DCs will still have a record of the object existing while others don't.  When ADCS is deployed on the new server, it attempts to re-create the Enrollment Services object, but according to one or more DCs, the object still exists. Moreover, the write action is being taken by the machine account, not the account that is configuring the role. THe new server's identity does not have write permissions to the Enrollment Services object.  So, what you end up with is a situation (which would probably take some low-level debugging by an AD product engineer) where AD is in conflict about the existence/contents of the object.  Given time, it may eventually work itself out, but this is not always the case.

    Solution: Very, very simple.  Before removing ADCS from the old server, assign write permissions for the target server's account on the CA Enrollment Services object. This way, when ADCS is deployed on the new server, it can simply overwrite the existing object.  We've had success with this strategy on 2 CAs in our development environment so far, whereas previous CAs we've migrated have all encountered the problem.

    Further recommendation:
    If at all possible, perform the activity of assigning rights for the new CA server account to all relevant AD objects (in the AIA, CDP, and Enrollment Services) well before you go about actually migrating the CA.  This should negate any replication issues.

    Monday, November 18, 2019 5:31 PM

All replies

  • Hello,
    Thank you for posting in our TechNet forum.

    Do we mean there is no the pKIEnrollmentService object in ADSI under CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=Domain,DC=com? If so, we can try the method in the link Evgenij Smirnov provided.






    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 14, 2019 4:17 AM
    Moderator
  • Thank you, I'll give this a try.

    You shouldn't have to do this, though. This is a product bug in my opinion. I am going to speak with our TAM about having this looked into by the ADCS development team.  The CA configuration wizard should complain and fail if it can't create/find its Enrollment Services object in AD.

    Thursday, November 14, 2019 4:09 PM
  • Hi Daisy,

    The location you specify in your screenshot is the correct one. I did try the solution that Evgenij Smirnov suggested, but it did not resolve the issue.

    I did confirm that, using the account that i am logged in as (which is a member of the Enterprise Admins group) I am able to create a test object of type "pkiEnrollmentService" in that container, so it does not appear to be a rights issue.

    Thursday, November 14, 2019 4:49 PM
  • Hi,
    According to "Afterwards, the CA service starts up fine on the new server, but we're unable to assign any certificate templates to it.", do we mean we can not issue certificate template on CA server -> <CA Name> -> right click Certificate Template-> New -> Certificate Template to Issue? If no,would you please describe it in details and provide the screeshot?






    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, November 15, 2019 5:59 AM
    Moderator
  • Hi,
    If this question has any update or is this issue solved? Also, for the question, is there any other assistance we could provide?


    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, November 18, 2019 1:44 AM
    Moderator
  • Hello All,

    I believe I've determined the root cause of this issue and how to prevent it:

    Root Cause: We have many domain controllers geographically dispersed. When ADCS is removed from the old CA, as long as we perform that activity as an EA, the existing Enrollment Services object is removed, however, that change needs time to replicate to all DCs. 

    The implication of this is that some DCs will still have a record of the object existing while others don't.  When ADCS is deployed on the new server, it attempts to re-create the Enrollment Services object, but according to one or more DCs, the object still exists. Moreover, the write action is being taken by the machine account, not the account that is configuring the role. THe new server's identity does not have write permissions to the Enrollment Services object.  So, what you end up with is a situation (which would probably take some low-level debugging by an AD product engineer) where AD is in conflict about the existence/contents of the object.  Given time, it may eventually work itself out, but this is not always the case.

    Solution: Very, very simple.  Before removing ADCS from the old server, assign write permissions for the target server's account on the CA Enrollment Services object. This way, when ADCS is deployed on the new server, it can simply overwrite the existing object.  We've had success with this strategy on 2 CAs in our development environment so far, whereas previous CAs we've migrated have all encountered the problem.

    Further recommendation:
    If at all possible, perform the activity of assigning rights for the new CA server account to all relevant AD objects (in the AIA, CDP, and Enrollment Services) well before you go about actually migrating the CA.  This should negate any replication issues.

    Monday, November 18, 2019 5:31 PM
  • Glad you got it sorted. The recommendation is actually even simpler and of more general nature:

    When performing operations on forest-wide objects (such as an enterprise CA), always wait for replication to complete forest-wide or, depending on topology, force it to occur.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Monday, November 18, 2019 5:40 PM