JamfAAD - Issue

asidhu
New Contributor III

Hi 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?

291beb292a9c479d91cda5efc371d5df
66efb5c4e9b14c11a66a441e7488e3fe
075cb066ba6c4493b4703746b417f59a

129 REPLIES 129

pueo
Contributor II

If it means anything I am now receiving the Jamf AAD pop ups on my iMac with the latest Safari and latest Chrome installs.  I was hoping the latest Safari was going to resolve the issue with, but no.

Levi_
Contributor II

Has anyone seen any change with the Intune integration at all? As of right now, my Intune registration has to fail three times, Once when you launch from Self Service, Second when you authenticate during the first browser launch and third after you attempt to approve the connector. This is with Safari every time, Chrome is hit or miss, and Edge is a no-go. 

pueo
Contributor II

Hello @Levi_

Honestly I do not know what's going on with Jamf AAD/InTune.  MS and Apple have not fixed the issue yet and Jamf does not have any update on the issue (relying on MS and Apple).  

One Mac may require Authentication using Safari 2 times but the next Mac may need to use Chrome. Very inconsistent.  Our C-Levels are noticing the pop up. Which isn't good for Jamf Pro.

One process we have started is

  • Remove device from Intune
  • Re register device

There is also a script floating around on the web which removes all the files/keychain entries the Compliance installs in the Mac.  I figured it cannot hurt to run this as well.  

My reference was this great site:  https://www.macbuddy.info/blog/lets-get-conditional-unconditional-love

Cheers,

 .a

jonn1e
Contributor

Hey together, 

Has somebody already some experience with JamfAAD and MacOS 12 ? Did the upgrade to Monterey fixed the issue? 

I'm still struggling with some device which will loose their compliance every few weeks and looking for a little bit of hope with the next major upgrade.

 

Or much better someone from the Jamf staff team could give us statement regarding this issue.

 

Cheers,

Jonny

pueo
Contributor II

Apparently it's purely a MS issue which they have publicly announced it was their issue.  Now of course I don't have a URL to back up my claim.  I can only say I was on call with Apple who mentioned this during the discussion.   It does cripple our end users.  Of course its fixed in Monterey.  I have not had the issue yet.

Hi @pueo 

Thanks for you reply! 

When you say it's a MS issue, why was it fixed by Apple with Monterey? 

Just want to be sure the issue is fixed. My colleagues are really annoyed. 

 

pueo
Contributor II

Good question..

Here is the Apple Enterprise Support Answer from a few months ago. (I submitted a ticket about Jamf AAD)

macOS 12 Monterey has a fix which will allow legacy software that uses this method to keep working. The permanent solution is for developers to adjust their software to properly handle these authentication flows through the WKNavigationDelegate’s NSURLAuthenticationChallenge handling. See the documentation for details on this https://developer.apple.com/documentation/webkit/wknavigationdelegate?language=objc. They should adopt - webView:didReceiveAuthenticationChallenge:completionHandler:, responding with a credential that contains an identity if the challenge.protectionSpace.authenticationMethod is "client cert auth.” If they adopt this approach, it will work on all supported macOS releases.

So Monterey has coded their os to work around the issue.  Apple has not released the fix for macOS lower than Monterey.  As we all know Apple is all about going forwards.

 

A.

@pueo 

Many thanks for your reply and forwarding the technical deep dive from Apple. This will help to calm down my colleagues. 🤐

Sadfully that this must happen by Jamf customers and not by Jamf staff itself.

Maybe I'll have a look at the solution below to get a better user experience.  

pueo
Contributor II

If this really works as it says then you are golden @bwoods   Thank you. I will ask my team if we can consider looking into this.

One less step for users. I will admin the entire Intone (MEM) registration is clunky and not very User friendly. 

a.

bmack99
Contributor III

Curious if you have implemented this in your environment? Does this remove the need for device registration via company portal and the cloud connector in jamf? 

bwoods
Valued Contributor

@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.

bmack99
Contributor III

Thanks, I’m assuming that’s a channel in the macadmins slack?


bwoods
Valued Contributor

Yes sir, #jamf-intune-integration is a MacAdmins Slack channel.

dlondon
Valued Contributor

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?

bwoods
Valued Contributor

bwoods_0-1637766078286.png

 

jonn1e
Contributor

After the first SignIn at the Company Portal app it seems like that the registration process stucks at the second signin popup with login.microsoftonline.com? You can click several times at the SignIn button but nothing happens. There are some little dots which are travelling from right to left, so it seems like the system is wating for something. 

 

If you close the whole "login.microsoftonline.com" window and try it a second time via self service the users certificate will be shown and the registration process will be finished. Again this isn't a proper user experience? 

Does somebody faced the same issues?

 

Tested several times with fresh installed MacOS 12.1 M1 Pro, Safari Browser and different users. 

 

Screenshot 2021-12-18 at 16.38.29.png

pueo
Contributor II

I have received this a few times before as well.  We have a few different ways to resolve the continual issue of Jamf AAD. It really comes down to 'some time a fix works and other times you need to try another way'. I am starting lean towards using the Jamf WPJ script jamf-wpj-clean-up which I have received from Jamf Support @mojo21221 has also mentioned the use of it.
I thought it was a bit extreme but when all the other solutions fail, why not try this one. 
@bwoods link to the MCAS User Cert option has been approved for our environment. I will be looking into this in 2022.

Levi_
Contributor II

This is what I consider normal behavior using Safari at this point. If you use Chrome instead of Safari the registration should go straight through as you would expect of a working product however has a major flaw and your users are going to curse you over. If you use Chrome as the default browser, the Jamf AAD registration will hound them each and every day to login. 

This whole experience is ridiculous. I have to exclude a key group of users from this because it will bring negativity from C-Level. Jamf has given us excuses and left us to scream into the void.

bwoods
Valued Contributor

What a piece of crap. Fix this JAMF. We've only been asking for a year.

Levi_
Contributor II

Us: Jamf please help this isn't working right. Safari requires multiple registrations, Chrome asks for login each day and edge flat out doesn't work. 
Jamf: We are aware of these issues and reported these bugs to Google and MS. 
one eternity later
No change. Jamf Connect has received some updates though.

piotrr
Contributor III

For us, I have started running first-registrations (and re-registrations) through Safari as the default browser, but just like jonn1e the first attempt fails with a hanged Azure login window and we have to force quit JamfAAD. The second attempt asks for client certificate and continues, apparently successful. There are no duplicate ID's created either when we do this, so that's ..okay? 

 

Well I say it completes, but yesterday a brand new mos 11.3 Air M1 2020 apparently didn't register with MEM even though the JamfAAD registration went through, so the registration is (perceived as?) buggy and unreliable and when trying to guide users through the process, I must give them the impression I don't l know what I'm doing. I don't don't mind that personally, but it can undermine the trust in the competency of the IT department or their suppliers. 

piotrr
Contributor III

 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. 

bwoods
Valued Contributor

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

jonn1e
Contributor

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!  

vcherubino
New Contributor III

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?

jseckler-adi
New Contributor II

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. 

#!/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"

 

piotrr
Contributor III

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? 

vcherubino
New Contributor III

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. 🙃

piotrr
Contributor III

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.

astiephi
New Contributor III
New Contributor III

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>

 

40 years of Apple Experience... but not that old ! :)

pueo
Contributor II

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?

pueo
Contributor II

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.

Levi_
Contributor II

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 

Levi__0-1654815809308.png

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.

ysdevgan
Contributor

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.