Security

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

I had the same issue, had to do two things:

1) It seems that using a SAN field with the URI including 'IntuneDeviceID://' doesn't work because ClearPass doesn't strip it off. I think ClearPass just wants the actual DeviceID value only.

I opted to not use the SAN, and just use CN={{DeviceID}} in the SCEP profile.

2) I am using the 'enableEndpointCache' value and only syncing certain attributes. I was not syncing the attributes that I was trying to populate with the HTTP authz source, so I had to add these.

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Hi Skywave,

we are using the CN only in the SCEP profile, but I get the rlm_eap_tls: certificate does not have X509v3 Subject Alternative Name extension error.

Regards,

Erik

I had the same issue, had to do two things:

1) It seems that using a SAN field with the URI including 'IntuneDeviceID://' doesn't work because ClearPass doesn't strip it off. I think ClearPass just wants the actual DeviceID value only.

I opted to not use the SAN, and just use CN={{DeviceID}} in the SCEP profile.

2) I am using the 'enableEndpointCache' value and only syncing certain attributes. I was not syncing the attributes that I was trying to populate with the HTTP authz source, so I had to add these.

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Hi Erik,

I didn't see that issue in our deployment.

I wonder if you have Certificate Comparison enabled in your TLS authentication method?

Also we are using EAP-TEAP in our environment, 

Cheers,

Chris

Hi Skywave,

we are using the CN only in the SCEP profile, but I get the rlm_eap_tls: certificate does not have X509v3 Subject Alternative Name extension error.

Regards,

Erik

I had the same issue, had to do two things:

1) It seems that using a SAN field with the URI including 'IntuneDeviceID://' doesn't work because ClearPass doesn't strip it off. I think ClearPass just wants the actual DeviceID value only.

I opted to not use the SAN, and just use CN={{DeviceID}} in the SCEP profile.

2) I am using the 'enableEndpointCache' value and only syncing certain attributes. I was not syncing the attributes that I was trying to populate with the HTTP authz source, so I had to add these.

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Yes Compare CN or SAN.

I'll change it to Compare CN only

Hi Erik,

I didn't see that issue in our deployment.

I wonder if you have Certificate Comparison enabled in your TLS authentication method?

Also we are using EAP-TEAP in our environment, 

Cheers,

Chris

Hi Skywave,

we are using the CN only in the SCEP profile, but I get the rlm_eap_tls: certificate does not have X509v3 Subject Alternative Name extension error.

Regards,

Erik

I had the same issue, had to do two things:

1) It seems that using a SAN field with the URI including 'IntuneDeviceID://' doesn't work because ClearPass doesn't strip it off. I think ClearPass just wants the actual DeviceID value only.

I opted to not use the SAN, and just use CN={{DeviceID}} in the SCEP profile.

2) I am using the 'enableEndpointCache' value and only syncing certain attributes. I was not syncing the attributes that I was trying to populate with the HTTP authz source, so I had to add these.

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Changing to Compare CN only gave me the same error. 

Yes Compare CN or SAN.

I'll change it to Compare CN only

Hi Erik,

I didn't see that issue in our deployment.

I wonder if you have Certificate Comparison enabled in your TLS authentication method?

Also we are using EAP-TEAP in our environment, 

Cheers,

Chris

Hi Skywave,

we are using the CN only in the SCEP profile, but I get the rlm_eap_tls: certificate does not have X509v3 Subject Alternative Name extension error.

Regards,

Erik

I had the same issue, had to do two things:

1) It seems that using a SAN field with the URI including 'IntuneDeviceID://' doesn't work because ClearPass doesn't strip it off. I think ClearPass just wants the actual DeviceID value only.

I opted to not use the SAN, and just use CN={{DeviceID}} in the SCEP profile.

2) I am using the 'enableEndpointCache' value and only syncing certain attributes. I was not syncing the attributes that I was trying to populate with the HTTP authz source, so I had to add these.

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Hmm not sure why that would be the case, unless the SAN field is referenced elsewhere in the service, or the HTTP auth source.

As Herman has suggested, it would be worth getting a partner or TAC involved who can look at the logs and configuration in its entirety.

Changing to Compare CN only gave me the same error. 

Yes Compare CN or SAN.

I'll change it to Compare CN only

Hi Erik,

I didn't see that issue in our deployment.

I wonder if you have Certificate Comparison enabled in your TLS authentication method?

Also we are using EAP-TEAP in our environment, 

Cheers,

Chris

Hi Skywave,

we are using the CN only in the SCEP profile, but I get the rlm_eap_tls: certificate does not have X509v3 Subject Alternative Name extension error.

Regards,

Erik

I had the same issue, had to do two things:

1) It seems that using a SAN field with the URI including 'IntuneDeviceID://' doesn't work because ClearPass doesn't strip it off. I think ClearPass just wants the actual DeviceID value only.

