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.
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
- 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:
Tick the Include in CRLs and the Include in the CDP extension tick boxes.
Another thing to tick off is the FriendlyName for the IIS virtual directory running within default website on the CA running CEP\CES:
Open IIS, head to the virtual directory residing in the default website containing CEP and UsernamePassword, visit its Application Settings and change FriendlyName to include something, I chose Lab1. You will see this show up later on when requesting certificates.
Once that was all taken care of, the entire chain of proceeding activities fell into place nicely.
The next piece is about preparing the PKI certificates needed to allow the ConfigMgr client to talk to the CMG, a Trusted Root CA and a computer certificate with Client Authentication present.
The root certificate can be exported from any domain-joined device, or from the Certificate Authority server in your lab, here’s a guide.
ConfigMgr itself can deploy the root certificate, but it first has to have the client installed and have access to the intranet roles. Since you can service devices in Workgroup mode, if you are already setup to use ConfigMgr to service your DMZ assets, delivery of the Root CA is a cinch using Certificate Profiles, forming one of the activities needed to transition from internal management to external via the CMG.
Or you can drop the Root CA in manually.
We now need a computer certificate which has client authentication capability. In my lab’s CA I created one by cloning the Workstation Authentication certificate template:
On your CA, open the Certificate Authority console, right click Certificate Templates and select Manage. Nose around and find the Workstation Authentication template:
Right click it, and select Duplicate Template. A new template will be prepared, and its property sheet shown, so that we can populate the template before committing it:
Populate the Template display name, mine is called Lab 1 Client Certificate.
Head to the Request Handling tab:
Untick Allow private key to be exported.
Head to the Subject Name tab:
Select Supply in the request.
Select the Security tab:
By all means make changes here, but for my lab I’ve left as-is as my Domain Admin account will be used to initiate the certificate enrolment from the client.
You can select OK now and commit this new template.
Head back to the Certificate Authority console, right click Certificate Templates and this time select New > Certificate Template to Issue:
Once you’ve selected Certificate Template to Issue, from the list produced, select your newly created Certificate Template. This will make it available to anyone with enough permissions as defined in the Security tab of the template, to request the certificate.
Now on the client, we need to add a Certificate Enrollment Policy server using the Certificates MMC.
Run the MMC as an administrator or accept the UAC prompt, choose Computer account when adding the Certificates snap-in.
Right click Certificates > Personal or Certificates > Personal > Certificates if any certificates have already been issued, select All Tasks, then Advanced Operations, finally select Manage Enrollment Policies…:
We can now add and remove Enrollment policy servers:
You can obtain the format needed to create the CEP URI by using CERTUTIL.EXE, which as shown below returns the CES URI, just replace CES with CEP:
Or by visiting IIS:
Bound to be other ways to find it.
For my example it is:
So I punch that in as the enrollment policy server (URI) value, and select Validate Server.
We’re now prompted for credentials to access the CEP:
In my lab I chose the Domain Admin again.
You should now get some information back on what happened, the validation of the Certificate Enrollment point was successful:
Our Policy server is in place, we can request Certificates using it:
Just as an aside, if you do not set the FriendlyName as we did earlier in the article, you’ll get a warning when you validate, and the Name will show as a GUID:
Now right click Certificates > Personal or Certificates > Personal > Certificates, select All Tasks and Request New Certificate:
There’s our Policy server listed:
Scrolling through the certificates on offer, settled on the Lab 1 Client Certificate:
It needs more information so I’ve ticked it, and mouse clicked the “More information…” message:
We only need to specify a SAN to talk to the CMG, Subject Alternative Name, so in the Alternative name panel, select DNS as Type, and tap in the hostname of the workgroup-based client, selecting OK when done.
The certificate is ready for the request:
I have a ConfigMgr client running on this test client already. This is CCMMessaging before the certificate was issued:
I now select Enroll.
I’m prompted again for credentials to enrol the certificate:
and the certificate is issued:
Back to CCMMessaging, and you’ll see we’re cooking on gas:
Closer scrutiny shows the PKI certificate selection process, and the thumb print for the certificate settled on by the ConfigMgr client:
If we open the issued certificate, we can see the thumbprint listed:
So we know its selected the right certificate.
Let’s install the client using CCMSETUP.EXE stored locally on the client, and use the Client Management Gateway instead of via an intranet site system to deliver the client.
I’ve uninstalled the client, cleaned up the CCM folder, removed the CCMSETUP folder contents after copying CCMSETUP.EXE to C:\Temp.
I also use another trick to force a client to always assume it is on the internet, an IBCM artefact:
ClientAlwaysOnInternet will be overridden whatever I write in there, once I install the client from the CMG, as I’ll be specifying the CCMALWAYSINF switch, but it is handy to use on clients on the intranet that you want to simulate being on the internet.
Here’s the HOSTS file trickery to block out all communications with the lab, added so that from now the client can no longer talk to the intranet servers: