Why does “provide guest access” always feel like a no-win situation? You have to give untrusted clients access to your managed network. You have to provide an easy workflow to approve and allow visitor devices a connection to your SSID. You have to carve out IP address space, but you’re not sure how many hosts you need on the subnet. The business says this is a “nice-to-have service for guests,” but if it breaks, it’s a Severity 1 ticket with an SLA nobody can quantify.
Life is rough for the network engineer managing this environment.
The best way to deliver this service is to define what kind of devices and users you will support, how to authenticate those devices/users, and how to logically—or physically—segregate the guest traffic from trusted networks. This method will aid you in the SLA development later on.
From a corporate employee access point of view, it’s important to have a firm policy that may read something like, “Corporate electronic assets connecting to the Corporate network must use non-guest means of connectivity.” Your staff should not use guest networks to bypass security or acceptable use policies (AUP) governing their access. This should be a management and HR issue; your employees are not guests.
If you have placards in your conference rooms identifying the guest SSID and WPA Pre-Shared Key (PSK) information, there’s nothing preventing your internal users from jumping on with corporate assets. On the other hand, if you have a guest lobby where dynamically created accounts must be approved by one person sitting at their desks, that workflow isn’t better than a placard. Insurmountable problem?
Solutions, Are There Any?
There are a few architecture possibilities to help you sort out this conundrum. I’m a big fan of captive portals requiring some form of end-user interaction, with self-registration where it makes sense. The type of interaction will depend on your business model and not all solutions fit every situation. To deep dive guest access configuration steps, read the Aruba Guest Access with ArubaOS Validated Design Reference guide.
There are three common solutions for access authentication. You may configure your captive portal so that guests acknowledge your corporate AUP. You may have users respond to a system-generated message sent to their email or mobile device. And finally, you may have a lobby administrator create accounts for guest users.
The first option fits very well in those high-traffic businesses. We’ve all been to these places – restaurants, pubs and department stores. Usually when the user connects to the Wi-Fi SSID, they are redirected to the captive portal. Normally greeted with a webpage, the user selects the checkbox acknowledging agreement with the AUP, security and privacy policies and off they go to web sites “unknown.” Most users never read these policies, so I always suggest providing links to the policy rather than having customers scroll through all the verbiage.
The second option is a great choice for guest access in an office setting. Do you need to provide Internet access for your IT consultant coming in to pitch a new opportunity? Redirect them to a portal that requests their corporate email address and/or mobile phone number. Here the user is given temporary Internet access so they can check their email for the response code. To prevent the public from unauthorized use, blacklist email addresses from free email providers like @gmail.com and @yahoo.com. Separate the wheat from the chaff!
Once the customer receives and enters the code into the authorization page of the captive portal, they are given full access according to your policy. Using certain authentication services may require additional applications or middleware. Aruba’s captive portal optionally uses Amigopod—in lieu of ArubaOS—for visitor management. If middleware is involved, don’t forget to check licensing or other system requirements.
The third option of a lobby administrator works in small offices with light guest traffic. Your workflow will depend on a human being creating and approving these new guest accounts. It’s not a very scalable solution, but, it works nonetheless.
One Size Doesn’t Always Fit
Have you ever asked a technical question to someone in the know expecting to hear, “This is the best way to do {x}…”? Their answer is often disappointing because it’s never concrete; rather “it depends.” In the case of guests you aren’t necessarily limited to a single access solution, so don’t pigeonhole yourself. A friend mentioned a recent visit to a partner office where the partner used a layered approach to guest Wi-Fi access.
This particular company used three alternatives for guest access – employee guest, WPA PSK for public events and employee-sponsored guests. Why the options? Sometimes your employees need guest access because of policy restrictions on the corporate SSID. Perhaps the helpdesk needs to test VPN access but the internal wireless security policy doesn’t allow IPsec outbound and guest does. Or perhaps you’d rather segregate IoT devices for different security postures.
If your organization opens up conference rooms for training classes, presentations or other events to non-employees, you may not want to leverage your security resources for these users. Create a new SSID and WPA PSK for each new event. Your requirement, in this case, is to provide a secure service to attendees. The nice thing is the password and SSID will go away when the event does. No unauthorized access in the future.
Finally, employee-sponsored guest access would be for those times your employees host guests requiring different access. Again, think of the IT consultant, external developers or auditors that may be onsite for a while. In this case, the guests fill out their contact information within the captive portal and are provided access based on the assigned policy.
The point here is that all of these solutions can be used simultaneously. You have separation of the different roles each of your customers need. It’s also very logical for troubleshooting connectivity or security events.
Last Call
Technical engineering and architecture is oftentimes difficult. There are so many possible fixes that a project may stall due to analysis paralysis. You need to think about how your services may be used by your customers and consider the technical options available. Sometimes you are limited to a single, “most best” solution. Other times, you can take a layered approach to your service mesh. We IT folks tend to think in binary (on or off) and can sometimes miss the forest for the digital trees.
Guest access can be tricky but the Aruba platform offers quite a few options to make visitor management less of a nightmare and tools to help the administration.
Originally published on the Aruba Blog by Brian Gleason, July 18, 2019
