Security

I have been testing the new Intune Extension 6.3 and strong mapping additions.

I have a problem with Authorization requests done to the Intune Extension, where if I use "%{Certificate:Subject-AltName-URI}" as a filter it stops working, presumably because this field is now a multivalue entry. I have tried a few variations on the filter and the base URL trying to specify I want to use the "deviceid" variable, but with no luck. I tried while specifying the "deviceid:" prefix and without including it in my certificates, with no difference. Authentication works fine in all cases.

Also, I noticed this morning the extension version 6.3.5 has been released, and tested with that (I was using 6.3.3 initially). Are there release notes available for 6.3.5?

I have been testing the new Intune Extension 6.3 and strong mapping additions.

I have a problem with Authorization requests done to the Intune Extension, where if I use "%{Certificate:Subject-AltName-URI}" as a filter it stops working, presumably because this field is now a multivalue entry. I have tried a few variations on the filter and the base URL trying to specify I want to use the "deviceid" variable, but with no luck. I tried while specifying the "deviceid:" prefix and without including it in my certificates, with no difference. Authentication works fine in all cases.

Also, I noticed this morning the extension version 6.3.5 has been released, and tested with that (I was using 6.3.3 initially). Are there release notes available for 6.3.5?

Please forget about any PDF for the documentation, most recent documentation on the ClearPass Intune Extension is here.

That SAN parsing is something different than strong mapping, but it was released in the same extension update so may be confusing.

I found that before 6.3.5, you should only have the following SAN-URI attributes: AAD_Device_ID // DeviceId // UserPrincipalName // tag
where the attribute names must match case-sensitive. If you have any additional attributes, or one with a case mismatch (like deviceid), the extraction of the attributes did not work.

