Mastering Firewalls for Intunes and Autopilot Success, FQDN, IP, CRL to get Intunes running

Mastering Firewalls for Intunes and Autopilot Success

In the realm of IT, especially with the advent of cloud-based systems like M365 and Intune, managing firewalls has evolved into a complex challenge. Gone are the days of a handful of external ports; now, it’s like navigating a digital maze of ports and IP ranges. Enter the Firewall Team, tasked with untangling these complexities to ensure a seamless 100% functionality for Intune and other critical processes.

And let’s not forget the Firewall’s critical role in Intune deployments. As Intune downloads its packages via HTTP/Port 80, it’s essential that the Firewall handles the Port 80 stream according to Microsoft’s specifications, be it Palo Alto, Fortigate, or other contenders. This unassuming box holds the power to determine whether Intune and Autopilot will operate at 10% or achieve a flawless 100%, and sometimes, it’s a game-changer.

Do NOT Break SSL, do not watch into SSL

That one should be really clear and no don’t try it. It will look like it works than a few minutes later, or next client or package it want.

Allow HTTP Protocoll “Partial Repsonse” or “Partial Downloads”

RFC for HTTP requests (Section 14.35.2): https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.

This is security related. If the attacker can download small parts of an large file (Code) in small parts and then merge them together. As we understood as example

The IPS Filter or Realtime file Sandbox (Whatever FW producers use as terms) can’t analyse the file or try to analyse. That sound strange but because he download 3 separate parts 1xGIF, 1xJPG, 1xHTML and merge that together somehow.

The HTTP range option is like a secret handshake tucked away in the HTTP header. It’s the way client machines subtly ask servers for only specific chunks of a file. Picture it as a covert dance, where the client gracefully seeks out particular bytes from the server. This nifty protocol proves its worth when you’re resuming a download that took a pause or when you’re snatching parts of an executable file from a website.

Imagine you’re downloading an exe file, excited to unleash its power. The client doesn’t demand the whole file; instead, it politely whispers to the server, “Just a snippet, please.” This is the moment where the HTTP range option steps into the spotlight.

But here’s the intriguing part: sometimes, the client doesn’t devour the entire file immediately. It stores a portion away for safekeeping, like a squirrel stashing acorns for later. When it craves the rest, it sends an HTTP Accept-Ranges header, a subtle signal to the server that it’s ready for the next chapter.

We tried to explain this to ourself (Like RESUME in FTP)

The “Accept-Ranges” field in a server’s response is like a little flag telling the client whether it’s cool to make partial requests for a specific resource. Imagine you’re downloading a file, and this field says, “Hey, I’m okay with you asking for just a piece of this file if you want.”

For example, if a server is all about byte-range requests (where you request specific chunks of a file), it will include:

Accept-Ranges: bytes

This is like a green light for the client to use byte range requests for that specific resource. It’s like saying, “Feel free to download this file in parts if you need to. Bytes are the units we’re talking about here.” The technical term for these units is defined in Section 14.1 of the RFC.

Now, here’s the twist: a client can decide to make range requests even if it didn’t get this “Accept-Ranges” field. It’s not a strict rule; it’s more like a suggestion to help things run smoother and save on unnecessary data transfers.

But—and there’s always a but—the client should never assume that just because it got an “Accept-Ranges” field, future range requests will always get partial responses. The content might change, the server might only allow range requests at certain times, or maybe a different middleman will handle the next request.

If a server is not into any kind of range requests for a specific resource, it might shoot back:

Accept-Ranges: none

This is like saying, “Don’t bother asking for parts of this file. I’m not into that range request thing for this particular resource.” The term “none” is reserved just for this purpose.

Now, the tech wizards say this “Accept-Ranges” info can be sent in a trailer section, but it’s better to send it as a header field. Why? Because it’s super helpful when you’re trying to restart a big download that got interrupted. It gives the client a heads up on whether it’s worth trying to download in parts or not before it reaches the trailer section of the response.

We have found info regarding this issue for Palo Alto FW:

Firewall breaks SCCM communication for agent push/download between client and server

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008TvuCAE&lang=en_US%E2%80%A9

Check the box for: Device >> Setup >> Content-ID >> Content -ID Settings >> Allow HTTP Partial response

When it is valid for an SCCM Agent it also valid for a M365 Intunes Deployment standalone.

Microsoft side CRL, FQDN andd IP list you need Intunes and Microsoft Store (Company Portal) working

You want something working the FW-Teams wan’s a KB or a list with targets you must reach and how they can handle the stream (Break SSL, etc.)

Most firewall producers have Databases you can use as target objects like Fortigate. There are over 4’000 FQDN in that Service database. However sometimes Fortinet is not fast enough to update those or there are simply error in the data. Also keep in mind for any Round Robin DNS that cache may play a role.

Microsoft offers a Source list which will give you all FQDN and IP you need to open. The FQDN is depending on your Firewalls Round Robin mechanism and HOW fast this will update or cache. Behind a an FQDN there could be several IP address and depending on your FW or client system this may be outdated sometimes (Load Balancers).

Here is how to get the most important FQDN/IP’s from an INTUNES client which is already connected to MDM/Intunes and did run a deployment. (For the Parts with certutil). The certutil part will show you what CRL Cert Revocation Lists are used by Code Signing (EXE/DLL) on your machine. You MUST 100% have those URL open and working.

Get all FQDN that Intunes needs in a textfile with PowerShell

(invoke-restmethod -Uri (“https://endpoints.office.com/endpoints/WorldWide?ServiceAreas=MEM`&`clientrequestid=” + ([GUID]::NewGuid()).Guid)) | ?{$_.ServiceArea -eq “MEM” -and $_.ips} | select -unique -ExpandProperty ips > Intunes_FQDN.txt

Get all IP that Intunes needs in a textfile with Powershell

(invoke-restmethod -Uri (“https://endpoints.office.com/endpoints/WorldWide?ServiceAreas=MEM`&`clientrequestid=” + ([GUID]::NewGuid()).Guid)) | ?{$_.ServiceArea -eq “MEM” -and $_.urls} | select -unique -ExpandProperty urls > Intunes_IP.txt

Get a list off all Certificate related CRL (Certificate Revocation List) that your Intunes clients needs

Certuitl –urlcache > Intunes_crt_crl.txt

Please see our other related posts:

https://www.butsch.ch/post/missing-entry-in-fortigate-application-filter-root-certificate-url-and-ocsp-source-of-w10-setup-failing/

https://www.butsch.ch/post/Missing-entry-in-Fortigate-Application-Filter-ROOTCERTIFICATEURL-and-OCSP-source-of-W10-Setup-failing/