I have several users how are getting a pop up wanting them to register with jamf aad. It gives a pop wanting them to sign in and then grant key chain access, but the users have done this at first log in, and I have managed it clear cache's etc to get the mac back to to this fresh state and sign back into the SSO and register it in keychain.
Nothing works and the pop up's still happen. User's can force quit the pop up, but it will re-appear within an hour. I have added their machines to the exception list of the policy to notify them to register, but this didn't stop it, and they are showing as configured in the intune portal and compliant, so I cannot find any reason for this pop up to keep appearing. It's not stopping the users doing their jobs, but it is very annoying. Double so for me as it's not even happening to everyone!
Has anyone seen this issue and if so do you have a fix? users are running latest ventura, but we aren't using the most up to date jamf pro version, but we were out of date on jamf pro before and people weren't getting this.
Not sure if you have seen this or not but might be worth checking out.
What changed: In Jamf Pro 10.50, JamfAAD was updated to support the Enterprise SSO extension, which required a few changes.
1: The Redirect URI in the request was updated, the new redirect URI is: msauth.com.jamf.management.jamfAAD://auth
The user registration apps were updated with the new redirect URI a few months ago, so as long as JamfAAD is authenticating against the Jamf-published apps, no action needed here.
2: The scopes in the request changed. In 10.49 and lower, JamfAAD does not request any scopes. In 10.50 the User.Read scope was added to the request. For some environments this has resulted in JamfAAD prompting users every time it requests a refresh token. In the environments I’ve seen, this was resolved by adding the Microsoft Graph API User.Read permission to the user registration app. More information on this below.
3: The silent authentication flow uses a different MSAL call that more directly leverages the SSO extension. In some environments we’re seeing this silent call to the SSO extension fail, and it results in jamfAAD falling back to the interactive sign on flow. This seems to be more on a case-by-case basis, rather than impacting the entire environment.
What to do next:
First, verify that the user registration app has the Microsoft Graph API User.Read permission. The user registration app can vary depending on which integration and connection type is being leveraged. To identify your user registration app, do the following:
- On any computer that is registered, run this command: /usr/bin/defaults read /Library/Preferences/com.jamfsoftware.jamf microsoftCANativeClientAppId
This will return the ID of the enterprise app used for user registration.
- In Entra ID (formerly Azure AD), search for this app ID. Go to the Enterprise Application record and under the “Permissions” tab, ensure it has Microsoft Graph API User.Read consented by an administrator. Note this is NOT the same permission as Windows Azure AD Graph API User.Read.
If that all checks out, and you’re still getting jamfAAD prompts, please create a Jamf support case and state that you are encountering the behavior on this ticket number: JPRO-13621.
That was PI in Jamf Pro - and that is fixed with Jamf Pro 11.0.1
[PI113193] In environments integrated with Microsoft Intune and using Single Sign-On Extension, Jamf Pro no longer incorrectly reports some managed computers as "Deactivated" or "non-compliant".
Thanks guys but unfortunately we are running jamf pro 11.0.1 and that doesn't appear to be the case, the users are still getting prompts and azure AD is reporting non compliant entries for the machines even though there is one that shows it as compliant. We deleted the non compliant entries but it made no difference!