What they are describing isn't necessarily cert pinning, although it's possible there is also cert pinning. It just means there are hard-coded IP addresses somewhere; either a hard-coded DNS server, or the endpoint itself.
Notably, it's still possible to MITM the traffic, just not as easy as if the system respected the proxy settings. You need to spoof the destination IP and try to terminate the TLS with your own trusted cert. If the connection still fails, only then would you know there is a cert pin. I haven't heard if anyone has tried this with the "CDN"-bound traffic, or the persistent bing.com/live.com traffic.
If a VPN was being used, I would expect traffic would still be routed through the VPN interface. The HTTP(S) proxy code is higher up the stack than a VPN interface.
It does raise a huge red flag though, if you are not fully in control of your own network routing using standard tooling, IMO it's not an appropriate OS for any enterprise environment.
Notably, it's still possible to MITM the traffic, just not as easy as if the system respected the proxy settings. You need to spoof the destination IP and try to terminate the TLS with your own trusted cert. If the connection still fails, only then would you know there is a cert pin. I haven't heard if anyone has tried this with the "CDN"-bound traffic, or the persistent bing.com/live.com traffic.
If a VPN was being used, I would expect traffic would still be routed through the VPN interface. The HTTP(S) proxy code is higher up the stack than a VPN interface.
It does raise a huge red flag though, if you are not fully in control of your own network routing using standard tooling, IMO it's not an appropriate OS for any enterprise environment.