Roberts Blog

The House of ConfigMgr and Intune on Endpoint Management Way

Tag: CMG

DigiCert – CMG Server Authentication Certificate – Prove Domain Control using WWW

By

On 24th July 2020

In Uncategorised

I just went through the process of requesting a PKI certificate from one of the third-party certificate providers for my lab CMG, I used DigiCert, and the route I took was a little bit off-piste, as in not well-documented, so I thought I’d share.

CMG’s require a PKI “server authentication” certificate as an installation requirement:

This certificate can be issued internally using Enterprise PKI or issued by a Public provider. Simply put, the choices are a ‘third-party’ public provider versus an Enterprise server residing on your corporate network running Certificate services.

Notable key reasons why you’d use either:

  • Enterprise PKI – Complete management control over issuance and revocation for the entire lifetime of the certificate, requires an infrastructure footprint that can span both the Intranet and Internet (CRL publishing) with an attendant team with reasonable PKI skills. Fits well in a large organisation that needs PKI for more than ConfigMgr, but not so well in small environments. Requires a documented procedure and preservation of knowledge for 1 to 2 years to handle certificate expiration, which can be difficult for small teams who leave the PKI server (often a VM) alone until it is needed. I’ve seen a customer’s admin attempt to return to an Enterprise PKI VM only to find it is missing, make sure you read about what to back up up on your Enterprise PKI CA … and small shops be aware that once you implement Enterprise PKI you have both an ability and a liability in the environment. The trusted root certificate and any intermediate certificates need to be installed onto devices that are going to talk to a CMG.

  • Public PKI – No actual infrastructure is required, a one time cost until the certificate needs renewing (make a calendar reminder for at least 2 weeks before expiration). Renewal is a relatively straight-forward process but requires documentation or a decent guide. Windows 10 contains a DigiCert root certificate that will be in the CMG’s server authentication certificate certification path, that’s a tick in the box for one of the CMG’s security requirements and importantly means we do not have to install certificates on devices for them to talk to the CMG. This pathway opens up the minimal steps needed to install the ConfigMgr client on remote devices, which is CCMSETUP.EXE and a command line to point at the CMG, and I like it a lot, unlocks an age old problem around client install on workgroup devices residing anywhere in the world.

Before a client can talk to the CMG to do the actual authentication (Azure Identity, Token identity, Certificate identity) it has to have a root certificate installed that the CMG trusts, either your Enterprise PKI trusted root certificate if you are using an Enterprise PKI certificate, or if you are using a Public PKI certificate a Windows 10 built-in root certificate. Here’s a DigiCert certificate issued for my CMG showing the certificate certification path or “chain”, the certificate is linked or chained to an intermediate certificate which is linked or chained to the DigiCert root certificate:

I won’t cover the process for handling the CMG server authentication certificate request with DigiCert end-to-end, instead I’ll redirect you to a quite competent fellow EM MVP, Eswar Koneti, who wrote a good blog post on the entire procedure, from how to request the certificate to authorising it with DigiCert, to obtaining the certificate in readiness to hand it off to a CMG.

He has other posts, specifically one that talks about how to switch from Enterprise PKI to Public PKI which is definitely worth having a look at.

In Eswar’s guide he resorts to using Email as a means to prove control over the domain being used, which then leads to issuance of the Certificate.

DigiCert’s three options for doing this security-handshake before the certificate is issued currently are:

  1. Email
  2. File
  3. DNS

With Eswar taking the email route, I’ll show you how to take the File route.

The shot below shows a certificate that DigiCert are processing, I’ve provided the CSR and now need to prove that I own the domain:

The reason I went about using the file route is because I do not have email for ConfigMgr2012.com, and I couldn’t get the DNS method to work using a TXT record containing the CMG DNS name or a TXT record containing the TLD, like this:

Since configmgr2012cmg1.configmgr2012.com is just a CName alias to the cloudapp.net destination, there is no DNS zone in which to create a TXT file, has anyone else used DNS to prove control over the domain when ordering a certificate for a CMG? Or does DigitCert assume it is a sub-domain and isn’t checking the top level domain?

Without Email access and with the DNS changes not being recognised by DigiCert, that leaves the File method, which entails publishing a TXT extension file on a web server.

You might as well download the fileauth.txt file now and store it on your web server.

