Guest access without portal using sponsored credentials as PSK

[Madura Malwatte]

Is it possible to do something like this, where a sponsor on-boards a guest using the sponsor portal hence allocating an account with username/password. Where the guest then uses the credentials that was created by the sponsor to connect to the guest SSID using it as PSK?

The point is to have the guests completely bypass the guest portal where their credentials are normally entered. I understand that there is identity PSK option availble but reading this guide the psk is set up manually for each and users in an authz rule using cisco-av-pair, and also paired to a mac address manually added.

Ideally I would like to on-board guests via an employee using the sponsor portal. Then have authz rule like:

guest user connects to guest SSID WPA2/PSK -> prompted for username/password -> if username/password matches a sponsored guest account then allow access.... Can this be done, if so how? What condition would I use to check the identity group database for matching account username/password?

I have created sponsored guest accounts via sponsor portal and assigned guest type to "Daily (default)", but in Identity Groups > User Identity Groups > GuestType_Daily (default), the created account does not exist. I can't seem to find where this account details exists in ISE gui, besides the sponsor portal page.

[Arne Bier]

Hi @Madura Malwatte 

that would be a neat solution.

PSK doesn't use a username/password function - the authentication to the PSK SSID is based on a single component - a pre-shared key.

The thing with PSK is that you would have to do iPSK in order to first send a MAB request to ISE for that client's MAC address. Only then could you return the client's unique PSK to the WLC. This is not a problem as long as you capture the client's MAC address during the onboarding process. 

But you're also right, that ISE generated guest accounts are not visible to the Policy Set.

If there were a mechanism to retrieve any of the user's attributes (e.g. a PSK text string created during guest account creation) and then map that to the Cisco AV Pair then you'd have a working solution. Currently iPSK performs a MAC address lookup in ISE, and generally an Endpoint Identity Group is used to lump a whole bunch of MAC addresses into a group, that all share the same PSK. What you want is a mapping of 1 MAC address to unique PSK. 

Other option might be to not use the ISE Sponsor concept, but to rather offload this to an LDAP/AD/ODBC that stores the guests MAC addresses and then returns the unique PSK after authentication.

I don't see a way to encode a MAC address into an ISE Sponsored guest account.

[Madura Malwatte]

Hi @Arne Bier thanks for your response. 

I want to do away with MAC addresses and guest portal completely. For my use case, guest users are not able to reach the ISE IP addresses as they sit in a completely different DMZ, so they cannot reach the portal to self-register or even hotspot. Now I don't want to get bogged down with manually adding MAC addresses either. The solution I am looking for is to either have a sponsor on-board a guest user using the sponsor portal, or alternatively manually add a user account as an internal user into ISE. Maybe PSK is not the option, but looking for a way to secure the SSID (maybe CHAP, MD5??) with the guest account credentials created on ISE.

I found this - https://community.cisco.com/t5/network-access-control/how-to-restrict-access-to-guest-portal-or-encrypt-guest-traffic/m-p/3580405  @Jason Kunst mentions "WPA2 without portal* •sponsored credentials (guest type requires - Allow guest to bypass the Guest portal)".  I am not sure on how this mentioned method could be set up, but maybe Jason could reply. Getting a username / password variables of the user account and passing that in Cisco AV Pair sounds good to authenticate a user.

[Arne Bier]

I think the option you're referring to (Jason's third option) was just using WPA2/PSK in addition to a portal - this means that you need to tell your guests what the PSK is - same PSK for everyone. Once you enter the PSK, then you get redirected to the ISE portal - guests then have to enter their creds. The reason for such a solution is to stop/prevent casual users just connecting to an open SSID (people bored or phones randomly connecting) and consuming DHCP and WLC resources. Entering PSK requires some insider knowledge.

This is probably not the solution that you're looking for.

At that point you might as well go the whole hog and do WPA2/Enterprise EAP-PEAP - this allows each user to have their own sponsor creds, and their sessions are encrypted individually (not too easy to hack your way into WPA2/Enterprise).

Would this be a solution? In my opinion it's easier to implement than Open SSID web portal. You just need an ISE EAP System cert that is signed by a public CA to avoid getting client cert warnings when they connect.

[Madura Malwatte]

Hi @Arne Bier ah ok (jason's third option) - not what I am looking for.

If I use EAP-PEAP for guest access how would I tie in a condition to check for whether this user has been on-boarded with a guest account by a sponsor (and that the account has not expired), without having to match pre-loaded mac address?

[Arne Bier · Accepted solution]

Oh that's the great part - it behaves just like a Sponsored Account - you can suspend, delete users (ISE sends CoA to disconnect) and then also re-instate etc.

In the AuthZ below you'll see that I am referencing the User Identity Groups.

Update: I forgot to mention that by default, a Guest account is used to log into a portal. When creating a new sponsored guest account, the default state is "Created" - this means ISE is waiting for the guest to log into the portal successfully - only then does the state switch to "Active". If you try to log into a 802.1X SSID with a guest that is still in "Created" then it won't work. You can either cheat and log into a guest portal to force that guest account into Active ... but a more sensible approach would be to tick a little box in the Guest Type called "Allow guest to bypass the Guest portal" - that automatically sets the guest account into Active from the get go!

Happy days.

[Madura Malwatte]

@Arne Bier Awesome mate, thanks for this info! I would have been scratching my head regarding account state (created and active). I'll test this out and let you know how it goes.

[Madura Malwatte]

Hi @Arne Bier , tried to set this up but it didn't work.

Once I have created a guest user using the sponsor portal (assigned as Guest Type Contractor), ISE doesn't seem to know which Identity store to find this guest account.

Steps:

1. Create guest account (username/pass) using sponsor portal 

2. Connect to SSID set up for PEAP, and gets prompted for username/pass

3. Guest enters username/password of the account which was created by sponsor portal

4. ISE complains that Subject not found in the applicable identity store(s)

In my authentication policy, I have tried setting the identity source sequence as "Guest Users", but subject could not be found. I have tried "All_User_ID_Store" and still this guest identity cannot be found.

So question is how do I get ISE to look at the guest identities created via sponsor portal for the authentication phase?

[Arne Bier]

HHmmm - strange - I have Guest Users included in my Identity Source Sequence. In that same sequence I always search Internal Users first (those are NOT sponsored users), then Guest Users, and lastly AD Join Points.

Are you sure you are hitting the appropriate part of the Policy Set?

I am using a standalone ISE 2.6 node and when comparing your sponsored user, the fields are in slightly different order - not that it should matter - but if the config is correct then perhaps there is a difference in software versions?

Remember also that the PAN is responsible for managing the Guest accounts - and I think that perhaps these accounts get replicated to the PSNs (don't quote me on that) - is the PAN and PSN in sync? 

I will test again tomorrow when I am in the office.

[Arne Bier]

Still works for me

[Madura Malwatte]

Hi @Arne Bier thanks for testing this for me and confirming its working for you. Not sure what I am missing in my deployment.

How are you onboarding this Weekly Type Guest users? Is it via the self-register portal by the guest themselves or created via the sponsor portal?

In my case I am using sponsor portal to create the Guest account and I have selected the tick box (for Contractor Guest types) to "Allow guest to bypass the Guest portal". When I check the user identity groups, the accounts don't show up in any of the guest types. Does your "bbob" guest  user show up in the GuestType_Weekly(default) identity group? 

In my policy set for authentication identity group if I am using "Guest Users" store, it should specifically be referring to these GuestType identity groups. But if the user account doesn't show up here after creating via sponsor portal then this is why ISE is saying subject not found.

[Arne Bier]

Hello again

User Identity Groups don't seem to follow the usual logic - I don't see my bbob user in any of the GuestType User Identity Groups. The only time I see users in that group, is when I create an internal ISE user account (not via the Sponsor Portal) and then put that user account into that User Identity Group. And then only can I use that named Group in my Policy Set logic.

Sponsored user accounts only appear in the Sponsor Portal or in the Managed Accounts ts part of the Admin GUI. And ISE will find them when you use "Guest Users" as your Authentication Identity Source. 

Check your Identity Source Sequence again and put "Guest Users" at the top of the list.

I am onboarding the bbob user via the Manage Accounts screen in the Admin GUI (which takes me to the Sponsor Portal anyway)

Check your Guest Type config too.  Here is what I am using

[Madura Malwatte]

Hi Arne, I was able to test this out and it worked exactly how you explained. Thanks for that. Identity source was "Guest Users" but I am not sure why it didnt work earlier. The only problem I found with this solution unfortunately is that Android 11 no longer supports "Don't validate" option for CA certificate when using PEAP/MSCHAPv2. So if your EAP Authentication is tied to an certificate signed by your internal PKI, guests using Android 11 are now forced to trust the CA, and they can only trust it if its a well known CA they already have the root cert for by default or the root CA is imported onto the device (this option is not practical). So it leaves Android 11 users out of luck connecting via PEAP. Unless of course your EAP Authentication is tied to a well known CA.