For the last few years, Aerohive Networks has been influencing the enterprise Wireless LAN market and driving innovation with our ground-breaking controller-less architecture and exciting new features like Private Pre-Shared Key, Wireless Service Level Assurance (SLA), TeacherView and native Active Directory integration. While the rest of the Wi-Fi vendors are trying to figure out how to make their access points work in a distributed architecture, Aerohive is continuing to improve and release new features that will forever change the game in the wireless LAN marketplace.
One of the features that Aerohive has had for the past few years is native directory integration, which simplifies using external authentication to secure a wireless networking platform without requiring any special licensing or an expensive controller. The HiveAPs can perform all RADIUS (Remote Authentication Dial In User Service) authentication functionality and use proven security protocols to interface with the directory server(s), both for the Aerohive WLAN and for other existing network infrastructure devices.
Regardless of whether it is Active Directory, Open Directory, LDAP, or eDirectory, the access point will talk to the directory server and use the learned information to authenticate users to the network much the same way a laptop joined to the domain will allow any domain user to log into it.
The AP runs FreeRADIUS, and therefore supports not only basic user authentication, but also advanced functionality like Dynamic Change of Authorization (RFC 3576), RADIUS proxy, and even integration with Library SIP (3M’s Standard Interchange Protocol). Like all other functionality in Aerohive’s Wi-Fi architecture, this feature is built to be fully resilient and redundant and can operate in all conditions short of a site-wide power failure.
The administrator can specify up to 4 HiveAPs to act as RADIUS servers, and interface with up to 4 different domains – or even use Global Catalog. If the access point designated as the RADIUS server becomes inaccessible, the next available HiveAP will take over authentication. If access to the directory server is malfunctioning, the HiveAP can use the Samba technology to cache user credentials for users who have already authenticated, and continue allowing them to access the network until the directory server comes back online. This means not only do you not have to worry about implementing an authentication server at every remote location, but you also don’t have to worry that if access to your corporate location is unavailable, users will not be able to authenticate to the network.
Native directory authentication is helpful for setting up wireless 802.1X, Captive Web Portal authentication, and even for use with non-Aerohive devices like your firewalls and switches!
Shouldn’t all wireless companies make advanced authentication this easy?