If it doesn't work for you it may be most effective to work with TAC.
To share a bit more on my setup... here is what's in the Subject-AltName-URI for me:
| Certificate:Subject-AltName-URI |
DeviceId:fdd2d322-27fd-4f82-a5da-07eb7142dccf, AAD_Device_ID:74a622ba-eb11-486d-8ab8-0965bfb636b3, UserPrincipalName:herman@azure.arubalab.com |
And this is how the Auth Source looks like:
With the following Filter:
Do you see anything in the Extension logs?
This is what I see on a request (I set log level to DEBUG; so without that you will only see the INFO lines):
[2024-11-14T10:18:55.540] [DEBUG] Intune - Parsing the request having parameters: DeviceId:fdd2d322-27fd-4f82-a5da-07eb7142dccf,AAD_Device_ID:74a622ba-eb11-486d-8ab8-0965bfb636b3,UserPrincipalName:herman@azure.arubalab.com
[2024-11-14T10:18:55.540] [DEBUG] Intune - Parsed result: {"AAD_Device_ID":"74a622ba-eb11-486d-8ab8-0965bfb636b3","DeviceId":"fdd2d322-27fd-4f82-a5da-07eb7142dccf","UserPrincipalName":"herman@azure.arubalab.com","tag":null,"standaloneValue":null}
[2024-11-14T10:18:55.542] [INFO] Intune - [fdd2d322-27fd-4f82-a5da-07eb7142dccf] Request for information received from ::ffff:172.20.123.1.
[2024-11-14T10:18:55.542] [DEBUG] Intune - [fdd2d322-27fd-4f82-a5da-07eb7142dccf] Performing device lookup.
[2024-11-14T10:18:55.546] [DEBUG] Intune - Parsing the request having parameters: fdd2d322-27fd-4f82-a5da-07eb7142dccf
[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"}
[2024-11-14T10:18:55.547] [INFO] Intune - [fdd2d322-27fd-4f82-a5da-07eb7142dccf] Request for information received from ::ffff:172.20.123.1.
[2024-11-14T10:18:55.547] [DEBUG] Intune - [fdd2d322-27fd-4f82-a5da-07eb7142dccf] Performing device lookup.
[2024-11-14T10:18:55.794] [DEBUG] Intune - e259b1fc-f1a6-4abc-9c96-dca7fb17f5fc Request "GET '/deviceManagement/managedDevices/fdd2d322-27fd-4f82-a5da-07eb7142dccf'" took 251 ms.
[2024-11-14T10:18:55.794] [INFO] Intune - [fdd2d322-27fd-4f82-a5da-07eb7142dccf] Information returned for device fdd2d322-27fd-4f82-a5da-07eb7142dccf.
[2024-11-14T10:18:55.914] [DEBUG] Intune - 38c5a9aa-40ab-44bf-9d40-e595083d4445 Request "GET '/deviceManagement/managedDevices/fdd2d322-27fd-4f82-a5da-07eb7142dccf'" took 367 ms.
[2024-11-14T10:18:55.915] [INFO] Intune - [fdd2d322-27fd-4f82-a5da-07eb7142dccf] Information returned for device fdd2d322-27fd-4f82-a5da-07eb7142dccf.
If it doesn't work for you, the Parsed result debug lines can show what the extension could read from the request.
------------------------------
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 13, 2024 01:11 PM
From: jfasselin
Subject: ClearPass Intune Extension strong mapping issue
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}".
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?