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

76 REPLIES 76

brianmcbride99
Contributor

We have seen this on several machines as well in our environment, the only fix we have found so far is to:
1) delete the devices from Azure and InTune
2) delete the Company Portal App from the machine and reboot
3) reinstall Company Portal App
4) reRun device registration from Self Service
5) Safari HAS to be the default browser - registration seems to fail with Chrome or Edge set as default as your screen shot shows

behr_to
New Contributor

Hi asidhu,

in our environment, we got similar problems too since about a week.
For us, like @brianmcbride99 already mentioned, step 5 is enough to register the clients correctly again after they got unregistered without any reason.

Till now, we got this issue only on clients installed macOS 11.4.0.
A Support Ticket about that case is already opened by us.

asidhu
New Contributor III

@brianmcbride99 and @behr.to

Thank you for confirming and yes the issue was resolved by just changing default browser to Safari without deleting anything.
So it looks like JamfAAD does not work well with other browsers or its something else there thats breaking it when using a different browser.

geoffreykobrien
Contributor

deleted

mojo21221
Contributor II

We are experiencing this in our environment too. Here is our workflow. We use this script https://github.com/macbuddy-howto/jamfAAD-and-WPJ-scripts/blob/main/jamf-wpj-clean-up Have user Open System Preferences, select General and verify Safari is the Default web browser
Restart Mac (this is to verify they are not having login keychain issues)
Have the user open Terminal the type
/usr/local/jamf/bin/JamfAAD clean
hit return
Now open Self Service and search for the policy "Wait for Tech" (attached link to script)
run said policy
Remove the device record from Azure AD and MEM
restart the mac
wait a few minutes to verify the Mac has been removed from Azure AD
Have user register for Conditional Access
After completion wait a few moments for the machine to populate in AAD (maybe have the user run sudo jamf recon) Once the record shows compliance in Azure the user should be able to now sign into Microsoft apps

IamGroot
New Contributor III

We're seeing this in our environment as well. This was an issue with MSAL pre 10.26 previously and Jamf provided a fix in 10.26. It appears something changed and a new fix will need to be published. For now, Safari is the only workaround we have that works to "Continue".

vcherubino
New Contributor

Happening in my environment too. Trying Safari as the workaround.

asidhu
New Contributor III

@mojo21221 Thanks for the workflow and information. I will try to use that if I receive anymore complaints from users but so far its only a one off as most of users use safari but I guess it would be better if Jamf can fix this and make it work on all browsers.

@IamGroot and @vcherubino So far only Safari works but really Jamf should fix such issues and it should not be something only that can be done via for example a specific browser.

whitebeer
Contributor

We got the following reply for our jamf-Call:

Users must have Safari set as the default browser because jamfAAD calls MSAL (https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-overview) to do the auth. And then MSAL calls Safari via the ASWebAuth framework (https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession) and that is using Safari. I understand the concerns and compliancy if this is requested to have everything going via Microsoft Edge but so far there is no way for this to work via that browser. Changing this would be an Apple Feature Request around ASWebAuth. since jamfAAD is telling MSAL who is telling macOS to call WebKit to do the ASWebAuth. To make this work with other browser we would need to create a feature request with Apple but you could also create a feature request on Jamf Nation - however, our hand are tied because this is how Apple build it.

We used the workflow to change the standardbrowser to Microsoft Edge and registered the clients after that - there were no problems. I don't think that there is any documentation from jamf that Safari needs to be standard. Since a few days this problem occurs without changing our working workflow ...

asidhu
New Contributor III

@whitebeer Thank you for sharing that. I went through the links given in your post and on the microsoft end it mentions about Safari. However please read this link as if i understand correctly, there is way to make it work on other applications/browsers.

JEETS
New Contributor

follow the steps shared by @brianmcbride99 After step no 3 remove the WPJ certificate from keychain

bryce
New Contributor III

@asidhu long story short Chrome and Edge (Chrome based) added this and that is telling macOS to take over for the auth. as it is the default browser, but it can not actually do the auth. fully it seems as needed like Safari, and Firefox does not have that implemented.

It was added on this Change ID: https://chromium-review.googlesource.com/q/I5e140d5fea8dd72e644816b99e97607173c251f3

A temporary workaround is possible in theory... at this time while work is ongoing on the browsers (not really see the EDIT at the bottom of post).