I opted to not use the SAN, and just use CN={{DeviceID}} in the SCEP profile.

2) I am using the 'enableEndpointCache' value and only syncing certain attributes. I was not syncing the attributes that I was trying to populate with the HTTP authz source, so I had to add these.

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Yes Compare CN or SAN.

I'll change it to Compare CN only

Hi Erik,

I didn't see that issue in our deployment.

I wonder if you have Certificate Comparison enabled in your TLS authentication method?

Also we are using EAP-TEAP in our environment, 

Cheers,

Chris

Hi Skywave,

we are using the CN only in the SCEP profile, but I get the rlm_eap_tls: certificate does not have X509v3 Subject Alternative Name extension error.

Regards,

Erik

I had the same issue, had to do two things:

1) It seems that using a SAN field with the URI including 'IntuneDeviceID://' doesn't work because ClearPass doesn't strip it off. I think ClearPass just wants the actual DeviceID value only.

I opted to not use the SAN, and just use CN={{DeviceID}} in the SCEP profile.

2) I am using the 'enableEndpointCache' value and only syncing certain attributes. I was not syncing the attributes that I was trying to populate with the HTTP authz source, so I had to add these.

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Hello Herman,

When you say "Intune Device ID as CN" is it really mandatory for it to be "DevideID"? Couldn't it be, for example, the IMEI or SERIALNUMBER? In MS documentation, it is not advisable in some cases to use CN={{DeviceId}} ( Use SCEP certificate profiles with Microsoft Intune | Microsoft Learn)

Thank you

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Saw that recommendation as well. You can as well use one of the SAN options, where the URL seems most appropriated, to store the DeviceId. But I have not seen issues with CN={{DeviceId}}'. Bottom line, ClearPass needs to have access to the DeviceId in an (unique) attribute of the certificate.

Hello Herman,

When you say "Intune Device ID as CN" is it really mandatory for it to be "DevideID"? Couldn't it be, for example, the IMEI or SERIALNUMBER? In MS documentation, it is not advisable in some cases to use CN={{DeviceId}} ( Use SCEP certificate profiles with Microsoft Intune | Microsoft Learn)

Thank you

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Can you share what your filter looks like with your HTTP config?

Saw that recommendation as well. You can as well use one of the SAN options, where the URL seems most appropriated, to store the DeviceId. But I have not seen issues with CN={{DeviceId}}'. Bottom line, ClearPass needs to have access to the DeviceId in an (unique) attribute of the certificate.

Hello Herman,

When you say "Intune Device ID as CN" is it really mandatory for it to be "DevideID"? Couldn't it be, for example, the IMEI or SERIALNUMBER? In MS documentation, it is not advisable in some cases to use CN={{DeviceId}} ( Use SCEP certificate profiles with Microsoft Intune | Microsoft Learn)

Thank you

For the Intune Extension you would need the Intune Device ID as CN in your certificate and where you 'blurred' in the extension logs, should appear the Intune Device ID.

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Did you configure synchronization to the Endpoint DB as well? And do you see the Endpoint Repository populated with Intune Attributes?

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

I have the same issue with newly installed devices.

My logs:
[2024-05-29T13:13:19.941] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:21.182] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:21.423] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:23.312] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:23.507] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:26.265] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.

I don't mind sharing the ID's because they don't exist in our tenant. Neither as Intune ID or Azure ID.
At this point I have no idea where the Intune extension got the ID for this query..

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Hi David,

is your Intune setup right?

ClearPass Intune error 404 seems like this:

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

I have the same issue with newly installed devices.

My logs:
[2024-05-29T13:13:19.941] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:21.182] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:21.423] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:23.312] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:23.507] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:26.265] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.

I don't mind sharing the ID's because they don't exist in our tenant. Neither as Intune ID or Azure ID.
At this point I have no idea where the Intune extension got the ID for this query..

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Hi Erik,

The connector work fine for our 4-5k other devices.
Only the freshly installed ones have issues and that's when I get to see this log in the connector (querying unknown ID's).

I've checked the Intune entries of these newly installed devices and it doesn't equal their Intune or Azure ID.
I've entered the ID to see which device it belongs to (Intune and Azure) but no hits either

Hi David,

is your Intune setup right?

ClearPass Intune error 404 seems like this:

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

I have the same issue with newly installed devices.

My logs:
[2024-05-29T13:13:19.941] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:21.182] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:21.423] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:23.312] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:23.507] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:26.265] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.

I don't mind sharing the ID's because they don't exist in our tenant. Neither as Intune ID or Azure ID.
At this point I have no idea where the Intune extension got the ID for this query..

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Looked up these fauly id's in the 'Endpoint' database in the ClearPass and found the devices, but the Intune ID that the database has, does not match the Intune ID in Intune.
Seems like the database for some reason has issues updating (certain) devices

Hi Erik,

The connector work fine for our 4-5k other devices.
Only the freshly installed ones have issues and that's when I get to see this log in the connector (querying unknown ID's).

I've checked the Intune entries of these newly installed devices and it doesn't equal their Intune or Azure ID.
I've entered the ID to see which device it belongs to (Intune and Azure) but no hits either

Hi David,

is your Intune setup right?

ClearPass Intune error 404 seems like this:

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

I have the same issue with newly installed devices.

My logs:
[2024-05-29T13:13:19.941] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:21.182] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:21.423] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:23.312] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:23.507] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:26.265] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.

I don't mind sharing the ID's because they don't exist in our tenant. Neither as Intune ID or Azure ID.
At this point I have no idea where the Intune extension got the ID for this query..

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

I assume you use the Intune Device ID from a field in the client certificate? If so, check in your certificate policy (Intune) what is put in that field, or else where the Intune Device ID is stored... If you see the 404 error for HTTP based lookup, that is independent on what is in the ClearPass Endpoint database. I would find out, and make sure that you have the correct IDs to work with.

Could it be that you have clients with certificates issued before you made changes to the certificate fields? By default the Entra ID device ID is included in the certificate, not the Intune Device ID.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 30, 2024 06:15 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Looked up these fauly id's in the 'Endpoint' database in the ClearPass and found the devices, but the Intune ID that the database has, does not match the Intune ID in Intune.
Seems like the database for some reason has issues updating (certain) devices

Original Message:
Sent: May 29, 2024 11:27 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi Erik,

The connector work fine for our 4-5k other devices.
Only the freshly installed ones have issues and that's when I get to see this log in the connector (querying unknown ID's).

I've checked the Intune entries of these newly installed devices and it doesn't equal their Intune or Azure ID.
I've entered the ID to see which device it belongs to (Intune and Azure) but no hits either

Original Message:
Sent: May 29, 2024 08:27 AM
From: erik.boss
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi David,

is your Intune setup right?

ClearPass Intune error 404 seems like this:

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Original Message:
Sent: May 29, 2024 07:47 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

I have the same issue with newly installed devices.

My logs:
[2024-05-29T13:13:19.941] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:21.182] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:21.423] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:23.312] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:23.507] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:26.265] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.

I don't mind sharing the ID's because they don't exist in our tenant. Neither as Intune ID or Azure ID.
At this point I have no idea where the Intune extension got the ID for this query..

Original Message:
Sent: Oct 26, 2023 04:16 PM
From: ahmetsarikaya
Subject: Clearpass intune : HTTP attribute query returned error=404

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Sorry it took a while to reply.

We do indeed use the Intune ID, as we use the Extension in combination with a HTTP authZ source, which needs to do lookup based on Intune Device ID. (ClearPass Integration Guide Microsoft InTune (hpe.com) page 24)

I checked the ClearPass Endpoint database and I can confirm that some devices are present with the wrong Intune ID.

I suspect a reinstall of the device causes this issue, though I'd expect the extension to update the information automatically?
I can't find any logs in the Intune extension (6.2.8) that point to an error updating the database.

The device was reinstalled yesterday and has been trying to connect ever since.

Any suggestions on why this happens (the info doesn't get updated)? - So I can figure out how this can be prevented

Original Message:
Sent: May 30, 2024 07:36 AM
From: Herman Robers
Subject: Clearpass intune : HTTP attribute query returned error=404

I assume you use the Intune Device ID from a field in the client certificate? If so, check in your certificate policy (Intune) what is put in that field, or else where the Intune Device ID is stored... If you see the 404 error for HTTP based lookup, that is independent on what is in the ClearPass Endpoint database. I would find out, and make sure that you have the correct IDs to work with.

Could it be that you have clients with certificates issued before you made changes to the certificate fields? By default the Entra ID device ID is included in the certificate, not the Intune Device ID.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 30, 2024 06:15 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Looked up these fauly id's in the 'Endpoint' database in the ClearPass and found the devices, but the Intune ID that the database has, does not match the Intune ID in Intune.
Seems like the database for some reason has issues updating (certain) devices

Original Message:
Sent: May 29, 2024 11:27 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi Erik,

The connector work fine for our 4-5k other devices.
Only the freshly installed ones have issues and that's when I get to see this log in the connector (querying unknown ID's).

I've checked the Intune entries of these newly installed devices and it doesn't equal their Intune or Azure ID.
I've entered the ID to see which device it belongs to (Intune and Azure) but no hits either

Original Message:
Sent: May 29, 2024 08:27 AM
From: erik.boss
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi David,

is your Intune setup right?

