Jamf InTune Intergration issues

[perryd]

So i have Jamf and intune talking fine the app ID is all good and all says its fine.

I can enrol from self service and the Mac shows in Azure as registered but then it never seems to talk to InTune to pass on the computer details and become compliant.

Is anyone else having trouble with this? I use version 1.5 of company portal but have had this issue since version 1.1. It worked once for one device but now its fully broken and nothing enrols correctly.

Any help would be amazing as even Microsoft have no idea and the case is still ongoing.

[hansjoerg_watzl]

We also started with JAMF/Intune integration and have already registered some Macs successfully.
Unfortunately we often see now the following compliance error: "A password is required"

As this is a very generic error, we still do not know, which rule is affected by this.
We checked our configured compliance rule in Intune (only disk encryption and a strong password policy), but these clients have all this applied.
In the local company portal diagnostic log, we only see this entry (part of a very long line):
"NoncompliantRules": "[[SettingID": "Device_Password_Required", "ExpectedValue": "True"

So, it seems it's a device password and not an account password, which is not compliant. But what device password? There's only a firmware password and this is already set on all of our clients (we checked it). And in our Intune compliance rule, a Firmware/BIOS password is NOT required.

Intune gives no more info about these clients.

Is JAMF sending this information to the Intune server or the Company Portal app on the client? I thought, Intune will get the compliance state of the client from JAMF server only, so when there's something broken on the JAMF server, it will send false data to the Intune server?
Has anybody seen this error on Mac clients? Where to look for more info?
(We already removed these computer names from Intune and AzureAD, cleaned the local company portal plist/settings and tried to re-register, but with the same error.)

[Matt_Ellis]

Im having similar issues. for 4 days my system enrolled just fine. now they stopped. I can kick off the self service policy just fine after installing company portal 1.10. enroll into Azure AD. but the second part when the JamfAAD kicks off it times out saying it cant reach our Azure tenant so it only half enrolls.

The JSS test and heartbeat work fine. There is no network barrier we can find between the two systems. so far MS has been less than helpful and im working with Tier4 support at jamf as they have ever seen the issue.

[ThijsX]

@Matt.Ellis Sure that your users are allowed to enroll into Intune? Make sure that users/groups are in belowed

[Matt_Ellis]

@txhaflaire Are you saying that my users should be listed under the Groups section? for them to be able to regisgter there devices with azure ad?

[ThijsX]

@Matt.Ellis create a Azure AD group, assign the test users to that group. Alloe that group in the supplied screenshot and check if they are enrolling in Intune.

[hansjoerg_watzl]

Regarding our weird "Device Password required" non-compliance error, we think we found the reason for it!

All of these computers had one thing in common: They had an AutoLogin entry (user adobeinstall) in the com.apple.loginwindow.plist

After removing this entry with the following command and sending a recon, most of these devices (not all) changed to compliant state immediately:
defaults delete /Library/Preferences/com.apple.loginwindow autoLoginUser

These users were not affected by this AutoLogin setting, as we have set AutoLogin to off and on most of these computers, even the temporary user "adobeInstall" does not exist anymore.)

But it seems the Company Portal/Intune compliance check does read this AutoLogin entry and will give a wrong error.

[hansjoerg_watzl]

We're using JAMF Pro 10.9 and with the new "Intune inventory data sent" button, we now have some more info for troubleshooting.

But what we are really missing, is the current compliance state of a Intune registered Mac. As our team has no access to the Intune administrator console, we have no information, which of our managed Macs are successfully registered in Intune (compliant) and which are not or have issues with the compliance check.
I guess, JAMF Pro only sends the inventory attributes to the Intune server, which then calculates the compliance state. But it would be great, if JAMF Pro in return gets the Intune compliance state (and maybe some more log information about the compliance check itself).

[maiksanftenberg]

Basically Intune rely on information that send from Jamf to Intune.
This said it means if you know what components (Firewall, SIP, Password) are checked by Intune then you can create reports on how many devices fail overall or on a specific topic.
This is how we did it.

We have a EA that reports if you have a single AAD ID, multiple or none to check overall registration status and we have Smart Groups with Policies that can fix Compliance Issues.

[es95pl]

Configuring the MDM user scope is not needed. We have the settings set to None, and it works anyway. Reason is that the Machines is not enrolling in Intune. They are registered in Azure AD only. The Intune part is managed by the App that were created during setup. That app is the gateway in to Intune.

[ThijsX]

@maik.sanftenberg Are you willing to share the EA for the AAD registration?

[maiksanftenberg]

@txhaflaire Sure, we look into com.microsoft.CompanyPortal.usercontext.info

#!/bin/bash loggedInUser=python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + " ");' AADUNIQUEID="$(grep UniqueId /Users/$loggedInUser/Library/Application Support/com.microsoft.CompanyPortal.usercontext.info | awk -F""" '{print $2}')" if [[ "${AADUNIQUEID}" == "" ]] ; then /bin/echo "<result>None</result>" else /bin/echo "<result>${AADUNIQUEID}</result>" fi exit 0

If you have registered the device more then one time, the ${AADUNIQUEID} turns into Multiple.

[rastogisagar123]

We are having Company Portal Enrollment inconsistency issues mostly for existing Intune Enrolled users, whenever we tried to enroll in JAMF door existing Intune Enrolled users, it always a pain. So I always remove Intune Profile from System Preferences and delete Devices from Azure. But Everytime I used to enroll Company Portal from Self Service always throws error Company Portal Retry, Ok and Report.

I tried to delete devices from Azure many times and tried to remove keychain item /Library/Keychains/aspd.keychain, every time when I tried to enroll Company Portal from Self Service.I always see Report ,Ok and Retry . I checked in Azure logs , failure reason is JAMF Native macOS Connector, strange part is this issue only arising for Intune Enrolled users, sometime it works after removing and adding Device ,But for one off user I tried many things for couple of time. unfortunately there is no success.. do anyone have there inputs on this. Or anyone can suggest what other troubleshooting I can perform.. even I tried to check device compliance in portal.manage.microsoft.com .I found nothing. even we reset user system password but still there was no success.

I am left with no options as what I feel but I am wondering if anyone can provide expert advice, will be great help for sure..

[AVmcclint]

I'm having my own InTune problems so I was pointed to this thread. I'm not seeing the same issue, but I learned a lot by the file locations and keychain items. The keychain items triggered a new thought: Since keychains are fragile like tissue paper, what happens when we have to blow out a user's keychain to fix other problems and the user tries to use their Office 365 apps without the various keychain items inserted by InTune registration? Will the user need to redo the whole process or are there easier ways of getting them back to normal as far as InTune is concerned?

[brandonpeek]

@AVmcclint - I can share some of what we are seeing internally. We've setup our Macs with the LAPS solution from GitHub for the purpose of providing a local admin password option in certain account management troubleshooting scenarios. Now that we've introduced Intune registration into the mix we've determined that if the LAPS account is used to log into the Mac this will break Intune registration for the main user account. Apparently, LAPS isn't playing nicely with the JamfAAD keychain entry (or maybe its just tissue paper) and this is causing us to have to delete these impacted devices from Intune and ask our users to register thru the Company Portal again. In fact, we're doing quite a bit of Intune device deletion in general whenever a Mac is handed in by an employee and rebuilt for another employee - or if said employee has a Mac in a state that just requires a rebuild. We're spending quite a bit of time deleting device records from Intune because deleting a device from the Jamf console doesn't carry over to Intune and subsequent Intune registration attempts fails.

[Felix_Chrono24]

Hey @txhaflaire ,

can't see this in JamF. (attached Image) Everything else looks the same as you have described it.
In intune my mac is shown as uncomplient.

Do you have any idea what i can do?

Best regards
Felix

[Felix_Chrono24]

Okay. One Device now is shown as complient, the other one isn't.

Non of them are shown in jamf like in the picture above.