Cisco ISE - Multiple Guest Use Cases with one SSID

[Marc Aemmer]

Hi everybody

I'm looking for a single SSID solution to meet our multiple guest use cases::

- Tenants: Sponsored account with no expiration

- Employees: Active Directory Login for internet access (privat devices). Maybe device onboarding.

- Contractors / Guests: Self Registering Portal. 8 hour expiration.

- Patients: Forward Requests to external Radius Server. Condition: When username is Number.

Is there a elegant way to realize our requirements with ISE 2.3?

Looking forward to your answers.

Marc

[Craig Hyps]

Can multiple use cases be supported on one SSID?

Yes, but you must take into consideration WLC/wireless restriction that single SSID can be secure OR open, so cannot have 802.1X auth mixed with Web Auth as primary auth method--no flex auth like in wired.  You can have 802.1X + Web Auth, but not fallback to web auth.

Elegant way to combine use cases with wireless on single SSID is TrustSec.  It can allow assignment of policy to each use case and enforce policy based on tag rather than trying to assign to different subnets, interfaces, or VLANs.

Craig

[paul · Accepted solution]

Actually you should be able to do this by doing the following:

Setup a new Identity Source Sequence for your guest portal that does the following identity sources (in order):

Guest Users

Active Directory

External RADIUS server

Setup 4 endpoint identity groups:

1. Tenants
2. Employees
3. Guests
4. Patients

Setup 4 Guest Types:

1. Tenants- Duration 999 days, default duration 999 days.  Tie it to Tenants whitelist, Configure the # of devices you will allow them to register. This not no expiry, but you will see later you never purge the group.
2. Employees- Duration 999 days, default duration 999 days, Tie to Employees whitelist.
3. Guest- Duration 8 hours, default duration 8 hours.  Note with the purge policies running at 3 a.m. the guest account will expire in 8 hours but their MAC address won't be removed from whitelist until 3 a.m.
4. Patients- Duration and max whatever you want for patients.

Setup your purge policy for the whitelists as follows:

1. Tenants and Employes- don't setup a purge policy.
2. Guests- Elapsed days less than 9999 which guarantees the MAC addresses in that whitelist will be purged every night.
3. Patients- whatever you duration is for you pations, using elapsed days.

Then you setup your sponsor groups that can create Tenants and the Sponsor groups that can approve Guests. 

In the guest portal, you set the Employee whitelist to Employees and guest whitelist to Guest and do a normal self-registering guest setup.

Your Authorization rules would be simply:

1. If in one of the whitelists let them have Internet access.
2. If not redirect them to the portal.

Should work, but this is theory crafting.

[Marc Aemmer]

Sounds promising! Thanks.

I will try configure it tomorrow and let you know the results. For now, I already have two questions regarding your solution:

1. How does ISE determine employee's? Automatically when using External Identity Groups?

2. I'm not able to add a external radius server to a Identity Source Sequence. Other options?

regards,

Marc

[paul]

Anyone signing in with valid AD credentials is considered an Employee.

You can assign a RADIUS server to Identity Source Sequence. I do it all the time. You first need to define your RADIUS Token server which is the external RADIUS server(s) you are sending the request to. Then you link in that RADIUS token server into the ISS. The RADIUS token server can be any RADIUS server.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[bravojared]

If you want to minimize invalid logins to things not in the sequence, you can parse the patients out separately.  Otherwise if you put everything in a sequence you can get slower auth times and failed authentications to other sources in the sequence before hitting the source you care about.  If you know clearly that something should go somewhere based on clearly presented authentication attributes, putting it in a sequence is not optimal, instead optimize ISE and dependency processing by being explicit.

In your Authentication rules you can define WHEN to send a request to specific place.

So, if you want to only send requests to external RADIUS proxy if account ID starts with number, put a condition that matches regex for example.

This regex checks if a string starts with a number:    ^\d\w*$

AuthC:

If the user ID matches, send to X RADIUS Server.

Jared

[paul]

Guest portal don’t use traditional AuthC rules where you can parse that out. They only let you do a sequence.

In order to what you are saying you would have to do a RADIUS loopback call in the Guest Portal to ISE itself then do some parsing in AuthC which would add its own sets of challenges.

If we were talking 802.1x auth then what you are saying makes sense, but portal auth is its own animal.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[bravojared]

Yup, as soon as I hit post I realized and then followed up with the other message.  time to get a coffee...

[paul]

Yeah the one part of my solution I am unsure of is what identity group will the patients get mapped to. The aren't a true guest type. They may get treated as employees. If you cross link patients to their own portal as you suggest then you could for sure control what endpoint group they go to.

The first 3 use cases are standard guest portal functions.

Sent from my iPhone

[spitalfmi]

With your help I was able to get to the following situation:

- Guests are able to self register and are assigned to guest type "Guests".

- Sponsors can create users with guest type "Guests" and "Tenants".

- Patients can login and are challenged against Radius Token Server.

- Employee's can login and are assigned to Guest Type "Employee"

Now I got the following Problems / Questions:

- How can I restrict employee access by AD group membership?

- Patients are assignes to guest type "Employee".

[paul]

Okay now you are getting really complicated. The only portal in ISE that has an AD group awareness is the sponsor portal. For some reason none of the other portals have this capability directly. To get around this you need to configure a RADIUS callback sequence to have the PSNs do a RADIUS callback to themselves. Then you can setup a policy set that uses the device type of PSN as the criteria and allow whatever AD groups you want. So basically you would modify your Identity Source sequence to:

Guest users

RADIUS Call Back

RADIUS to Patient authentication server

That would solve your AD group issue for Employees, but Employees and Patients would still get mapped to the same Endpoint identity group. I would just make the purge policy the lower of the two types which is I am guessing is the Patients.

The Employees are getting Internet access… tell them to stop complaining and deal with having to see the portal once in a while. ☺

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[bravojared]

Another method that has been used historically is to use one portal page to redirect to other portal pages and maintain session ID, each with different experience/messaging/etc.  You will need to balance usability vs. security vs. operationalization of this if desired (and if it works for you - see my note after this link):

Linking one guest portal to another guest portal

Please note that while this has worked in the past, on some net new setups we have been running into a bug that was just created around using script/html code in optional content in guest portal pages CSCvf90363

[Marc Aemmer]

Does ISE support VSA when using External Radius Token Server? My external Radius Server is sending some Airespace VSA's but regarding to the ISE logs, ISE is not receiving or processing them...

[Craig Hyps]

ISE can process one VSA returned from external RADIUS server, for example, a group attribute, and then return one or more VSAs to access device based on matching the external VSA.

/Craig