ClearPass Intune error 404 seems like this:

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Original Message:
Sent: May 29, 2024 07:47 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

I have the same issue with newly installed devices.

My logs:
[2024-05-29T13:13:19.941] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:21.182] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:21.423] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:23.312] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:23.507] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:26.265] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.

I don't mind sharing the ID's because they don't exist in our tenant. Neither as Intune ID or Azure ID.
At this point I have no idea where the Intune extension got the ID for this query..

Original Message:
Sent: Oct 26, 2023 04:16 PM
From: ahmetsarikaya
Subject: Clearpass intune : HTTP attribute query returned error=404

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

There is two ways for ClearPass to work with Intune data. One is using the Endpoint Repository, and the data synchronized in there, with the recommendation to query the endpoint database by Intune DeviceID (versus default query on client MAC address; which is deprecated). Second is via HTTP, which you seem to have configured, and does not use the endpoint database at all. It's a realtime query.

If you check the Device ID from the extension logs, can you find the same Device ID as intune Device ID in Intune? The 404 means (in most cases) that there is no device in Intune with the queried Intune Device ID. If you see a mismatch on the synced information in the endpoint database, are you sure that the value that you use is indeed the Intune Device ID? I believe by default in a SCEP request, the Entra ID (AAD) Device ID is used, which looks similar but is different. 

Sorry it took a while to reply.

We do indeed use the Intune ID, as we use the Extension in combination with a HTTP authZ source, which needs to do lookup based on Intune Device ID. (ClearPass Integration Guide Microsoft InTune (hpe.com) page 24)

I checked the ClearPass Endpoint database and I can confirm that some devices are present with the wrong Intune ID.

I suspect a reinstall of the device causes this issue, though I'd expect the extension to update the information automatically?
I can't find any logs in the Intune extension (6.2.8) that point to an error updating the database.

The device was reinstalled yesterday and has been trying to connect ever since.

Any suggestions on why this happens (the info doesn't get updated)? - So I can figure out how this can be prevented

Original Message:
Sent: May 30, 2024 07:36 AM
From: Herman Robers
Subject: Clearpass intune : HTTP attribute query returned error=404

I assume you use the Intune Device ID from a field in the client certificate? If so, check in your certificate policy (Intune) what is put in that field, or else where the Intune Device ID is stored... If you see the 404 error for HTTP based lookup, that is independent on what is in the ClearPass Endpoint database. I would find out, and make sure that you have the correct IDs to work with.

Could it be that you have clients with certificates issued before you made changes to the certificate fields? By default the Entra ID device ID is included in the certificate, not the Intune Device ID.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 30, 2024 06:15 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Looked up these fauly id's in the 'Endpoint' database in the ClearPass and found the devices, but the Intune ID that the database has, does not match the Intune ID in Intune.
Seems like the database for some reason has issues updating (certain) devices

Original Message:
Sent: May 29, 2024 11:27 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi Erik,

The connector work fine for our 4-5k other devices.
Only the freshly installed ones have issues and that's when I get to see this log in the connector (querying unknown ID's).

I've checked the Intune entries of these newly installed devices and it doesn't equal their Intune or Azure ID.
I've entered the ID to see which device it belongs to (Intune and Azure) but no hits either

Original Message:
Sent: May 29, 2024 08:27 AM
From: erik.boss
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi David,

is your Intune setup right?

ClearPass Intune error 404 seems like this:

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Original Message:
Sent: May 29, 2024 07:47 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

I have the same issue with newly installed devices.

My logs:
[2024-05-29T13:13:19.941] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:21.182] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:21.423] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:23.312] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:23.507] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:26.265] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.

I don't mind sharing the ID's because they don't exist in our tenant. Neither as Intune ID or Azure ID.
At this point I have no idea where the Intune extension got the ID for this query..

Original Message:
Sent: Oct 26, 2023 04:16 PM
From: ahmetsarikaya
Subject: Clearpass intune : HTTP attribute query returned error=404

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Hi - Sorry to dive in, but I have the same issue as everyone.

I see 404 messages in the intune extension, with messages such as:

Error searching by id 6677a546-5613-4577-aef5-a4f94ertert2c.  Request failed with status code 404

If I take '6677a546-5613-4577-aef5-a4f94ertert2c' and search Intune directly, the device is found immediately.

And to confirm, the Certificate: Subject-CN on the request reads the same.

The HTTP auth source is configured similarly, with %{Certificate:Subject-CN}

Therefore, what remains - API permissions ( or anything else?)

If API permissions, then could you please confirm the the exact permissions needed, as I believe I have everything correct, based upon the Oct 23 documentation, but maybe things have changed, since Microsoft like to do that.

Any pointers, things to try etc, would be very helpful! Thanks in advance.

