Intune MDM Attributes missing

[stevez]

Hi,

we are currently facing the following issue running a Cisco ISE 3.2 Patch 2:

• We have 2 MDM Integrations, Intune and JAMF set up - both working with APIv3 and successful connection tests, querying multiple MDMs is enabled in General MDM settings.
• We have a Authorization Policy that checks if MDM.DeviceRegisterStatus is Registered - that rule works and we see successful endpoint authz
• But for a couple of clients that rule fails, despite them being registered - I have checked this with the python script from here (https://github.com/vbobrov/iseutils), which returns <register_status>true</register_status> from Intune.
• In ISE, I don't see any MDM attributes at all for the problematic clients and looking at the debug ise-psc logs, it seems that ISE is just not querying the MDM endpoints at all when those clients go through authz workflow.
• We have set our MDM cache timers to minimum, deleted the endpoints from the database, but no luck: when those clients go through authz, ISE just nopes out when checking for MDM registered status and denies authorization without even querying the MDM endpoint.

So, anyone got any idea about this? when should ISE query the MDM endpoints for the MDM attributes when not during authz (with having no cached/expired attributes available)? We are running out of ideas here

[Greg Gibbs]

I would suggest opening a TAC case to investigate the issue.

[hslai · Accepted solution]

@stevez  Since you have two MDMs, please ensure MDM:MDMServerName used in the authorization conditions.

For example,

If MDM:MDMServerName EQUALS itune

AND MDM:DeviceRegisterStatus EQUALS Registered

AND MDM:DeviceCompliantStatus EQUALS Compliant

...

Attached is the info on this ISE 3.2 feature that shared by one of my coworkers.

[stevez]

thx, @hslai - that did the trick. I was already aware that it was related to the 2 MDMs, since it was working with only one enabled. Then I checked docs again, and saw mentioning of MDMServerName and that really fixed the issue in the end.

What I don't understand: If this is an endpoint that ISE sees for the first time, why does that rule even trigger (since it has no information about MDMServerName at that point)? And I also observed that the rule is only working when MDMServerName is used as the FIRST condition in the ruleset - also something that I learned the hard way during multiple trial and errors.

Anyways, it's working now with fresh(unknown) devices and 2 active MDMs.

[hslai]

@stevez I believe the reason that MDMServerName has to come first among the list of MDM conditions is how we addressed CSCuv68500 MDM: do not force redirection for devices not already enrolled with MDM; i.e., it tags which MDM server to query for the other MDM conditions.