Security

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.
------------------------------

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.

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.
------------------------------

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.

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.

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.

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.

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.

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.

Did you verify that the certificate used has been actutally replaced?

Yes cert was verified - this was tested on a few machines with the same SCEP template. I should point out that we are using MS PKI and for some reason it is changing all SAN values to lower-case. I have a case open with Microsoft and they are suggesting it is normal, and have even suggested I try using DNS instead of URI (!??). Alternatively, they suggested "ID:Microsoft Endpoint Manager:GUID:{{DeviceId}}" in the SAN although I am not sure why. Ultimately I wonder why we don't just use Clearpass as the SCEP for Entra-joined machines, or even is it possible to just use the Intune cert issued by "Microsoft Intune MDM Device CA" which has Client Auth EKU, and the Intune ID in the CN, although it does not have any SANs. Just a thought!

see the proper SAN-URI in access tracker? 

The value in the access-tracker was correct as it exists in the certificate, but as I say it is lower case. Access-tracker shows:

Certificate:Subject-AltName-URI as "deviceid:<guid>"

According to the DEBUG message, it seems that ClearPass could not properly extract the UUID from the Certificate:Subject-AltName-URI

Yes that matches what I'm seeing, although in your own debug message I notice your DeviceId comes back as "null" and the actual value is via standaloneValue... not that it means anything to me. 

[2024-11-14T10:18:55.547] [DEBUG] Intune - Parsed result: {"AAD_Device_ID":null,"DeviceId":null,"UserPrincipalName":null,"tag":null,"standaloneValue":"fdd2d322-27fd-4f82-a5da-07eb7142dccf"}

..but given that the latest doco - I finally found the latest is on the website - says specifically that values are case sensitive I assume there is at least some involvement there?

https://arubanetworking.hpe.com/techdocs/NAC/clearpass/integrations/unified-endpoint-management/intune/#whats-new-in-clearpass-intune-extension-v63

" INFO

The KEY's for all attributes in the certificate SAN field are case sensitive. The extension can only parse them correctly when they are in correct case. The PKI server signing the client certificates should honour the KEY:VALUE pair format"

I have also double/triple-checked for typos and it all appears fine. Unfortunately at this stage I have to move on from HTTP method as we cannot seem to get past this issue. The Endpoint DB method looks solid still so I don't think we have compromised security a lot, and it is also faster.

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.