There is two ways for ClearPass to work with Intune data. One is using the Endpoint Repository, and the data synchronized in there, with the recommendation to query the endpoint database by Intune DeviceID (versus default query on client MAC address; which is deprecated). Second is via HTTP, which you seem to have configured, and does not use the endpoint database at all. It's a realtime query.

If you check the Device ID from the extension logs, can you find the same Device ID as intune Device ID in Intune? The 404 means (in most cases) that there is no device in Intune with the queried Intune Device ID. If you see a mismatch on the synced information in the endpoint database, are you sure that the value that you use is indeed the Intune Device ID? I believe by default in a SCEP request, the Entra ID (AAD) Device ID is used, which looks similar but is different. 

Sorry it took a while to reply.

We do indeed use the Intune ID, as we use the Extension in combination with a HTTP authZ source, which needs to do lookup based on Intune Device ID. (ClearPass Integration Guide Microsoft InTune (hpe.com) page 24)

I checked the ClearPass Endpoint database and I can confirm that some devices are present with the wrong Intune ID.

I suspect a reinstall of the device causes this issue, though I'd expect the extension to update the information automatically?
I can't find any logs in the Intune extension (6.2.8) that point to an error updating the database.

The device was reinstalled yesterday and has been trying to connect ever since.

Any suggestions on why this happens (the info doesn't get updated)? - So I can figure out how this can be prevented

Original Message:
Sent: May 30, 2024 07:36 AM
From: Herman Robers
Subject: Clearpass intune : HTTP attribute query returned error=404

I assume you use the Intune Device ID from a field in the client certificate? If so, check in your certificate policy (Intune) what is put in that field, or else where the Intune Device ID is stored... If you see the 404 error for HTTP based lookup, that is independent on what is in the ClearPass Endpoint database. I would find out, and make sure that you have the correct IDs to work with.

Could it be that you have clients with certificates issued before you made changes to the certificate fields? By default the Entra ID device ID is included in the certificate, not the Intune Device ID.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 30, 2024 06:15 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Looked up these fauly id's in the 'Endpoint' database in the ClearPass and found the devices, but the Intune ID that the database has, does not match the Intune ID in Intune.
Seems like the database for some reason has issues updating (certain) devices

Original Message:
Sent: May 29, 2024 11:27 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi Erik,

The connector work fine for our 4-5k other devices.
Only the freshly installed ones have issues and that's when I get to see this log in the connector (querying unknown ID's).

I've checked the Intune entries of these newly installed devices and it doesn't equal their Intune or Azure ID.
I've entered the ID to see which device it belongs to (Intune and Azure) but no hits either

Original Message:
Sent: May 29, 2024 08:27 AM
From: erik.boss
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi David,

is your Intune setup right?

ClearPass Intune error 404 seems like this:

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Original Message:
Sent: May 29, 2024 07:47 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

I have the same issue with newly installed devices.

My logs:
[2024-05-29T13:13:19.941] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:21.182] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:21.423] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:23.312] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:23.507] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:26.265] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.

I don't mind sharing the ID's because they don't exist in our tenant. Neither as Intune ID or Azure ID.
At this point I have no idea where the Intune extension got the ID for this query..

Original Message:
Sent: Oct 26, 2023 04:16 PM
From: ahmetsarikaya
Subject: Clearpass intune : HTTP attribute query returned error=404

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

That Device ID looks invalid as it should be in UUID format which only has hexadecimal characters. There can't be an 'r' or 't' in it.

Here's my App registration API permissions for the Intune extension:

Hi - Sorry to dive in, but I have the same issue as everyone.

I see 404 messages in the intune extension, with messages such as:

Error searching by id 6677a546-5613-4577-aef5-a4f94ertert2c.  Request failed with status code 404

If I take '6677a546-5613-4577-aef5-a4f94ertert2c' and search Intune directly, the device is found immediately.

And to confirm, the Certificate: Subject-CN on the request reads the same.

The HTTP auth source is configured similarly, with %{Certificate:Subject-CN}

Therefore, what remains - API permissions ( or anything else?)

If API permissions, then could you please confirm the the exact permissions needed, as I believe I have everything correct, based upon the Oct 23 documentation, but maybe things have changed, since Microsoft like to do that.

Any pointers, things to try etc, would be very helpful! Thanks in advance.

There is two ways for ClearPass to work with Intune data. One is using the Endpoint Repository, and the data synchronized in there, with the recommendation to query the endpoint database by Intune DeviceID (versus default query on client MAC address; which is deprecated). Second is via HTTP, which you seem to have configured, and does not use the endpoint database at all. It's a realtime query.

If you check the Device ID from the extension logs, can you find the same Device ID as intune Device ID in Intune? The 404 means (in most cases) that there is no device in Intune with the queried Intune Device ID. If you see a mismatch on the synced information in the endpoint database, are you sure that the value that you use is indeed the Intune Device ID? I believe by default in a SCEP request, the Entra ID (AAD) Device ID is used, which looks similar but is different. 

Sorry it took a while to reply.

We do indeed use the Intune ID, as we use the Extension in combination with a HTTP authZ source, which needs to do lookup based on Intune Device ID. (ClearPass Integration Guide Microsoft InTune (hpe.com) page 24)

I checked the ClearPass Endpoint database and I can confirm that some devices are present with the wrong Intune ID.

I suspect a reinstall of the device causes this issue, though I'd expect the extension to update the information automatically?
I can't find any logs in the Intune extension (6.2.8) that point to an error updating the database.

The device was reinstalled yesterday and has been trying to connect ever since.

Any suggestions on why this happens (the info doesn't get updated)? - So I can figure out how this can be prevented

Original Message:
Sent: May 30, 2024 07:36 AM
From: Herman Robers
Subject: Clearpass intune : HTTP attribute query returned error=404

I assume you use the Intune Device ID from a field in the client certificate? If so, check in your certificate policy (Intune) what is put in that field, or else where the Intune Device ID is stored... If you see the 404 error for HTTP based lookup, that is independent on what is in the ClearPass Endpoint database. I would find out, and make sure that you have the correct IDs to work with.

Could it be that you have clients with certificates issued before you made changes to the certificate fields? By default the Entra ID device ID is included in the certificate, not the Intune Device ID.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 30, 2024 06:15 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Looked up these fauly id's in the 'Endpoint' database in the ClearPass and found the devices, but the Intune ID that the database has, does not match the Intune ID in Intune.
Seems like the database for some reason has issues updating (certain) devices

Original Message:
Sent: May 29, 2024 11:27 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi Erik,

The connector work fine for our 4-5k other devices.
Only the freshly installed ones have issues and that's when I get to see this log in the connector (querying unknown ID's).

I've checked the Intune entries of these newly installed devices and it doesn't equal their Intune or Azure ID.
I've entered the ID to see which device it belongs to (Intune and Azure) but no hits either

Original Message:
Sent: May 29, 2024 08:27 AM
From: erik.boss
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi David,

is your Intune setup right?

ClearPass Intune error 404 seems like this:

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Original Message:
Sent: May 29, 2024 07:47 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

I have the same issue with newly installed devices.

My logs:
[2024-05-29T13:13:19.941] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:21.182] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:21.423] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:23.312] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:23.507] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:26.265] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.

I don't mind sharing the ID's because they don't exist in our tenant. Neither as Intune ID or Azure ID.
At this point I have no idea where the Intune extension got the ID for this query..

Original Message:
Sent: Oct 26, 2023 04:16 PM
From: ahmetsarikaya
Subject: Clearpass intune : HTTP attribute query returned error=404

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Hi - I'm so sorry - I should have said that UUID was made up, as I didn't publish an original one - I just replaced some with random characters (I should have been more careful and replaced them with hex, rather than tapping the keyboard randomly). 

Thank you for the permission list though, mine are a little different, so i'll try those...

That Device ID looks invalid as it should be in UUID format which only has hexadecimal characters. There can't be an 'r' or 't' in it.

Here's my App registration API permissions for the Intune extension:

Hi - Sorry to dive in, but I have the same issue as everyone.

I see 404 messages in the intune extension, with messages such as:

Error searching by id 6677a546-5613-4577-aef5-a4f94ertert2c.  Request failed with status code 404

If I take '6677a546-5613-4577-aef5-a4f94ertert2c' and search Intune directly, the device is found immediately.

And to confirm, the Certificate: Subject-CN on the request reads the same.

The HTTP auth source is configured similarly, with %{Certificate:Subject-CN}

Therefore, what remains - API permissions ( or anything else?)

If API permissions, then could you please confirm the the exact permissions needed, as I believe I have everything correct, based upon the Oct 23 documentation, but maybe things have changed, since Microsoft like to do that.

Any pointers, things to try etc, would be very helpful! Thanks in advance.

There is two ways for ClearPass to work with Intune data. One is using the Endpoint Repository, and the data synchronized in there, with the recommendation to query the endpoint database by Intune DeviceID (versus default query on client MAC address; which is deprecated). Second is via HTTP, which you seem to have configured, and does not use the endpoint database at all. It's a realtime query.

If you check the Device ID from the extension logs, can you find the same Device ID as intune Device ID in Intune? The 404 means (in most cases) that there is no device in Intune with the queried Intune Device ID. If you see a mismatch on the synced information in the endpoint database, are you sure that the value that you use is indeed the Intune Device ID? I believe by default in a SCEP request, the Entra ID (AAD) Device ID is used, which looks similar but is different. 

Sorry it took a while to reply.

