Chapter 10 Bring Your Own Device (BYOD) and Guest Access

IN THIS CHAPTER, YOU WILL LEARN ABOUT THE FOLLOWING:

✓ Mobile Device Management

• Company-issued devices vs. personal devices

• MDM architecture

• MDM enrollment

• MDM profiles

• MDM agent software

• Over-the-air management

• Application management

✓ Self-service device onboarding for employees

• Dual SSID onboarding

• Single SSID onboarding

• MDM vs. Self-service onboarding

✓ Guest WLAN access

• Guest SSID

• Guest VLAN

• Guest firewall policy

• Captive web portals

• Client isolation, rate limiting, and web content filtering

• Guest management

• Guest self-registration

• Employee sponsorship

• Social login

• Encrypted guest access

✓ Network access control (NAC)

• Posture

• NAC and BYOD

• OS fingerprinting

• AAA

• RADIUS change of authorization

For many years, the primary purpose of enterprise WLANs was to provide wireless access for company-owned laptop computers used by employees. Some vertical markets, such as healthcare, retail, and manufacturing, also required WLAN access for company-owned mobile devices such as VoWiFi phones and wireless barcode scanners. However, in recent years there has been a massive population explosion of Wi-Fi personal mobile devices. Wi-Fi radios are now the primary communications component in smartphones, tablets, PCs, and many other mobile devices.

Although mobile devices initially were intended for personal use, organizations found ways of deploying corporate mobile devices with custom software to improve productivity or functionality. Employees also increasingly want to use their personal mobile devices in the workplace. Employees have expectations of being able to connect to a corporate WLAN with multiple personal mobile devices. The catchphrase of bring your own device (BYOD) refers to the policy of permitting employees to bring personally owned mobile devices such as smartphones, tablets, and laptops to their workplace. A BYOD policy dictates which corporate resources can or cannot be accessed when employees connect to the company WLAN with their personal devices.

The main focus of this chapter is how security is used to control and monitor BYOD access to a WLAN. Mobile device management (MDM) solutions can be used to remotely manage and control company-owned as well as personal mobile Wi-Fi devices. MDM solutions use server software or cloud services to configure client settings, along with client applications to control and monitor what the user can do. Additionally there is a growing trend to use self-service BYOD solutions where employees can securely provision their personal WLAN devices. Network access control (NAC) integrates different security technologies, such as AAA, RADIUS, client health check, guest services, and client self-registration and enrollment. Using these technologies, NAC can control and monitor client access on the network. NAC can be used to provide authentication and access control of MDM-managed devices, corporate Wi-Fi devices, or BYOD and guest devices.

This chapter will also cover the many components of WLAN guest access and how it has evolved over the years. Guest access technology includes support for visitor devices along with employee BYOD devices.

Mobile Device Management

Consumerization of IT is a phrase used to describe a shift in information technology (IT) that begins in the consumer market and moves into business and government facilities. It has become common for employees to introduce consumer market devices into the workplace after already embracing new technology at home. In the early days of Wi-Fi, most businesses did not provide wireless network access to the corporate network. Due to the limited wireless security options available at that time, along with a general mistrust of the unknown, it was common for companies to avoid implementing WLANs. However, because employees enjoyed the flexibility of Wi-Fi at home, they began to bring small office/home office (SOHO) wireless routers into the office and install them despite the objections of the IT department. Eventually, businesses and government agencies realized that they needed to deploy WLANs to take advantage of the technology as well as manage the technology.

Personal mobile Wi-Fi devices, such as smartphones and tablets, have been around for quite a few years. The Apple iPhone was first introduced in June 2007, and the first iPad debuted in April 2010. HTC introduced the first Android smartphone in October 2008. These devices were originally meant for personal use, but in a very short time, employees wanted to also use their personal devices on company WLANs. Additionally, software developers began to create enterprise mobile business applications for smartphones and tablets. Businesses began to purchase and deploy tablets and smartphones to take advantage of these mobile enterprise applications. Tablets and smartphones provided the true mobility that employees and businesses desired, and within a few years, the number of mobile devices connecting to corporate WLANs surpassed the number of laptop connections. This trend is continuing, with many, if not most, devices shipping with Wi-Fi as the primary networking adapter. Many laptop computers now ship without an Ethernet adapter because the laptop Wi-Fi radio is used for network access.

Because of the proliferation of personal mobile devices, a BYOD policy is needed to define how employees’ personal devices may access the corporate WLAN. A mobile device management (MDM) solution might be needed for onboarding personal mobile devices as well as company-issued devices (CIDs) to the WLAN. Corporate IT departments can deploy MDM servers to manage, secure, and monitor the mobile devices. An MDM solution can manage devices across multiple mobile operating systems and across multiple mobile service providers. Most MDM solutions are used to manage iOS and Android mobile devices. However, mobile devices that use other operating systems such as BlackBerry OS and Windows Phone can also be managed by MDM solutions. Although the main focus of an MDM solution is the management of smartphones and tablets, some MDM solutions can also be used to onboard personal Mac OS and Chromebook laptops. A few of the devices that can be managed by an MDM solution are shown in Figure 10.1.

Some of the WLAN infrastructure vendors have developed small-scale MDM solutions that are specific to their WLAN controller and/or access point solution. However, the bigger MDM companies sell overlay solutions that can be used with any WLAN vendor’s solution.

FIGURE 10.1 Personal mobile devices with Wi-Fi radios

These are some of the major vendors selling overlay MDM solutions:

VMware AirWatch—www.air-watch.com

Citrix—www.citrix.com

IBM—www.maaS360.com

JAMF Software—www.jamfsoftware.com

MobileIron—www.mobileiron.com

Company-Issued Devices vs. Personal Devices

An MDM solution can be used to manage both company-issued devices and personal devices. However, the management of CID and BYOD is quite different. A company mobile device was purchased by the company with the intent of enhancing employee performance. A tablet or smartphone might be issued to an individual employee or shared by employees on different shifts. Commercial business applications, and very often industry-specific applications, are deployed on these devices. Many companies even develop in-house applications unique to their own business needs. Very often company mobile devices are deployed to replace older hardware. For example, inventory control software running on a tablet might replace legacy handheld bar code scanners. A software Voice over Internet Protocol (VoIP) application running on a smartphone might be used to replace WLAN VoWiFi handsets. The IT department will usually choose one model of mobile device that runs the same operating system.

The management strategy for company mobile devices usually entails more in-depth security because very often the CIDs have company documents and information stored on them. When company devices are provisioned with an MDM solution, many configuration settings such as virtual private network (VPN) client access, email account settings, Wi-Fi profile settings, passwords, and encryption settings are enabled. The ability for employees to remove MDM profiles from a CID is disabled and the MDM administrator can remotely wipe company mobile devices if they are lost or stolen. The MDM solution is also used for hardware and software inventory control. Because these devices are not personal devices, the IT department can also dictate which applications can or cannot be installed on tablets and/or smartphones.

The concept of BYOD emerged because personally owned mobile devices are difficult to control and manage, while allowing access to the enterprise network. Access and control may be managed using an MDM or NAC solution, but BYOD needs are different than CID needs. Employees, visitors, vendors, contractors, and consultants bring a wide range of personal devices—different makes and models loaded with a variety of operating systems and applications—to the workplace. Therefore, a different management strategy is needed for BYOD. Every company should have its own unique BYOD containment strategy while still allowing access to the corporate WLAN. For example, when the personal devices are provisioned with an MDM solution, the camera may be disabled so that pictures cannot be taken within the building. As shown in Figure 10.2, many restrictions can be enforced on a CID or BYOD device after it has been enrolled in the MDM solution.