The issue that if any SAN-URI value does not match a known attribute, seems to be addressed in the 6.3.5 extension that you found (I wasn't aware, so thank you for bringing that to my attention). 

Here is an example of a certificate that works in my lab (with the 6.3.3 version and just tested with 6.3.5 as well):

So, make sure the attribute is DeviceId (not deviceid or DeviceID), and I would upgrade to the 6.3.5 if you are now on 6.3.3.

------------------------------
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: Nov 11, 2024 09:05 AM
From: jfasselin
Subject: ClearPass Intune Extension strong mapping issue

I have been testing the new Intune Extension 6.3 and strong mapping additions.

I have a problem with Authorization requests done to the Intune Extension, where if I use "%{Certificate:Subject-AltName-URI}" as a filter it stops working, presumably because this field is now a multivalue entry. I have tried a few variations on the filter and the base URL trying to specify I want to use the "deviceid" variable, but with no luck. I tried while specifying the "deviceid:" prefix and without including it in my certificates, with no difference. Authentication works fine in all cases.

Also, I noticed this morning the extension version 6.3.5 has been released, and tested with that (I was using 6.3.3 initially). Are there release notes available for 6.3.5?

I have double-checked that the DeviceId field is set with the correct case in my certs. I also had upgraded to 6.3.5 previously.

Still, my HTTP authorization request to the extension fails if I use "%{Certificate:Subject-AltName-URI}".

Please forget about any PDF for the documentation, most recent documentation on the ClearPass Intune Extension is here.

That SAN parsing is something different than strong mapping, but it was released in the same extension update so may be confusing.

I found that before 6.3.5, you should only have the following SAN-URI attributes: AAD_Device_ID // DeviceId // UserPrincipalName // tag
where the attribute names must match case-sensitive. If you have any additional attributes, or one with a case mismatch (like deviceid), the extraction of the attributes did not work.

The issue that if any SAN-URI value does not match a known attribute, seems to be addressed in the 6.3.5 extension that you found (I wasn't aware, so thank you for bringing that to my attention). 

Here is an example of a certificate that works in my lab (with the 6.3.3 version and just tested with 6.3.5 as well):

So, make sure the attribute is DeviceId (not deviceid or DeviceID), and I would upgrade to the 6.3.5 if you are now on 6.3.3.

------------------------------
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: Nov 11, 2024 09:05 AM
From: jfasselin
Subject: ClearPass Intune Extension strong mapping issue

I have been testing the new Intune Extension 6.3 and strong mapping additions.

I have a problem with Authorization requests done to the Intune Extension, where if I use "%{Certificate:Subject-AltName-URI}" as a filter it stops working, presumably because this field is now a multivalue entry. I have tried a few variations on the filter and the base URL trying to specify I want to use the "deviceid" variable, but with no luck. I tried while specifying the "deviceid:" prefix and without including it in my certificates, with no difference. Authentication works fine in all cases.

Also, I noticed this morning the extension version 6.3.5 has been released, and tested with that (I was using 6.3.3 initially). Are there release notes available for 6.3.5?

Please forget about any PDF for the documentation, most recent documentation on the ClearPass Intune Extension is here.

That SAN parsing is something different than strong mapping, but it was released in the same extension update so may be confusing.

I found that before 6.3.5, you should only have the following SAN-URI attributes: AAD_Device_ID // DeviceId // UserPrincipalName // tag
where the attribute names must match case-sensitive. If you have any additional attributes, or one with a case mismatch (like deviceid), the extraction of the attributes did not work.

The issue that if any SAN-URI value does not match a known attribute, seems to be addressed in the 6.3.5 extension that you found (I wasn't aware, so thank you for bringing that to my attention). 

Here is an example of a certificate that works in my lab (with the 6.3.3 version and just tested with 6.3.5 as well):

So, make sure the attribute is DeviceId (not deviceid or DeviceID), and I would upgrade to the 6.3.5 if you are now on 6.3.3.

------------------------------
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: Nov 11, 2024 09:05 AM
From: jfasselin
Subject: ClearPass Intune Extension strong mapping issue

I have been testing the new Intune Extension 6.3 and strong mapping additions.

I have a problem with Authorization requests done to the Intune Extension, where if I use "%{Certificate:Subject-AltName-URI}" as a filter it stops working, presumably because this field is now a multivalue entry. I have tried a few variations on the filter and the base URL trying to specify I want to use the "deviceid" variable, but with no luck. I tried while specifying the "deviceid:" prefix and without including it in my certificates, with no difference. Authentication works fine in all cases.

Also, I noticed this morning the extension version 6.3.5 has been released, and tested with that (I was using 6.3.3 initially). Are there release notes available for 6.3.5?

Thanks Herman.

I am running 6.3.5 with CPP 6.12.3 and seeing 404 errors when trying to use the HTTP method. 

I notice that the guide suggests using %{Certificate:Subject-AltName-URI} but for some reason it is coming through unparsed in the connection logs as lowercase -  Request Details/Input/Computed Attributes: Certificate:Subject-AltName-URI = intunedeviceid://<guid>

I have checked the device and the cert is also coming through as lowercase even though the SCEP template (using Microsoft PKI) that it is showing as, Attribute:URI, Value:IntuneDeviceId://{{DeviceId}}

Is case going to be an issue and therefore do I need to resolve this between Intune and the device?

Please forget about any PDF for the documentation, most recent documentation on the ClearPass Intune Extension is here.

That SAN parsing is something different than strong mapping, but it was released in the same extension update so may be confusing.

I found that before 6.3.5, you should only have the following SAN-URI attributes: AAD_Device_ID // DeviceId // UserPrincipalName // tag
where the attribute names must match case-sensitive. If you have any additional attributes, or one with a case mismatch (like deviceid), the extraction of the attributes did not work.

The issue that if any SAN-URI value does not match a known attribute, seems to be addressed in the 6.3.5 extension that you found (I wasn't aware, so thank you for bringing that to my attention). 

Here is an example of a certificate that works in my lab (with the 6.3.3 version and just tested with 6.3.5 as well):

So, make sure the attribute is DeviceId (not deviceid or DeviceID), and I would upgrade to the 6.3.5 if you are now on 6.3.3.

------------------------------
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: Nov 11, 2024 09:05 AM
From: jfasselin
Subject: ClearPass Intune Extension strong mapping issue

I have been testing the new Intune Extension 6.3 and strong mapping additions.

I have a problem with Authorization requests done to the Intune Extension, where if I use "%{Certificate:Subject-AltName-URI}" as a filter it stops working, presumably because this field is now a multivalue entry. I have tried a few variations on the filter and the base URL trying to specify I want to use the "deviceid" variable, but with no luck. I tried while specifying the "deviceid:" prefix and without including it in my certificates, with no difference. Authentication works fine in all cases.

Also, I noticed this morning the extension version 6.3.5 has been released, and tested with that (I was using 6.3.3 initially). Are there release notes available for 6.3.5?

The SAN for the Intune DeviceId should be URL=> DeviceId:aabbcc-ddffgg-the-uuid. Looks you have intunedeviceid instead of DeviceId, and you included //.

Please check the screenshots and documentation above. The SAN URI attribute is fixed and needs to be an exact match (case-sensitive). Hopefully you can change the SCEP Enrollment Profile to match (or even include an additional SAN URI DeviceId:<uuid> would work).

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

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: Feb 24, 2025 06:45 PM
From: BrendanMYS
Subject: ClearPass Intune Extension strong mapping issue

Thanks Herman.

I am running 6.3.5 with CPP 6.12.3 and seeing 404 errors when trying to use the HTTP method. 

I notice that the guide suggests using %{Certificate:Subject-AltName-URI} but for some reason it is coming through unparsed in the connection logs as lowercase -  Request Details/Input/Computed Attributes: Certificate:Subject-AltName-URI = intunedeviceid://<guid>

I have checked the device and the cert is also coming through as lowercase even though the SCEP template (using Microsoft PKI) that it is showing as, Attribute:URI, Value:IntuneDeviceId://{{DeviceId}}

Is case going to be an issue and therefore do I need to resolve this between Intune and the device?

Original Message:
Sent: Nov 13, 2024 10:32 AM
From: Herman Robers
Subject: ClearPass Intune Extension strong mapping issue

Please forget about any PDF for the documentation, most recent documentation on the ClearPass Intune Extension is here.

That SAN parsing is something different than strong mapping, but it was released in the same extension update so may be confusing.

I found that before 6.3.5, you should only have the following SAN-URI attributes: AAD_Device_ID // DeviceId // UserPrincipalName // tag
where the attribute names must match case-sensitive. If you have any additional attributes, or one with a case mismatch (like deviceid), the extraction of the attributes did not work.

The issue that if any SAN-URI value does not match a known attribute, seems to be addressed in the 6.3.5 extension that you found (I wasn't aware, so thank you for bringing that to my attention). 

Here is an example of a certificate that works in my lab (with the 6.3.3 version and just tested with 6.3.5 as well):

So, make sure the attribute is DeviceId (not deviceid or DeviceID), and I would upgrade to the 6.3.5 if you are now on 6.3.3.

------------------------------
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: Nov 11, 2024 09:05 AM
From: jfasselin
Subject: ClearPass Intune Extension strong mapping issue

I have been testing the new Intune Extension 6.3 and strong mapping additions.

I have a problem with Authorization requests done to the Intune Extension, where if I use "%{Certificate:Subject-AltName-URI}" as a filter it stops working, presumably because this field is now a multivalue entry. I have tried a few variations on the filter and the base URL trying to specify I want to use the "deviceid" variable, but with no luck. I tried while specifying the "deviceid:" prefix and without including it in my certificates, with no difference. Authentication works fine in all cases.

Also, I noticed this morning the extension version 6.3.5 has been released, and tested with that (I was using 6.3.3 initially). Are there release notes available for 6.3.5?

Thanks Herman.

I've changed the SCEP SAN URI value to DeviceId:{{DeviceId}} and although the values still came through to the client cert with lowercase at least the trailing forward slash was removed.

The extension seemed to accept it, although instead of a 404 I instead got errors that the attributes are not found. I wonder if I'm missing some parts that are not mentioned in the v6 extension guide.

Connection log:
2025-02-27 12:56:56,503    [HttpModule-ThreadPool-2-0x7f8507dfe700 r=R0000033b-01-67bfc667 h=73] ERROR Http.HttpAutzSession - Failed to get value for attributes=Intune Azure AD Device Id, Intune Compliance State, Intune Device Name]

And after turning on DEBUG level logging for the extension I see this as well:{"AAD_Device_ID":null,"DeviceId":null,"UserPrincipalName":null,"tag":null,"standaloneValue":"deviceid:<guid>"}

This is on a vanilla Clearpass 6.12 other than what I am trying to get working here so all defaults other than:

service : type:Aruba 802.1X Wireless type, authorization (checked)

authentication: methods: EAP TLS With CN Check, sources: Endpoints Repository

authorization: sources: Microsoft Intune[HTTP]

rolemapping: Endpoint:

Source EQUALS Intune AND, Endpoint:Intune Compliance State EQUALS compliant AND, Endpoint Intune Device Enrollment Type EQUALS windowsAzureADJoin -> entra_machine_role

Enforcement: Tips:Role EQUALs entra_machine_role -> Corp_VLAN_enforcementprofile

The HTTP Intune source is:

Base URL:    http://172.17.0.2/device/info/id/

Authorization sources: (none)

Use for authorization: (checked)

Filters :    1. %{Certificate:Subject-AltName-URI}

Attributes: (Name / Alias Name / Data type / Enabled As)

Intune Device Name / Intune Device Name / String / Role, Attribute

Intune Azure AD Device Id / Intune Azure AD Device Id / String / Attribute

Intune Is Encrypted / Intune Is Encrypted / String / -

Intune Compliance State / Intune Compliance State / String / Attribute

[The reason I had IntuneDeviceID:=//{{DeviceID}} value in the SAN URI is that the latest version of the Microsoft Intune Integration Guide (2023-01 Oct 2023) Appendix E for the SCEP template lists it (Page 50 of the PDF). Can you please ask that all these misleading older bits of information be updated? It causes so much wasted time. There's also conflicting info in there after the v6 behaviour change info - about MAC auth and a few other things. ]

Original Message:
Sent: Feb 25, 2025 06:27 AM
From: Herman Robers
Subject: ClearPass Intune Extension strong mapping issue

The SAN for the Intune DeviceId should be URL=> DeviceId:aabbcc-ddffgg-the-uuid. Looks you have intunedeviceid instead of DeviceId, and you included //.

Please check the screenshots and documentation above. The SAN URI attribute is fixed and needs to be an exact match (case-sensitive). Hopefully you can change the SCEP Enrollment Profile to match (or even include an additional SAN URI DeviceId:<uuid> would work).

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

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: Feb 24, 2025 06:45 PM
From: BrendanMYS
Subject: ClearPass Intune Extension strong mapping issue

Thanks Herman.

I am running 6.3.5 with CPP 6.12.3 and seeing 404 errors when trying to use the HTTP method. 

I notice that the guide suggests using %{Certificate:Subject-AltName-URI} but for some reason it is coming through unparsed in the connection logs as lowercase -  Request Details/Input/Computed Attributes: Certificate:Subject-AltName-URI = intunedeviceid://<guid>

I have checked the device and the cert is also coming through as lowercase even though the SCEP template (using Microsoft PKI) that it is showing as, Attribute:URI, Value:IntuneDeviceId://{{DeviceId}}

Is case going to be an issue and therefore do I need to resolve this between Intune and the device?

Original Message:
Sent: Nov 13, 2024 10:32 AM
From: Herman Robers
Subject: ClearPass Intune Extension strong mapping issue

Please forget about any PDF for the documentation, most recent documentation on the ClearPass Intune Extension is here.

That SAN parsing is something different than strong mapping, but it was released in the same extension update so may be confusing.

I found that before 6.3.5, you should only have the following SAN-URI attributes: AAD_Device_ID // DeviceId // UserPrincipalName // tag
where the attribute names must match case-sensitive. If you have any additional attributes, or one with a case mismatch (like deviceid), the extraction of the attributes did not work.

The issue that if any SAN-URI value does not match a known attribute, seems to be addressed in the 6.3.5 extension that you found (I wasn't aware, so thank you for bringing that to my attention). 

Here is an example of a certificate that works in my lab (with the 6.3.3 version and just tested with 6.3.5 as well):

So, make sure the attribute is DeviceId (not deviceid or DeviceID), and I would upgrade to the 6.3.5 if you are now on 6.3.3.

------------------------------
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: Nov 11, 2024 09:05 AM
From: jfasselin
Subject: ClearPass Intune Extension strong mapping issue

I have been testing the new Intune Extension 6.3 and strong mapping additions.

I have a problem with Authorization requests done to the Intune Extension, where if I use "%{Certificate:Subject-AltName-URI}" as a filter it stops working, presumably because this field is now a multivalue entry. I have tried a few variations on the filter and the base URL trying to specify I want to use the "deviceid" variable, but with no luck. I tried while specifying the "deviceid:" prefix and without including it in my certificates, with no difference. Authentication works fine in all cases.

Also, I noticed this morning the extension version 6.3.5 has been released, and tested with that (I was using 6.3.3 initially). Are there release notes available for 6.3.5?

Did you verify that the certificate used has been actutally replaced, and you see the proper SAN-URI in access tracker? According to the DEBUG message, it seems that ClearPass could not properly extract the UUID from the Certificate:Subject-AltName-URI; also doublecheck that you did not make a typo in that one, where you would see replacement errors in the log detail of from Access Tracker.

Think there is a small typo somewhere, and you are close to the solution. Sometimes it helps to go through all with someone else (who has knowledge on this topic).

Thanks Herman.

I've changed the SCEP SAN URI value to DeviceId:{{DeviceId}} and although the values still came through to the client cert with lowercase at least the trailing forward slash was removed.

The extension seemed to accept it, although instead of a 404 I instead got errors that the attributes are not found. I wonder if I'm missing some parts that are not mentioned in the v6 extension guide.

Connection log:
2025-02-27 12:56:56,503    [HttpModule-ThreadPool-2-0x7f8507dfe700 r=R0000033b-01-67bfc667 h=73] ERROR Http.HttpAutzSession - Failed to get value for attributes=Intune Azure AD Device Id, Intune Compliance State, Intune Device Name]

And after turning on DEBUG level logging for the extension I see this as well:{"AAD_Device_ID":null,"DeviceId":null,"UserPrincipalName":null,"tag":null,"standaloneValue":"deviceid:<guid>"}

This is on a vanilla Clearpass 6.12 other than what I am trying to get working here so all defaults other than:

service : type:Aruba 802.1X Wireless type, authorization (checked)

authentication: methods: EAP TLS With CN Check, sources: Endpoints Repository

authorization: sources: Microsoft Intune[HTTP]

rolemapping: Endpoint:

Source EQUALS Intune AND, Endpoint:Intune Compliance State EQUALS compliant AND, Endpoint Intune Device Enrollment Type EQUALS windowsAzureADJoin -> entra_machine_role

Enforcement: Tips:Role EQUALs entra_machine_role -> Corp_VLAN_enforcementprofile

The HTTP Intune source is:

Base URL:    http://172.17.0.2/device/info/id/

Authorization sources: (none)

Use for authorization: (checked)

Filters :    1. %{Certificate:Subject-AltName-URI}

Attributes: (Name / Alias Name / Data type / Enabled As)

Intune Device Name / Intune Device Name / String / Role, Attribute

Intune Azure AD Device Id / Intune Azure AD Device Id / String / Attribute

Intune Is Encrypted / Intune Is Encrypted / String / -

Intune Compliance State / Intune Compliance State / String / Attribute

[The reason I had IntuneDeviceID:=//{{DeviceID}} value in the SAN URI is that the latest version of the Microsoft Intune Integration Guide (2023-01 Oct 2023) Appendix E for the SCEP template lists it (Page 50 of the PDF). Can you please ask that all these misleading older bits of information be updated? It causes so much wasted time. There's also conflicting info in there after the v6 behaviour change info - about MAC auth and a few other things. ]

Original Message:
Sent: Feb 25, 2025 06:27 AM
From: Herman Robers
Subject: ClearPass Intune Extension strong mapping issue

The SAN for the Intune DeviceId should be URL=> DeviceId:aabbcc-ddffgg-the-uuid. Looks you have intunedeviceid instead of DeviceId, and you included //.

Please check the screenshots and documentation above. The SAN URI attribute is fixed and needs to be an exact match (case-sensitive). Hopefully you can change the SCEP Enrollment Profile to match (or even include an additional SAN URI DeviceId:<uuid> would work).

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

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: Feb 24, 2025 06:45 PM
From: BrendanMYS
Subject: ClearPass Intune Extension strong mapping issue

Thanks Herman.

I am running 6.3.5 with CPP 6.12.3 and seeing 404 errors when trying to use the HTTP method. 

I notice that the guide suggests using %{Certificate:Subject-AltName-URI} but for some reason it is coming through unparsed in the connection logs as lowercase -  Request Details/Input/Computed Attributes: Certificate:Subject-AltName-URI = intunedeviceid://<guid>

I have checked the device and the cert is also coming through as lowercase even though the SCEP template (using Microsoft PKI) that it is showing as, Attribute:URI, Value:IntuneDeviceId://{{DeviceId}}

Is case going to be an issue and therefore do I need to resolve this between Intune and the device?

Original Message:
Sent: Nov 13, 2024 10:32 AM
From: Herman Robers
Subject: ClearPass Intune Extension strong mapping issue

Please forget about any PDF for the documentation, most recent documentation on the ClearPass Intune Extension is here.

That SAN parsing is something different than strong mapping, but it was released in the same extension update so may be confusing.

I found that before 6.3.5, you should only have the following SAN-URI attributes: AAD_Device_ID // DeviceId // UserPrincipalName // tag
where the attribute names must match case-sensitive. If you have any additional attributes, or one with a case mismatch (like deviceid), the extraction of the attributes did not work.

The issue that if any SAN-URI value does not match a known attribute, seems to be addressed in the 6.3.5 extension that you found (I wasn't aware, so thank you for bringing that to my attention). 

Here is an example of a certificate that works in my lab (with the 6.3.3 version and just tested with 6.3.5 as well):

So, make sure the attribute is DeviceId (not deviceid or DeviceID), and I would upgrade to the 6.3.5 if you are now on 6.3.3.

------------------------------
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: Nov 11, 2024 09:05 AM
From: jfasselin
Subject: ClearPass Intune Extension strong mapping issue

I have been testing the new Intune Extension 6.3 and strong mapping additions.

I have a problem with Authorization requests done to the Intune Extension, where if I use "%{Certificate:Subject-AltName-URI}" as a filter it stops working, presumably because this field is now a multivalue entry. I have tried a few variations on the filter and the base URL trying to specify I want to use the "deviceid" variable, but with no luck. I tried while specifying the "deviceid:" prefix and without including it in my certificates, with no difference. Authentication works fine in all cases.

Also, I noticed this morning the extension version 6.3.5 has been released, and tested with that (I was using 6.3.3 initially). Are there release notes available for 6.3.5?

Hi Herman,

As Brendan did, we also used the value  IntuneDeviceID:=//{{DeviceID}} in the SAN URI.

Now this certificate is pushed to all users. Isn't there a way we can alter the authentication source filter so the {{DeviceID}} is filtered out?

Thanks in advance.

Turan

Did you verify that the certificate used has been actutally replaced, and you see the proper SAN-URI in access tracker? According to the DEBUG message, it seems that ClearPass could not properly extract the UUID from the Certificate:Subject-AltName-URI; also doublecheck that you did not make a typo in that one, where you would see replacement errors in the log detail of from Access Tracker.

Think there is a small typo somewhere, and you are close to the solution. Sometimes it helps to go through all with someone else (who has knowledge on this topic).

Thanks Herman.

I've changed the SCEP SAN URI value to DeviceId:{{DeviceId}} and although the values still came through to the client cert with lowercase at least the trailing forward slash was removed.

The extension seemed to accept it, although instead of a 404 I instead got errors that the attributes are not found. I wonder if I'm missing some parts that are not mentioned in the v6 extension guide.

Connection log:
2025-02-27 12:56:56,503    [HttpModule-ThreadPool-2-0x7f8507dfe700 r=R0000033b-01-67bfc667 h=73] ERROR Http.HttpAutzSession - Failed to get value for attributes=Intune Azure AD Device Id, Intune Compliance State, Intune Device Name]

And after turning on DEBUG level logging for the extension I see this as well:{"AAD_Device_ID":null,"DeviceId":null,"UserPrincipalName":null,"tag":null,"standaloneValue":"deviceid:<guid>"}

This is on a vanilla Clearpass 6.12 other than what I am trying to get working here so all defaults other than:

service : type:Aruba 802.1X Wireless type, authorization (checked)

authentication: methods: EAP TLS With CN Check, sources: Endpoints Repository

authorization: sources: Microsoft Intune[HTTP]

rolemapping: Endpoint:

Source EQUALS Intune AND, Endpoint:Intune Compliance State EQUALS compliant AND, Endpoint Intune Device Enrollment Type EQUALS windowsAzureADJoin -> entra_machine_role

Enforcement: Tips:Role EQUALs entra_machine_role -> Corp_VLAN_enforcementprofile

The HTTP Intune source is:

Base URL:    http://172.17.0.2/device/info/id/

Authorization sources: (none)

Use for authorization: (checked)

Filters :    1. %{Certificate:Subject-AltName-URI}

Attributes: (Name / Alias Name / Data type / Enabled As)

Intune Device Name / Intune Device Name / String / Role, Attribute

Intune Azure AD Device Id / Intune Azure AD Device Id / String / Attribute

Intune Is Encrypted / Intune Is Encrypted / String / -

Intune Compliance State / Intune Compliance State / String / Attribute

[The reason I had IntuneDeviceID:=//{{DeviceID}} value in the SAN URI is that the latest version of the Microsoft Intune Integration Guide (2023-01 Oct 2023) Appendix E for the SCEP template lists it (Page 50 of the PDF). Can you please ask that all these misleading older bits of information be updated? It causes so much wasted time. There's also conflicting info in there after the v6 behaviour change info - about MAC auth and a few other things. ]

Original Message:
Sent: Feb 25, 2025 06:27 AM
From: Herman Robers
Subject: ClearPass Intune Extension strong mapping issue

The SAN for the Intune DeviceId should be URL=> DeviceId:aabbcc-ddffgg-the-uuid. Looks you have intunedeviceid instead of DeviceId, and you included //.

Please check the screenshots and documentation above. The SAN URI attribute is fixed and needs to be an exact match (case-sensitive). Hopefully you can change the SCEP Enrollment Profile to match (or even include an additional SAN URI DeviceId:<uuid> would work).

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

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: Feb 24, 2025 06:45 PM
From: BrendanMYS
Subject: ClearPass Intune Extension strong mapping issue

Thanks Herman.

I am running 6.3.5 with CPP 6.12.3 and seeing 404 errors when trying to use the HTTP method. 

I notice that the guide suggests using %{Certificate:Subject-AltName-URI} but for some reason it is coming through unparsed in the connection logs as lowercase -  Request Details/Input/Computed Attributes: Certificate:Subject-AltName-URI = intunedeviceid://<guid>

I have checked the device and the cert is also coming through as lowercase even though the SCEP template (using Microsoft PKI) that it is showing as, Attribute:URI, Value:IntuneDeviceId://{{DeviceId}}

Is case going to be an issue and therefore do I need to resolve this between Intune and the device?

Original Message:
Sent: Nov 13, 2024 10:32 AM
From: Herman Robers
Subject: ClearPass Intune Extension strong mapping issue

Please forget about any PDF for the documentation, most recent documentation on the ClearPass Intune Extension is here.

That SAN parsing is something different than strong mapping, but it was released in the same extension update so may be confusing.

I found that before 6.3.5, you should only have the following SAN-URI attributes: AAD_Device_ID // DeviceId // UserPrincipalName // tag
where the attribute names must match case-sensitive. If you have any additional attributes, or one with a case mismatch (like deviceid), the extraction of the attributes did not work.

The issue that if any SAN-URI value does not match a known attribute, seems to be addressed in the 6.3.5 extension that you found (I wasn't aware, so thank you for bringing that to my attention). 

Here is an example of a certificate that works in my lab (with the 6.3.3 version and just tested with 6.3.5 as well):

So, make sure the attribute is DeviceId (not deviceid or DeviceID), and I would upgrade to the 6.3.5 if you are now on 6.3.3.

------------------------------
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: Nov 11, 2024 09:05 AM
From: jfasselin
Subject: ClearPass Intune Extension strong mapping issue

I have been testing the new Intune Extension 6.3 and strong mapping additions.

I have a problem with Authorization requests done to the Intune Extension, where if I use "%{Certificate:Subject-AltName-URI}" as a filter it stops working, presumably because this field is now a multivalue entry. I have tried a few variations on the filter and the base URL trying to specify I want to use the "deviceid" variable, but with no luck. I tried while specifying the "deviceid:" prefix and without including it in my certificates, with no difference. Authentication works fine in all cases.

Also, I noticed this morning the extension version 6.3.5 has been released, and tested with that (I was using 6.3.3 initially). Are there release notes available for 6.3.5?

Did you verify that the certificate used has been actutally replaced, and you see the proper SAN-URI in access tracker? According to the DEBUG message, it seems that ClearPass could not properly extract the UUID from the Certificate:Subject-AltName-URI; also doublecheck that you did not make a typo in that one, where you would see replacement errors in the log detail of from Access Tracker.

Think there is a small typo somewhere, and you are close to the solution. Sometimes it helps to go through all with someone else (who has knowledge on this topic).

Thanks Herman.

I've changed the SCEP SAN URI value to DeviceId:{{DeviceId}} and although the values still came through to the client cert with lowercase at least the trailing forward slash was removed.

The extension seemed to accept it, although instead of a 404 I instead got errors that the attributes are not found. I wonder if I'm missing some parts that are not mentioned in the v6 extension guide.

Connection log:
2025-02-27 12:56:56,503    [HttpModule-ThreadPool-2-0x7f8507dfe700 r=R0000033b-01-67bfc667 h=73] ERROR Http.HttpAutzSession - Failed to get value for attributes=Intune Azure AD Device Id, Intune Compliance State, Intune Device Name]

And after turning on DEBUG level logging for the extension I see this as well:{"AAD_Device_ID":null,"DeviceId":null,"UserPrincipalName":null,"tag":null,"standaloneValue":"deviceid:<guid>"}

This is on a vanilla Clearpass 6.12 other than what I am trying to get working here so all defaults other than:

service : type:Aruba 802.1X Wireless type, authorization (checked)

authentication: methods: EAP TLS With CN Check, sources: Endpoints Repository

authorization: sources: Microsoft Intune[HTTP]

rolemapping: Endpoint:

Source EQUALS Intune AND, Endpoint:Intune Compliance State EQUALS compliant AND, Endpoint Intune Device Enrollment Type EQUALS windowsAzureADJoin -> entra_machine_role

Enforcement: Tips:Role EQUALs entra_machine_role -> Corp_VLAN_enforcementprofile

The HTTP Intune source is:

Base URL:    http://172.17.0.2/device/info/id/

Authorization sources: (none)

Use for authorization: (checked)

Filters :    1. %{Certificate:Subject-AltName-URI}

Attributes: (Name / Alias Name / Data type / Enabled As)

Intune Device Name / Intune Device Name / String / Role, Attribute

Intune Azure AD Device Id / Intune Azure AD Device Id / String / Attribute

Intune Is Encrypted / Intune Is Encrypted / String / -

Intune Compliance State / Intune Compliance State / String / Attribute

[The reason I had IntuneDeviceID:=//{{DeviceID}} value in the SAN URI is that the latest version of the Microsoft Intune Integration Guide (2023-01 Oct 2023) Appendix E for the SCEP template lists it (Page 50 of the PDF). Can you please ask that all these misleading older bits of information be updated? It causes so much wasted time. There's also conflicting info in there after the v6 behaviour change info - about MAC auth and a few other things. ]

Original Message:
Sent: Feb 25, 2025 06:27 AM
From: Herman Robers
Subject: ClearPass Intune Extension strong mapping issue

The SAN for the Intune DeviceId should be URL=> DeviceId:aabbcc-ddffgg-the-uuid. Looks you have intunedeviceid instead of DeviceId, and you included //.

Please check the screenshots and documentation above. The SAN URI attribute is fixed and needs to be an exact match (case-sensitive). Hopefully you can change the SCEP Enrollment Profile to match (or even include an additional SAN URI DeviceId:<uuid> would work).

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

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: Feb 24, 2025 06:45 PM
From: BrendanMYS
Subject: ClearPass Intune Extension strong mapping issue

Thanks Herman.

I am running 6.3.5 with CPP 6.12.3 and seeing 404 errors when trying to use the HTTP method. 

I notice that the guide suggests using %{Certificate:Subject-AltName-URI} but for some reason it is coming through unparsed in the connection logs as lowercase -  Request Details/Input/Computed Attributes: Certificate:Subject-AltName-URI = intunedeviceid://<guid>

I have checked the device and the cert is also coming through as lowercase even though the SCEP template (using Microsoft PKI) that it is showing as, Attribute:URI, Value:IntuneDeviceId://{{DeviceId}}

Is case going to be an issue and therefore do I need to resolve this between Intune and the device?

Original Message:
Sent: Nov 13, 2024 10:32 AM
From: Herman Robers
Subject: ClearPass Intune Extension strong mapping issue

Please forget about any PDF for the documentation, most recent documentation on the ClearPass Intune Extension is here.

That SAN parsing is something different than strong mapping, but it was released in the same extension update so may be confusing.

I found that before 6.3.5, you should only have the following SAN-URI attributes: AAD_Device_ID // DeviceId // UserPrincipalName // tag
where the attribute names must match case-sensitive. If you have any additional attributes, or one with a case mismatch (like deviceid), the extraction of the attributes did not work.

The issue that if any SAN-URI value does not match a known attribute, seems to be addressed in the 6.3.5 extension that you found (I wasn't aware, so thank you for bringing that to my attention). 

Here is an example of a certificate that works in my lab (with the 6.3.3 version and just tested with 6.3.5 as well):

So, make sure the attribute is DeviceId (not deviceid or DeviceID), and I would upgrade to the 6.3.5 if you are now on 6.3.3.

------------------------------
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: Nov 11, 2024 09:05 AM
From: jfasselin
Subject: ClearPass Intune Extension strong mapping issue

I have been testing the new Intune Extension 6.3 and strong mapping additions.

I have a problem with Authorization requests done to the Intune Extension, where if I use "%{Certificate:Subject-AltName-URI}" as a filter it stops working, presumably because this field is now a multivalue entry. I have tried a few variations on the filter and the base URL trying to specify I want to use the "deviceid" variable, but with no luck. I tried while specifying the "deviceid:" prefix and without including it in my certificates, with no difference. Authentication works fine in all cases.

Also, I noticed this morning the extension version 6.3.5 has been released, and tested with that (I was using 6.3.3 initially). Are there release notes available for 6.3.5?