I’ll take NDES in the DMZ, for 1000 Alex

Hello. Jim here yet again to talk to you about deploying Windows Server 2008 R2 with the Network Device Enrollment Services (NDES) role in a secure perimeter network. Let's consider the scenario.

You have an internal PKI hierarchy consisting of an Offline Root Certificate Authority (CA), a policy CA, and an issuing CA. You want to deploy the server holding the NDES role to the secure perimeter network. You do not want to open any ports to facilitate communication between the internal network and the perimeter network. You want to enroll unmanaged non-Microsoft devices like iPads and iPhones using the NDES server in the perimeter network from the Internet.

Your preliminary idea looks like this:

Looks good on paper. The problem is that without any connectivity between the perimeter network and the internal AD forest, certificate enrollment via the NDES server will be impossible. There are a few options for you to consider. The first is to insist that the necessary ports opened between the perimeter network and the internal LAN, which is an uphill fight at best. Another option would be to configure the issuing CA to listen for RPC traffic on a single port, and then open that single port in the firewall. You can then use firewall rules allow traffic only between the NDES server and the CA. This requires opening a port to the internal network. Another option is to bring up a new AD forest within the perimeter network. This will require at least one domain controller, an issuing Certificate Authority, a Windows 2008 R2 server to handle the NDES role and finally a server to act as an Internet-facing HTTP CRL Distribution Point (CDP) location for all of your CAs when you first set up the PKI. Your perimeter hosts will use that to check revocation status of certificates issued by the internal and perimeter network PKI. HTTP CRL distribution point locations are ideal for providing accessible CRL locations for clients that are not running the Windows operating system.

"Why not setup a forest trust?" you may ask. Well, you would then need to punch even more holes in the firewall to establish and maintain the trust, which is sure to make your security team gnash their teeth even more than when you asked them to open up ports for the NDES server.

Good news! A forest trust is unnecessary. All we need to do is follow some specific steps concerning setting up the additional issuing CA in the perimeter network after we have created the new forest. This can be deployed quite effectively using Hyper-V or some other more costly virtualization solutions that will remain nameless.

Our new setup will look like this:

Sweet!

Configuration decisions for the perimeter network must be made including but not limited to IP settings, subnets, DNS, backup planning and management. For the sake of this blog post, I will leave those details to you and move on.

Here is a picture of how the PKI hierarchy will look on both sides of the firewall:

I am keeping it simple with one site, one subnet and the DC in the perimeter network will serve DNS only for the resources in the perimeter network. The first thing we do is bring up a new domain controller in the perimeter network and it will be the first DC for a brand new forest. This DC will also be a DNS server. Once this is accomplished, we build and join a Windows Server 2008 R2 server to the new perimeter forest. This server will be our issuing CA. We install the Certificate Services role on this member server and make it an Enterprise CA so we can leverage certificate templates.

During the configuration of the issuing CA, you have to save the certificate request to file and manually transport it to the parent CA because we do not have connectivity to the internal Root CA from the perimeter network.

Now we complete our install of the issuing CA in the perimeter network by getting the certificate back from the Root CA in the internal network and making our issuing CA operational.

You must also export the Offline Root CA certificate and publish it in the perimeter forest using the following certutil.exe command:

certutil.exe -dspublish -f filename.CER RootCA

Since this is a Windows Server 2008 Active Directory forest we must enable Certificate Services Client – Auto-Enrollment. This can be accomplished by creating a new Group Policy object or configured within the default domain policy as explained here – https://technet.microsoft.com/en-us/library/cc731522.aspx

This will propagate the Root certificate down to the trusted root store on all domain joined computers via Group Policy. This will establish your internal Root CA as a trust anchor in the perimeter forest.

Next, bring a server online in the DMZ to be the repository for all the CRLs for every CA that is involved. This server has the IIS role installed and will be configured as a CDP on all the certificates issued by the perimeter forests issuing CA.

To specify the Web Server as the CDP you will have to perform the following tasks on the internal ROOT CA and on the issuing CA server in the perimeter forest in that order. This will enable both to publish their CRLs to this location as well as including that CDP path on the certificate the ROOT CA issues to the issuing CA in the DMZ forest:

Load Certification Authority management console.

Right-click your CA, select Properties, and then click the Extensions tab.

With CRL Distribution Point (CDP) selected

Click Add.

In the Add Location dialog box, type the following and then click OK:

https://<FQDN_of_Web_Server/<CRL_directory_name>/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

For example, if your Web server is called crlserver.ExtForest.com and the virtual directory you created in IIS was called CRL, you would type:

https://crlserver.ExtForest.com/crl/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

The following options will be selected for this new entry and are highlighted in the above screen capture:

1. Check Include in CRLs. Clients use this to find Delta CRL locations.
2. Check Include in the CDP extension of issued certificates
3. Click OK.
4. If you are prompted to restart Active Directory Certificate Services, click Yes.

It will be necessary to copy the CRLs for the internal PKI hierarchy to the HTTP location in the perimeter forest. This can be accomplished via script or scheduled task leveraging robocopy and a service account in the perimeter forest.

You can then proceed with the installation of the NDES role on the Windows Server 2008 R2 member server in the perimeter forest. Steps for configuration are illustrated in detail here.

The CA in the DMZ should probably have a Hardware Security Module HSM as this network isn't safe.

After installing the NDES role, you may install the certificate authority web enrollment pages, as these are not installed by default when you install the NDES role nor are they needed. The ISAPI .DLL will intercept any requests for mscep_admin, or mscep so you don’t need an actual certsrv/mscep_admin virtual directory. However, if it makes you happy to open up IIS management and see the virtual directories there, have at it!

Something else to remember is if you install both Web Enrollment and NDES on the same server, depending on the order, anonymous access to the mscep virtual directory may be turned off. Anonymous access must be enabled on the mscep virtual directory so that NDES clients, without accounts, can submit requests.

Now you are cruising through the NDES install and get to the end. Much to your chagrin, you are confronted with the following error:

Element not found. 0x80070490 (WIN32: 1168)

Huh?

You verify the permissions on the following templates:

• CEP Encryption
• Exchange Enrollment Agent (Offline Request)
• IPSec (Offline Request)

Authenticated Users – Read and Enroll
NDES service account – Read and Enroll
Domain Admins – Read, Write and Enroll
Enterprise Admins – Read, Write and Enroll

You test accessibility to the templates by logging in to the NDES server with an Enterprise Administrator account and then running the Computer Certificates MMC and attempting to enroll against the aforementioned templates. When the available templates window opens in the Computer Certificates MMC, nothing is listed.

You then take a network trace of the Computer Certificates MMC attempt at manual enrollment and observe the following:

618 192.168.124.121 10.0.2.69 LDAP searchRequest(60) "CN=CA Policy CA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=Contoso,DC=COM" baseObject

619 10.0.2.69 192.168.124.121 LDAP searchResDone(60) operationsError (00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece) [0 results]

Frame 618 indicates that we are attempting to complete the chaining to a Policy CA certificate as part of the verification of the issuing CA's certificate. Remember the CA hierarchy from our internal forest in the diagram above.

We cannot access that LDAP path in the other forest from the perimeter network. The query fails as reported in frame 619 and so does the ability to enroll against any templates published by the subordinate CA in the perimeter forest.

Now we must export the Policy CA certificate from the internal forest and copy it to a domain joined computer in the perimeter forest and run the following command:

certutil.exe -f -dspublish policyca.cer SubCA

Autoenrollment, which is configured and in place will download the Policy CA certificate to the intermediate store on any domain joined computer.

Computer Autoenrollment runs when the computer is started and every 8 hours thereafter. You can force Computer Autoenrollment to run by running:

certutil.exe -pulse

Now the install of the NDES server will complete without error.

I deliberately skipped the Policy CA certificate -dspublish step to show you the kind of cryptic error you will receive during the install in this particular instance.

After you have accomplished all of the aforementioned please install the following hotfix as well:

2483564 Renewal request for an SCEP certificate fails in Windows Server 2008 R2 if the certificate is managed by using NDES - https://support.microsoft.com/kb/2483564

Now you have a relatively secure environment where you can leverage NDES for device certificate enrollment and renewal without opening up your internal LAN to the DMZ. There is understandably a lot of overhead in this design as we are working around the limitations placed on access to the internal network through the firewall. For information on non-Windows device enrollment, please refer back to this spectacular blog post written by my colleague Robert Greene.

Until next time.

Jim "Daily Double" Tierney