We see the same things here. Did you solve this issue ?

Yes.  I got this from support.

Could you please add the following process separated by commas in the cert-pin app definition:

---For Windows intunewindowsagent.execompanyportal.exeomadmclient.exemicrosoft.management.servicesintunewindowsagent.exeagentexecutor.exedeviceenroller.exe

---For Mac company portalmdmclientwdavdaemon_enterprise

This is already what is present in the Netskope default Microsoft Intune certificate pinned app so this shouldn’t fix the issue.

@barrycuda72, 

I have seen cases where you must also bypass manage.microsoft.com and dm.microsoft.com from SSL inspection or steering.  Microsoft does not support SSL interception on these endpoints.  I believe there are subdomains in these as well so I’d test with *.manage.microsoft.com and *.dm.micrsoft.com.  I believe there are already discussions around adding these to the default SSL and steering bypasses in Netskope but I’d need to confirm internally. 

We had already tested with manage.microsoft.com because those subdomains always appear in the logs in cas of Intune synchronization but it seems that it was not sufficient.

I hadn’t notice for dm.microsoft.com.

Looking at our logs I see only checkin.dm.microsoft.com.

We will try with manage.microsoft.com and checkin.dm.microsoft.com to see if it is sufficient.

Regards

@mbouillaguet please ensure you’ve bypassed the subdomains for manage.microsoft.com and dm.microsoft.com.  I have seen in client logs in the past that the company portal process uses r.manage.microsoft.com in some cases as well.

Confirmed fix.

NetSkope Settings > Security Cloud Platform > App Definition > Certificate Pinned Apps

Find ‘Microsoft Intune’ click … kSteering Config Exceptions]

Edit ‘Action’ for your steering configuration

Add (manage.microsoft.com, dm.microsoft.com) to ‘Custom App Domains’

Save.

Open Windows Settings > Accounts > Access Work or School

Click on your domain > Click Info

Scroll down > Click ‘Sync’