We do indeed use the Intune ID, as we use the Extension in combination with a HTTP authZ source, which needs to do lookup based on Intune Device ID. (ClearPass Integration Guide Microsoft InTune (hpe.com) page 24)

I checked the ClearPass Endpoint database and I can confirm that some devices are present with the wrong Intune ID.

I suspect a reinstall of the device causes this issue, though I'd expect the extension to update the information automatically?
I can't find any logs in the Intune extension (6.2.8) that point to an error updating the database.

The device was reinstalled yesterday and has been trying to connect ever since.

Any suggestions on why this happens (the info doesn't get updated)? - So I can figure out how this can be prevented

Original Message:
Sent: May 30, 2024 07:36 AM
From: Herman Robers
Subject: Clearpass intune : HTTP attribute query returned error=404

I assume you use the Intune Device ID from a field in the client certificate? If so, check in your certificate policy (Intune) what is put in that field, or else where the Intune Device ID is stored... If you see the 404 error for HTTP based lookup, that is independent on what is in the ClearPass Endpoint database. I would find out, and make sure that you have the correct IDs to work with.

Could it be that you have clients with certificates issued before you made changes to the certificate fields? By default the Entra ID device ID is included in the certificate, not the Intune Device ID.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 30, 2024 06:15 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Looked up these fauly id's in the 'Endpoint' database in the ClearPass and found the devices, but the Intune ID that the database has, does not match the Intune ID in Intune.
Seems like the database for some reason has issues updating (certain) devices

Original Message:
Sent: May 29, 2024 11:27 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi Erik,

The connector work fine for our 4-5k other devices.
Only the freshly installed ones have issues and that's when I get to see this log in the connector (querying unknown ID's).

I've checked the Intune entries of these newly installed devices and it doesn't equal their Intune or Azure ID.
I've entered the ID to see which device it belongs to (Intune and Azure) but no hits either

Original Message:
Sent: May 29, 2024 08:27 AM
From: erik.boss
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi David,

is your Intune setup right?

ClearPass Intune error 404 seems like this:

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Original Message:
Sent: May 29, 2024 07:47 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

I have the same issue with newly installed devices.

My logs:
[2024-05-29T13:13:19.941] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:21.182] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:21.423] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:23.312] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:23.507] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:26.265] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.

I don't mind sharing the ID's because they don't exist in our tenant. Neither as Intune ID or Azure ID.
At this point I have no idea where the Intune extension got the ID for this query..

Original Message:
Sent: Oct 26, 2023 04:16 PM
From: ahmetsarikaya
Subject: Clearpass intune : HTTP attribute query returned error=404

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping:

Hi - I fixed it from my side - an error which I found by reading the API documentation and finding an anomaly, but hopefully it helps someone else:

Microsoft allows API queries in several ways - for example:
GET /devices/{id}
GET /devices(deviceId='{deviceId}')
and:
GET /deviceManagement/managedDevices/{managedDeviceId} (see https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-get?view=graph-rest-1.0) for reference.

Clearpass uses the last one, managedDeviceId. This made me think - what is the difference between id, deviceId and managedDeviceId

Basically:
Id = Object ID in MS Azure, Entra 
DeviceId = Device ID in MS Azure, Entra , or Microsoft Entra Device ID in Microsoft Intune
managedDeviceId = Intune Device ID in Microsoft Intune

Essentially, make sure you use the 'Intune Device ID' in the cert, for %{Certificate:Subject-CN} 

Hope that was clear and helped someone.

Original Message:
Sent: Aug 23, 2024 04:38 AM
From: DarrellH
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi - I'm so sorry - I should have said that UUID was made up, as I didn't publish an original one - I just replaced some with random characters (I should have been more careful and replaced them with hex, rather than tapping the keyboard randomly). 

Thank you for the permission list though, mine are a little different, so i'll try those...

Original Message:
Sent: Aug 23, 2024 03:58 AM
From: Herman Robers
Subject: Clearpass intune : HTTP attribute query returned error=404

That Device ID looks invalid as it should be in UUID format which only has hexadecimal characters. There can't be an 'r' or 't' in it.

Here's my App registration API permissions for the Intune extension:

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: Aug 22, 2024 10:25 AM
From: DarrellH
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi - Sorry to dive in, but I have the same issue as everyone.

I see 404 messages in the intune extension, with messages such as:

Error searching by id 6677a546-5613-4577-aef5-a4f94ertert2c.  Request failed with status code 404

If I take '6677a546-5613-4577-aef5-a4f94ertert2c' and search Intune directly, the device is found immediately.

And to confirm, the Certificate: Subject-CN on the request reads the same.

The HTTP auth source is configured similarly, with %{Certificate:Subject-CN}

Therefore, what remains - API permissions ( or anything else?)