Before we dive in be aware that this change will take an already existing CMG service offline for several hours, as we will modify the public DNS CName record making it inaccessible to clients for a period of time. Therefore the Email and DNS routes are more desirable as a consequence outside of a lab.

Firstly go to your DNS admin portal and change your CMG CName alias, so that instead of pointing at your cloudapp.net destination it points at the IP address of your web server.

From:

To:

It will take an hour or two for the DNS record to expire and be refreshed, dependent on the TTL.

In the meantime visit your web server.

Create a folder somewhere so as to host the fileauth.txt file you downloaded from DigitCert:

C:\Website\well-known\pki-validation

The above example shows Website as the root folder, you can call this anything you want, however the following folder and its sub-folder must remain the same: well-known\pki-validation

Here’s a shot of Explorer:

Drop fileauth.txt into the pki-validation folder.

Visit IIS Manager.

One of your web sites will have your DNS name bound to it, mine is ConfigMgr2012.com, if you don’t have an existing website create a new one yourself (create a new folder for it, sort out its bindings, put a test landing-page in there, make sure it renders in a web browser) and follow on with these steps.

Open your websites bindings and add the FQDN that you use for your CMG CName, mine is configmgr2012cmg1.configmgr2012.com:

Once the DNS change for the CMG’s CName has taken place, punching it in to a web browser will take you to your website.

If you have a landing page for your website, mine is a WordPress blog, you should see it, if not check that the CName change we made has replaced the previous by visiting a website like mxtoolbox.com, if that is okay it’s most likely firewall rules if its a new website.

Next we create a virtual directory using our website as the target:

The Alias has to be called .well-known, and the physical path points to the new well-known folder that we created earlier. Worth noting that you can create the well-known folder and its subfolder within an existing websites folder, I kept them separate for no real reason.

You should have a new virtual directory shown hanging off your website:

Open a web browser, punch in the URL and see if the FileAuth.txt files contents are rendered.

In my case the URL would be: HTTP://ConfigMgr2012CMG1.ConfigMgr2012.com/.well-known/pki-validation/fileauth.txt

Here’s the file appearing in the web browser:

Once it is showing, return to DigitCert and complete the process for proving control over the domain for this certificates request, and go collect your certificate. Eswar’s guide explains what to do next, but before moving on revert your DNS CName change back to your cloudapp.net destination:

And also remove the website virtual directory and the folder structure, so as to tidy up.

An hour or two later DNS lookups will show the CName has changed back, at which point you are good to go with installing the CMG with your new PFX certificate.

Enjoy.

ConfigMgr–CMG and the DMZ

By

On 24th November 2018

In Uncategorised

Patching servers or ‘managing Windows assets’ in a DMZ has always been a challenge.

Trying to manage assets with one systems management solution in two domains, the DMZ (external network) and the intranet (Internal network) broadens the challenge further.

All designs put forward to manage assets in a DMZ using the internal networks systems management solution, essentially depend on spinning services, or in ConfigMgr lingo ‘roles’, out into the DMZ so that the devices that reside there, do not need to reach back into the internal network for content and communications purposes.

The holy grail of DMZ design is to literally eliminate all communications from the DMZ into the Intranet, but allow communications from the intranet into the DMZ.

That’s a tall order.

To give a sense of what I mean, here is an analogy using tennis!

If you imagine a tennis court, a net, two players with racquet in hand and a tennis ball.

To have a sensible game of tennis both players need to be able to bounce a ball over the net and attempt to return the ball if it is received.

Now imagine that the net is the DMZ’s firewall, player 1 is the Site server, player 2 is an asset in a DMZ, the tennis ball is the content and communications.

In our imaginary game of tennis, player 2 cannot return the ball as the net always blocks it, thus the game cannot be played. Game over. Insert coins to continue.

In some rare configurations, IPSEC and other security services are employed to tunnel communications from a SPOC such as an MP, from the DMZ, back into the internal network to overcome the challenges. For those that do not tolerate this, providing a solution that can manage assets in both the internal and DMZ networks gets complicated quickly.

In the past I’ve managed to achieve complete DMZ compliance while using ConfigMgr to service DMZ assets. And yes it was complicated.

I achieved this by introducing a Management Point Replica so that the clients communications with an MP in the DMZ does not result in the MP talking to the DB located within the intranet, as well as by deploying a DP, a SUP, and all rounded off by reversing the Site system to Site server communications (set on the Site system itself). Site systems in the DMZ never talk back to the intranet, and assets always talk to those site systems, job done.

