Review: Aerohive HiveUI - Page 2
March 27, 2009
The final task in the concise and well-illustrated HiveUI QuickStart guide is configuring a test WLAN. It is at this point that basic HiveUI provisioning becomes flat-out simple as compared to HiveManager. In HiveManager, WLAN policies are bound to a rich list of reusable SSID profiles, traffic filters, and QoS policies that can be selectively applied to each HiveAP. In HiveUI, basic WLAN setup applies to the entire hive and requires nothing more than most consumer APs: a list of SSIDs, defined by name, encryption, and authentication.
In our view, HiveUI succeeds in keeping basic tasks simple without reducing everyone to that low common denominator. But there are limits to what can be accomplished this way. By default, each SSID is bound to one auto-generated user profile and default priority. Alternatively, those with multi-purpose WLANs can configure QoS objects that apply per-user and per-priority rate limits and scheduling algorithms. Admins that head down the latter path must then bind QoS objects to uniquely-numbered user profiles that determine how authorized traffic will be treated, based upon attributes assigned at authentication time.
While these profiles are not rocket science, they are a hefty step beyond basic WLAN setup. On the other hand, many advanced options are not accessible through HiveUI--including Aerohive's new Dynamic Airtime Scheduling (see Part 2 of our review). Larger businesses that use HiveUI to experiment with a small test WLAN can step up to HiveManager when ready for rollout--but they won't have full access to enterprise-class options until they do.
For our test, we configured three SSIDs: a guest WLAN, a WPA2-Personal (PSK) WLAN, and a WPA2-Enterprise (802.1X) WLAN. Our WPA2-Personal WLAN was no more difficult to configure than on most SOHO APs. Small businesses often stop there--open guest WLANs invite abuse, while 802.1X requires infrastructure they don't have. HiveUI can help small businesses circumvent both of these common pain-points.
For starters, HiveUI provides a "zero-config" internal RADIUS server. Aimed squarely at small businesses, this on-board HiveUI service is a simplified version of HiveManager's RADIUS server. In enterprise 802.1X deployments, admin configures one or more RADIUS servers with digital certificates, user/group policies, and access to a user account database like ActiveDirectory. Small businesses that need this can still configure HiveUI to consult an external RADIUS server for any SSID.
However, those that want 802.1X benefits without this complexity can use the HiveUI internal server to authenticate up to 512 permanent or temporary logins. For example, HiveUI can create randomly-generated temporary logins and passwords to be used by guests for up to 120 hours (see Figure 4). While this internal RADIUS server can't share accounts defined for your Windows domain, it could be just the ticket for many small WLANs.
Beyond go/no-go authentication, each defined login is bound to a user profile associated with an authorized SSID, IP packet filters, bandwidth limits, QoS priorities, and security requirements. For example, we let our temporary users connect to our unencrypted guest SSID, sending only DNS, DHCP, and Web traffic at best effort priority after passing captive portal login. But we let our permanent users connect to our WPA2-Enterprise SSID, sending any kind of AES-encrypted IP traffic (including high priority traffic) after passing 802.1X authentication.
Figure 5. Guest User Profile with Bandwidth and Traffic Restrictions
Here again, HiveUI caters to simple needs, while providing unobtrusive hooks for greater control. Those control objects--user profiles, QoS objects, and firewall rules--are configured using separate HiveUI menus that are slightly more complex (see Figure 5). However, we found one simplification that generated extra work: because each login is bound to just one user profile, anyone allowed to connect to more than one SSID needs multiple logins and passwords.
To facilitate guest access, HiveUI (and HiveManager) provide embedded captive Web portals. Any SSID can be configured to redirect HTTP/HTTPS from unauthenticated clients to AP-resident captive portals that display a RADIUS authentication page or a self-registration page. RADIUS authentication is carried out by an internal or external server as described for 802.1X. Self-registration uses a Web page to request name, e-mail, etc, before permitting unconditional access. HiveManager supports custom landing pages; HiveUI uses Aerohive default pages.
Note that using embedded authentication introduces central dependencies not otherwise present in cooperative control hives. Specifically, if the HiveAP running HiveUI becomes unreachable, existing guest and 802.1X sessions continue, but new sessions cannot be authenticated. A guest who tries to connect will be redirected to his local HiveAP's captive portal, but timeout on RADIUS authentication. An authenticated 802.1X client can roam to other HiveAPs using fast reconnect and cached pairwise master keys (known to all HiveAPs), but an 802.1X client that deauthenticates cannot reconnect until the HiveAP running HiveUI becomes available.