Dot1X access for trusted third party

[Scaremonger]

Hi,

We have a Dot1X policy for corporate Windows 10 PC's using TEAP(EAP-TLS) which works fine, but we also have a support company who connect to the LAN in order to manage servers and other equipment. 

The third-party connect to our LAN on a different VLAN and have access through the firewall to the services they manage, but their laptops have Dot1X configured for their company domain. The Cisco ISE policy identifies them as Dot1X, but fails because their certificate is invalid and falls back to MAB.

My question is in regards to Dot1X and EAP-TLS. We are not allowed to add our certificate to the third-party laptops, so the ISE policy always fails authentication regardless of what I seem to add into it.

I have created a seperate DOT1X policy for them that identifies the domain name from the Radius attributes, but I cannot get authentication working with an unknown certificate. I found an article that suggested you should be able to authenticate against the SAN and not the actual certificate, but I dont seem to be able to figure out how to do that.

All of their devices are in an Internal group for MAB purposes, but the dot1X policy doesn't seem to use it. Also the MAB policy doesn't seem to be able to access RADIUS information from the previous authentication attempt so I lose things like the hostname and domain.

Any suggestions on how to authenticate a device that has non-corporate dot1X configured, or should I just leave it falling back to MAB?

Policy Set: Wired_Dot1X_Support
Conditions:
- Wired_802.1X

- Radius-User-Name MATCHES ^(host/xyz[0-9]*.example.com)$
Protocol: Default Network Access

AUTHENTICATION:

Conditions:

- Wired_802.1X

Use:

- SupportCertSeq

- Options: Reject, Reject, Drop      (Continue does nothing here)

AUTHORIZATION:

- Default - Permit

Identity Source Sequence: SupportCertSeq

Certificate based Auth

- Profile: Unchecked

- Auth Search List: Internal Endpoints       (Laptops endpoints are in a group)

Advanced Search:

- Treat as if the user was not found and procees

Cisco ise 2.7 (Due to upgrade in a couple of months).

[Arne Bier · Accepted solution]

Hello @Scaremonger 

Great question - I have not run into this myself, but I think that in order for your ISE to handle foreign EAP-TLS clients, it will take two things

1) The foreign clients will need to trust your ISE EAP Certificate (or at least be configured to not care about that trust - if they are set to "don't check the server" then that's probably bad security for them, but good news for you. They can remedy that trust situation by adding your CA chain (that signed the ISE EAP cert) into their trust store - I seriously doubt they would do that.

2) Your ISE deployment needs to add their CA chain (that signed their client certs) into your ISE Trusted Certificates. Else the TLS negotiation will never work.

I don't know if it's possible to work with a half-baked TLS negotiation - in other words, let's say you can't perform the TLS negotiation because the mutual certificate checks fail on either end. What then? In essence, EAP cannot continue because there is no mutual trust - no point or value in poking around the cert looking for attributes - I don't think ISE will even let you do that.

You could try by creating a new Certificate Authentication Profile  (under Administration > Identity Management > External Identity Sources > Certificate Authentication Profiles)

My guess is that ISE won't let you get that far, because the cert checks (client rejected ISE, or ISE rejected client) failed.

The Windows supplicant has a tickbox "fallback to non 802.1X" or something along those lines - that would then cause the Windows machine to perform MAB.

[Scaremonger]

Hi,

Thanks for the quick response.

As you noted with Option 1, they won't let me do that and they are a hesitant to allow option 2 as well.

The option "Continue" in Authentication does not work if the certificate fails and I've already been through the Certificate Auth Profiles and they don't support this situation either. I think that MAB is the only solution for the moment; which is fine until they use a docking station with a generic MAC address. At that point I have no hostname or other attributes to use to identify them. I guess they will have to stop using the docks, lol.

In case others come here with a similar question; I found that I can stop the dot1x failure from logging in Collection filters, so now I only see the MAB authentication for these devices.

Thanks for your help.