+6Hi All,
One of my user is getting the below pop up and after clicking on Get App it is redirecting to a weird broken link. This user is already registered in Intune/Azure AD and it just randomly started to happen. I am mostly curious about the link. Any ideas where this is coming from?
+8By 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.
+7I'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!
+4Several 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?
+1Here 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.
#!/bin/bash
#Current User
loggedInUser=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }')
#Delete Keychain Access Entries
sudo -u $loggedInUser -H security delete-generic-password -l "https://device.login.microsoftonline.com/ (UBF8T346G9.com.microsoft.CompanyPortalMac)"
sudo -u $loggedInUser -H security delete-generic-password -l "com.microsoft.adalcache"
#clean
sudo -u $loggedInUser -H "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfAAD.app/Contents/MacOS/JamfAAD" clean
#Open Safari, prompt user to set it as default browser via jamfHelper, then registerWithIntune
open -a Safari
title="JamfAAD Fix"
description="Please make Safari your default browser by clicking Make Safari Default within the top banner of the Safari window. After clicking Make Safari Default, click Use Safari."
button1="Ok"
#button2="null"
jamfHelper="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"
icon="/Applications/Safari.app/Contents/Resources/AppIcon.icns"
RESULT=$("$jamfHelper" -windowType utility -windowPosition ur -title "$title" -description "$description" -icon "$icon" -button1 "$button1")
#-button2 "$button2"
if [[ $RESULT == 0 ]]; then
sudo -u $loggedInUser -H "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfAAD.app/Contents/MacOS/JamfAAD" registerWithIntune
#elif [[ $RESULT == 2 ]]; then
#exit 0
fi
#Run gatherAADInfo
sudo -u $loggedInUser -H "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfAAD.app/Contents/MacOS/JamfAAD" gatherAADInfo
#Close Safari
osascript -e "tell application \\"Safari\\" to quit"
+810.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?
+410.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
+8You 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.
+7Running 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. 🙃
+8@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.
+7The 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.
+9You 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
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.
+8You 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>
+14@bmack99 I have implemented this in my production environment. As I mentioned in the post, you no longer have to register a device with the company portal app. You just need to deploy your MCAS cert. This also gives you full control of device compliance. You can hop over to the # jamf-intune-integration Slack channel for more information.
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?
+7I 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?
+9You 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>
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?
+9This 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.
+7I 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.
+7I 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?
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.
+4With the Webview config profile & the Microsoft Enterprise SSO plugin together deployed, we haven't received one complaint since. Works really well!
+7With 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!
+9With the Webview config profile & the Microsoft Enterprise SSO plugin together deployed, we haven't received one complaint since. Works really well!
Sounds like a dream come true!
+2With the Webview config profile & the Microsoft Enterprise SSO plugin together deployed, we haven't received one complaint since. Works really well!
@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!
+9@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?
+7I 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
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.