Conditional Access Registration asking for Jamf Native macOS Connector

[jonn1e]

Hi, We've setup the Intune Registration at Jamf properly. Devices are successfully imported to Intune. But there is an additional window at the registration process, which asks the user to allow the "Jamf Native macOS Connector". Accroding to the Jamf documentation, this window shouldn't appear? I already checked the permissions at the app which seems fine to me. We haven't assigned any endusers to the app, but enabled for signin. Do I miss something?

Regards,
Jonny

Update: After some further investigation, I've found this error message, but I have no idea why this is happening. Will open a case with Microsoft Support.

[jonn1e]

So I talked with Microsoft Support about this issue. They said it is intented because the Native Connector is owned by another tenant. Can somebody confirm this behavior?

[jonn1e]

push

[Cyberghost]

Hey,

I checked in our setup. There is only the setting "visble to user" set to yes. You checked already the setting on the JSS as well? Do you checked-in your clients via the CompanyPortal in the SelfService?

Best
Thorsten

[jonn1e]

@Cyberghost Thanks for your reply. The setting "visible to users" defines if the user can see this app at his App Dashboard at AAD. But I guess that is not the root cause of the issue. I've got two policies, one for the installation of the company portal and another for "Register for Device Compliance with Azure AD" which are pushed to the users. If they accept popup for the Jamf Native Connector it's fine and the devices are succesfully registered with Intune.

But actual the user have to enter his credentials 3x times for registration and I try to simplify the process regarding the jamf documentation where the popup isn't documented.

How is it in your environment, does the popup also appear and asking for user consent?

[Cyberghost]

At our environment the popup didn't appear but we are not simplify the process currently. So we need to enter the password also 3 times. Don't know if it's possible to reduce this. Think the point is, first login is to azure via Companyportal, the second via JAMFAAD and the third to gain JAMFAAD access to the key chain. Don't think there is a shorter way.

[jonn1e]

Sorry, didn't count the access to keychain. So it's 4 times with the keychain in our environment. As you mentioned, the first time is for the Company Portal, the second for the registration and the simultaneously with the keychain request a third popup which is asking also for credentials and consent for MacOS Native Connector. So It's one step more which is also not documented. Something is wrong.

[Cyberghost]

Hmm, this is very strange. I never saw 4 pw request. Think in this case a support ticket will be the best. This looks not right from here. Sorry that I can't help you there.

Update: Do you use Conditional Access? Perhaps there is something wrong.

[jonn1e]

Don't worry. Yes, a support ticket is maybe the best way to go. Already checked our conditional access rules, but none of them are applied.

[bryce]

@jonn1e is your AAD sign in federated with your own branded sign in? I have been looking into this and have been unable to replicate it in my non-federated standalone AAD tenant. Also, have seen other federated tenants that do not see this. So it might be a global or federation setting that I have been working to find and document.

[jonn1e]

Hey @bryce,
Thanks for your reply. We're using AzureAD Connect to sync our users from AD to AAD. No ADFS. The branded sign in comes from AAD settings.

I already searched our AAD for any settings that may be the root cause of the user consent question, but normally the app shouldn't ask if a global administrator already granted all needed permissions. Did you noticed the error message in third screenshot? Would it be helpful to delete the Native Connector App and reinstall it or will this may broke something in the background?

Best regards,
Jonny

[jonn1e]

Hey @bryce ,
Any updates from your side? Unfortunately this issue is a Showstopper for our whole Intune registration.
Best regards, Jonny

[bryce]

Hey @jonn1e ,

Sorry for the delay across a lot of things right now. I will reply in line here:

I already searched our AAD for any settings that may be the root cause of the user consent question, but normally the app shouldn't ask if a global administrator already granted all needed permissions.

Correct; if a global admin has granted the consent experience that should not be the case, and I know for people that see that it was not always (since the inception of the connection) it seems to have only been in the last quarter or so (no hard date as different people noticed it at different times).

Did you noticed the error message in third screenshot?

