cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7875
Views
31
Helpful
22
Replies

ISE external MDM Intune integration returns old\wrong API version

rogergh
Level 1
Level 1

Hi, we are trying to integrate our Microsoft Endpoint Manager (previously Intune) into Cisco ISE 3.1 Patch 3 as external MDM-server, but it always returns API version 2 instead of version 3 when testing connection. The documentation says version 3 is supported when using Microsoft Endpoint Manager. Enabling debug on the MDM-component reveals the following lines which seem to be relevant to the detection process:

2022-08-24 15:01:05,195 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.authtoken.MdmAzureActiveDirectoryClient -::::- Access token has acquired  succesfully from Microsoft Azure.
2022-08-24 15:01:05,195 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.api.MdmServerInfoApi -::::- inside the method : callMdmServerInfoApiOnMdmServer()
2022-08-24 15:01:05,195 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.apiimpl.MDMVerifyServer -::::- apiVersionSb : 3, mdmApiVersionSb : , tryWithV3 : false
2022-08-24 15:01:05,195 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.apiimpl.MDMVerifyServer -::::- MDM Rest API Server Query String -> /ciscoise/mdminfo/?ise_api_version=3 
2022-08-24 15:01:05,195 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.apiimpl.MDMVerifyServer -::::- MDM Rest API Server Query PATH String -> /ciscoise/mdminfo/?ise_api_version=3 
2022-08-24 15:01:05,195 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.apiimpl.MDMVerifyServer -::::- 1. Connecting to the MDM server host fef.msub05.manage.microsoft.com using apiVersion 3
2022-08-24 15:01:05,195 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- sendGETRequestDom: start  HTTP request - connectionsUsed: 2, connectionsAvailable: 198
2022-08-24 15:01:05,195 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- sendGETRequestDomNonComp: start  HTTP request - connectionsUsed: 0, connectionsAvailable: 200
2022-08-24 15:01:05,195 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- ===mdmFlowInfo===null,=====serverType=====MobileDeviceManager,===serverAuthType===OAuth - Client Credentials
2022-08-24 15:01:05,195 INFO   [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- GET: MDM Server URL: https://fef.msub05.manage.microsoft.com/StatelessNACService/ciscoise/mdminfo/?ise_api_version=3
2022-08-24 15:01:05,322 INFO   [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- MDM Server Response Code: 200
2022-08-24 15:01:05,326 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- sendGETRequestDom: end  HTTP request - connectionsUsed: 2, connectionsAvailable: 198
2022-08-24 15:01:05,326 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- sendGETRequestDomNonComp: end  HTTP request - connectionsUsed: 0, connectionsAvailable: 200
2022-08-24 15:01:05,326 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.api.MdmServerInfoApi -::::- returning from the method : callMdmServerInfoApiOnMdmServer() -> com.cisco.cpm.mdm.api.MdmServerInfoData Object {
  apiPath: /StatelessNacService/ciscodeviceinfo/mdm/api
  redirectUrl: https://portal.manage.microsoft.com/networkaccesscontrol/index
  queryMaxSize: 100
  apiVersion: 2
  vendor: Microsoft
  productName: Microsoft Intune
  productVersion: 5.0
  COMMA: , 
  errorMsg: null
  errorOccurred: false
} 
2022-08-24 15:01:05,893 ERROR  [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Unable to load the handler impl class 'com.cisco.cpm.psqmgr.notification.PxGridNotificationHandler' com.cisco.cpm.psqmgr.notification.PxGridNotificationHandler
2022-08-24 15:01:05,893 ERROR  [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Unable to get handler with name  PxGridNotificationHandler
2022-08-24 15:01:05,893 WARN   [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Handler with name 'PxGridNotificationHandler' is not loaded with impl class 'com.cisco.cpm.psqmgr.notification.PxGridNotificationHandler'
2022-08-24 15:01:05,894 ERROR  [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Unable to load the handler impl class 'com.cisco.cpm.eps.config.ConfigChangeHandler' com.cisco.cpm.eps.config.ConfigChangeHandler
2022-08-24 15:01:05,895 ERROR  [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Unable to get handler with name  EPSConfigChangeHandler
2022-08-24 15:01:05,895 WARN   [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Handler with name 'EPSConfigChangeHandler' is not loaded with impl class 'com.cisco.cpm.eps.config.ConfigChangeHandler'
2022-08-24 15:01:05,911 DEBUG  [admin-http-pool55][] cisco.cpm.mdm.pip.MdmSettingsNotificationHandler -::::- add / update mdm server to the local MDM servers cache MSEndpMgmt
2022-08-24 15:01:05,912 INFO   [admin-http-pool55][] cisco.cpm.mdm.util.MdmServersCache -::::- MDM server - Status : InActive, mdm server id : REMOVEDFROMLOG and mdm server name : MSEndpMgmt

Anyone else made this work with API version 3?

 

1 Accepted Solution

Accepted Solutions

After a month of zero updates I went into ISE again to try and troubleshoot again but to no avail.

So I searched the forum again, found this topic and after that gave bugsearch a go again.

There I found the following bug: https://bst.cisco.com/bugsearch/bug/CSCwd84055

The following is stated and including a workaround:

 

Symptom:

While integrating ISE 3.1 with Azure AD/Intune for MDM, ISE reports that MDM only supports Cisco ISE API Version 2.

This occurs due to ISE incorrectly assuming that in the Azure Auto Discovery JSON, ComplianceRetrievalService (V3) appears before NACAPIService(V2). If Azure result has NACAPIService appearing first, ISE picks that endpoint and ignores ComplianceRetrievalService that appears further in the output.

ISE needs first look for ComplianceRetrievalService in the entire JSON before failing over to NACAPIService

 

Conditions:

Integrating ISE 3.1 with Azure AD and it reports that it support Version 2 and not Version 3.

 

Workaround:

To workaround this issue, Auto Discovery has to be set to No and we can specify the endpoint for Version 3 manually.

Hostname: fef..manage.microsoft.com

Port: 443

Instance: TrafficGateway/TrafficRoutingService/ResourceAccess/ComplianceRetrievalService

 

Did you already try and test this workaround?

I've just pointed our TAC engineer to this bug as a possible workaround.

The given symptoms and clarification matches your last post at least in essence.

View solution in original post

22 Replies 22

marce1000
VIP
VIP

 

 - Ref : https://www.cisco.com/c/en/us/support/docs/field-notices/724/fn72427.html 

  >...Configure the use of MDM APIv3 Microsoft Intune integration. This includes the deployment of certificates to all Intune registered endpoints and confirmation that those certificates are used for network authentication. For further information, see the Integrate MDM and UEM Servers with Cisco ISE Configuration Guide.

                            Check of any of the mentioned 'arguments' can be applicable to your case.

 M.

  



-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
    When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

@rogergh check out this Cisco video relating to configuring ISE 3.1 with Intune. https://www.youtube.com/watch?v=iAKyIHFqbgE

 

rogergh
Level 1
Level 1

@marce1000 The Azure application\registration is configured to use the Cisco ISE-certificate for authentication, and the Endpoint Manager device profiles are configured to deploy certificates from our PKI (with MS Connector for MEM\Intune) with the SAN URI as DeviceID (as per the documentation). We don't have to activate some other global MEM\Intune certificate config I assume?

@Rob Ingram The video seems very interesting, but from what I can see it doesn't seem to include configuring the External MDM-connector in ISE against MEM (Intune), only policy and endpoint-configuration after getting it up and running. Thanks anyway though, seems interesting for the post-config parts.

 

 - Check if there are any settings on Microsoft Endpoint Manager , where you could specify or set the api version to be used explicitly.

 M.



-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
    When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

Greg Gibbs
Cisco Employee
Cisco Employee

In the logs, I see an MDM response of 200. This should mean a successful response to the APIv3 query, so it looks like that should be working.

 

2022-08-24 15:01:05,195 INFO   [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- GET: MDM Server URL: https://fef.msub05.manage.microsoft.com/StatelessNACService/ciscoise/mdminfo/?ise_api_version=3
2022-08-24 15:01:05,322 INFO   [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- MDM Server Response Code: 200

 

What have you configured for the Device Identifier in the MDM server config? Have you disabled the 'Legacy MAC Address' option for identity? If not, ISE would likely be using both APIv2 and APIv3 during the lookups.
You might want to enable the TRACE level on the external-mdm log via the Debug Wizard, test an endpoint, and see what details you can see related to the session (deviceIdentifier, GUID, etc).

Example from my Webinar:

Screen Shot 2022-08-26 at 9.10.03 am.png

 

 

Hi.

We can't adjust the settings for Device Identifier, since it only says that it supports API V2 (greyed out).
See the screenshots for our settings. I have removed client ID and Token Issuing URL in the picture only. They are correctly filled out in the settings.

The configuration on ISE and the API Permissions in Azure look correct.

Does your token endpoint have the following format?
https://login.microsoftonline.com/<tenantID>/oauth2/v2.0/token

Did you upload the Admin certificate from ISE to the App Registration in Azure as described from Step 7 in the guide (https://www.cisco.com/c/en/us/td/docs/security/ise/UEM-MDM-Server-Integration/b_MDM_UEM_Servers_CiscoISE/chapter.html)?

Have you installed all of the Trusted Certificates listed in Step 25?

Was this an existing External MDM in ISE that you are re-configuring to use the APIv3 or are you configuring it as a new MDM? If it was already existing using APIv2, you might try configuring it as a new MDM to see if that resolves the issue.

I configured it as a new MDM in my lab as per the guide, and my ISE 3.1p3 instance states it supports APIv3.
Screen Shot 2022-08-30 at 8.20.54 am.png

If all of the above are correct, you might need to open a TAC case and provide the TRACE level external-mdm logs for further investigation.

hslai
Cisco Employee
Cisco Employee

I saw similar in a customer case, whose TAC engaged the BU escalation team as well as Microsoft Intune team. FYI.

Jeremybosch
Level 1
Level 1

We have a similair problem, not resolved. MDM connections to our production tenant return API v2 but if I hookup the MDM to our my test tentant it defaults to v3.

rogergh
Level 1
Level 1

Thanks for the replies, guys.

I guess we will have to open a TAC case and get this investigated.

@rogergh 

Hi, we've the same issue currently and opened a TAC case as well. We see MDM respond with version 2 as well and TAC directs us now to the Intune Engineer to look for an option to simply enable V3 somehow.

So I'll do that. But...

How did it end for you? Was it fixed?

Thanks for sharing!

@bart.t 

Unfortunately the case progress has been very slow. After a lot of ISE log debugging, Cisco redirected us to Microsoft to verify that "version 3" is active and being sent, and then Intune support just redirect us to the integration guide and say that everything seems correct on their end (I'm not sure they understood what Cisco wants them to check, so I asked for a clarification from Cisco support as well, but haven't heard back yet). I can see from Microsoft documentation (https://learn.microsoft.com/en-us/mem/intune/protect/network-access-control-integrate) that they refer to their NAC-integration version as NAC 2.0, so the debug logs might actually return correct information (if it refers to Microsofts version numbering and not Cisco's, but I still need clarification from Cisco on this).

If you get any closer to a solution, let us know here as well

Thank you for your quick response. It's unfortunate that your case is dragging on as well. One would think Cisco and Microsoft should interact directly regarding which data is sent across and how it should be interpreted.

Thanks for sharing, I will as well for sure.

After a month of zero updates I went into ISE again to try and troubleshoot again but to no avail.

So I searched the forum again, found this topic and after that gave bugsearch a go again.

There I found the following bug: https://bst.cisco.com/bugsearch/bug/CSCwd84055

The following is stated and including a workaround:

 

Symptom:

While integrating ISE 3.1 with Azure AD/Intune for MDM, ISE reports that MDM only supports Cisco ISE API Version 2.

This occurs due to ISE incorrectly assuming that in the Azure Auto Discovery JSON, ComplianceRetrievalService (V3) appears before NACAPIService(V2). If Azure result has NACAPIService appearing first, ISE picks that endpoint and ignores ComplianceRetrievalService that appears further in the output.

ISE needs first look for ComplianceRetrievalService in the entire JSON before failing over to NACAPIService

 

Conditions:

Integrating ISE 3.1 with Azure AD and it reports that it support Version 2 and not Version 3.

 

Workaround:

To workaround this issue, Auto Discovery has to be set to No and we can specify the endpoint for Version 3 manually.

Hostname: fef..manage.microsoft.com

Port: 443

Instance: TrafficGateway/TrafficRoutingService/ResourceAccess/ComplianceRetrievalService

 

Did you already try and test this workaround?

I've just pointed our TAC engineer to this bug as a possible workaround.

The given symptoms and clarification matches your last post at least in essence.