By the way, it turns out our infrastructure does not allow certificate issuance, so I'm stuck with the Self Service / Company Portal / Jamf AAD / browser mess. 

@piotrr why is your Jamf Pro server unable to issue certs?

I've build a workaround to set Google Chrome as default browser after the first deployment with DEPNotify. Then the authentication will work properly in most cases. 
But please can somebody from the Jamf Support Team bring some light into this AAD cave? It's so annoying!  

Several machines that have initially registered with Intune are now disappearing from Endpoint Manager and I have no idea why. Looks like I'll need to enable JamfAAD logging.
It seems like the AAD ID is changing on the Mac side?

Here is a script that I whipped up. It gets around the PI bug with the blank Safari page. All of the Macs in my environment have Chrome set as their default browser during DEP and use Chrome for Azure Device Registration. Only 6 out of 353 Macs have had this issue in my environment. 62 other Macs that were migrated from another organization work fine, just those 6 had a problem. Those 68 Macs were done via User Initiated Enrollment, as we did not have their serial numbers absorbed into Apple Business Manager prior to the migration. 

These Keychain keys were mentioned somewhere in another thread. 

10.38 appears to have finally given us an alternative, by employing WebView in JamfAAD. 

New Features and Enhancements - Jamf Pro Release Notes | Jamf 
I've created and deployed the script to two of my machines, but they're both already enrolled so it's not a perfect scenario. However, when rerunning the registration (which should do nothing, really) I still get a browser-branded popup asking me to continue with the registration. 

Has anyone else already tried this on non-enrolled machines to see if the Webview option works? 

You need to run as the logged in user for it to work. The policy in the docs did not work for me.
This script did:

#!/bin/sh
loggedInUser=`/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }'`
sudo -u "$loggedInUser" defaults write com.jamf.management.jamfAAD useWKWebView true

Running the script as the current user did save the default. 

After a system restart, JamfAAD even used webview. It _had_ to be a restart though. 

Now to deploy the script to the users who are having registration requests every 30 days. 

@piotrr 
There is no need for a restart? 

I'm executing the script via DEPnotify before users can take action at the device. Everything is working flawless. 🙃

The script, yes, but even though I have confirmed the defaults saved, running the JamfAAD registration procedure to re-register devices that have become unlinked from Intune, this _still_ starts the default web browser until a restart has been performed. 

Hm strange, never observed this kind of behavior.
Did a few enrollments since the update. 

What about the fact the machines are already registered!.  Does the WebView still work OK? The documentation reads like net new machines only or if you wipe all the settings out then register.

I am wondering I should put the script in SS. When users call Service Desk with the issue, SD can direct the user to the Policy in SS.

You can set the useWKWebView through a configuration profile, with a custom payload set to the com.jamf.management.jamfAAD domain :

And that's it !

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>useWKWebView</key>
<true/>
</dict>
</plist>

Hi @bwoods - do you mean you are using a device cert to control access on the network?  Or, do you mean somehow you are using the device cert for authentication for Intune?

I was looking to enable this today and noticed a difference between the script and the jamf docs. It looks like they added an update to the command to enable Webview. Jamf Release Notes 

Has anyone had any problems deploying the prior command without the -bool or testing out the policy with the new update? 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>useWKWebView</key>
<true/>
</dict>
</plist>

This did not work for me.

Added profile to Computer

Rebooted

Checked com.jamf.management.jamfAAD for userWKwebView entry...nada.

Manually added userWKwebView using defaults write.....the entry was there.

Tried again assigned the profile to USER.  Same issue. the entry did not appear in the plist.

Is there more to this or is this expected behaviour?

Let me change my mind.  
Although there was nothing written to the plist I did experience different behaviours when I reregistered my Mac using SS and Azure, then removed the Profile and registered again.  The registration with profile (user OR device scoped) was cleaner and smoother.

I tried it in our environment but it didn't as expected. I was using policy to push it. @astiephi's plist via config profile worked on few pilot devices. I'm planning to expand it.

I tried it in our environment but it didn't as expected. I was using policy to push it. @astiephi's plist via config profile worked on few pilot devices. I'm planning to expand it.

With the Webview config profile & the Microsoft Enterprise SSO plugin together deployed, we haven't received one complaint since. Works really well!

Sorry, I haven't tested Microsoft Enterprise SSO plugin yet. Will review Microsoft doc and try it next week. Thanks!

Sounds like a dream come true!

@vcherubino Thank you for the tip!

For those unaware, there is a documentation from Jamf about how to build the Configuration Profile (Jump to the 'Configure JamfAAD to use WebView' section):
https://docs.jamf.com/technical-articles/Troubleshooting_Microsoft_Azure_Login_Using_JamfAAD.html

I'm trying it out and see if it works. Thanks!

I can confirm webview is working with device registration when utilizing this config profile with the custom settings. The big question i have is if i deploy this config profile out to my fleet now will that suffice for when JamfAAD goes nuts after a pw change or inactivity etc, or does the device have to be completely re registered first?

From my experience, deploying new profile will be suffice. Existing enrolled Macs won't be impacted. New users will have better experience registering their device. I would recommend two additional things to minimize JamfAAD prompts:
-Increase inactivity in macOS Connector to max (120 days)

-Plan schedule cleanup for macOS devices in Azure. Support case was lodged Microsoft where Intune compliant was not able access company resources. We had to delete old Mac devices (associated to users in Azure) which helped. Here is link to doc from Microsoft [Cause 6] - Troubleshooting Jamf Pro integration with Microsoft Intune - Intune | Microsoft Docs