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: