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?
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.
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?
@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?
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.
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.
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 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.
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?
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.
@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?
@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).
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:
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.
@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