Problem in rule to compare SAN (Subject Alternative Name) and Calling

[rafaelsalvinos]

Hey, Guys!

I'm with a problem related to athentication of users that use certificates generetad by Cisco ISE.

I generated the individual certificates through Certificate Provisioning Protal in Cisco ISE for EndPoints (smartphones corporate) authenticate via EAP-TLS, to network to access Internet only.

The autentication process of endpoint via EAP-TLS occurs successfully.

The problem is that when I export the individual certificate for other device with MAC Address different from SAN (Subject Alternative Name) of certificate, authentication continues to occur.

I believe that certificate of endpoint generated through ISE is unique.

To resolve, I created a rule for compare SAN and MAC Address Device (Calling Sation ID), but doesn't match.

I saw in the log, that the field "Calling Sation ID" use format MAC Address with ":" and the field "Subject Alternative Name" use format MAC Address "-". This difference in format is reject the access endpoint.

Event log:

Rule:

I would't like to change format MAC Address in WLC because there are many.

My need is accept to access only the MAC device it is equal SAN, for prevent export the certificate.

Can you help me to solve this problem?

Thanks!

[Arne Bier]

I am using ISE 3.2 and in Authorization there is an operator called "MAC Contains" - that strips out the delimiter and compares only the hex digits. But that does not help your case where you're comparing SAN and Calling-Station-ID ...

[rafaelsalvinos]

Hi @Arne Bier 

Tomorrow I'm going to do a test with this condition.

In theory, I believe its work, because the formats of comparison are same formats your example.

I will back here with result.

Thanks.

[Arne Bier]

Oh cool - I hod forgotten that you can click on the "3x3 grid" icon to reveal other operands. I reckon that should work.

But as @Greg Gibbs  pointed out, by default most smartphones will use Private MAC addresses - and that might defeat the checks. But see how you go.

I don't place any limitations on how one can/should use the internal CA - it's a tedious affair, but if customers can use it to their advantage, then that is a good thing.

[Greg Gibbs]

First off, the ISE Internal CA is only built and supported for the BYOD use case (and some minor pxGrid use cases). If these are Corporate-owned smartphones, you should be using an MDM to manage the devices and enrol certificates.

Secondly, using this MAC_in_SAN condition match is going to be problematic in one or another due to the fact that most vendor devices are moving to use randomized MAC addresses by default. See ISE 3.1 BYOD Solution for MAC Randomized Endpoints for more info.

[rafaelsalvinos]

Hi @Greg Gibbs 

The smartphones will connect in network with access only Internet. It's not exactly BYOD network, but similar.

I'm test this solution. If OK after the tests, my idea is provisioning the certificates to smartphones in ISE. The instalation certificates on smartphones and profile configuration, will be done by Intune team.

My objective is that the user, receive the smartphone already configured, with the profile and certificate generated by ISE. This process will be done through Intune.

[Greg Gibbs]

@rafaelsalvinos I'm not quite understanding how this is intended to work.

The Profile (802.1x settings) is only installed on smartphones as part of the ISE BYOD enrolment flow. There is no way to export this from ISE to load into Intune, nor is there a way for Intune to integrate with ISE to programmatically request certificates on behalf of the users (like the SCEP or PKCS connector options).

You would have to manually request individual certificates for each user, then use the Imported PKCS option to push the certificate and private key to each user along with the Wifi Profile created in Intune. That is a lot of operational overhead (if even feasible for multiple users).

Using a CA that integrates with Intune (like AD CS, SCEPman, or MS Cloud PKI) would be a much better option.