FIGURE 10.2 Device restrictions

As an alternative to MDM solutions, NAC solutions can be used to authenticate BYOD devices along with controlling access to the enterprise network without having to necessarily install software on the client device. NAC solutions do not provide control of the individual device but can provide extensive control over the level of access the BYOD device has on the network.

MDM Architecture

The basic architecture of any MDM solution consists of four main components:

Mobile Device The mobile Wi-Fi device requires access to the corporate WLAN. The mobile device can be either a company-owned or an employee-owned device. Depending on the MDM vendor, multiple operating systems may be supported, including iOS, Android, Chrome, and Mac OS, among others. The mobile devices are not allowed onto the corporate network until an enrollment process has been completed and an MDM profile has been installed.

AP/WLAN Controller All Wi-Fi communications are between the mobile devices and the access point to which they connected. If the devices have not been enrolled via the MDM server, the AP or WLAN controller quarantines the mobile devices within a restricted area of the network known as a walled garden. Mobile devices that have been taken through the enrollment process are allowed outside of the walled garden.

MDM Server The MDM server is responsible for enrolling client devices. The MDM server provisions the mobile devices with MDM profiles that define client device restrictions as well as configuration settings. Certificates can be provisioned from the MDM server. MDM servers can also be configured for either enrollment whitelisting or blacklisting. Whitelisting policies restrict enrollment to a list of specific devices and operating systems. Blacklisting policies allow all devices and operating systems to enroll except for those that are specifically prohibited by the blacklist. Although the initial role of an MDM server is to provision and onboard mobile devices to the WLAN, the server is also used for client device monitoring. Device inventory control and configuration are key components of any MDM solution. The MDM server usually is available as either a cloud-based service or as an on-premises server that is deployed in the company datacenter. On-premise MDM servers can be in the form of a hardware appliance or can run as software in a virtualized server environment.

Push Notification Servers The MDM server communicates with push notification servers such as Apple Push Notification service (APNs) and Google Cloud Messaging (GCM) for over-the-air management of mobile Wi-Fi devices. Over-the-air management will be discussed in greater detail later in this chapter.

There are other key components to an MDM architecture deployment. MDM servers can be configured to query Lightweight Directory Access Protocol (LDAP) databases, such as Active Directory. Typically, a corporate firewall also will be in place. Proper outbound ports need to be open to allow for communications between all of the various components of the MDM architecture. For example, Transmission Control Protocol (TCP) port 443 needs to be open for encrypted SSL communications between the AP and the MDM server as well as SSL communications between the mobile device and the MDM server. TCP port 5223 needs to be open so that mobile devices can communicate with APNs. TCP ports 2195 and 2196 are needed for traffic between the MDM server and APNs. TCP ports 443, 5223, 5229, and 5330 are required for communication between mobile devices and GCM. Communications between the MDM server and GCM require TCP port 443 to be open.

MDM Enrollment

When MDM architecture is in place, mobile devices must go through an enrollment process in order to access network resources. The enrollment process can be used to onboard both company-issued devices and personal devices. Figure 10.3 illustrates the initial steps of the MDM enrollment process.

FIGURE 10.3 MDM enrollment—initial steps

Step 1: The mobile device connects with the access point. The mobile device must first establish an association with an AP. The Wi-Fi security could be open, but usually the CID or personal devices are trying to establish a connection with a secure corporate SSID that is using 802.1X or preshared key (PSK) security. At this point, the AP holds the mobile client device inside a walled garden. Within a network deployment, a walled garden is a closed environment that restricts access to web content and network resources while still allowing access to some resources. A walled garden is a closed platform of network services provided for devices and/or users. While inside the walled garden designated by the AP, the only services that the mobile device can access are Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), push notification services, and the MDM server. To escape from the walled garden, the mobile device must find the proper exit point, much like in a real walled garden. The designated exit point for a mobile device is the MDM enrollment process.

Step 2: The AP checks whether the device is enrolled. The next step is to determine if the mobile device has been enrolled. Depending on the WLAN vendor, the AP or a WLAN controller queries the MDM server to determine the enrollment status of the mobile device. If the MDM is provided as a cloud-based service, the enrollment query crosses a WAN link. (An on-premise MDM server typically will be deployed in a DMZ.) If the mobile device is already enrolled, the MDM server will send a message to the AP to release the device from the walled garden. Unenrolled devices will remain quarantined inside the walled garden.

Step 3: The MDM server queries LDAP. Although an open enrollment process can be deployed, administrators often require authentication. The MDM server queries an existing LDAP database, such as Active Directory. The LDAP server responds to the query, and then the MDM enrollment can proceed.

Step 4: The device is redirected to the MDM server. Although the unenrolled device has access to DNS services, the quarantined device cannot access any web service other than the MDM server. When the user opens a browser on the mobile device, it is redirected to the captive web portal for the MDM server, as shown in Figure 10.4. The enrollment process can then proceed. For legal and privacy reasons, captive web portals contain a legal disclaimer agreement that gives the MDM administrator the ability to restrict settings and remotely change the capabilities of the mobile device. The legal disclaimer is particularly important for a BYOD situation where employees are onboarding their own personal devices. If the user does not agree to the legal disclaimer, they cannot proceed with the enrollment process and will not be released from the walled garden.

FIGURE 10.4 MDM server—enrollment captive web portal—step 4

Step 5: The device installs the certificate and MDM profile. Once enrollment begins, a secure over-the-air provisioning process for installing the MDM profile is needed. Over-the-air provisioning differs between different device operating systems, but using trusted certificates and SSL encryption is the norm. For this example we will describe how iOS devices are provisioned. For iOS devices, the Simple Certificate Enrollment Protocol (SCEP) uses certificates and Secure Sockets Layer (SSL) encryption to protect the MDM profiles. The user of the mobile device accepts an initial profile that is installed on the device. After installation of the initial profile, device-specific identity information can be sent to the MDM server. The MDM server then sends an SCEP payload that instructs the mobile device about how to download a trusted certificate from the MDM certificate authority (CA) or a third-party CA. Once the certificate is installed on the mobile device, the encrypted MDM profile with the device configuration and restrictions payload is sent securely to the mobile device and installed. Figure 10.5 depicts the installation of MDM profiles using SCEP on an iOS device.

FIGURE 10.5 Certificate and MDM profile installation—step 5

Step 6: The MDM server releases the mobile device. As shown in Figure 10.6, once the device has completed the MDM enrollment, the MDM server sends a message to the AP or WLAN controller to release the mobile device from the walled garden.

Step 7: The mobile device exits the walled garden. The mobile device now abides by the restrictions and configuration settings defined by the MDM profile. For example, use of the mobile device’s camera may no longer be allowed. Configuration settings, such as email or VPN settings, also may have been provisioned. The mobile device is now free to exit the walled garden and access the Internet and corporate network resources. Access to available network resources is dictated by the type of device or the identity of the user. For example, company-owned devices may have access to all network servers whereas personal devices may only access specific servers such as the email server.

FIGURE 10.6 The mobile device exits the walled garden in the final step.

MDM Profiles

We have already learned that MDM profiles are used for mobile device restrictions. The MDM profiles can also be used to globally configure various components of a mobile device. MDM profiles are essentially configuration settings for a mobile device. As the example in Figure 10.7 shows, MDM profiles can include device restrictions, email settings, VPN settings, LDAP directory service settings, and Wi-Fi settings. MDM profiles can also include webclips, which are browser shortcuts that point to specific URLs. A webclip icon is automatically installed on the desktop screen of the mobile device. For example, a company-issued device could be provisioned with a webclip link to the company’s internal intranet.

