Impact of Microsoft KB5014754 with ISE and EAP-TLS authentication

[REJR77]

Hi,

Microsoft has published a KB to address some vulnerabilities with certificate authentication.

Is there any impact to be noticed with ISE, especially EAP authentications?

Thanks

[Arne Bier]

my reading of that article is that the certificates need to be created (and potentially re-issued) with more attributes to make it harder for an attacker to spoof. I don't believe it has any impact on ISE, other than tweaking Policy Sets to look for additional attributes to make the Authentication/Authorization water tight.

[LuisMediavilla]

Actually this new SID field is ignored on ISE 3.2 Patch 7, I wonder what is the way to get the user name if nothing else is provided.

[Greg Gibbs]

I believe a Field Notice is forthcoming that will explain the impact this new SID will have and the fix that ISE patches will implement.

In short, the SID will use the SAN URI field of the certificate, which is the same place the GUID is inserted (unless using the CN field) for use as the identifier for performing MDM registration/compliance lookups. ISE needs to understand how to parse the SAN URI field for the GUID when the SID is also present, which is the enhancement in 3.2 patch 7 that will also be in future patches for other current ISE versions that are not past the End of Software Maintenance.
https://www.cisco.com/c/en/us/td/docs/security/ise/3-2/release_notes/b_ise_32_RN.html#c_new_features_32p7

The identity used for authentication/authorization against an external ID store would still be defined in the Certificate Authentication Profile, so it should not be affected unless a value in the SAN URI field is used for that identity (which is uncommon, from my experience)

[Shorty]

Greg,

The field notice was posted here: https://www.cisco.com/c/en/us/support/docs/field-notices/742/fn74227.html

Is it safe to assume that this only impacts Microsoft InTune deployments?

My user and computer certificates are enrolled from Windows CA.  I want to be sure that even when I upgrade to one of the recommended versions of Cisco ISE, I can still perform EAP-TLS authentication against Active Directory. 

the Cisco bug associated with this field notice has two conditions. Do you have to meet both of these conditions or just one of them?

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwk73785

[Greg Gibbs]

There are two aspects to this… the first is the strong cert matching being enforced by MS in Feb. Enabling Compatibility Mode would be important for customers that cannot meet the strong cert matching requirements by that date (adding SID to certificate templates, rolling out new certs, testing their auth against AD with certs that include the SID and strong cert matching enforcement enabled, etc).

MS does not really provide much detail on exactly where this strong certificate mapping occurs in their KB article, nor do they specifically mention 802.1x as a scenario, so I'm not convinced that cert-based 802.1x auth from ISE is actually impacted by this. ISE only handles the Kerberos auth piece against AD, which does not involve AD ever seeing the certificate from the client.

The second aspect is for customers using Intune MDM integration with ISE 3.1+ and GUID-based lookups. Without the relevant patched version, ISE cannot properly identify the GUID in the SAN URI field to perform the MDM lookup against Intune due to the added SID in the URI field. The ISE patches fix this lookup issue and allow ISE to properly parse the GUID from the SAN URI field.

[klnnnnng]

Thank you for the thorough explanation.

So to my understanding if I am doing authentication and authorization based on the Certificate's CN or other any attributes rather than SAN there should be no impact even with version 3.2 P4. Could the "Match Client Certificate Against Certificate In Identity Store" = "Only to resolve identity ambiguity" Option in the Certificate Authentication Profile have some impact?

Regards

[Greg Gibbs]

No, the binary comparison will work as long as the certificate is present in the Published Certificates for the user in AD.
https://community.cisco.com/t5/network-access-control/ise-binary-comparison/td-p/4003868

[Arne Bier]

Am I correct in assuming that, in scenarios where there is no MDM integration with ISE, and also,  if ISE is configured as follows, then this bug is not applicable?  it's the most basic CAP configuration that simply picks the identity from the cert for cert authentication to proceed to Authorization.

[Greg Gibbs]

The SID is only applicable to user/computer accounts in traditional AD, so the Identity Store for those sessions would typically be configured for your AD join point. With the 'Use Identity From' set to the generic 'SAN' instead of something more specific like 'SAN - Other Name' it could still be impacted, depending on where the identity is in the SAN, and what other attributes are in the SAN.

This is the best way I can summarise the issues/concerns around this FN and the MS changes…

If Intune is not used to enrol certificates or they are using PKCS profiles instead of SCEP profiles in Intune, there would be no SID inserted in the SAN URI field. In that case, there would be no impact from the ISE side for either Identity for lookups against AD or GUID for lookups against Intune.

In both cases (certs enrolled using Intune PKCS profiles or directly by ADCS and Group Policy), the SID is inserted in a separate OID field in the certificate (assuming the servers have been patched since the 2022 updates and the certificates were enrolled after that time). For ADCS to insert the SID for Intune PKCS profiles, the EnableSidSecurityExtension registry key must be configured on the ADCS server(s) as per this MS doc.

https://techcommunity.microsoft.com/blog/intunecustomersuccess/support-tip-implementing-strong-mapping-in-microsoft-intune-certificates/4053376/

In this case, the customer would still be meeting the MS requirement around strong certificate mapping. This separate certificate OID field would have no bearing on ISE auth or MDM integration use cases.

---

If the customer is using Intune SCEP profiles, and inserting the SID into the SAN URI field, this is when issues might arise with ISE parsing the SAN for either Identity to check against AD or the GUID for Intune lookups. This is where the documented ISE patches should be used to mitigate this issue.

If they are using SCEP profiles and not inserting the SID, this is where they may not be meeting the requirements from MS around "strong certificate mapping". If they have questions about this requirement and potential impacts (outside of ISE), they need to seek advice from MS.

[CiscoU9834]

ISE side it's pretty clean, if you're using External MDM check and Intune Device Configurator for deploying Certificate, you install the fixed release of ISE and the MS:GUID is correctly handled from ISE API.
What we're unable to understand is if MS will automatically add the additional URI field after the 11th February and if after the 11th February the 802.1x authentication need that field on certificate (Microsoft Device side).
But Cisco ISE side, everything seems clear.

The real question is: "If customer is using Device/User certificate only for 802.1x auth deployed with Intune+SCEP and nobody will change anything, after the 11th February everything will work as before or auth will fail due that MS want the additional URI for 802.1x auth scenario?"

Because ISE will only decrypt the Certificate, check the CN (if not specified other attribute on ISE Cert Profile) and perform a LDAP query for check the account status and group membership, not a real authentication is performed over EAP-TLS, so this is the not well explained detail.