Posted on 01-05-2021 12:54 AM
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.
Posted on 01-06-2021 07:07 AM
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?
Posted on 01-14-2021 11:43 PM
push
Posted on 01-15-2021 04:52 AM
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
Posted on 01-15-2021 05:06 AM
@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?
Posted on 01-15-2021 05:16 AM
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.
Posted on 01-15-2021 05:27 AM
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.
Posted on 01-15-2021 07:25 AM
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.
Posted on 01-18-2021 12:59 AM
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.
Posted on 01-18-2021 07:50 AM
@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.
Posted on 01-18-2021 08:17 AM
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
Posted on 01-20-2021 06:31 AM
Hey @bryce ,
Any updates from your side? Unfortunately this issue is a Showstopper for our whole Intune registration.
Best regards,
Jonny
Posted on 01-20-2021 06:49 PM
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!
Posted on 01-21-2021 12:21 AM
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.
Posted on 01-21-2021 10:16 AM
@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
Posted on 01-21-2021 01:24 PM
@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?
Posted on 01-21-2021 01:41 PM
@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).
Posted on 01-22-2021 01:39 AM
Posted on 05-05-2021 04:41 PM
Hey @jonn1e did you end up ever solving this with support?
Posted on 05-06-2021 12:31 AM
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:
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
Posted on 05-11-2021 11:53 AM
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!
Posted on 06-07-2021 09:40 AM
@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
Posted on 06-08-2021 12:24 AM
@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
Posted on 07-05-2023 12:48 AM
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?