We recently did an implementation of our Certificate Management System (CMS) version 4.0 product for a customer and ran into a bizarre problem with Microsoft’s implementation of SCEP–the Microsoft Network Device Enrollment Service (NDES) certificate authority role service under the Active Directory Certificate Services (AD CS) role–on Windows Server 2012 R2 that we had never encountered before. I thought I’d tell you all about it so in case you run into this issue, you won’t have to beat your head against the wall quite as long as we did before coming up with a solution.
Microsoft’s NDES is used in conjunction with CMS to support enrolling for certificates from iOS devices. In this particular customer implementation, CMS was being installed on the same server on which the Microsoft NDES role was installed. This is a common implementation design. Both CMS and NDES run under IIS, but CMS requires more IIS role services than NDES. It also requires ASP.NET 4.5, which is both a feature and a role service under IIS Application Development on Windows Server 2012 R2.
Because NDES can be a bit fiddly to get working, we typically install it first and make sure that it is successfully issuing SCEP challenges before installing CMS, and so we did in this case. But, try as hard as we could, we could not get the NDES service to issue SCEP challenges. We had correctly configured NDES as per Microsoft documentation using Kerberos authentication and had granted our user rights to enroll for certificates using the template configured for use by NDES. But, each time we requested a SCEP challenge, we got a message indicating that we did not have sufficient permissions to request a SCEP challenge. The exact message in the event log for each failure was:
The Network Device Enrollment Service cannot provide its password because the user does not have Enroll permissions on the configured certificate template, or the certification authority is not enabled to issue certificates based on the configured certificate template.
The message received by the end user was:
You do not have sufficient permission to enroll with SCEP. Please contact your system administrator.
As we continued to beat our heads against the wall on this one, we noticed some very curious behaviors:
- If we granted our user local administrative rights on the NDES server, that user was able to obtain a SCEP challenge remotely (by visiting the /certsrv/mscep_admin URL served from the NDES server from a different computer) but was unable to obtain a SCEP challenge locally. For CMS to operate correctly, this needs to function locally. Plus, it’s a security risk to grant the user (for CMS functionality this would be the service account under which CMS runs) local administrative rights on the server, and it shouldn’t be required.
- The domain administrative user “Administrator” (the built-in account) could obtain a SCEP challenge locally, but no other domain or enterprise administrator account could obtain a SCEP challenge locally. Note that this behavior appeared only in environments where NDES was configured to do Kerberos authentication. When functioning correctly, NDES will successfully operate within a single domain using NTLM authentication.
- The permission denied message when attempting to obtain a SCEP challenge occurred even if we granted the magic “Everyone” group permissions to enroll on the CA template configured for NDES.
Clearly the permission denied message was a bogus one and something else was going wrong, but what? Ready for the big reveal? Here’s what it turned out to be.
When we installed the NDES roles on the server (both the Network Device Enrollment Service and the Certificate Authority Web Enrollment roles), we installed the additional roles needed for CMS at the same time–Basic Authentication for IIS and ASP.NET 4.5 (both the feature and the IIS role service). NDES on Windows Server 2012 R2 does not play well with this. The mumbling we heard from Microsoft on this was that the web.config file used by NDES gets stomped on (aka corrupted) by one of these other roles, leading to a situation in which there is no hope for NDES to function.
The solution to this problem? Uninstall NDES (all the CA roles) and all the IIS roles. Then reinstall just the NDES roles and whatever IIS role services it wants to install. Do not select any additional roles or features on this first install. Once you have SCEP challenges working both remotely and locally (without prompts for password), you can go back and install the additional required roles and features for CMS and continue on with the CMS implementation.
WARNING: Do not uninstall .NET Framework 4.5 from Windows Server 2012 R2. This uninstalls the computer’s GUI, leaving you with something that looks like a Windows Server Core installation. It’s OK to uninstall ASP.NET 4.5, but it’s not required in order to fix the issue.
While troubleshooting this NDES issue, we encountered another odd NDES issue that produced the same bogus error message as above but with a different cause. In this alternate case, the problem was the result of an IIS Handler Mapping bug. This bug is specific to Windows Server 2012 R2 and NDES and appears to be related to the installation of the ASP.NET 4.5 role in addition to the NDES and web enrollment roles on the NDES server, although we are still awaiting word from Microsoft as to the exact cause of this issue. If you run into this problem and the above reinstall method does not resolve the issue, try this resolution:
- Launch IIS Manager using the “Run as Administrator” option.
- Drill down to the mscep_admin virtual directory under certsrv for the Default Web Site.
- Double-click on “Handler Mappings”.
- Click “View ordered list…” in the right-hand pane.
- Locate and select “ExtensionlessURLHandler-ISAPI-4.0_64bit”.
- Under “Actions” in the right-hand pane, click “Move down” until “ExtensionlessURLHandler-ISAPI-4.0_64bit” is all the way at the bottom of the list.
- Restart IIS in IIS Manager or at an administrative command prompt with “iisreset”.
- Re-try the SCEP challenge retrieval as the NDES service account both locally and remotely.