The configuration profiles used by Mac OS and iOS devices are Extensible Markup Language (XML) files. Apple has several tools to create profiles, including the Apple Configurator and the iPhone Configuration Utility. For manual installations, the XML profiles can be delivered via email or through a website. Manual installation and configuration is fine for a single device, but what about in an enterprise where thousands of devices might need to be configured? In the enterprise, a method is needed to automate the delivery of configuration profiles, and that is where an MDM solution comes into play. MDM configuration profiles are created on the MDM server and installed onto the mobile devices during the enrollment process.

FIGURE 10.7 MDM profile settings

As mentioned, one aspect of an MDM profile is that the Wi-Fi settings can be provisioned. Company-owned devices can be locked down with a specific Wi-Fi profile that designates the corporate SSID and proper security settings. An MDM profile can also be used to deploy Wi-Fi settings to an employee’s personal device. If 802.1X/EAP is deployed, a root CA certificate must be installed on the supplicant mobile device. An MDM solution is the easiest way to provision root CA certificates on mobile devices. Client certificates can also be provisioned if EAP-TLS is the chosen 802.1X security protocol.

MDM profiles can be removed from the device locally or can be removed remotely through the Internet via the MDM server.

MDM Agent Software

The operating systems of some mobile devices require MDM agent application software. For example, Android devices require an MDM agent application like the one shown in Figure 10.8. The Android OS is an open source operating system that can be customized by the various mobile device manufacturers. Although this provides much more flexibility, managing and administering Android devices in the enterprise can be challenging due to the sheer number of hardware manufacturers. An MDM agent application can report unique information about the Android device back to an MDM server, which can later be used in MDM restriction and configuration policies. An MDM agent must support multiple Android device manufacturers.

FIGURE 10.8 MDM agent application

An employee downloads the MDM agent from a public website or company website and installs it on their Android device. The MDM agent contacts the MDM server over the WLAN and is typically required to authenticate to the server. The MDM agent must give the MDM server permission to make changes to the device and function as the administrator of the device. Once this secure relationship has been established, the MDM agent software enforces the device restriction and configuration changes. MDM administration on an Android device is handled by the agent application on the device. Changes can, however, be sent to the MDM agent application from the MDM server via the Google Cloud Messaging (GCM) service.

Although iOS devices do not require MDM agent software, some MDM solutions do offer iOS MDM agents. The MDM agent on the iOS device could potentially send information back to the MDM server that is not defined by the Apple APIs.

Over-the-Air Management

Once a device has been provisioned and enrolled with an MDM server, a permanent management relationship exists between the MDM server and the mobile device. As shown in Figure 10.9, the MDM server can monitor such device information as its name, serial number, capacity, battery life, and the applications that are installed on the device. Information that cannot be seen includes SMS messages, personal emails, calendars, and browser history.

FIGURE 10.9 Device information

The mobile device can still be managed remotely, even if the mobile device is no longer connected to the corporate WLAN. The MDM server can still manage the device as long as the device is connected to the Internet from any location. The communication between the MDM server and the mobile devices requires push notifications from a third-party service. Both Google and Apple have APIs that allow applications to send push notifications to mobile devices. iOS applications communicate with the Apple Push Notification service (APNs) servers and Android applications communicate with the Google Cloud Messaging (GCM) servers.

As seen in Figure 10.10, the first step is for the MDM administrator to make changes to the MDM configuration profile on the MDM server. The MDM server then contacts push notification servers. A previously established secure connection already exists between the push notification servers and the mobile device. The push notification service then sends a message to the mobile device telling the device to contact the MDM server over the Internet. Once the mobile device contacts the MDM server, the MDM server sends the configuration changes and/or messages to the mobile device.

FIGURE 10.10 Over-the-air management

What kind of remote actions can an MDM administrator accomplish over the Internet?

• Make changes to the configuration.

• Make changes to the device restrictions.

• Deliver a message to the device.

• Lock the device.

• Wipe the device.

• Make application management changes.

Application Management

Enterprise MDM solutions also offer various levels of management of the applications that run on mobile devices. Once an MDM profile is installed, all of the applications installed on the device can be viewed from the MDM server, as shown in Figure 10.11. The MDM server can manage applications by whitelisting and/or blacklisting specific applications that can be used on the mobile devices. Managing applications on company-owned devices is commonplace; however, application management on employee’s personal devices is not as prevalent.

FIGURE 10.11 Mobile device applications

MDM solutions integrate with public application stores, such as iTunes and Google Play, in order to allow access to public applications. The MDM server communicates with the push notification server, which then places an application icon on the mobile device. The mobile device user can then install the application. The Apple Volume Purchase Program (VPP) provides a way for businesses and educational institutions to purchase apps in bulk and distribute them across their organization. Applications can be purchased and pushed silently to the remote devices. An MDM server can also be configured to deliver custom in-house applications that might be unique to the company.

As shown in Figure 10.12, eBooks can also be managed and distributed to mobile devices via an MDM platform. We suggest that your company make a bulk purchase of the CWSP Study Guide eBook.

FIGURE 10.12 MDM distribution of the CWSP Study Guide eBook

Self-Service Device Onboarding for Employees

As you have learned, MDM solutions can be used to manage and provision both company-owned devices as well as employee-owned WLAN devices. Typical configuration for BYOD management is self-service device onboarding solutions as opposed to a robust enterprise MDM. The main purpose of these onboarding solutions is to provide an inexpensive and simple way to provision employee personal WLAN devices onto a secure corporate SSID. A self-service device onboarding solution is not meant to offer all the monitoring and restriction aspects of a full-blown MDM. Instead, device onboarding provides a self-service method for an employee to configure the BYOD supplicant and install security credentials such as an 802.1X/EAP root CA certificate.

Consider this scenario: Jeff logs in to the enterprise network as an employee from his corporate computer using 802.1X/EAP. His username is verified in the LDAP database using RADIUS. In this scenario, Jeff is trusted as the user because his username and password are valid. His corporate laptop is trusted because his machine can be validated. However, Jeff using his corporate laptop is different from Jeff using his smartphone, Jeff using his personal laptop, or Jeff using his tablet.

In the world of authentication and encryption, 802.1X/EAP is typically the required method to provide secure access to corporate networks and data. However, configuration of the client supplicant is typically not a task that can be easily performed by a nontechnical user. Additionally, the root CA certificate needs to be securely transferred to the client device and installed. This can be a problem for corporations and employee BYOD users, since the corporation will not provide access without a properly configured device. As you can imagine, requiring a trained IT help desk person to configure employee personal devices is not practical. The solution is a process known as onboarding.

A properly configured and secured 802.1X/EAP network requires that a root CA certificate be installed on the supplicant. Installing the root certificate onto Windows laptops can be easily automated using a Group Policy Object (GPO) if the Windows laptop is part of the Active Directory (AD) domain. However, a GPO cannot be used for Mac OS, iOS, or Android mobile devices, or for personal Windows BYOD devices that are not joined to the AD domain. Manually installing certificates on mobile devices and employee-owned devices is an administrative nightmare.

The onboarding solution is most often used to install the root CA certificates on mobile devices to be used with an 802.1X/EAP-enabled SSID. Client certificates can also be provisioned with an onboarding solution. Some of the Wi-Fi vendors that offer dynamic PSK solutions also offer onboarding solutions that can provision mobile devices with Wi-Fi client profiles configured with unique individual PSKs.

Self-service onboarding solutions for personal employee devices can come in many different forms and are often WLAN vendor-specific. Onboarding solutions typically use an application that uses similar over-the-air provisioning aspects of MDM solutions to securely install certificates and Wi-Fi client profiles onto mobile devices. Self-service onboarding solutions may also use custom applications built using a WLAN vendor’s application programming interface (API). Regardless of the solution, the device onboarding normally requires an initially WLAN connection to complete the self-service process.

Dual-SSID Onboarding

Dual-SSID onboarding is performed using an open SSID and an 802.1X/EAP secure corporate SSID. The employee initially connects to the open SSID and will be prompted with a captive portal page. Depending on how onboarding is implemented, the employee may log in directly through the captive portal using their corporate username and password, or the employee may click on a link that would take them to an onboard login screen where they would enter their corporate username and password. The captive web portal authentication validates the employee’s username and password via RADIUS and LDAP. The captive web portal authentication is protected via HTTPS. After the employee logs in to the network, an onboarding application is typically downloaded to the mobile device. The onboarding application is then executed to securely download the 802.1X root certificate and/or other security credentials as well as provision the supplicant on the mobile device. Custom onboarding applications are often distributed via the open SSID. An onboarding solution for different types of users might also be available as a web-based application. Figure 10.13 shows a custom onboarding web application used by the Calgary Board of Education used to provision different security credentials to guests, students, and staff.

FIGURE 10.13 BYOD onboarding application

Courtesy of the Calgary Board of Education

After the employee device is provisioned using the onboarding application, it is ready to connect to the secure network. Because the secure network is a separate SSID, the employee would have to manually disconnect from the open SSID and reconnect to the secure SSID.

Single-SSID Onboarding

Single-SSID onboarding uses a single SSID that is capable of authenticating 802.1X/EAP-PEAP clients and 802.1X/EAP-TLS clients. The client initially logs in to the SSID using an 802.1X/EAP-PEAP connection, using their corporate username and password. After the device is logged on to the network, the employee would bring up a captive portal page, requiring the user to log in again, this time to validate that they are allowed to perform the onboard process. As with the dual-SSID process, an onboarding program is downloaded to the device and executed, and then the application downloads the server certificate via SSL and provisions the supplicant on the device.

After the employee device is configured, the RADIUS server will initiate a change of authorization (CoA) to the employee device, disconnecting the device from the network. The device will immediately reconnect to the same SSID, using either 802.1X/EAP-PEAP or 802.1X/EAP-TLS, depending on the wireless profile that was installed on the employee device. This time, the client will also validate the server certificate.

MDM vs. Self-Service Onboarding

MDM solutions are often the preferred choice for large corporations. An enterprise MDM gives a corporation the ability to manage and monitor company WLAN devices as well as provide a provisioning solution for employee personal WLAN devices. However, an MDM solution is not always the best choice for a BYOD solution. Enterprise MDM deployments are often cost-prohibitive for medium-size and small businesses. As previously mentioned, employees often do not like to use MDM due to privacy issues.

Self-service device onboarding solutions are typically much cheaper and simpler to deploy as an employee BYOD solution. Self-service onboarding solutions are used primarily to provision employee WLAN devices and are not used to enforce device restrictions or for over-the-air management. The privacy concerns are no longer an issue for the employee personal devices.

Depending on a company’s security requirements, MDM, self-service onboarding, or a combination of the two solutions can be chosen for a BYOD solution.

Guest WLAN Access

Although the primary purpose for enterprise WLANs has always been to provide employees wireless mobility, WLAN access for company guests can be just as important. Customers, consultants, vendors, and contractors often need access to the Internet to accomplish job-related duties. When they are more productive, employees will also be more productive. Guest access can also be a value-added service and often breeds customer loyalty. In today’s world, business customers have come to expect guest WLAN access. Free guest access is often considered a value-added service. There is a chance that your customers will move toward your competitors if you do not provide guest WLAN access. Retail, restaurants, and hotel chains are all prime examples of environments where wireless Internet access is often expected by customers.

The primary purpose of a guest WLAN is to provide a wireless gateway to the Internet for company visitors and/or customers. Generally, guest users do not need access to company network resources. Therefore, the most important security aspect of a guest WLAN is to protect the company network infrastructure from the guest users. In the early days of Wi-Fi, guest networks were not very common because of fears that the guest users might access corporate resources. Guest access was often provided on a separate infrastructure. Another common strategy was to send all guest traffic to a separate gateway that was different from the Internet gateway for company employees. For example, a T1 or T3 line might have been used for the corporate gateway, whereas all guest traffic was segmented on a separate DSL phone line.

WLAN guest access has grown in popularity over the years, and the various types of WLAN guest solutions have evolved to meet the need. In the following sections, we will discuss the security aspects of guest WLANs. At a minimum, there should be a separate guest SSID, a unique guest VLAN, a guest firewall policy, and a captive web portal. We will also discuss the many guest access options that are available, including guest self-registration.

Guest SSID

In the past, a common SSID strategy was to segment different types of users—even employees—on separate SSIDs; each SSID was mapped to an independent VLAN. For example, a hospital might have unique SSID/VLAN pairs for doctors, nurses, technicians, and administrators. That strategy is rarely recommended now because of the Layer 2 overhead created by having many SSIDs. Today, the more common method is to place all employees on the same SSID and leverage Remote Authentication Dial-In User Service (RADIUS) attributes to assign different groups of users to different VLANS. What has not changed over time is the recommendation that all guest user traffic be segmented onto a separate SSID. The guest SSID will always have different security parameters than the employee SSID, and therefore the necessity of a separate guest SSID continues. For example, employee SSIDs commonly use 802.1X/EAP security, whereas guest SSIDs are most often an open network that uses a captive web portal for authentication. Although encryption is not usually provided for guest users, some WLAN vendors have begun to offer encrypted guest access and provide data privacy using dynamic PSK credentials. Encrypted guest access can also be provided with 802.1X/EAP with Hotspot 2.0, which is discussed later.

Like all SSIDs, a guest SSID should never be hidden and should have a simple name, such as CWSP-Guest. In most cases, the guest SSID is prominently displayed on a sign in the lobby or entrance of the company offices.

Guest VLAN

Guest user traffic should be segmented into a unique VLAN tied to an IP subnet that does not mix with the employee VLANs. Segmenting your guest users into a unique VLAN is a security and management best practice. The main debate about the guest VLAN is whether or not the guest VLAN should be supported at the edge of the network. As shown in Figure 10.14, a frequent design scenario is that the guest VLAN does not exist at the edge of the network and instead is isolated in what is known as a demilitarized zone (DMZ). As shown in Figure 10.14, the guest VLAN (VLAN 10) does not exist at the access layer, and therefore, all guest traffic must be tunneled from the AP back to the DMZ where the guest VLAN does exist. An IP tunnel, commonly using Generic Routing Encapsulation (GRE) protocol, transports the guest traffic from the edge of the network back to the isolated DMZ. Depending on the WLAN vendor solution, the tunnel destination in the DMZ can be either a WLAN controller or simply a Layer 2 server appliance.

Although isolating the guest VLAN in a DMZ has been a common practice for many years, it is no longer necessary if guest firewall policies are being enforced at the edge of the network. Various WLAN vendors are now building enterprise-class firewalls into access points. If the guest firewall policy can be enforced at the edge of the network, the guest VLAN can also reside at the access layer and no tunneling is needed.

FIGURE 10.14 GRE tunneling guest traffic to a DMZ

Guest Firewall Policy

The most important security component of a guest WLAN is the firewall policy. The guest WLAN firewall policy prevents guest user traffic from getting near the company network infrastructure and resources. Figure 10.15 shows a very simple guest firewall policy that allows DHCP and DNS but restricts access to private networks 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Guest users are not allowed on these private networks because corporate network servers and resources often reside on that private IP space. The guest firewall policy should simply route all guest traffic straight to an Internet gateway and away from the corporate network infrastructure.

FIGURE 10.15 Guest firewall policy

Firewall ports that should be permitted include the DHCP server (UDP port 67), DNS (UDP port 53), HTTP (TCP port 80), and HTTPS (TCP port 443). This allows the guest user’s wireless device to receive an IP address, perform DNS queries, and browse the Web. Many companies require their employees to use a secure VPN connection when the employee is connected to an SSID other than the company SSID. Therefore, it is recommended that IPsec IKE (UDP port 500) and IPsec NAT-T (UDP port 4500) also be permitted.

The firewall policy shown in Figure 10.15 represents the minimum protection needed for a guest WLAN. The guest firewall policy can be much more restrictive. Depending on company policy, many more ports can be blocked. A good practice is to force the guest users to use webmail and block SMTP and other email ports so that users cannot “spam through” the guest WLAN. It is up to the security policy of the company to determine what ports need to be blocked on the guest VLAN. If the policy forbids the use of SSH on the guest WLAN, then TCP port 22 will need to be blocked. In addition to blocking UDP and TCP ports, several WLAN vendors now have the ability to block applications. In addition to stateful firewall capability, WLAN vendors have begun to build application-layer firewalls capable of deep packet inspection (dpi) into access points or WLAN controllers. An applicationlayer firewall can block specific applications or groups of applications. For example, some popular video streaming applications can be blocked on the guest SSID, as shown in Figure 10.16. The company security policy will also determine which applications should be blocked on a guest WLAN.

FIGURE 10.16 Application firewall policy

Captive Web Portals

Often, guest users must log in through a captive web portal page before they are given access to the Internet. One of the most important aspects of the captive web portal page is the legal disclaimer. A good legal disclaimer informs the guest users about acceptable behavior when using the guest WLAN. Businesses are more likely to be legally protected if something bad, such as being infected by a computer virus, should happen to a guest user’s WLAN device while connected through the portal. A captive portal solution effectively turns a web browser into an authentication service. To authenticate, the user must first connect to the WLAN and launch a web browser. After the browser is launched and the user attempts to go to a website, no matter what web page the user attempts to browse to, the user is redirected to a different URL, which displays a captive portal logon page. Captive portals can redirect unauthenticated users to a logon page using an IP redirect, DNS redirection, or redirection by HTTP. As shown in Figure 10.17, many captive web portals are triggered by DNS redirection. The guest user attempts to browse to a web page but the DNS query redirects the browser to the IP address of the captive web portal.

FIGURE 10.17 Captive web portal—DNS redirect

Captive portals are available as standalone software solutions, and most WLAN vendors offer integrated captive portal solutions. The captive portal may exist within a WLAN controller, or it may be deployed at the edge within an access point. WLAN vendors that support captive portals provide the ability to customize the captive portal page. You can typically personalize the page by adding graphics such as a company logo, inserting an acceptable use policy, or configuring the logon requirements. Depending on the chosen security of the guest WLAN, different types of captive web portal logon pages can be used. A user authentication logon page requires the AP or WLAN controller to query a RADIUS server with the guest user’s name and password. If the guest user does not already have an account, the logon page may provide a link, allowing the user to create a guest account, as shown in Figure 10.18. The guest registration page allows the user to enter the necessary information for them to self-register, as shown in Figure 10.19. The guest user may also be connected to a captive portal web page requiring them to simply acknowledge a user policy acceptance agreement, as shown in Figure 10.20.

FIGURE 10.18 Captive web portal—guest logon

FIGURE 10.19 Captive web portal—guest self-registration

FIGURE 10.20 Captive web portal—policy acceptance

Client Isolation, Rate Limiting, and Web Content Filtering

When guest users are connected to the guest SSID, they are all in the same VLAN and the same IP subnet. Because they reside in the same VLAN, the guests can perform peer-to-peer attacks against each other. Client isolation is a feature that can be enabled on WLAN access points or controllers to block wireless clients from communicating directly with other wireless clients on the same wireless VLAN. Client isolation (or the various other terms used to describe this feature) usually means that packets arriving at the AP’s wireless interface are not allowed to be forwarded back out of the wireless interface to other clients. This isolates each user on the wireless network to ensure that a wireless station cannot be used to gain Layer 3 or higher access to another wireless station. The client isolation feature is usually a configurable setting per SSID linked to a unique VLAN. Client isolation is highly recommended on guest WLANs to prevent peer-to-peer attacks.

Enterprise WLAN vendors also offer the capability to throttle bandwidth of user traffic. Bandwidth throttling, which is also known as rate limiting, can be used to curb traffic at either the SSID level or the user level. Rate limiting is recommended on guest WLANs. It can ensure that the majority of the wireless bandwidth is preserved for employees. Rate limiting the guest user traffic to 1024 Kbps is a common practice.

Enterprise companies often deploy web content filter solutions to restrict the type of websites that their employees can view while at the workplace. A web content filtering solution blocks employees from viewing websites based on content categories. Each category contains websites or web pages that have been assigned based on their primary web content. For example, the company might use a web content filter to block employees from viewing any websites that pertain to gambling or violence. Content filtering is most often used to block what employees can view on the Internet, but web content filtering can also be used to block certain types of websites from guest users. All guest traffic might be routed through the company’s web content filter.

Guest Management

As Wi-Fi has evolved, so have WLAN guest management solutions. Most guest WLANs require a guest user to authenticate with credentials via a captive web portal. Therefore, a database of user credentials must be created. Unlike user accounts in a preexisting Active Directory database, guest user accounts are normally created on the fly and are created in a separate guest user database. Guest user information is usually collected when the guests arrive at company offices. Someone has to be in charge of managing the database and creating the guest user accounts. IT administrators are typically too busy to manage a guest database; therefore, the individual who manages the database is often a receptionist or the person who greets guests at the front door. This individual requires an administrative account to the guest management solution, which might be a RADIUS server or some type of other guest database server. The guest management administrators have the access rights to create guest user accounts in the guest database and issue the guest credentials, which are usually usernames and passwords.

A guest management server can be cloud based or can reside as an on-premise server in the company datacenter. Although most guest management systems are built around a RADIUS server, the guest management solution offers features in addition to providing RADIUS services. Modern WLAN guest management solutions offer robust report-generation capabilities for auditing and compliance requirements. As shown in Figure 10.21, a guest management solution can also be used as a 24/7 full-time monitoring solution. An IT administrator usually configures the guest management solution initially; however, a company receptionist will have limited access rights to provision guest users. Guest management solutions can also be integrated with LDAP for employee sponsorships and usually have some method for guest users to self-register. Most often, guest management solutions are used for wireless guests, but they might also be used to authenticate guests connected to wired ports.

FIGURE 10.21 Guest management and monitoring

As you can see in Figure 10.22, there can be multiple ways to deliver the guest credentials to the guest user. The credentials can be delivered via an electronic wallet, SMS text message, an email message, or a printed receipt. The SMS, email, and receipt can also be customized with company information. The guest registration logon pages can all be customized with company logos and information.

FIGURE 10.22 Guest credential delivery methods

Guest Self-Registration

Guest management solutions have traditionally relied on a company receptionist or lobby ambassador to register the guest users. A good guest management solution allows the receptionist to register a single guest user or groups of users. Over the past few years, there has also been a greater push for guest users to create their own account, what is commonly referred to as self-registration. When the guest is redirected to the captive web portal, if they do not already have a guest account, a link on the logon web page redirects them to a self-registration page. Simple self-registration pages allow guests to fill out a form and their guest account is created and displayed or printed for them. More advanced self-registration pages require guests to enter an email or SMS address, which is then used by the registration system to send users their logon credentials.

As shown in Figure 10.23, some guest management solutions now offer a kiosk mode, where the self-registration logon page runs on a tablet that functions as the kiosk. Selfregistration via a kiosk is quite useful when the kiosk is deployed in the main lobby or at the entrance to the company. An advantage of self-registration kiosks is that the receptionist does not have to assist the users and can concentrate on other work duties.

FIGURE 10.23 Kiosk mode

Employee Sponsorship

Guest users can also be required to enter the email address of an employee, who in turn must approve and sponsor the guest. The sponsor typically receives an email with a link that allows them to easily accept or reject the guest’s request. Once the user is registered or sponsored, they can log on using their newly created credentials. A guest management solution with employee sponsorship capabilities can be integrated with an LDAP database, such as Active Directory.

As you already learned, a receptionist can register guest users or a company may choose to use a registration kiosk so that guests can self-register. For larger or distributed organizations, a central registration kiosk does not scale well. Self-registration with employee sponsorship is becoming popular for many organizations.

When guest users initially connect to the guest network, they are redirected to a captive portal page. The captive portal page prompts them to log on if they already have an account, or it allows them to click a link that allows them to create their own guest account. As shown in Figure 10.24, the guest must enter the email address of the employee who is sponsoring them. Typically, this is the person they are meeting with.

When the registration form is completed and submitted, the sponsor receives an email notifying them that the guest would like network access. As shown in Figure 10.25, the email typically contains a link that the sponsor must click to approve network access. Once the link is clicked, the guest account is approved and the guest receives confirmation either by email or SMS, and they will then be allowed to log on to the network. If the sponsor does not click the link, the guest account is never created and the guest is denied access to the network.

FIGURE 10.24 Employee sponsorship registration

FIGURE 10.25 Employee sponsorship confirmation email

Employee sponsorship ensures that only authorized guest users are allowed onto the guest WLAN and that the company employees are actively involved in the guest user authorization process.

Social Login

A new trend in guest networks in retail and service industries is social login. Social login is a method of using existing logon credentials from a social networking service (such as Twitter, Facebook, or LinkedIn) to register on a third-party website. Social login allows a user to forgo the process of creating new registration credentials for the third-party website. Social login is often enabled using the OAuth protocol. OAuth (Open Standard for Authorization) is a secure authorization protocol that allows access tokens to be issued to third-party clients by an authorization server. As shown in Figure 10.26, the OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service and can be used for social login for Wi-Fi guest networks.

FIGURE 10.26 OAuth 2.0 application

As shown in Figure 10.27, social login can be tied to an open guest SSID. Guest users are redirected to a captive web portal page and they can then log on to the guest WLAN using their existing social media logon credentials. Retail and service businesses like the idea of social login because it allows the business to obtain meaningful marketing information about the guest user from the social networking service. Businesses can then build a database of the type of customers who are using the guest Wi-Fi while shopping at the business. It should be noted that there are serious privacy concerns with social login, and the logon captive web portal always has a legal disclaimer stating that customer information might be gathered if the customer agrees to use the social login registration to the guest WLAN.

FIGURE 10.27 Social login

Encrypted Guest Access

Most guest networks are open networks that do not use encryption; thus, there is no data privacy for guest users. In Chapter 14, “Wireless Security Monitoring,” you learned about the numerous wireless attacks that make unsecured Wi-Fi users vulnerable. Because no encryption is used on most guest WLANs, the guest users are low-hanging fruit and often targets of skilled hackers or attackers. For that reason, many corporations require their employees to use an IPsec VPN solution when connected to any kind of public or open guest SSID. Because the guest SSID does not provide data protection, the guest user must bring their own security in the form of a VPN connection that provides encryption and data privacy.

The problem is that many consumers and guest users are not savvy enough to know how to use a VPN solution when connected to an open guest WLAN. As a result, there is a recent trend to provide encryption and better authentication security for WLAN guest users. Protecting the company network infrastructure from attacks from a guest user still remains a top security priority. However, if a company can also provide encryption on the guest SSID, the protection provided to the guest user is a value-added service.

One simple way to provide encryption on a guest SSID is to use a static PSK. Although encryption is provided when using static PSK, this is not ideal because of brute-force dictionary attacks and social engineering attacks. Some WLAN vendors offer cloud-based servers to distribute secure guest credentials in the form of unique dynamic PSKs. A guest management solution that utilizes unique PSKs as credentials also provides data privacy for guest users with WPA2 encryption.

Another growing trend with public access networks is the use of 802.1X/EAP with Hotspot 2.0. Hotspot 2.0 is a Wi-Fi Alliance technical specification that is supported by the Passpoint certification program. With Hotspot 2.0, the client device is equipped by an authentication provider with one or more credentials, such as a SIM card, username/password pair, or X.509 certificate. Passpoint devices can query the network prior to connecting in order to discover the authentication providers supported by the network. Though open networks are still the norm today, growing interest in security and automated connectivity in public access networks will motivate adoption and use of Hotspot 2.0.

Network Access Control (NAC)

Network access control (NAC) evaluates the capability or state of a computer to determine the potential risk of the computer on the network and to determine the level of access to allow. NAC has changed over the years from an environment that primarily assessed the virus and spyware health risk to an environment where checks and fingerprinting are performed on a computer, extensively identifying its capabilities and configuration. These checks are integrated with 802.1X/EAP and RADIUS to authenticate and authorize network access for the user and the computer.

Posture

NAC began as a response to computer viruses, worms, and malware that appeared in the early 2000s. The early NAC products date back to around 2003 and provided what is known as posture assessment. Posture is a process that applies a set of rules to check the health and configuration of a computer and determine whether it should be allowed access to the network. NAC products do not perform the health checks themselves but rather validate that the policy is adhered to. A key task of posture assessment is to verify that security software (antivirus, antispyware, and a firewall) is installed, up-to-date, and operational. Figure 10.28 shows an example of some of the antivirus settings that can be checked. Essentially, posture assessment “checks the checkers.” In addition to checking security software status, posture assessment can check the state of the operating system. Posture policy can be configured to make sure that specific patches or updates are installed, verify that certain processes are running or not running, or even check to determine whether or not specific hardware (such as USB ports) is active.

A posture check is performed by a persistent agent (software that is permanently installed on the computer) or by a dissolvable agent (software that is temporarily installed). If a company deploys posture software, a persistent agent will likely be installed on all of the corporate laptops to make sure that they are healthy. The company may also want to check guest computers that are trying to connect to the network; however, the guest is not likely to allow your company to install software on their computer. When the guest connects to the captive portal, a posture assessment process can temporarily run and check the guest computer for compliance.

After the posture check is performed, if a computer is considered unhealthy, the ideal scenario would be for the posture agent to automatically fix or remediate the problem so that the computer can pass the check and gain network access. Since the persistent agent is installed on the corporate computer and typically has permissions to make changes, automatic remediation can be performed. Computers that are running dissolvable agents typically cannot be automatically updated. The guest user must resolve the problems before network access will be allowed.

FIGURE 10.28 Antivirus posture settings

OS Fingerprinting

The operating system of WLAN client devices can be determined by a variety of fingerprinting methods, including DHCP and HTTP snooping. After a client successfully establishes a Layer 2 connection, the next action is to send a DHCP request to obtain an IP address. As part of that request, the client device includes DHCP option information and requests a list of DHCP parameters or options from the DHCP server. These options may include subnet mask, domain name, default gateway, and the like. When a client sends DHCP discover and request messages, each type of client requests different parameters under the DHCP option 55 portion of the request. The parameters within DHCP option 55 create a fingerprint that can be used to identify the operating system of the client.

For example, iOS devices include a common set of parameters when performing a DHCP request, thus making it possible to identify that the device is most likely an iOS device. DHCP fingerprinting is not perfect, and it is often not possible to discern the difference between similar devices such as an iPod, an iPhone, or an iPad. Depending on the NAC vendor, the DHCP fingerprint is referenced as an ASCII list of parameter request options, such as 1, 3, 6, 15, 119, 252. Or it might be display as a hexadecimal string, such as 370103060F77FC. In the string, the first two hex digits are equal to ASCII 55 (option 55), and each of the following two digits pairs are the hex values of each option.

You will find an extensive list of DHCP fingerprints at www.fingerbank.org. Although the parameter request list is not guaranteed to be unique, it can typically be used along with other fingerprinting techniques to identify devices.

Another OS detection method is HTTP fingerprinting. The user-agent header within an HTTP packet identifies the client operating system. During captive portal authentication, NAC solutions are able to inspect HTTP/HTTPS frames while handling the client requests. This fingerprinted information is combined with the information obtained through other methods to paint a better picture of the client device. Other ways of obtaining client information are active methods such as SNMP and TCP scanning.

AAA

Earlier in the book we mentioned authentication, authorization, and accounting (AAA). AAA is a key component of NAC. Authentication obviously is used to identify the user who is connecting to the network. We often refer to this as identifying “who you are.” Although “who you are” is a very important piece of the process for allowing access to the network, an equally important component of the connection is authorization. We often refer to this as identifying “what you are.” Authorization is used to analyze information such as the following:

• User type (admin, help desk, staff)

• Location, connection type (wireless, wired, VPN)

• Time of day

• Device type (smartphone, tablet, computer)

• Operating system

• Posture (system health or status)

When configuring AAA for authentication, one of the configuration tasks is to define or specify the database that will be used to verify the user’s identity. Historically we have referred to this as the user database; however, the user’s identity could be verified by something other than a user account and password, such as a MAC address or a certificate. If you are not sure of the identity type that is being used, or if you want to maintain a more neutral stance, the term identity store is a good one to use.

By utilizing both authentication and authorization, a NAC can distinguish between Jeff using his smartphone and Jeff using his personal laptop. From this information, the NAC can control what Jeff can do with each device on the network.

To use an analogy to explain authorization, say that George is a member of a country club. As he drives onto the property, the guard at the entrance checks his identification card and verifies his membership. He has been authenticated. After parking his car, he decides to go to the restaurant since it is 6:30 p.m. and he is hungry. When he arrives at the restaurant, he is told that he is not allowed in the restaurant. Confused, George questions why since he has already verified that he is a member of the club at the entrance. The hostess then explains to him that after 6 p.m., the restaurant has a policy that all male guests must be wearing slacks and a sports jacket or suit jacket. Unfortunately George was wearing shorts and did not have a jacket; therefore he was not authorized to eat at the restaurant. The hostess was polite, and did tell George that he was authorized to go to the lounge and have a meal there, since the requirements for the lounge were not as strict.

As you can see from the analogy, authentication is about who you are, whereas authorization is about other parameters, such as what, where, when, and how. Also, unlike authentication where you are or are not authenticated, authorization varies depending on the parameters and the situation.

RADIUS Change of Authorization

Prior to RADIUS Change of Authorization (CoA), if a client was authenticated and assigned a set of permissions on the network, the client authorization would not change until the client logged out and logged back in. This only allowed the authorization decision to be made during the initial connection of the client.

RADIUS accounting (the final A in AAA) is used to monitor the user connection. In the early days of AAA, it typically tracked client connection activity: logging on and logging off events, which in some environments may be all you want or need to track. Enhancements to accounting allow the AAA server to also provide interim accounting. Interim accounting can track resource activity such as time and bytes used for the connection. If the user exceeds or violates the allowed limits of resources, RADIUS CoA can be used to dynamically change the permissions that the user has on the network.

To use an analogy to explain RADIUS CoA, Jack is going to a club with some friends to enjoy some cocktails and dancing. When they arrive, a bouncer at the door admits them into the club but tells them that they are not allowed to become drunk or cause trouble in the club. While telling them this, the bouncer checks to make sure that they are not already drunk or causing trouble. Unfortunately, the bouncer must stand at the door and monitor the guests only as they enter the club. The bouncer cannot monitor the guests once they are inside the club. After a few nights of experiencing some problems in the club, the manager decides to hire additional bouncers, who walk around the club and monitor the guests who are already in the club. Anyone who is found to be drunk or causing problems is either restricted within the club (maybe they are no longer allowed to purchase alcoholic drinks), or the guest may be removed from the club. Once the guest is outside the club, the bouncer at the door can reevaluate the status of the guest, possibly denying reentry into the club, allowing the guest back in the club, or allowing the guest to reenter, but with a different set of permissions.

RADIUS CoA was originally defined by RFC 3576 and later updated in RFC 5176. Before you begin to worry, no, you do not need to know this for the CWSP exam. We are mentioning it because many of the AAA servers, NAC servers, and enterprise wireless equipment reference “RADIUS RFC 3576” on configuration menus without referring to CoA. Therefore, from a practical perspective, you should be aware that if you see RFC 3576 on any configuration menu, that is the section where RADIUS CoA is configured.

Single Sign-On

In the early days of networking, users had to log on to the file or print server in order to get access to the network resources. The user accounts were managed and stored on each server. Initially this was rarely a problem since networks were smaller, but as the number of internal servers and server types increased, logging in to multiple servers became a hassle. To simplify the process, companies began to implement single sign-on (SSO) within the organization, allowing users to access many if not all of the internal resources using a single network logon. Not only did this simplify the logon process for the user, it also simplified network management by consolidating user accounts into one central user database.

Within the organization, single sign-on worked well for many years until corporate resources began migrating to Internet- and cloud-based servers and services. User logons now had to extend outside the corporate network, and many cloud-servers were actually services provided by other companies, such as CRM systems, office applications, knowledge bases, and file-sharing servers. Authentication and authorization across organizational boundaries introduce more complexity and a greater security risk.

Two technologies, Security Assertion Markup Language (SAML) and OAuth can be used to provide the access security needed to expand outside the organization’s network. The following sections will briefly explain the components of these technologies and how they work.

SAML

SAML provides a secure method of exchanging user security information between your organization and an external service provider, such as third-party cloud-based customer relationship management (CRM) platform. When a user attempts to connect to the CRM platform, instead of requiring the user to log on, a trust relationship between your authentication server and the CRM server will validate the user’s identity and provide access to the application or service. This allows users to log on once to the enterprise network and then seamlessly and securely access external services and resources without having to revalidate their identities.

The SAML specification defines three roles that participate in the SSO process; the identity provider (IdP), which is the asserting party; the service provider (SP), which is the relying party; and the user. This section will briefly explain two scenarios in which SAML can be used to provide SSO.

The first scenario is the service provider–initiated login, as illustrated in Figure 10.29. Here, the user attempts to access a resource on the CRM server (SP). In this scenario, if the user has not been authenticated, the user is redirected to the enterprise authentication server (IdP) using a SAML request. After successful authentication, the user is then redirected to the CRM server using a SAML assertion, at which time the user will have access to the requested resources.

FIGURE 10.29 Service provider–initiated login

The second scenario is the identity provider–initiated login, as illustrated in Figure 10.30. Here, the user logs on to the enterprise authentication server (IdP) first. Once logged on, the user is redirected to the CRM server and a SAML assertion verifies the user’s access.

There are many ways of configuring SAML. The key concept is that it provides access to resources outside of the enterprise network, using the user’s enterprise credentials, and without requiring the user to log on multiple times.

OAuth

OAuth is different from SAML; it is an authorization standard and not an authentication standard. With OAuth, a user logs on to the authenticating application. Once logged on, the user (resource owner) can authorize a third-party application to access specific user information or resources, providing an authorization flow for web and desktop applications, along with mobile devices. NACs can use OAuth to communicate with external resources and systems.

FIGURE 10.30 Identity provider–initiated login

Summary

In this chapter, we discussed BYOD policy and the MDM solutions that are needed to manage company-issued mobile devices as well as employee personal mobile devices. We examined the differences between CID and BYOD devices and the MDM policy considerations for both. We discussed the various components of an MDM architecture and how the components interact. We explained the MDM enrollment process and over-the-air provisioning. We reviewed the types of mobile devices that use MDM profiles and those that use MDM agent software. We also discussed over-the-air management and application management when using an MDM solution for mobile devices.

We discussed self-service device onboarding solutions for employees. Self-service onboarding for employee devices is the fastest growing trend for BYOD provisioning.

We reviewed guest WLAN access and the key security components needed to protect corporate network infrastructure from guest users. We examined the various methods of guest management, including employee sponsorship, self-registration, and social login. Finally, we discussed how NAC can be used to provide access control by monitoring posture and by fingerprinting the client device prior to it connecting to the network. AAA services can authenticate the user connecting to the network and can authorize the device onto the network. RADIUS CoA can be used to modify the authorization of a user if a new set of permissions needs to be assigned.

Although MDM, self-service device onboarding, WLAN guest management, and NAC are separate components of a WLAN, we chose to write about all four together in this chapter because several WLAN vendors package these security solutions together as one application suite. MDM, device onboarding, WLAN guest management, and NAC can be deployed as separate components or can be deployed in unison to provide mobile device security management, guest user security, and network access security.

Exam Essentials

Define the differences between company-issued devices and personal mobile devices. Be able to explain the MDM policy concerns for both CID and BYOD devices.

Describe the four main components of an MDM architecture. Define the roles of a mobile device, an MDM server, an AP, and push notification servers. Explain how they interact.

Explain how MDM profiles and MDM agents are used within an MDM solution. Describe how MDM profiles can be used for restrictions and mobile device configurations. Describe the role of MDM agents and which mobile devices require MDM agent software.

Discuss MDM over-the-air management and MDM application management. Be able to explain how push notification servers are used to manage mobile devices across the Internet. Explain how an MDM can manage mobile device applications.

Explain self-service device management. Be able to discuss both dual- and single-SSID methods used to provision employee devices. Explain the advantages and differences between self-service device management versus MDM.

Define the four main security objectives of a guest WLAN. Discuss the importance of guest SSIDs, guest VLANs, guest firewall policies, and captive web portals.

Explain the many components and methods of WLAN guest management. Be able to explain self-registration, employee sponsorship, social login, and other ingredients of guest management.

Explain NAC and how it is used to control access to the network. Describe how posture, RADIUS attributes, and DHCP fingerprinting are used along with AAA to authenticate and authorize a user and device onto the network. Describe how RADIUS CoA can be used to modify the authorization of the user.

Review Questions

1. In a guest firewall policy, what are some of the ports that are recommended to be permitted? (Choose all that apply.)

A. TCP 22

B. UDP 53

C. TCP 443

D. TCP 110

E. UDP 4500

2. In a guest firewall policy, which IP networks should be restricted? (Choose all that apply.)

A. 172.16.0.0/12

B. 20.0.0.0/8

C. 192.16.0.0/16

D. 172.10.0.0/24

E. 10.0.0.0/8

3. What are some the components within an MDM architecture? (Choose all that apply.)

A. AP

B. RADIUS

C. BYOD

D. APNs

E. GCM

4. What are some the methods that can be used to provision a root certificate onto Wi-Fi clients that function as 802.1X supplicants? (Choose all that apply.)

A. GPO

B. RADIUS

C. MDM

D. APNs

E. GCM

5. What type of files are used by the MDM profiles for Apple Mac OS and iOS devices? (Choose all that apply.)

A. HTTP

B. XML

C. JAVA

D. PHP

E. Python

6. What type of information can be seen on a mobile device that is monitored by an MDM server? (Choose all that apply.)

A. SMS messages

B. Battery life

C. Web browsing history

D. Installed applications

E. Device capacity

7. Which of these is used to report back to an MDM server unique information about mobile devices that can later be used in MDM restriction and configuration policies?

A. MDM profile

B. Push notification service

C. Captive web portal

D. MDM agent

E. Access point

8. What are some of the methods that can be used by a captive web portal to redirect a user to the captive portal logon page? (Choose all that apply.)

A. HTTP redirection

B. IP redirection

C. UDP redirection

D. TCP redirection

E. DNS redirection

9. During the MDM enrollment process, what resources can a mobile client reach while quarantined inside a walled garden? (Choose all that apply.)

A. SMTP

B. DHCP

C. DNS

D. MDM server

E. Exchange server

10. What is the protocol used by iOS and Mac OS devices for over-the-air provisioning of MDM profiles using certificates and SSL encryption?

A. OAuth

B. GRE

C. SCEP

D. XML

E. HTTPS

11. What mechanism can be used if the guest VLAN is not supported at the edge of the network and only resides in a DMZ?

A. GRE

B. VPN

C. STP

D. RTSP

E. IGMP

12. Which type of guest management solution needs to integrate with LDAP?

A. Social login

B. Kiosk mode

C. Receptionist registration

D. Self-registration

E. Employee sponsorship

13. An employee has enrolled a personal device with an MDM server over the corporate WLAN. The employee removes the MDM profile while at home. What will happen with the employee’s personal device the next time the employee tries to connect to the company SSID?

A. The MDM server will reprovision the MDM profile over the air.

B. The push notification service will reprovision the MDM profile over the air.

C. The device will be quarantined in the walled garden and will have to reenroll.

D. The device will be free to access all resources because the certificate is still on the mobile device.

14. Which phrase best describes a policy of permitting employees to bring personally owned mobile devices such as smartphones, tablets, and laptops to their workplace?

A. MDM

B. NAC

C. DMZ

D. BYOD

15. Which method of guest management can be used by a company to gather valuable personal information about guest users?

A. Social login

B. Kiosk mode

C. Receptionist registration

D. Self-registration

E. Employee sponsorship

16. What kind of remote actions can an MDM administrator send to the mobile device over the Internet?

A. Configuration changes

B. Restrictions changes

C. Locking the device

D. Wiping the device

E. Application changes

F. All of the above

17. What are some extra restrictions that can be placed on a guest user other than those defined by the guest firewall policy? (Choose all that apply.)

A. Encryption

B. Web content filtering

C. DHCP snooping

D. Rate limiting

E. Client isolation

18. With a WLAN infrastructure, where can the guest captive web portal operate? (Choose the best answer.)

A. AP

B. WLAN controller

C. Third-party server

D. All of the above

19. When an MDM solution is deployed, after a mobile device connects to an access point, where does the mobile device remain until the MDM enrollment process is complete?

A. DMZ

B. Walled garden

C. Quarantine VLAN

D. IT sandbox

E. None of the above

20. To calculate the capability Jeff should have on the network, which of the following can the NAC server use to initially identify and set his permission? (Choose all that apply.)

A. Posture

B. DHCP fingerprinting

C. RADIUS attributes

D. RADIUS CoA

E. MDM profiles