Another way to overcome this is to utilise IBCM, if it is setup for client management over the internet. Placing an MP, a DP and a SUP in the DMZ, and letting those internet-based devices access those roles, and most importantly the servers in the DMZ seals the deal.

As you can see, there are many ways to go at this problem.

With the cloud-first approach Microsoft have adopted for the last decade, we’re seeing heavy integration taking place through cloud products and services evolving, that is yielding some very interesting tooling.

With the introduction of the Client Management Gateway, we have another solution for managing DMZ clients.

Let the servers in the DMZ go out onto the internet via the CMG, and back into the on-premise roles, while using the Cloud DP to issue content.

It is worth noting that the Cloud DP can now be installed along with the CMG itself, and does not require another virtual machine to house it, reducing the cost of the solution somewhat.

There are so many options available right now, you can even throw an IBCM DP into the mix along with a CMG running just an MP and SUP, just to negate content delivery costs, but I suspect this is a short-term solution, and that over the long term it might cost more than using a Cloud DP with its associated metered download costs.

In the simplified above shot we see the DMZ layers, protecting company assets from external interference, and generally as a rule of thumb, preventing any communications originating from the DMZ into the internal network.

The servers will reach out to the CMG and not talk directly to the ConfigMgr Stand-alone hierarchy.

Outstanding.

So today, to service (patch\update) assets in the DMZ we can go one of several routes:

  • Abandon the idea of servicing DMZ assets using the production ConfigMgr hierarchy instance, and instead stand up a new ConfigMgr Hierarchy located in the DMZ itself
  • Opt to use stand-alone WSUS
  • Service directly using Microsoft Updates, while employing some form of control using Local Group Policy to configure the Windows Update Agent
  • Employ Management Point Replicas, Site systems using reverse replication (SMB level) and with the SQL replication reversed (important so as to maintain DMZ compliance), deploy DP’s and SUP’s
  • Join to Azure and service from there
  • Use Operations Manager Suite (token nod to Sam Erskine who bangs the drum for servicing using OMS!)
  • Implement IBCM

or

  • Service using ConfigMgr and the super-amazing Client Management Gateway

The list isn’t exhaustive by the way …

In this article, I’m going to walk through how to setup a method for managing DMZ assets that involves ConfigMgr, CMG and PKI, with Certificate issuance to workgroup clients being handled by Certificate Enrollment Policy and Certificate Enrollment Services (CEP\CES).

I do not have a DMZ, and my PKI infrastructure is on the intranet. If you were aiming to test this with a real DMZ you’ll need to ponder how to deploy the PKI infrastructure appropriately.

Some of you may already have NDES setup, as part of your Intune implementations or explorations, and can use that to service the workgroup assets.

In a real production environment you’d break down how you’re going to place a CA\CEP\CES\CDP in the DMZ that they can utilise, while making sure these PKI services in the DMZ are not reaching back into the intranet.

In the shot above, is a Callout for the Primary showing 6 servers. This is my stand-alone Primary, which is configured for High Availability and really does consist of 6 servers:

  • 2 Primaries (Active/Passive) running Build 1806
  • 2 Site systems (single instance roles, duplication of non-single-instance roles, SMS Providers, some Shares)
  • 2 SQL servers running SQL AlwaysOn on top of a Windows Cluster, File Cluster services to accommodate the Content Library

I also have:

  • 1 Domain Controller for Lab1.com
  • 2 Certificate Authority servers
    • 1 running CA, CA Web Enrollment, NDES (IIS HTTP)
    • 1 running CEP, CES (IIS HTTPS)
  • 4 Windows 10 test clients
    • 2 AD/AAD joined
    • 2 Workgroup joined

I’ve ‘faked’ having a client in a DMZ, by blocking all communications to the ConfigMgr intranet servers using the HOSTS file on one of my workgroup based Windows 10 test clients. It cannot directly talk to ConfigMgr, it has unfettered access to the internet.

I had a few issues along the way that burnt a serious amount of hours, firstly not having an HTTP CDP for the CRL tripped me up, and then figuring out what the CEP URI is supposed to be caused delays.

With hindsight, this is pretty easy stuff, the CEP URI can be found in several places, and I didn’t need to do much to enable a HTTP CDP.

Here’s where you turn on the HTTP CDP, it has to be done before you begin issuing certificates, or existing certificates will need to be renewed to pick up this meta change: