Multiple devices when phone number used as the username in ISE Guest Self-Registration

[Amir Asfandyarov]

Hello All,

Thanks to Jason and others, solution described in  ISE Guest Self-Registration phone number as the username is working perfectly in ISE 2.1

The major issue I cannot find a way to solve is the following:

Customer wants to allow up to 3 devices to be connected via the same username. That is, to me, a very common scenario which, for example, a typical hotel hotspot will provide (say, a Phone, an IPAD and a business laptop).

The "single username" collision issue is unavoidable in the following scenario:

- Username has expired at, say 3 pm and is not purged yet - waiting for 1 am;

- User connects via a new device (say, using his laptop while previous he was using his cell);

- We are making AuthZ rules based on endpoints but as this a new endpoint for this user, it has not been allocated to a group, hence we redirect to a Portal where Customer tries to authenticate and fails as user is expired...

Trying to think of any workarounds but cannot think of any?

Also, thing with auto-generated usernames allows user to keep sensing SMS/create usernames nearly indefinitely which does not seems correct either (in case Customer wants to limit to only several devices - that also allows to keep username/SMS explosion to a minimum)?

Limiting user to a single device without allowing user to control them (will be also impossible with expired username) is not an option either...

Any ideas how to approach this?

Thank you!

Amir

[Jason Kunst]

I understand the problem however I am not really have have an easy solution for that

As you stated the unique username has expired but not yet purged. And there is no way to reinstate an account (accept by a sponsor or specialized portal via API class?). So if you set to daily then unless you expired the account at midnight the user is stuck

And there is no way to set when it expires via self registration as it's by hours or days but not set time

Trying to do special flows without facilities in the box sometimes doesn't work out all of what's needed but we try our best to come up with workarounds that maybe works most of the time, granted we would like to address the more use cases the better

How about an external registration portal to manage it via API this way you're able to control and track the username as the phone number if the user has expired but they should still have access because they are valid patrons of the hotel then the system can decide that logic and reinstate the account

I'm not really sure how you're managing who's able to register or not

What we need are the following features

Ability for user to reinstate themselves via self-reg portal? may need to tie into some sortof external data base via ODBC or LDAP To look up if a person is still a valid patron as well

Ability to only allow registration via a cell number 1 time in x hours perhaps

Missed anything?

[Amir Asfandyarov]

Hello Jason,

Thank  you for your answer - yes, I understood that there are no workarounds for us here

>>How about an external registration portal to manage it via API this way you're able to control and track the username as the phone number if the user has expired but they should still have access because they are valid patrons of the hotel then the system can decide that logic and reinstate the account

[Amir] Well, our case is a large venue (exposition complex), so it is close to a stadium/event type of thing. Although Guest API is a possible solution, Customer wanted so much to keep things local on ISE ("you have portal on ISE anyway, don't you?) and also reinstating the account will mean extending it for another period of validity which defeats the whole purpose of providing 1,2 or 3-day access.

>>I'm not really sure how you're managing who's able to register or not

[Amit] Well, just any user with a valid cell phone #- that is the way authorities track the user identity.

>>Ability for user to reinstate themselves via self-reg portal? may need to tie into some sortof external data base via ODBC or LDAP To look up if a person is still a valid patron as well

Ability to only allow registration via a cell number 1 time in x hours perhaps

[Amir] In a typical event/stadium/etc environment a possibility to reinstate the account is a possible option indeed. In our case we do not care too much if person will get "lengthier" access as long as he is authenticated via his cell phone.

With this we could avoid collision. Another thing is to somehow rework internal logic and provide a tickbox (per guest user type) to purge user immediately after expiry, but I bet that might not be possible on platform due to some hidden DB/logic-related limitations.

I could not find a way to programmatically purge Guest User Database - I guess that is not possible and moreover, is not really possible to do it frequently (otherwise why do we do this at 3 am)?

Thank you, as always.

Regards, Amir

[Jason Kunst]

Seems to me why not just create accounts that are good for longer than the user needs them? Then they would be purged at later date?

Otherwise you're trying to do too much work?

It seems like they are free accounts so what is the problem if the accounts last longer so you don't have collisions?

Also have you looked at CMX or EMSP products? They might already do what you need.

Let me think about the other line items here

[Amir Asfandyarov]

Other products won't work as we're given ISE and requirement to create Guest Portal so this is something outside of my control .

I've probably confused everyone, apologies - this is NOT a hotel, that was just an analogy. This is a WiFi service at exhibition center.

Correct, this is a free service - my concerns with longer account duration are:

1) Maximum amount of Guest Users in the DB (I remember something like 1,5M ?) which we can hit if we create users for the duration of the event and won't purge them. I could end up creating users which are lasting for 90+ days and forget about that issue but scalability will be an issue then.

2) If I make duration of the Guest User account smaller than event itself  but still longer than a typical use-case (visitor coming maybe once or twice within 1 week) then we can hit an issue with visitor coming several times outside of the period and he will still hit this corner-case scenario with expired user (that is possible).

I think Paul has given a very good idea in the answer below - we may end up with 1-day accounts and purge them daily, I will need to test this though.

[paul]

Amir,

Let me ask you a question on the exact requirements of the customer. The fact that this is an open SSID it sounds like they are basically saying “Anyone within Wi-Fi range with a valid cell phone number can get on and potentially register multiple devices.”. There is no verification that the cell phone is registered to a user at the conference. It could be someone just wanting free Wi-Fi.

Do they have a requirement that the user accept an AUP?

If there is no AUP then why not just do a PSK that is given out during registration? Then shut down the SSID at night when the convention is not on.

If they require AUP, in the newest WLC code you can do PSK with AUP as well.

These are discussion I usually have with customers. Just curious.

Hopefully my previous suggestion works. I would be interested to see how your testing goes.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[Amir Asfandyarov]

Hello Paul,

First of all, thanks for all your suggestions.

So, the important thing with SMS is that authorities mandate ALL accounts to be tied to a mobile number - that is, password should arrive via SMS and that is a method to actually track WiFi user (another option will be sponsored access which by definition tracks the identity of the user). We cannot just have AUP - that would be much-much-much simpler in that case of course), same answer for PSK.

I will update the thread after the testing.

Amir

[Amir Asfandyarov · Accepted solution]

OK, this idea has failed Customer will have this even opened from 9 am to 1 am during some of the days, so that won't work.

Another one came to your mind which we want to test now:

- create a script which gets all users from a particular User Type (via API);

- suspend all those users 1 or 2 hours before purging (2 or 3 am); As far as I can see, suspension marks users for purging.

- configure purging to run at, say, 4 am.

- run this script daiy on external server - that will first suspend all "1-day users" and then hopefully will clean them up.

Guys, do you see any flaws here, will that work? To me it should, will write a script now and test.

Regards, Amir

[Jason Kunst]

Sounds good ultimately wondering what type of solution we could offer in box if any

please when you're done let's work offline through email

[Amir Asfandyarov]

Hello All,

So, reporting on the progress so community could benefit from it (and contribute ).

1. Idea from ISE Guest Self-Registration phone number as the username does not work well for us as it seems that behavior has been changed. Previously, as described in the article above, you could base the authorization rule off the endpoint group (EP) and purge EP group later. However, in 2.1p3 endpoint is immediately removed from EP once associated username expires (we do not wait until purge time comes), so user cannot access network anymore from previously registered MAC.

So, unique username combination + authorization rule based on EP does not work in 2.1p2 (at least for us).

2. I've written an ISE ERS API script which a) retrieves users of a particular Guest Type b) parses the list and composes XML c) sends XML in a bulk deletion request towards ISE to delete users.

This script has been installed as a cron job in a separate Linux server and runs at ~2am. I've also written a script to bulk create users (to test deletion script) - so, with 10K users on a portal it takes about 35 mins to delete them (via bulk job, a batch of 4500 users). So need to account for it - 30K will be deleted in roughly  2 hours, then endpoint purge will happen, than EP purge, then backup and ideally I do not want all these to overlap as ISE is s sensitive beast (I think ).

We are about to test how scripted workaround works, I am expecting the following caveats:

- we may hit CSCvd16176 so I need to test;

- I still do not know how to deal with PAN failover - if that happens, script (which is tied to primary PAN IP) will not work and next morning we will have a nightmare

Ah and yes, suspension was not marking users for purging to had to use delete operation directly.

Will report results later.

Amir

[paul]

I haven't tried this before but was just playing around with this.  The multiple devices per username should work.  I am testing on 2.2 and I only used the java script on the self-registration portal. 

So the user comes into the standard self-registration and has the option to enter the username/password or click the "Don't have an Account?" link.  I modified the username text to say "Phone Number" on the customization.

User clicks on the "Don't have an Account?" link and goes to self registration.  I have removed all fields except username and phone number.  The java script hides the username.  User types in their phone number and clicks Register.  The user ID with their phone number is generated and credentials texted to them. 

As part of the success message or text you can let the user know that the username/password can be used to register up to 3 devices.

Now they click sign-in and use their information that was texted to them.  The portal is tied to a guest type that allows 3 registered devices.  I set the expiry time for the user credentials to 8 hours after creation..

As you said this is a convention.  I shouldn't need to handle people registering at all hours of the night.  Let's say I want to accommodate someone registering up to 8:00 p.m.  That means the guest user would expire at 4:00 a.m and configure my guest purge job to run at 4:30 a.m.  I configure my endpoint purge to run at 5:00 a.m. 

So after the endpoint purge runs at 5 everything is ready for the new day.

I haven't fully tested this, but wouldn't that work.  I know in a hotel scenario where guests are registering 24/7 this wouldn't work but for a convention scenario it should work.