There comes a time in every Active Directory engineer’s life when your manager stands at your desk and asks “Do we have a CA?” To which you, Master of all things AD, deftly reply…..“are you asking if we have a California?”
Okay maybe our collective PKI denial isn’t quite that bad, but for most hard-scrabble Active Directory gurus AD CS is “the other white meat.” It’s the thing that plugs into AD which we’ve never been forced to learn in-depth. Be that as it may, on a long enough timeline most of us will encounter a manager or PM at our desk clamoring for an Enterprise CA to be stood up post-haste. The driver for this first CA is typically a high profile project where certificates are a requirement. Confident in your knowledge and ability to learn, you did your homework and read most of the articles here http://social.technet.microsoft.com/wiki/contents/articles/4797.ad-cs-and-pki-step-by-steps-labs-walkthroughs-howto-and-examples.aspx, labbed it out in a QA environment, and possibly even read the ancient-but-still-completely-valid “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure” over a good bottle of scotch. If not, I highly recommend taking a couple of steps.
Step1 – Do the aforementioned research & testing.
Step2 – Inform the requestor that implementing AD CS quickly and without proper planning & testing is a grave mistake because ripping it out and doing it correctly is a headache at best and a $499/hour (plus tax) call to Microsoft at worst.
Let’s fast-forward a bit and assume all that research, planning, & testing is done. You’ve created the Standalone root CA, just finished saving the CAPolicy.inf, and installed AD CS role on the server intended to be the Enterprise Issuing CA. While walking through the configuration wizard you get stuck – of all unexpected places – on this:
Fixes range from the simple to the complex. Here are some areas to take a look.
1.) Is the server joined to the domain? This is a requirement for an Enterprise CA.
2.) User credentials: We must be logged in with a user that has membership in Enterprise Admins and Domain Admins in the forest root domain.
Those are the easier fixes. From here we get into a combination of the server’s ability to talk to AD and researching log files.
- Check the primary & secondary DNS settings on the server and ensure they point to valid DNS servers for the domain. Perform an “nslookup domain.com” inserting this particular domain name for good measure.
- Run an nltest/dsgetdc:domain.com inserting the domain name after the colon. If it returns successfully, continue. If we get an error like the following, we need to troubleshoot the server’s DNS settings.
- If the server appears to have happy healthy DNS resolution then begin analyzing the in-site domain controllers for health issues. I’m talking about the usual suspects here: DS log, dcdiag, repadmin, etc.
- There is a log on the CA that may help guide the thinking here. Check c:\windows\certocm.log for indications of where the install is going arye. This could provide some insight on whether to check user permissions, whether the server is unable to contact AD, and so on.
Hopefully this helps some of you get past an unexpected hitch in your Certificate Authority giddy-up. Certificate Authorities are complex enough as it is. We don’t need to be tripping on stuff right out of the gate.