Difference between revisions of "Information Systems:Implementing staff and guest WiFi networks"

From uniWIKI
Jump to navigation Jump to search
Line 24: Line 24:
   
 
While MAC authentication + captive portal achieves the requirements above, our specific implementation comes with a few significant limitations/caveats:
 
While MAC authentication + captive portal achieves the requirements above, our specific implementation comes with a few significant limitations/caveats:
* Our wireless infrastructure uses one of the APs as the controller (a.k.a virtual AP controller). Since it has limited resources, WiNG cannot run a database server/service.
+
* Our wireless infrastructure uses one of the APs as the controller (a.k.a one AP is in 'Virtual AP' mode). Since it has limited resources, WiNG on a virtual AP cannot run a database server/service. A database is necessary to store information, and thus it is logical that the absence of one means the record-keeping for wireless traffic is minimal and temporary. This imparts the following limitations:
  +
:* For MAC authentication + captive portal fallback (the scheme being proposed for the staff network), self-registration of devices is not possible. That is, MAC entries (for MAC authentication) in the RADIUS database must be manually added.
* Captive portal.
 
  +
:* The 'remembering' of devices by Captive Portal across APs does not seem to work properly. Again, this is likely due to MAC address caching staying local to an AP rather than querying a central database run by a dedicated controller.
  +
:* SMS and email delivery of OTPs (one-time passwords) may not also be possible.
  +
  +
   
   

Revision as of 10:39, 8 November 2017

In progress.

Overview

This page will document the design/implementation of staff and guest wireless networks. This mini-project builds upon the current, recently upgraded wireless setup, which was acquired and implemented primarily to serve the RF guns in the DC. Wireless hardware is already in place; this documentation relates only to software configuration of these new networks.

It is worth noting that these staff and guest wireless networks were/are not a requirement - rather this is a side project to get more value out of the wireless infrastructure and to provide a perk to staff and guests.

Configuration

Staff network

  • SSID: uwd_staff
  • Authentication: MAC authentication + Captive Portal fallback.
  • Encryption method: TBD

The staff network will use MAC authentication as the primary authentication method and captive portal as the fallback. The reason this particular scheme is being used is to satisfy the following conditions, as decided on by management:

  • Staff should see a sign-in page initially, where they can authenticate their device using pre-defined user credentials. (Any web page presentation requires captive portal.)
  • Initial sign-in should also present a Terms of Conditions page that they must accept.
  • After initial login, staff would not be required to frequently re-authenticate using captive portal. Their device should be 'remembered' as being 'approved'. (MAC address uniquely identifies network devices.)
  • Ability to identify user/devices on the network to some extent. (Prevents use of pre-shared key).

WPA-Enterprise is commonly used in enterprise wireless deployments, but where EAP is involved, certificates are required. That level of security is just a bit beyond what the company needs, considering that the staff and guest wireless networks will not have access to the company intranet.

Caveats

While MAC authentication + captive portal achieves the requirements above, our specific implementation comes with a few significant limitations/caveats:

  • Our wireless infrastructure uses one of the APs as the controller (a.k.a one AP is in 'Virtual AP' mode). Since it has limited resources, WiNG on a virtual AP cannot run a database server/service. A database is necessary to store information, and thus it is logical that the absence of one means the record-keeping for wireless traffic is minimal and temporary. This imparts the following limitations:
  • For MAC authentication + captive portal fallback (the scheme being proposed for the staff network), self-registration of devices is not possible. That is, MAC entries (for MAC authentication) in the RADIUS database must be manually added.
  • The 'remembering' of devices by Captive Portal across APs does not seem to work properly. Again, this is likely due to MAC address caching staying local to an AP rather than querying a central database run by a dedicated controller.
  • SMS and email delivery of OTPs (one-time passwords) may not also be possible.



Guest network

Authentication: Captive Portal