Yes; that is where I think we should grab a sysdiagnose from an affected Mac and break down the MSAL traffic that is taking place since maybe it is down to how MSAL (inside of jamfAAD) is doing the request.

Would it be helpful to delete the Native Connector App and reinstall it or will this may broke something in the background?

Possibly; but only if you had not used a Global Admin account prior, and it sounds like you had.

If you get a support case going with the sysdiagnose files that might be the best path and we can break down what the client side is doing and then loop in Microsoft if we can find something within MSAL.

Thanks!

[jonn1e]

Hey @bryce Thanks for your reply. How can I create the sysdiagnose for MSAL traffic? Do you have a KBA article or something similar?
Already tried to reinstall Native Connector App, but without any success.
My support case number is: JAMF-2219060 if needed.

[bryce]

@jonn1e so the MSAL logs are passed back to jamfAAD since it invokes it to verify the WPJ. jamfAAD logs to the unified system logs so just doing a full sysdiagnose dump should do it.

sudo sysdiagnose -f ~/Desktop

[merps]

@bryce What happens in the event that an account is global admin when configuring the Native Connector App, but is then demoted? Is the global admin portion a point-in-time permission or does the current permission of the authorizing account get taken into consideration during future device registrations?

[bryce]

@merps You are on the right train of thought. It is a point in time action when the enterprise application is created. So you can demote the user later. What many customers do is use a service account or do a joint set up call with an AAD admin so they do that part of the set up (via a copy/paste of the URL to AAD or temp Jamf Pro admin access on the screen share).

[jonn1e]

@bryce Thanks, but your colleague Maciej send me also a command which we can deploy in our self service. This make things much eassier. :) I uploaded the logs at our support case.
@merps We used our regular azure global admin to install the app, the user isn't demoted after this action.

[adthree]

Hey @jonn1e did you end up ever solving this with support?

[jonn1e]

Hey @adthree

We discussed this issue over weeks with the support and the result was that all popup windows are intended. They didn't fix the documentation with correct screenshots, which is quite confusing. Beside that, the "registration flow" isn't that reliable for a proper documentation. Sometimes windows vanishes or simple doesn't appear when the user try to register it's device. Especially the last window throws often an error message and left the user clueless. I'm not sure why this is happening or what is the root cause. BUT if the device is registered successfully, it runs without any issues (for the moment) and Conditional Access can be enforced.

So the registration process looks like the following for our AAD:

1. First Login on MacOS at Company Portal, triggered by Self Service Registration Button
2. Second Login also at the Company Portal in a separate Window with MFA -> Company Portal completed!
3. After a few seconds the little window from Jamf with the help text, triggers a third default browser popup which is asking for consent to Jamf User registration. We noticed that it must be Safari to accept this. After that Jamf is asking for the users MacOS keychain password. --> Finished

You must ensure that the User have an AAD P1 and Endpoint Manager (Intune) License. Second bump could be conditional access rules which must exclude the registration Apps from Jamf. Last but not least, we setup the whole Jamf <-> Intune configuration once again with the automatic setup.

Best regards,
Jonny

[adthree]

Thanks for the response @jonn1e - its what I believed to be true as well but I had a glimmer of hope that it maybe wasn't and the native connector window was a fluke for the registration/reauth steps. Appreciate the follow up!

[inflicted]

@jonn1e for this step We noticed that it must be Safari to accept this is there a quick way to do this? This is the exact problem that i am facing. When the 3rd browser popup with the help text shows up, it is now using chrome (before it was using safari). Not sure if its a big sur issue, but is there a quick way to get it to use Safari? Do i need to make safari the default browser before proceeding? Hoping there is an easier way since majority of my users use chrome

[jonn1e]

@inflicted Yes, we also noticed this behaviour with Big Sur. Please have a look here: https://www.jamf.com/jamf-nation/discussions/39069/jamfaad-issue

[husnudagidir]

Hi Everyone,

I see this question has been discussed for a long time. We are in 2023 and I still have the problem discussed here. Has anyone found a solution to this problem?