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

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.

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

deleted

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

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

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

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

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

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

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

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

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.

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

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

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

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

@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?"

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.

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.

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)

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.

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

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 f  $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 f  $defaultbrowser == "Firefox" ]]; then 

        echo "Printing Firefox to file..."

        echo "Firefox" > /tmp/defaultbrowser.txt

    fi

    if f  $defaultbrowser == "Microsoft Edge" ]]; then 

        echo "Printing Microsoft Edge to file..."

        echo "Edge" > /tmp/defaultbrowser.txt

    fi

    if f  $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 f  -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 "${plistbuddyPreferencese@]}"; do

        "$plistbuddyPath" -c "$plistbuddyCommand" "$launchServicesPlist"

        if f  "$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...."

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