ISE MAB to external Radius then MAB internal for Guest User auth

[Philip91]

Hello guys,

we have the following requirements for our ISE Guest Access Deployment:

We want to provide guest access but only to non Company Laptops. To check if the Laptop is company or a non company Laptop we have have all MAC Addresses in our ACS server. So in my understanding we have to to the following.

Check the MAC Address against the External Radius Server (ACS)

If Access-Accept returns -> Deny Access

If Access-Deny returns -> Check MAC Address against Internal Endpoint Store

If User not found -> Guestflow

Right now i don´t no how i can sould design it but i need two Authentication Policys first for the redirect to the External Radius and then another one for check against internal Identity Endpoint Store. Am i right ? I don´t know if that is possible.

Really thanks for your help!!

Greetings

Philip

[Saurav Lodh]

You can create Identity source sequence

[riwakefi]

You can't configure External Radius in an Identity Source sequence, you use it in a authentication policy which doesn't seem to have the option of fail-continue for External Radius. 

Did anybody find a way to do this?

[Philip91]

Yes i did.

You build two authentication rules with different conditions. May the screens will help you:

[Richard Wakefield]

Thanks, this is helpful to see how you got this working. 

Unfortunately, it doesn't help with my scenario. I have a customer who wants to check ISE for the MAC, if it's not registered, check a 2nd external Radius for the MAC, if it's not registered, onboard them on ISE.

What I'm finding is that 'Radius Proxy' authentication rule doesn't have the option to 'continue if user is rejected'. It seems like the 2nd external Radius becomes the 'last word' in the authentication, and if it sends back a deny that's the end of ISE's search. If it were to send a permit (to get it to drop to authorization stage), I wouldn't know if it was a Permit due to the MAC being there, or a Permit for the MAC not being there.

What I was thinking was maybe have the 2nd Radius server send back a permit either way, but include some kind of AVP if the user is there that I could match on with ISE, or no AVP if the user is not there. The I could write two rules, one to permit if-AVP, another to deny if no-AVP.... But this is getting very convoluted to make it work and another solution may be in order. 

[Philip91]

Hello Richard,

i´m not understanding your problem at all. Please describe what you wanna do in deep. What i have shown you is definitely a way to deny "known" Mac addresses from accessing anything with MAB (guest or byod) and still trigger authorization policies. If you wanna use my config but with byod instead of just guest access i don´t see a point why it shouldn´t work because it will use the guest portal as well ;) ?

Greetings

Philip

[Richard Wakefield]

For Guest.

2 Radius Servers, 1 ISE, 1 3rd party. 

This customer is migrating from a 3rd party Radius solution to ISE. They want ISE to look locally first for GuestEndpoints, then to a 3rd party Radius for endpoints, and if the user isn't found in either, the user is directed to the Self Registration Guest portal to sign up.



In this case, the 3rd party Radius can't send a 'deny' to ISE or ISE will not pass them to the authorization policy to push them to the Guest portal. You can't configure it to 'continue' if Radius Proxy sends back a deny. 


What I'm going to attempt is:
1) Rather than sending just a Permit or Deny back to ISE from the 3rd party Radius based on Device/MAC registration, configure 3rd party Radius to send:

A) If device is not found, send a Permit with a Radius Attribute (example: something=unknown)

B) If device is found, send a Permit with a Radius Attribute (example: something=pass)

2) In ISE, write two authorization rules.

A) If Permit and Radius Attribute=something=unknown, Guest Portal.

B) If Permit and Radius Attribute=something=pass, Permit access.

The point is simply:
1) You can't use Radius Proxy in a Identity Source Sequence.
2) You can't 'Continue' if Radius Proxy sends back a Deny.
But if Radius Proxy sends back a permit with an AVP if the device was found or not, I can continue to the authorization policy and write rules based upon that AVP.

[Philip91]

Hello Richard,

got your point. Did you already test it?

Greetings

Philip

[Richard Wakefield]

No, not yet.

The customer is also looking to see if the "Radius Token" could be manipulated to work, so we could make it a Identity Source Sequence rather than having to play games with the AVPs. 

[nspasov]

Let me ask you a quick question: Are all domain machines Windows and joined to AD?