The ASWebAuthenticationSessionWebBrowserSupportCapabilities value that lives in the Info.plist of each respective Chrome based browser can be edited to make macOS not attempt to use that default browser as the ASWebAuth. owner.

To do this use these following commands on the device or as a Jamf Policy action or script.

Set Chrome to not take over ASWebAuth:

/usr/libexec/PlistBuddy -c "set :ASWebAuthenticationSessionWebBrowserSupportCapabilities:IsSupported false" /Applications/Google Chrome.app/Contents/Info.plist

Set Edge to not take over ASWebAuth:

/usr/libexec/PlistBuddy -c "set :ASWebAuthenticationSessionWebBrowserSupportCapabilities:IsSupported false" /Applications/Microsoft Edge.app/Contents/Info.plist

After that is run a user log out and login (or reboot (because you can always use a good reboot)) is needed to reload the settings to the macOS.

After that any jamfAAD gatherAADInfo agent/session that needs interactive mode (password change, session timeout, fresh registration) will default to Safari for the ASWebAuth. as it did a few versions ago.

Note: If Edge or Chrome update that ASWebAuthenticationSessionWebBrowserSupportCapabilities key will be overwritten, and the command will need to be run again. Also, test the Info.plist edit on a few devices before pushing to more devices.

EDIT: The Info.plist change would not be a viable workaround as that breaks other components in the browser as it sees the plist edit as tampering.

bouvet
New Contributor II

From today our users are reporting a second re-register since the latest jamf upgrade. This is horrible. Our users are extremely frustrated, and so are we. Please jamf put some more resources into this, Bryce can’t do all the work by himself as it seems he is? it’s a really important feature and when it’s not working it’s a REALLY REALLY bad one that wrecks our users ability to work.

jonn1e
New Contributor III

@bryce Thanks for the technical deep dive. If I understand it correctly the issue was already fixed at Chromium in March, so the Fix should have already arrived at the actual builds from Edge and Chrome?

mrowell
Contributor

@jonn1e The issue was triggered by the change in Chromium in March, so is only just now appearing in the production builds of Edge and Chrome.

skeb1ns
Contributor

Can confirm in our environment as well. Registered users with Chrome as their default browser are complaining about the random popups.

bryce
New Contributor III

@jonn1e what @mrowell has is correct. It was not in production till later versions of 91.x Chrome (and thus Edge).

inflicted
New Contributor II

@bryce In your post, one of your scripts says this:

Set Chrome to not take over ASWebAuth:

/usr/libexec/PlistBuddy -c "set :ASWebAuthenticationSessionWebBrowserSupportCapabilities:IsSupported false" /Applications/Google Chrome.app/Contents/Info.plist

but at the end you say that editing the Info.plist is not a viable solution. Are you saying that we shouldn't deploy your script then? Or is it more like "here's how you fix the popups, but btw, it will screw up other things so use at your own risk?"

bryce
New Contributor III

Correct @inflicted I went back and edited the post as we have seen small issues here and there with some versions of Chrome and Edge that I can not safely say that is a viable band-aid while we work with others on the browser level fix. I keep the info in the post to give the context of what the root cause is etc.

77Baron
New Contributor II

Yes, we've got the same issue. I was finding issues with the latest Company Portal (2.16) - I had to go back to 2.13 on Big Sur 11.4 and make Safari the default browser. Then I could get it working.

cmveloso
New Contributor

I hear that Chrome 91.0.4472.101 has been released... curious if anyone has results (fixed/not fixed) on this version yet? I'll definitely be trying with an end user later but more curious if someone's already attempted.

Update just tried it and no luck (same issue)

piotrr
New Contributor II

Great idea there Bryce, too bad it didn't work. Thank you for testing the idea!

So for everyone saying Safari is the work-around, are you saying that users who switch to Safari as the default browser will have NO future problems with it until they switch default browser again? I suppose I could push a policy that changes the default browser to Safari for the time being?

Jamf Support is telling me Firefox may work as well, but we're dead set on Edge.

asidhu
New Contributor III

@bryce Thank you for the information and providing the reason for this issue. Fortunately we have a very small user base for macOS. Looks like making safari the default browser would be the best way to avoid such issues for now but it would be great if there will be a way for Jamf to find a fix for this.

davidjess
New Contributor III

Been following this one with some interest as we are seeing the same thing in our environment. I wondered if it was possible to write a script to check the default browser, change it to safari if necessary and leave the existing default in a text file so you could prompt the user to change back later (or automate it somehow - not really looked into it)

The idea being that you could add this to the start of your Intune registration policy and it would make sure that users are registering with Safari, getting a JamfAAD clean and hopefully rule out about 80% of your issues, I still need to add some checks, but curious to see what people think.

#!/bin/zsh

# A script to find the default browser and change it to Safari for JamfAAD registration if necessary, also takes a note of the current 
# browser so you can prompt the user to change back in a post script on your registration policy. Mercilessly hacked together from a script
# to find the default browser from VikingOSX on Apple Communities - https://discussions.apple.com/thread/251602703 and a script to change 
# the default browser from Palandir Technologies on GitHub - https://github.com/palantir/jamf-pro-scripts/blob/main/scripts/Set%20Default%20Browser%20and%20Email%20Client.sh
# Tested on Catalina, may have unpredictable results on Big Sur or later. 

# Find the default browser

user=`ls -la /dev/console | cut -d " " -f 4`

function default_browser () {
    sudo -u $user osascript <<-AS
    use framework "AppKit"
    use AppleScript version "2.4"
    use scripting additions

    property NSWorkspace : a reference to current application's NSWorkspace
    property NSURL : a reference to current application's NSURL

    set wurl to NSURL's URLWithString:"https://www.apple.com"
    set thisBrowser to (NSWorkspace's sharedWorkspace)'s ¬
                        URLForApplicationToOpenURL:wurl
    set appname to (thisBrowser's absoluteString)'s lastPathComponent()'s ¬
                    stringByDeletingPathExtension() as text
    return appname as text
AS
    return
}

defaultbrowser=$(printf '%s
' $(default_browser) | sed 's/%20/ /g')

function 1stcheck () {
    if [[ $defaultbrowser == "Safari" ]]; then
        echo "As default browser is already Safari, registration can continue..."
                /usr/local/jamf/bin/jamfAAD clean 
        exit 0
    else
        echo "As default browser is not Safari, we will need to change it before registration can continue..."
    fi 
}

function printbrowser () { 
    if [[ $defaultbrowser == "Firefox" ]]; then 
        echo "Printing Firefox to file..."
        echo "Firefox" > /tmp/defaultbrowser.txt
    fi
    if [[ $defaultbrowser == "Microsoft Edge" ]]; then 
        echo "Printing Microsoft Edge to file..."
        echo "Edge" > /tmp/defaultbrowser.txt
    fi
    if [[ $defaultbrowser == "Google Chrome" ]]; then 
        echo "Printing Google Chrome to file..."
        echo "Chrome" > /tmp/defaultbrowser.txt
    fi
}


function changebrowsertosafari () {
    ########## variable-ing ##########

    # Browser agent string should be in the format domain.vendor.app (e.g. com.apple.safari).
    browserAgentString="com.apple.safari"
    loggedInUser=$(/usr/bin/stat -f%Su "/dev/console")
    loggedInUserHome=$(/usr/bin/dscl . -read "/Users/$loggedInUser" NFSHomeDirectory | /usr/bin/awk '{print $NF}')
    launchServicesPlistFolder="$loggedInUserHome/Library/Preferences/com.apple.LaunchServices"
    launchServicesPlist="$launchServicesPlistFolder/com.apple.launchservices.secure.plist"
    plistbuddyPath="/usr/libexec/PlistBuddy"
    plistbuddyPreferences=(
        "Add :LSHandlers:0:LSHandlerRoleAll string $browserAgentString"
        "Add :LSHandlers:0:LSHandlerURLScheme string http"
        "Add :LSHandlers:1:LSHandlerRoleAll string $browserAgentString"
        "Add :LSHandlers:1:LSHandlerURLScheme string https"
        "Add :LSHandlers:2:LSHandlerRoleViewer string $browserAgentString"
        "Add :LSHandlers:2:LSHandlerContentType string public.html"
        "Add :LSHandlers:3:LSHandlerRoleViewer string $browserAgentString"
        "Add :LSHandlers:3:LSHandlerContentType string public.url"
        "Add :LSHandlers:4:LSHandlerRoleViewer string $browserAgentString"
        "Add :LSHandlers:4:LSHandlerContentType string public.xhtml"
    )
    lsregisterPath="/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister"

    ########## main process ##########

    # Clear out LSHandlers array data from $launchServicesPlist, or create new plist if file does not exist.
    if [[ -e "$launchServicesPlist" ]]; then
        "$plistbuddyPath" -c "Delete :LSHandlers" "$launchServicesPlist"
        echo "Reset LSHandlers array from $launchServicesPlist."
    else
        /bin/mkdir -p "$launchServicesPlistFolder"
        "$plistbuddyPath" -c "Save" "$launchServicesPlist"
        echo "Created $launchServicesPlist."
    fi

    # Add new LSHandlers array.
    "$plistbuddyPath" -c "Add :LSHandlers array" "$launchServicesPlist"
    echo "Initialized LSHandlers array."

    # Set handler for each URL scheme and content type to specified browser
    for plistbuddyCommand in "${plistbuddyPreferences[@]}"; do
        "$plistbuddyPath" -c "$plistbuddyCommand" "$launchServicesPlist"
        if [[ "$plistbuddyCommand" = *"$browserAgentString"* ]]; then
            arrayEntry=$(echo "$plistbuddyCommand" | /usr/bin/awk -F: '{print $2 ":" $3 ":" $4}' | /usr/bin/sed 's/ .*//')
            prefLabel=$(echo "$plistbuddyCommand" | /usr/bin/awk '{print $4}')
            echo "Set $arrayEntry to $prefLabel."
        fi
    done

    # Fix permissions on $launchServicesPlistFolder.
    /usr/sbin/chown -R "$loggedInUser" "$launchServicesPlistFolder"
    echo "Fixed permissions on $launchServicesPlistFolder."

    # Reset Launch Services database.
    sudo -u $user "$lsregisterPath" -kill -r -domain local -domain system -domain user
    echo "Reset Launch Services database. A restart may also be required for these new default client changes to take effect."

}

function jamfaadclean () {
    /usr/local/jamf/bin/jamfAAD clean 
}

echo "Finding the default browser..."
echo "The default browser is... $defaultbrowser"
1stcheck 
echo "Taking a note of the current default browser..."
printbrowser
echo "Changing browser to Safari..."
changebrowsertosafari
echo "Running a JamfAAD clean just to be safe...."
jamfaadclean
echo "Sleeping for 10 seconds just to be EXTRA safe...."

bouvet
New Contributor II

@piotrr @bryce I was wondering the same, if the default browser is Safari, will the users not be prompted with a re-registration? This is the most annoying/frustrating problem, to randomly again and again be asked to register a device you already have registered.

bryce
New Contributor III

@bouvet if Safari is the default browser the end user would not be re-prompted unless the AAD session ends and MSAL (the auth. binary inside of jamfAAD) needs to interact with the end user to start a new session. This would be if the password has changed (AAD ends the sessions for a re-auth. then), if the end user hits the global time out for all sessions (14 days is default, but an org. can change that in AAD), if the end users macOS keychain was deleted, or if the Revoke all sessions action it taken on the AAD portal for a given user.

bryce
New Contributor III

@piotrr an update on a workaround for right now. For those orgs. that are Edge mandated we have a workaround while we work on this with Microsoft.

If you roll back to v90.0.816.66 (last version of v90 ) the ASWebAuth. goes to Safari as needed. This could be a workaround for the time being. The Microsoft CDN location to get this from safely can be found here.

piotrr
New Contributor II

@bryce, Thank you that's a sweet idea but Edge v90 (and Chrome v90) had a bug with Dynamics 365 interaction that can cause tens of thousands of sign-in events per user per day.

Besides, Edge v90 would just update back to v91 as soon as the user restarts the browser, unless I force that in yet another policy, wouldn't it?

I'm sorry to say we may have to accept Safari as the default browser until Edge v92. At least it will only affect clicks from other apps.

piotrr
New Contributor II

@davidjess This is the first I've seen of jamfaad clean. Reading the Help, it seems JamfAAD clean does many of the tasks listed under "Cause 6" in Microsoft's troubleshooting article for MEM/Intune integration problems here :
https://docs.microsoft.com/en-us/troubleshoot/mem/intune/troubleshoot-jamf#cause-6

So far I've been doing this mostly manually, but it looks like jamfaad clean could be incorporated into a the first two rows of instructions: There's should be no point running jamfaad at all after jamf removeframework. 🙂

Cayde-6
Valued Contributor

So we're also getting hit by this now

keep getting a "jamfaad wants to use microsoftonline.com to sign in" prompt which is really hard to ignore (it takes you away from full screen windows).
 
Following the steps gets me to a chrome window with the following question "Are you trying to sign in to Cloud Connector user registration app?"
 
Attempting to click continue results in nothing happening.  Looking in the developer tools for errors I am seeing this error "Failed to launch 'jamfaad://aadtokenrequest/?code=<REDACTED> because the scheme does not have a registered handler".

blockcham
New Contributor II

@bryce and I have been working with Google for a few days now and there is a potential fix that is currently implemented in Chrome Canary version 93.0.4543.0.

If you have the time, could you
1. Download Chrome Canary from here, https://www.google.com/chrome/canary/
2. Make it the default browser
3. Log out/in or restart
4. Then attempt the Intune registration

The webauth should go through Chrome Canary but it should work fine, I've tried it with some VMs and physical machines and it has been working really well. Let me know how it goes. Thanks.

Cayde-6
Valued Contributor

How soon would this hit Microsoft Edge beta?

blockcham
New Contributor II

@Cayde-6 no idea just yet but normal cadence is 6 weeks for Edge Beta. Will reply here as soon as I hear anything about timeline.

shyam9490
New Contributor II

Try running this /Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfAAD.app/Contents/MacOS/JamfAAD -verbose gatherAADInfo -disable-cache-read

blockcham
New Contributor II

sorry duplicate post

blockcham
New Contributor II

sorry duplicate post

Levi_
New Contributor III

Hey @blockcham,

I've tested this on two of my machines 10.15.7 and 11.2.3 and was successful. I even skipped step 3 as an additional test run and still worked.

Hopefully Googs pushes whatever change in this Canary build to a production build soon and Edge gets the fix too.

Thank you man.

asidhu
New Contributor III

Hi @bryce,

Any updates or news with this issue? Seems like in my small environment everyone is starting to get this, we even had issue after setting Safari as default where it would open a page in Safari, the user enters the creds then it brings them to an "Get App" button which when clicked downloads a blank txt file. What we had to do was to run the jamfaad clean, change default browser again to safari, remove company portal and reinstall from Microsoft site, do a restart then run the reg again using the command then it works fine.

Just wanted to know if something new is coming or i will just need to do this for all of them.

Thanks

ashley_stonham
New Contributor

As a temporary workaround this seems to work for us in place of the normal device registration policy.
- It backs up both info.plists - Writes the preference to the Info.plists
- Performs device registration
- Restores the plists

#!/bin/bash
consoleUser=$(/usr/bin/stat -f%Su /dev/console)

if [ "$consoleUser" == "root" ] || [ "$consoleUser" == "_mbsetupuser" ] || [ "$consoleUser" == "temp" ]; then
    echo "Current User is $consoleUser exiting "
    exit 0
fi

##Kill jamfAAD if running and probably frozen
pkill -9 jamfAAD

if [ -d "/Applications/Google Chrome.app" ]; then
    echo "Found Google Chrome"
    cp /Applications/Google Chrome.app/Contents/Info.plist /tmp/ChromeInfo.plist
    /usr/libexec/PlistBuddy -c "set :ASWebAuthenticationSessionWebBrowserSupportCapabilities:IsSupported false" /Applications/Google Chrome.app/Contents/Info.plist
        killall cfprefsd
        killall Google Chrome
fi

if [ -d "/Applications/Microsoft Edge.app" ]; then
    echo "Found Microsoft Edge"
    cp /Applications/Microsoft Edge.app/Contents/Info.plist /tmp/EdgeInfo.plist
    /usr/libexec/PlistBuddy -c "set :ASWebAuthenticationSessionWebBrowserSupportCapabilities:IsSupported false" /Applications/Microsoft Edge.app/Contents/Info.plist
    killall cfprefsd
    killall Microsoft Edge
fi

sudo -u ${consoleUser} /usr/local/jamf/bin/jamfAAD registerWithIntune

if [ -d "/Applications/Google Chrome.app" ]; then
    echo "Found Google Chrome"
    cp /tmp/ChromeInfo.plist   /Applications/Google Chrome.app/Contents/Info.plist
        killall cfprefsd
        killall Google Chrome
fi

if [ -d "/Applications/Microsoft Edge.app" ]; then
    echo "Found Microsoft Edge"
    cp /tmp/EdgeInfo.plist  /Applications/Microsoft Edge.app/Contents/Info.plist
    killall cfprefsd
    killall Microsoft Edge
fi