ZPA Loves Microsoft SCCM

As major global companies continue to march toward Zero Trust Network Access (ZTNA), there are a few applications out there that, at least initially, seem to be incompatible with each other. One such pairing is with Microsoft's System Center Configuration Manager (SCCM). But it's Valentine's week, so let's pair these two up anyway, shall we?

ZPA meets SCCM

First, a bit more background about these two 'love birds' in the making. 

  • SCCM was born of an era when everyone and every device they operated were, far more often than not, on the corporate network at all times (L3 IP connectivity). The expectation from the server and those who governed it was that each device would have an internal IP address that it could connect directly to whenever needed. Ahh...a simpler time (or was it?).

  • ZTNA [aka Zscaler Private Access (ZPA)] didn't grow up in the pre-cloud LAN connectivity baseline world. Rather, it emerged with the cloud and modern day cybersecurity threats in mind. More importantly, ZTNA architects understood what CIOs and CISOs had been saying for at least the past decade, which is that users don't need or even desire to connect to the corporate network. All they are really after is access to their private applications (internal apps), with the least amount of friction as possible. 

So combined, we have one true original "Boomer --> Generation X --> Generation Y" architecture (SCCM), being supported by a clear "Generation Z" model (ZTNA / ZPA). Clearly a bit of an age a life goals mismatch, so will what will it take to pair them up?

Someone Has to Change

(teaser and spoiler alert: SCCM already has)

Now it's time to lay down some bare truth. One of the top questions I get very early on with any ZPA client engagement is "when will ZPA fully support SCCM?", as if the young has to start merely acting old or, at the very least, "grow up". Really? Isn't it far more likely (in the tech world) that the older generation will ultimately make every effort to appeal to the younger generation? Yeah, that's what I thought you would say. 

To look at it another way is to see it through the eyes of the product manager. Product managers (program managers at Microsoft) know all too well that they can either create the market (rarely succeeds like, say....the iPhone) or change with it.

And this is what ZTNA is really doing within IT now, as it changes the way networks are built, security models laid out, and users access applications. Those who don't live by this likely doomed to experience their own "Kodak moment".

"The Market is the Market is the Market... The fact of the matter is, you don’t get to dictate where the market places it’s attention. You don’t get to decide...You just have to observe and react."

Gary Vaynerchuk

The bottom line, then, is who will change more here? Will it be ZTNA somehow going to a more legacy VPN model? Oh sure it's just software so therefore technically possible, but would that be the right move? Or will SCCM, having realized that the much broader client connectivity market is fundamentally changing less in their favor, adapt to where that market is and where it is so clearly going?

With all that said, you will surely be delighted to know that Microsoft, having recognized the future market needs, has changed. Their clear answer to showing everyone how SCCM remains modern, sexy, and continually market ready is the...


Full disclosure: While most will recognize the fact that I worked at Zscaler, I also spent twice as long at Juniper Networks as a senior product manager for the Pulse SSL VPN (even co-authored the book on that one). And well before that I worked at Microsoft. Without a doubt, I'm a huge fan of all three. That said, the future and where the market is taking us is what matters.

Ask the Real Experts

If you ask Zscaler, Microsoft, or any joint SCCM/ZPA customer what the recommended configuration looks like, this is what you will almost surely encounter:

  • Microsoft: Simple. Move to the cloud model for SCCM. Highly recommend everyone start planning for that now anyway. 
  • Zscaler: Simple. Move to the cloud model for SCCM, using the Microsoft Lightweight Filter (LWF) driver within Z App.LWF Driver
  • Successful Customer: Simple. Move to the cloud model for SCCM with AD boundaries defined. Note that if you go with AD boundaries, then when the client goes remote it will try to connect to last known distribution point, which is generally acceptable. And make sure you use the LWF driver to avoid legacy "Route Based" driver issues, such as switching networks and best addressing other applications that don't understand the multiple IP addresses -- potentially also some Z App roadmap items. SCCM Reporting, patches, and inventory will all work splendidly. Enjoy!

The reality, however, is that not everyone has moved to the Cloud Management Gateway just yet, so we can, and should, be realistic about what a roadmap might look like to get to where things need to be.

3 Ways to Implement SCCM

Here are the widely recognized deployment options, from "in love" to, well, coping and something else along the lines of marriage counseling. 

Best (in love)

As noted, this is just following what Microsoft, Zscaler, and other successful customers will all agree is the modern day best practice. Cloud Management Gateway, using AD boundaries, with the Zscaler App running Microsoft LWF driver (note that there is no LWF driver for MacOS, so those MacBook devices only ever have route mode - not that that is a big consideration for SCCM). 

Minimally Viable Product (MVP) (coping)

If you haven't yet upgrade to the SCCM cloud model and need to get applications up and running today, without breaking some of the core SCCM components, then your options will be a bit more... limited. Here you will be looking at running the Z App client with Route Mode rather than the preferred Microsoft LWF driver mode.

While Zscaler's online help for SCCM seems to present those to options as equal, I firmly present them as less (Route) and more (LWF). This is precisely why I consider Route Based SCCM to be a minimally viable product. 

Of course I  would also not consider this to be sustainable over the long term, hence the MVP status. This is implicitly a call-to-action for getting the Cloud Management Gateway nirvana that you (CIO, CISO, SCCM managers, support team, network team...), Microsoft, and your users really desire you to have. 

Hacked Up (oh we need help)

I have yet to encounter a customer willing to even entertain this, but it is at least an option worth mentioning. This is where, in addition to Z App with ZPA, you would continue to run your legacy layer 3 VPN on each remote laptop.  

Of course it's generally shot down because all of the cloud-forward CIOs and CISOs are sharply and profoundly in favor of ZTNA over VPNs. They widely view VPNs as a MVP category service anyway, filled with unacceptable risk / uncertainty, and want to make a clean break from it. Dare we say they want a clean divorce from the old VPN so that they can just focus on their new model? 

BUT...if you happen to have enough VPN licenses still lingering on the old CapEx books, it is technically possible to just set  clients to always being connected to the corporate LAN. Just lock down the access to just the services that are required for SCCM. Split tunneling would be okay here, though many might have to get that one through their change leadership boards and possibly even amend their own written policies in the process. 

Yes, it's a hack. Yes, it may add costs. And yes, it's probably going to make some IT executives much less happy.  As a short term option, I can't say I would rule it out entirely. But it's certainly not the one I would get married to.  

Summary Analysis

The very first time I heard it mentioned from anyone that SCCM and ZTNA were not compatible I took the time to listen and learn. It didn't take long at all to realize that they were just 2 independent solutions, each born of a different generation, that needed a bit extra to pair up. And that's perfectly okay. Making things work and moving the business forward to where they want and need to be is our jobs, right? 

My conclusion from early on is the same as it is now. Applications that require direct IP address connections from the server to client, which will clearly fail in the ZTNA models, must be adapted. Simply put: this one was primarily Microsoft's problem to solve. They did (Cloud Management Gateway option). Now, as the clear beneficiaries of what has so rapidly evolved, we just need to adopt it. 

This is, by all measures, the classic win-win-win: Zscaler, Microsoft, and the jointly held customer benefit exponentially. It's recognizing these changes in the market, then executing on them to advance our shared goals, that elevates us where others might fail. 

So welcome again to 2020, where the vision of IT in the cloud takes shape and seemingly incompatible models just come together, perhaps just in time on occasion, as though they were all planned that way from the very beginning. 

Feb 12, 2020 Update:

Using the power of human networking, I connected with 2 of my top go-to Microsoft resources (one an independent consultant, the other a top architect at Microsoft). Combined, they noted that as long as the customer has the Azure tenant, a CA/PKI in place, SCCM already deployed, and Azure AD active, then the upgrade to the Cloud Management Gateway should only take a few days. 

Written by Kevin Peterson, CISSP

Kevin Peterson is the founder and cybersecurity practice lead at ZecurityAscent. His background includes: 3.5 years at Zscaler as Director, Security & Network Transformation; 8 years at McKesson (Fortune 5), the last 2 as a business unit security officer / cloud application security lead across all business units (introduced Zscaler); and 7.5 years at Juniper Networks as Sr. Product Manager for the Pulse Secure SSL VPN. Adding to this is his own professional brand as an author, blogger, speaker, InfraGard board member, former police officer, pilot, and United States Air Force veteran.
Find me on: