Captive portal login allow receiving emails with generated credentials

[f_bonacini]

Hi all.

As the title says, my problem is the following:

• we're deploying an AH SSID inside a place with a high number of guests.
• the phone network is expected to blocked for this reason.
• However, we need to be able to forward emails with credentials to the clients registering on the portal so that they can login.
• The only possible solution would be to send these information by email even if the client has not logged in yet.
• Sending an SMS is not a valid option due to the phone network not being reliable.

My questions are:

1. is this possible to achieve by using the Walled garden of the CWP?
2. if it is possible, how can I achieve it? Because I've tried to white list some services of Google to allow Gmail, but the native app on my mobile phone and an iOs device I used for tests ares not receiving the emails.
3. If this is not possible, can clients data registered with only self registration be retrieved by my server somehow? Because I've tried to remove the "User Auth" check (see attached image), but by using the developers API "/v1/identity/credentials" I cannot get the data the user has inserted.

[f_bonacini · Accepted solution]

For those who'll stumble upon this same problem, here are a few guidelines that worked for me:

1 - Maximum of 64 rules.

Remember that the Walled Garden has a limited number of rules which can be inserted. At the time of writing, this limitation is of about 64 rules, regardless of their complexity. In other words you have to choose wisely which email domain providers you want to be enabled.

2 - Analyze email domain providers required resources.

Smaller email domain providers will usually put advertisement and other kind of analytic tools inside the resources they use to build their web app / native app. Without some of those, the application may refuse to work. You will have to check those applications individually.

Usually, big providers, such as Google, Apple, Microsoft and Yahoo, use less external tools, so it's easy to white list those applications domains and make them work. The same cannot be said for smaller providers which make a large use of in-app advertisement.

3 - Analyze https traffic to understand which DNS records must be added to the WalledGarden.

You can do this by opening the web app page inside of your browser and, by using the developer tools, check the Network panel to control the addresses of the requests.

This usually covers both the web application and the native application. However, this is not always true.

Again, small email providers may have created a native application where some resources need a particular DNS record to be accessible in order to work correctly (or be used at all).

If this is your case, then you will have to setup a sort of middleware on your PC and direct your device traffic to it so that you will be able to analyze all traffic coming from your test device.

4 - Devices make use of HTTP request to detect and activate the Captive portal land page.

As the title says and at the time of writing, to trigger the captive portal splash page, devices usually make an HTTP (not HTTPS) request to some predefined endpoint. For iOs is something like a .apple.com /some/path/ while for Android devices the endpoint can vary from Android distribution and physical device.

Therefore, to be sure that the Captive Portal will be correctly displayed regardless of the DNS rules set into the Walled Garden, make sure to enable only https traffic in your Walled Garden rules. Thats because when these connection endpoint cannot be reached, the device will automatically detect the captive portal and redirect the user to it.

5 - Max of 2MB of compressed archive can be deployed as Captive Portal to an access point device.

Do not build an over complex or too stylish Captive Portal splash page. At the time of writing, the compressed package sent to the access point configuration can be of a maximum of 2MB.

If your custom Captive portal makes use of too many resources or images, the ExtremeCloud manager will give you a deploy error when trying to transfer a compressed package whose size exceeds the limit mentioned above.

[f_bonacini]

Ok thank you. now I've a grasp on how to approach this issue.

[samantha_lynn]

You could enable a walled garden so they can get to their email only without fully connecting, but I don't think we can limit that to just five minutes via the registration portal.

[f_bonacini]

Back in the office.

Another curiosity I've come up with: is there the possibility, after a user has submitted their self registration data, to allow that user to have full Internet connectivity but just for, let's say, 5 minutes to allow them to get their credentials and then blocking their connection so that they have to login?