ISE EAP-TLS as a Radius Proxy but only sometimes

[User42]

Hi Guys

I have two customers.

Customer A, Use ISE with EAP-TLS

Customer B, Use NPS Azure

The clients from customer B now needs to authenticate in the network of customer A also with EAP-TLS.

But the clients don't trust the certificat of the ISE from A. (they shouldn't trust)

Is there a way to do this:

If clients from A login, ISE authenticates and authorize the Client.

But if clients from B login, ISE act as a Radius Proxy to the NPS Server. (So he don't present his Certificat)

And if this is possible, how can I configure this?

Thanks!

[Arne Bier · Accepted solution]

Hi @User42 

Customer B using NPS in Azure, I assume is also performing EAP-TLS (albeit, in Azure NPS) - is that correct?

Remember that you don't 'hand off' the RADIUS request entirely, even if the request is to be authenticated on a remote RADIUS server. Any client RADIUS request that is sent to Server A, will end on Server A.  But you can 'forward/proxy' the request along a chain of RADIUS servers until you hit the server that must perform the Authentication. But the final RADIUS Authorization result to the NAS/NAD comes from Server A.

The scenario you have is very similar to Eduroam, where students connect to any education wireless network that hosts the 'eduroam' SSID, and then get routed to their 'home network' for authentication. Eduroam also uses 802.1X - however, I am pretty sure that with eduroam, the EAP certificate does not have to be signed by a public CA, and hence, the TLS negotiation happens on the 'home' RADIUS server (i.e. Customer B), and not the 'host' RADIUS server (i.e. Customer A).

As with Eduroam, the ISE AuthN (Authentication) Rule would have to perform a check on the RADIUS Username presented, and then make a decision to forward that request on to the NPS server. And that determination can be made using one or more of the RADIUS attributes in the Access-Request. If the username contains something like a domain (e.g. @customerB.com) then that's easy. Otherwise, any deterministic condition that can tell Customer A apart from Customer B will work.

In the host ISE, configure NPS as an External RADIUS server. The Identity lookup for customer B authentications will then use that for AuthN.

Your NPS server must list the ISE PSN server(s) as RADIUS clients.

Once ISE AuthN is done, you can perform any local authorizations if required.

[User42]

Hi Arne

Thanks for the answer!
Yes you are correct the NPS Server also use EAP-TLS

So it is possible that the clients from B don't trust the ISE certificat but can authenticate to that ISE because we proxy the traffic to another Radius Server.
In other words, the TLS Handshake happens between client B and NPS Server from B (ISE is just between them as proxy)
Is this correct?
In this case my task is to find a RADIUS attribute that differs clients A from Clients B.

[Arne Bier · Accepted solution]

Hello again

That's correct. The first RADIUS server never engages in the EAP conversation. Only the Authenticating Server (in this case, Company B) will engage in TLS negotiation. I just tested this in my lab, and I could validate in Wireshark that the TLS Server Hello was identifying itself as the "Remote RADIUS Server".   If you want to validate this yourself, you can spin up two ISE VMs, and then use a Linux tool like wpa_supplicant to send wireless 802.1X messages to ISE. The cool thing about wpa_supplicant is that you can pretend you are sending real requests from an 802.11 wireless device (SSID, EAP-TLS, EAP-PEAP, etc.) - this is how I do all my rapid prototyping tests when I don't have a real AP and client for testing.

Have a look at client A vs client B username formats. That would be the best bet. You can't use any characteristics from the certificate, because the first RADIUS server will not look as far as that - the first receiving RADIUS server can only look into the RADIUS attributes (Username, Called-Station-ID (SSID name), etc.)

good luck!

[User42]

Thank you very much!