If API permissions, then could you please confirm the the exact permissions needed, as I believe I have everything correct, based upon the Oct 23 documentation, but maybe things have changed, since Microsoft like to do that.

Any pointers, things to try etc, would be very helpful! Thanks in advance.

Original Message:
Sent: Jun 24, 2024 08:26 AM
From: Herman Robers
Subject: Clearpass intune : HTTP attribute query returned error=404

There is two ways for ClearPass to work with Intune data. One is using the Endpoint Repository, and the data synchronized in there, with the recommendation to query the endpoint database by Intune DeviceID (versus default query on client MAC address; which is deprecated). Second is via HTTP, which you seem to have configured, and does not use the endpoint database at all. It's a realtime query.

If you check the Device ID from the extension logs, can you find the same Device ID as intune Device ID in Intune? The 404 means (in most cases) that there is no device in Intune with the queried Intune Device ID. If you see a mismatch on the synced information in the endpoint database, are you sure that the value that you use is indeed the Intune Device ID? I believe by default in a SCEP request, the Entra ID (AAD) Device ID is used, which looks similar but is different. 

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: Jun 19, 2024 06:14 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Sorry it took a while to reply.

We do indeed use the Intune ID, as we use the Extension in combination with a HTTP authZ source, which needs to do lookup based on Intune Device ID. (ClearPass Integration Guide Microsoft InTune (hpe.com) page 24)

I checked the ClearPass Endpoint database and I can confirm that some devices are present with the wrong Intune ID.

I suspect a reinstall of the device causes this issue, though I'd expect the extension to update the information automatically?
I can't find any logs in the Intune extension (6.2.8) that point to an error updating the database.

The device was reinstalled yesterday and has been trying to connect ever since.

Any suggestions on why this happens (the info doesn't get updated)? - So I can figure out how this can be prevented

Original Message:
Sent: May 30, 2024 07:36 AM
From: Herman Robers
Subject: Clearpass intune : HTTP attribute query returned error=404

I assume you use the Intune Device ID from a field in the client certificate? If so, check in your certificate policy (Intune) what is put in that field, or else where the Intune Device ID is stored... If you see the 404 error for HTTP based lookup, that is independent on what is in the ClearPass Endpoint database. I would find out, and make sure that you have the correct IDs to work with.

Could it be that you have clients with certificates issued before you made changes to the certificate fields? By default the Entra ID device ID is included in the certificate, not the Intune Device ID.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 30, 2024 06:15 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Looked up these fauly id's in the 'Endpoint' database in the ClearPass and found the devices, but the Intune ID that the database has, does not match the Intune ID in Intune.
Seems like the database for some reason has issues updating (certain) devices

Original Message:
Sent: May 29, 2024 11:27 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi Erik,

The connector work fine for our 4-5k other devices.
Only the freshly installed ones have issues and that's when I get to see this log in the connector (querying unknown ID's).

I've checked the Intune entries of these newly installed devices and it doesn't equal their Intune or Azure ID.
I've entered the ID to see which device it belongs to (Intune and Azure) but no hits either

Original Message:
Sent: May 29, 2024 08:27 AM
From: erik.boss
Subject: Clearpass intune : HTTP attribute query returned error=404

Hi David,

is your Intune setup right?

ClearPass Intune error 404 seems like this:

The 404 error suggests that the ID queried in Intune is not the Intune Device ID, or the device is not in the same Intune Instance, or the API permissions are not properly setup in Entra ID.

Original Message:
Sent: May 29, 2024 07:47 AM
From: DavidB
Subject: Clearpass intune : HTTP attribute query returned error=404

I have the same issue with newly installed devices.

My logs:
[2024-05-29T13:13:19.941] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:21.182] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:21.423] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:23.312] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.
[2024-05-29T13:13:23.507] [ERROR] Intune - Error searching by id 46aed026-f652-43c1-996d-b9485a835a77.  Request failed with status code 404
[2024-05-29T13:13:26.265] [INFO] Intune - [46aed026-f652-43c1-996d-b9485a835a77] Request for information received from ::ffff:172.17.0.1.

I don't mind sharing the ID's because they don't exist in our tenant. Neither as Intune ID or Azure ID.
At this point I have no idea where the Intune extension got the ID for this query..

Original Message:
Sent: Oct 26, 2023 04:16 PM
From: ahmetsarikaya
Subject: Clearpass intune : HTTP attribute query returned error=404

We currently have an on prem AD that we check based on a computer certificate. We are now working on doing this with Intune devices based on EAP TLS. We use 1 root CA under which the local ad and intune users receive their certificate from another "issuing". Now we get the error 404 back.

We are using the following authentication source:

If we do not use role mappings, authentication works, even though we get the same error message. Is this more because clearpass knows our certificate. However, we want to make a distinction here with the following role mapping: