ZScaler + Microsoft Store - Errors/Issues

VPN
1

Hi all. First off, I am on the client Engineering side; we own Windows, MSFT stack, etc.

We have about ~300 ZScaler sites, using ZIA. At those sites, we cannot use the MSFT Store; get random errors, which never occur outside of Zscaler.

We all sort of know it’s a ‘policy issue’, but the networking team seems very dedicated to not turning off SSL decryption for a plethora of MSFT URLs. They want me to open a MSFT case. “Sure”. I assume they’ll just link me to this:

https://learn.microsoft.com/en-us/windows/privacy/manage-windows-11-endpoints

Specifically, we have worked through and ‘turned off SSL decryption’ for a lot of the URLs there, but it’s just a back and forth; none of them have worked. Keep retrying, keep failing, keep disabling more.

Is there, in the ZScaler ‘support portal’, of which I do not have access to, a “KB” or something, that says “Hey, silly gooses, for Store to work, use RuleSet123?” I have to assume there is a canned THING to let this work, as there are simply an insane amount of rules/endpoints to ‘try’ before it magically works.

Thanks in advance, and I can clarify where I can. All I really know, for sure: It works outside of ZScaler, on VPN/at sites without it, and it does NOT at ZScaler sites. The “SSL decryption” is typically at fault for OTHER applications, so that’s the path we’re going down.

2

In regards to Microsoft related sites, the “one click configuration” enabled is absolutely essential. I’m assuming that’s turned on. At that point, any Microsoft related site that needs exclusion has to be bypassed at the pac file or p2p tunnel level, and there are very few, but the f’ing Store and Company Portal app is one of them. Keep in mind, any site that is added to ssl exclusions no longer is subject to DLP or cloud app policy. If you for example excluded .google.com in ssl exceptions and then blocked “google drive” in app control policy, it would not be blocked. So exclude with caution.
These are the MS urls we have BYPASSED:

Device.login.Microsoftonline.com
*.manage.microsoft.com
Enterpriseregistration.windows.net
Nexus.officeapps.live.com

Some of these may actually no longer be needed. The “manage” one is what you need to get the company portal and store to open and sign in.

For other sites, you need to make sure entire categories are not subject to ssl inspection. Financial services, healthcare, software updates are three examples of categories that should be excluded. You only want to inspect categories where either a) you are doing dlp and b) need cloud app categorization and present a potential security risk.

3

From another Reddit post four months ago, there is an internal Microsoft CA being used for fe3cr.delivery.mp.microsoft.com and slscr.update.microsoft.com so you not only have to bypass these URLs but have to add them to a specific rule to allow Untrusted server certificates.

4

Also don’t forget to track calls to IPv4 addresses in your web logs and firewall logs, not just looking at fqdns. Microsoft will call out to a 23.x.x.x or 52.x.x.x something-or-other which may get lost in the web log noise. Really the best thing to do is isolate a laptop, sign in at exactly 9:00am, replicate the issue, shutdown at 9:05 (or whatever). Filter the logs for blocks and you’ll find something… …but if you don’t, Microsoft’s edge is blocking you for some reason or you’re SIPA through ZPA and you don’t realize it.

5

Interesting. The portal opens fine. We see stuff. We can search and sign in. It’s just downloads that fail. The device urls referenced I know we have bypassed for intune registration and such, not necessarily done for the “store”.

I want to say we don’t have the one click rules enabled. I see this here:

https://help.zscaler.com/zia/about-microsoft-one-click-options

I’ll poke around and see if I can see where traffic is going. I 100% understand why Msft and Zac’s lee would do that, but I also know our network and security teams do not like bypassing. Hence this ask: super specific URLS. And yes, I know that might not exist…

Thanks for the reference of one click, that gives me somewhere to poke and see.

6

The one click config is essential. You can’t use Zscaler and O365 without it. If you have been bypassing stuff whack a mole, back it all out and turn on the one click config. It is a preset dynamic rule that Zscaler maintains with all relevant necessary Microsoft bypasses (in theory), but those do change and it takes them time to catch up, hence the need for the occasional manual bypass.

7

The one click is Microsoft’s vendor recommendation. It is not the most secure approach. You are removing a layered protection and trusting your security to Microsoft.

8

I won’t/can’t speak to the ‘why’ my network/security team made the choices they did, but… yeah. I will see if I can ‘find’ where stuff is actually going. I do not have access to the ZScaler side. From one of the dumps they sent me, I see this rule:

||
||
|Not inspected because of O365 bypass|

On SSL decryption tab. I assume that’s not the name of the ZScaler ruleset?

9

Well, you can bypass all these that are “required” instead and accomplish the same thing, minus the CDN optimization and other stuff Zscaler does. Or you can just leave ssl inspection on and have entire suites like autopilot, Intune, and teams not work… try activating an Adobe product with ssl inspection on…
Zscaler, VMware, Palo Alto, they all have these extensive lists of urls that need to be bypassed…

https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide&redirectSourcePath=%252farticle%252fOffice-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2

10

Yes, Adobe Creative Cloud is a thick client application that uses pinned certificates. So is Intune Autopilot. As far as most of the other Microsoft sites, they don’t need to be SSL bypassed but setting up rules to inspect specific sites such as OneDrive and SharePoint ahead of a one-click rule may be sufficient. Every company is going to have their own level of risk.

Client Connector 4.3 (if not using network tunnels) also allows for configuration of process based bypasses, which can help simplify some of the configurations for bypassing thick client applications that use pinned certificates.

11

I thought the process based exclusions were added because unlike tunnel 1.0, 2.0 tunnels have to worry about non web ports being blocked, which obviously can’t be excluded via pac file like in 1.0. Not because bypassing a process is more secure than a url.
But you’re definitely right about Microsoft security. Too bad they made me shut down my 15 year old well oiled on prem data center during covid and migrate all of it into O365 so I can spend half my day just waiting for UI’s to load.

12

Tunnel 2.0 has a flag to send Web traffic to local proxy to be able to configure exclusions in PAC. Process-based bypass seems to be more for not having to manage these lists for known pinned certificate processes.