Extending Guest Wireless Access to Employee Personal Devices
The following sections discuss two methods for extending guest wireless access, discussed in “BYOD Guest Wireless Access,” to also allow employee personal devices access to the guest network:
- Allowing employees to provision guest credentials for themselves.
- Extending guest web authentication (Web Auth) to also utilize the Microsoft Active Directory (AD) database when authenticating guests and employees using personal devices.
Allowing Employees to Provision Guest Credentials for Themselves
“BYOD Guest Wireless Access,” discusses provisioning guest credentials with the Cisco ISE sponsor portal. The most basic form of extending guest wireless access to employee personal devices is simply to allow employees to sponsor themselves as guests. Employees then manually connect to the open guest SSID to utilize personal devices on the wireless guest network.
With the Cisco ISE sponsor portal, the sponsor authentication policy can be based on membership within a particular Microsoft AD group. This was discussed in Configuring the Cisco ISE Sponsor Portal, which discussed the use of Microsoft AD groups within the ISE sponsor group policy as a means to limit sponsor access to the Cisco ISE server. This can equally be used to allow broader access to the ISE sponsor portal simply by adding additional employees to those Microsoft AD groups. Alternatively a new sponsor group can be created that allows individual employees to configure guest credentials yet restricts them to being able to only modify credentials that they provisioned. An example is shown in the figures below.
Figure 18-1 Example ISE Sponsor Group for Employees to Create Self Guest Credentials
Membership to this ISE sponsor group can then be restricted to a Microsoft AD group via the ISE sponsor group policy, as shown in Figure 18-2.
Figure 18-2 Example ISE Sponsor Group Policy for Employees to Create Self Guest Credentials
In this example, access to the sponsor group is limited to those members of the Microsoft Active Directory domain who are members of the group “Users/Domain Users”. The exact condition for the example is of the form:
AD1:ExternalGroups EQUALS uatest.com/Users/Domain Users
The Microsoft Active Directory domain is “uatest.com” in this example. Note that the Microsoft Active Directory server must be configured as an external identity source to select this option. In this example it is known by the name “AD1”.
One advantage of this design is that an audit trail exists through the ISE Reports for employees authenticating to the ISE sponsor portal. The ISE Sponsor Mapping report shows when the employee created a guest credential as well as the guest credential created. The ISE Sponsor Mapping report can be run over various time ranges from 30 minutes up to 30 days or a custom time range can be requested. This report can be used to gain a rough idea of which employees are accessing the ISE sponsor portal to create guest credentials and how often. An example is shown in Figure 18-3.
Figure 18-3 Example of the Audit Trail for an Employee Accessing the ISE Sponsor Portal
Note that this method of allowing employees the ability to create guest credentials for themselves does not prevent them from creating credentials for true guests who are visiting the organization. Corporate business policy should dictate that true guest credentials only be added by authorized members of sponsor groups, as discussed in Chapter21, “BYOD Guest Wireless Access” The next design option eliminates this issue by removing the ability for employees to create guest credentials for themselves altogether.
Extending Web Auth to Use Microsoft AD when Authenticating Employees with Personal Devices
The previous section discussed the most basic way of extending guest wireless access to allow employees with personal devices to access the guest network. That method simply allows employees to configure guest credentials for themselves via the Cisco ISE sponsor portal. Although this provides several advantages over methods such as utilizing a shared sponsor account on the guest wireless controller for adding credentials, it still has several shortcomings. Employees must still provision temporary guest credentials for themselves. Finally, there is nothing preventing the employee from sponsoring a true guest, other than corporate business policy.
An alternative means of providing access to the guest wireless network for employee personal devices is to simply allow the ISE server to check multiple identity sources for credentials when performing web authentication (Web Auth). For example, the ISE server could first check its internal identity groups (local database) for guest credentials. If the credentials are not found there, then check the Microsoft AD external identity store to see if the person accessing the guest network is an employee instead of a guest.
Cisco ISE Policy Configuration in Chapter 21, “BYOD Guest Wireless Access” discusses the use of a user-defined identity source sequence called Guest_Portal_Sequence for authenticating guest access via Web Auth. The Guest_Portal_Sequence uses the Internal Users identity source only. This can easily be extended by adding a Microsoft Active Directory (AD1) external identity source to the sequence, as shown in Figure 18-4.
Figure 18-4 Example of Guest_Portal_Access Identity Source Sequence Extended to Include AD
This configuration now allows employees who are in the Microsoft Active Directory database to access the guest wireless network from their personal devices once they have performed web authentication and accepted the Acceptable Use Policy (AUP) or End User Agreement (EUA).
NoteThis allows employees to access the guest wireless network from corporate-owned devices as well, since the authentication and authorization decision is based on Microsoft Active Directory userid and password only. The device itself is not considered within the authentication and authorization decision. This allows employees to access the guest wireless network from corporate-owned devices as well, since the authentication and authorization decision is based on Microsoft Active Directory userid and password only. The device itself is not considered within the authentication and authorization decision.
Deploying Guest-Like Wireless Access for Employee Personal Devices
The previous sections discussed options for extending access to the wireless guest network for employees with personal devices, either by allowing employees to configure guest credentials for themselves or by extending Web Auth to also check the Microsoft AD database where employee credentials are kept. With these options, employee personal devices share the same wireless SSID as guest devices. Employee personal devices also share the same IP subnet address space as guest devices, since they terminate on the same DMZ segment of the ASA firewall. Essentially the employee’s personal device is treated as a guest on the network, which can bring up potential concerns.
Since IP subnet space is shared between guest devices and employee personal devices, there can be some concern that employee personal devices could deplete the IP addressing space, limiting the ability of guest devices to gain access to the guest network or vice-versa.
The ASA firewall guest DMZ interface ingress policy can be modified to allow certain application flows inbound from the guest network to a mirror of the company website server, dedicated for employee personal devices, sitting on other DMZ segments. This is discussed further in Accessing Corporate Resources. However, the ASA firewall policy would not be able to distinguish between guest devices and employee personal devices, since they share the same IP subnet address space. Therefore, application level access control at the mirror web server itself is necessary to prevent guests from accessing services on it. Likewise, the ASA firewall guest DMZ interface ingress policy could be modified to allow traffic from a virtual client—such as a Citrix or VMware client—inbound to internal Citrix or VMware servers. Again, the ASA firewall policy would not be able to distinguish between true guest devices and employee personal devices, since they share the same IP subnet address space. Application level access control at the Citrix or VMware server would be necessary to prevent guests from accessing these servers.
Since the guest SSID is typically open with no encryption, traffic from employee personal devices will be in the clear, unless the devices use either secure applications or some form of VPN tunneling, which encrypts the traffic. Although web traffic can be made secure simply by requiring the use of HTTPS, not all applications used by employee personal devices may be encrypted. This leaves some vulnerability which must be considered by security operations personnel, especially any site that authenticates using the employee's corporate login and password. If internal company data is being accessed from employee personal devices via the guest wireless network, then that information should be encrypted to prevent eavesdropping. Allowing employee devices to launch a VPN client to establish an IPsec VPN session-either directly to the ASA firewall or out to the Internet and back to another corporate VPN concentrator-may be one alternative. Another option is the establishment of an SSL VPN tunnel to the ASA firewall for employee devices. Both of these options may also require per-user authentication.
NoteCisco’s implementation of Web Auth uses HTTPS when redirecting the web session and requesting credentials. Cisco’s implementation of Web Auth uses HTTPS when redirecting the web session and requesting credentials.
Because of these concerns, security operations personnel may be hesitant to allow anything but Internet access for any device accessing the guest network, whether it is a true guest device or an employee personal device.
As in “BYOD Guest Wireless Access,” two distinct terminologies are used in this chapter. The first pair of terminologies is guest controller and campus controller. The guest controller is a dedicated controller that is used for dealing with guest and employee personal device traffic. The campus controller is dedicated for handling internal traffic. Note that the term campus controller is used somewhat generically here. The campus controller discussed within this chapter may refer to a standalone wireless controller platform deployed within a campus location or wireless controller functionality integrated within Catalyst 3850 Series switches deployed within a branch location.
The second set of terminologies is foreign controller and anchor controller. These two terminologies are used when a user roams from one controller to another controller. The new controller to which the user associates is the foreign controller. This controller anchors all the traffic to the old controller, which becomes the anchor controller. These terminologies are used in this document.
Dedicated SSID for Employee Personal Devices
This section discusses another option in which a second guest-like wireless SSID is provisioned for employee personal devices. This SSID is auto-anchored to another DMZ segment off of the ASA firewall, in a similar fashion as the wireless guest SSID. An example of this design using CUWN infrastructure is shown in Figure 18-5.
Figure 18-5 Guest-Like Wireless Access for Employee Personal Devices Using CUWN Infrastructure
With the auto-anchor mobility feature of Cisco wireless controllers, packets from the wireless client are encapsulated through a mobility tunnel between the internal wireless controller (known as the foreign controller) to the guest wireless controller (known as the anchor controller), where they are de-capsulated and delivered to the wired network.
A similar example of this design using a Converged Access wireless infrastructure is shown in Figure 18-6.
Figure 18-6 Guest-Like Wireless Access for Employee Personal Devices Using Converged Access Infrastructure
The auto-anchor mobility feature also applies to the Converged Access Infrastructure. Note that with the Converged Access branch design shown in Figure 18-6, the Catalyst 3850 switch within the branch implements both the Mobility Agent (MA) and Mobility Controller (MC) function. With the Converged Access campus design, the Catalyst 3850 switch only implements the MA function. The MC function is implemented by a dedicated CT5760 wireless controller. Since the auto-anchor tunnel is initiated from the MC within a Converged Access design, traffic is first tunneled from the campus Catalyst 3850 switch to the CT5760 wireless controller, where it is then auto-anchored to the guest anchor controller within the DMZ. For additional discussion regarding the MA and MC functionality within Converged Access infrastructure, see Configuring the Infrastructure.
NoteIn this version of the design guide, it is assumed that employees with personal devices would need to manually associate with this SSID. Future versions may investigate other alternatives that make use of RADIUS change-of-authentication (CoA) functionality or device profiles. In this version of the design guide, it is assumed that employees with personal devices would need to manually associate with this SSID. Future versions may investigate other alternatives that make use of RADIUS change-of-authentication (CoA) functionality or device profiles.
An advantage of implementing a dedicated SSID for employee personal devices is that the SSID does not have to be configured with open access and can be encrypted, unlike the guest SSID discussed throughout this design guide. Instead, the employee personal device SSID can be secured via mechanisms such as 802.1X authentication and WPA-2/AES encryption to prevent eavesdropping of traffic from employee personal devices. Employees can be authenticated via the Cisco ISE server using the external Microsoft AD identity source as they associate with the SSID.
Another advantage of implementing a dedicated SSID for employee personal devices is that the devices can be isolated from guest devices by provisioning separate VLANs for each SSID. Separate DMZ segments-implemented as separate physical interfaces off of the ASA firewall or as separate VLAN sub-interfaces off a single physical interface of the ASA firewall-can be deployed. Each DMZ interface now has a separate IP subnet address space and a separate access-control policy. This expands the IP addressing space deployed for guest devices as well as employee personal devices and removes the issue of employee personal devices causing IP address starvation issues for guest devices and vice-versa. The guest DMZ can be configured to allow only Internet access for guest devices. The employee personal device DMZ can be configured to allow Internet access, as well as access to a mirror web server sitting on another DMZ segment. Additional access can be allowed by modifying the ASA firewall personal device DMZ interface ingress policy to allow traffic from a virtual client-such as a Citrix or VMware client-inbound to internal Citrix or VMware servers. Access can also be extended by allowing employee personal devices to launch a VPN client to establish an IPsec VPN session, either directly to the ASA firewall or out to the Internet and back to another corporate VPN concentrator. Another option is the establishment of an SSL VPN tunnel to the ASA firewall for employee personal devices.
Wireless Controller Configuration
To deploy this option in which a second guest-like wireless SSID is provisioned for employee personal devices, both the campus (foreign) wireless controllers and the guest (anchor) controller need to be configured with a new WLAN for employee personal devices. This WLAN has a unique SSID different from the corporate WLAN and the guest WLAN.
Campus Controller Configuration
This section discusses configurations when using either CUWN wireless controllers or Converged Access (IOS XE based) wireless controllers for the campus controller.
CUWN Wireless Controller Configuration
An example of a CUWN campus controller configuration is shown in Figure 18-7, in which the new WLAN is called the BYOD_Personal_Device WLAN.
Figure 18-7 Example Configuration of a CUWN Campus Wireless Controller for the Employee Personal Devices WLAN
The WLAN is configured for WPA2 security with AES as the cipher, along with 802.1X authenticated key management. Next, the WLAN on the campus (foreign) controller needs to be configured with a mobility anchor pointing at the management interface of the guest (anchor) controller. An example is shown in Figure 18-8. Note that in branch scenarios which utilize a FlexConnect wireless design, the controller servicing branch APs will be the foreign controller for the branch personal device WLAN.
Figure 18-8 Example Configuration of the Mobility Anchor on a Campus CUWN Wireless Controllers
Note that the campus controller and the guest controller must be part of the same mobility group before the mobility anchor can be configured. The mobility anchors establish the mobility tunnel through which packets from the wireless client are automatically encapsulated and sent from the campus controller to the guest controller where they are de-capsulated and delivered to the wired network.
The network administrator must also configure the employee personal devices WLAN to use RADIUS within the campus controller for authentication. This is shown in Figure 18-9.
Figure 18-9 Authentication via RADIUS for the Employee Personal Devices WLAN on the Campus Controller
Since Web Auth is not involved with this option, there is no redirection of web sessions to a guest portal and hence no configuration required within the guest controller for Web Auth or any requirement for a pre-authentication ACL. When an employee personal device connects to the SSID, the RADIUS session is initiated by the campus controller management interface to the Cisco ISE server for authentication and authorization. Upon successful authentication, the employee’s personal device is then anchored to the guest controller.
Converged Access (IOS XE Based) Wireless Controller Configuration
The following partial configuration shows an example of the employee personal devices WLAN along with part of the AAA server configuration on an IOS XE based wireless controller.
aaa authentication login default enable
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius
aaa server radius dynamic-author
client 10.225.49.15 server-key 7 032A4802120A701E1D5D4C
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 send nas-port-detail
radius-server dead-criteria time 5 tries 3
radius-server host 10.225.49.15 auth-port 1812 acct-port 1813 key 7 1237161E060E5D56797F71
! /Radius server in the line above points to ISE
wlan BYOD_Personal_Device 4 BYOD_Personal_Device /Defines the personal devices WLAN and SSID
client vlan Guest /Static assignment to non-routed (isolated) VLAN
mobility anchor 10.225.50.35 /Creates an anchor tunnel to the guest wireless controller
no shutdown /Enables the employee devices WLAN
By default WPA2 with AES as the cipher is enabled, along with 802.1X authenticated key management. Hence they do not show up in the configuration. The administrative-level show wlan id <wlan ID number> command can be used to display additional details regarding the configuration of the WLAN, including default values which do not appear within the configuration.
The employee devices WLAN must be configured on the device which functions as the Mobility Agent (MA) and on the device which functions as the Mobility Controller (MC). Therefore the configuration above is basically the same, regardless of whether a Catalyst 3850 Series switch is deployed as both the MA and MC within a branch deployment, a Catalyst 3850 Series switch is deployed as only an MA within a campus deployment, or a CT5760 wireless controller is deployed as an MA and MC within a campus deployment.
The Guest client VLAN in the configuration above is a VLAN which is isolated on the CT5760 wireless controller or Catalyst 3850 Series switch. It is not trunked to the adjacent Layer 3 device. This isolates any guest devices should the CAPWAP tunnel between the foreign and anchor controllers go down.
The following partial configuration example shows the configuration of the mobility group and mobility group members on an IOS XE based wireless controller.
wireless mobility group member ip 10.225.50.35 public-ip 10.225.50.35 /Guest Controller
wireless mobility group name byod /Mobility group name
The mobility group name and mobility group peers must appear on the device which functions as the Mobility Controller (MC). Therefore, when a Catalyst 3850 Series switch is deployed as both the MA and MC within a branch deployment, the configuration must include the above two lines. A Catalyst 3850 Series switch deployed as only an MA within a campus deployment would not include the mobility group configuration. Instead the CT5760 wireless controller deployed as a MA and MC within a campus would contain the mobility group configuration. Note that since IOS XE based wireless controllers only support the new hierarchical mobility architecture; no configuration is required to enable it.
NoteCisco wireless controllers currently support two different mobility architectures. The old mobility architecture relies on Ethernet-over-IP tunnels between wireless controllers. The new mobility architecture, also called the hierarchical mobility architecture, relies on CAPWAP tunnels between wireless controllers. The two mobility architectures are not compatible with each other. If mobility (including the auto-anchoring function) is required between wireless controllers, all wireless controllers must be running either the new mobility or the old mobility architecture. The new mobility architecture is supported on Cisco 5508 and WiSM2 wireless controllers with software release 7.3.112 and on the Cisco 5508, WiSM2, and 2504 wireless controllers with software release 7.5. The new mobility architecture is supported on the Cisco 5760 wireless controller and the Catalyst 3850 Series switch with IOS XE software releases 3.2.0SE and 3.2.2SE. CUWN wireless controller release 7.4 and releases below 7.3.112 support only the old mobility architecture. The Cisco Flex 7500, 8500, and vWLC do not support the new mobility architecture. IOS XE based wireless controllers do not support the old mobility architecture. Hence if a network contains both Flex 7500 wireless controllers and Converged Access controllers, then separate sets of guest wireless controllers must be deployed with the DMZ to support both mobility architectures with the guest wireless design discussed in this design guide. Cisco wireless controllers currently support two different mobility architectures. The old mobility architecture relies on Ethernet-over-IP tunnels between wireless controllers. The new mobility architecture, also called the hierarchical mobility architecture, relies on CAPWAP tunnels between wireless controllers. The two mobility architectures are not compatible with each other. If mobility (including the auto-anchoring function) is required between wireless controllers, all wireless controllers must be running either the new mobility or the old mobility architecture. The new mobility architecture is supported on Cisco 5508 and WiSM2 wireless controllers with software release 7.3.112 and on the Cisco 5508, WiSM2, and 2504 wireless controllers with software release 7.5. The new mobility architecture is supported on the Cisco 5760 wireless controller and the Catalyst 3850 Series switch with IOS XE software releases 3.2.0SE and 3.2.2SE. CUWN wireless controller release 7.4 and releases below 7.3.112 support only the old mobility architecture. The Cisco Flex 7500, 8500, and vWLC do not support the new mobility architecture. IOS XE based wireless controllers do not support the old mobility architecture. Hence if a network contains both Flex 7500 wireless controllers and Converged Access controllers, then separate sets of guest wireless controllers must be deployed with the DMZ to support both mobility architectures with the guest wireless design discussed in this design guide.
Guest Controller Configuration
The guest controller is the point where all the employee device traffic is terminated. For this version of the design guide, the discussion only includes a CT5508 CUWN wireless controller as the guest controller. An example of a guest controller configuration for the employee personal devices WLAN is shown in Figure 18-10.
Figure 18-10 Example Configuration of a Guest Wireless Controller for the Employee Personal Devices WLAN
As can be seen, the configuration of the WLAN on the guest controller must match the configuration of the WLAN on the campus controller.
The guest controller needs to be configured with a mobility anchor pointing at itself. An example is shown in Figure 18-11.
Figure 18-11 Example Configuration of the Mobility Anchor on a Guest CUWN Wireless Controller
Again, this assumes the campus controller and the guest controller are configured to be part of the same mobility group before the mobility anchor is configured.
The network administrator must also configure the employee personal devices WLAN to use RADIUS within the guest controller for authentication. This is shown in Figure 18-12.
Figure 18-12 Authentication via RADIUS for the Employee Personal Devices WLAN on the Guest Controller
Finally, in order to support the new mobility architecture (also referred to as the hierarchical mobility architecture), the network administrator must check the Enable Hierarchical Architecture option within the global mobility configuration of both the campus and guest controller. An example is shown in Figure 18-13.
Figure 18-13 Enabling the Hierarchical Mobility Architecture
NoteSince the Flex 7500 wireless controller does not support the new mobility architecture, this step can be skipped in deployments involving a Flex 7500 as the branch wireless controller. Since the Flex 7500 wireless controller does not support the new mobility architecture, this step can be skipped in deployments involving a Flex 7500 as the branch wireless controller.
Cisco ISE Policy Configuration
From a Cisco ISE policy perspective, the existing authentication rule—which is used to support both the on-boarding of corporate-owned (IT-managed) devices and the authentication of on-boarded corporate-owned devices within the Limited Access use case—can also be used to support wireless employee personal devices for the Basic Access use case. An example of such a policy rule is shown in Figure 18-14.
Figure 18-14 Example of Cisco ISE Authentication Policy Allowing Wireless Employee Personal Device Access
The logical format of the authentication policy rule for this example is:
IF (Wired_802.1X OR Wireless_802.1X)
THEN (Allow Default Network Access AND
IF Network Access:EapAuthentication EQUALS EAP-TLS USE Certificate_Profile
IF Network Access:EapTunnel EQUALS PEAP USE AD1
ELSE Default EQUALS DenyAccess)
Wired_802.1X is a system-generated compound condition that is used here to match 802.1X-based authentication requests from switches. It matches the following two standard RADIUS dictionary attribute-value (AV) pairs:
Service-Type -  EQUALS Framed
NAS-Port-Type -  EQUALS Ethernet
Wireless_802.1X is a system-generated compound condition that is used here to match 802.1X-based authentication requests from Cisco wireless controllers. It matches the following two standard RADIUS dictionary attribute-value (AV) pairs:
Service-Type -  EQUALS Framed
NAS-Port-Type -  EQUALS Wireless - IEEE 802.11
Default Network Access is a system-generated authentication result, which allows various EAP protocols to be used for authentication.
Certificate_Profile is a user-defined Certificate Authentication Profile configured under the External Identity Sources section of the Cisco ISE server.
AD1 corresponds to the Microsoft Active Directory identity store, where employee credentials are typically held within an organization.
For the Basic Access use case, wireless employee personal devices which use PEAP for authentication will match on the second condition—IF Network Access:EapTunnel EQUALS PEAP USE AD1—causing these devices to proceed to the authorization phase. Note that the example above works for employee personal devices which utilize PEAP authentication only. If the customer requires other authentication or EAP methods, additional conditions would need to be added to the above authentication policy rule. These conditions could also use the AD1 Microsoft Active Directory identity store to verify employee user credentials. Alternatively, the default condition could be changed from denying access to also using the AD1 identity store.
From a Cisco ISE policy perspective, an additional authorization rule needs to be added in order to support the Basic Access use case. This rule permits access for devices using PEAP authentication, which originate from the SSID corresponding to the employee personal devices WLAN. An example of the policy rule is shown in Figure 18-15.
Figure 18-15 Example of Cisco ISE Authorization Policy Allowing Wireless Employee Personal Device Access
The logical format of the authorization policy rule for this example is:
IF (Wireless_PEAP AND Personal_Device_WLAN)
Wireless_PEAP is a user-defined compound authorization condition that is used here to match authentication requests from wireless PEAP devices. It matches the following two standard RADIUS dictionary attribute-value (AV) pairs, along with a Network Access condition which specifies the use of PEAP.
Service-Type -  EQUALS Framed
NAS-Port-Type -  EQUALS Wireless - IEEE 802.11
Network Access:EapTunnel EQUALS PEAP
Personal_Device_WLAN is a user-defined simple authorization condition for employee personal devices that access the network via the WLAN corresponding to the employee personal devices SSID. It matches the following RADIUS AV pair from the Airespace dictionary:
Airespace-Wlan-Id -  EQUALS 4
The Airespace-Wlan-Id is the identification number (WLAN ID) of the WLAN corresponding to the employee personal devices SSID. This is shown in Figure 18-16.
Figure 18-16 Example Wireless Controller WLAN IDs Showing Employee Personal Devices WLAN and SSID
Note that this WLAN ID must be consistent across the entire BYOD deployment. This rule allows the ISE authorization policy to differentiate 802.1X authentication requests coming from the employee personal devices SSID and simply permit access. A WLAN ID cannot be changed on an existing WLAN. To change a WLAN ID, the WLAN must be removed and created again.
ASA Firewall Configuration
Figure 18-17 shows an example of the flows that need to pass through the Cisco ASA firewall to support this option.
Figure 18-17 Example of Flows that Need to Pass Through the Cisco ASA Firewall for Employee Personal Devices
The RADIUS session is initiated by the campus (foreign) wireless controller management interface to the Cisco ISE server for authentication and authorization. Therefore it does not need to be allowed through the ASA firewall for employees who are authenticating with personal devices. If using the newer hierarchical mobility architecture (as indicated in Figure 18-17), a CAPWAP auto-anchor mobility tunnel (UDP ports 5246 and 5247) between the management interfaces of the two wireless controllers must be allowed through the ASA firewall. If using the older mobility tunnel architecture, an Ethernet-over-IP (IP protocol 97) auto-anchor mobility tunnel, as well as the WLAN control port (UDP port 16666) between the management interfaces of the two wireless controllers, must be allowed through the ASA firewall.
Besides allowing DNS and DHCP (assuming the deployment of an internal DHCP server), the ASA firewall should be configured to block all other traffic generated from employee personal devices onto the internal network. Additional ports can be opened to accommodate the access of corporate resources as discussed in the following section and summarized in Table 21-2 .
NoteAdditional ASA firewall ports may need to be opened to accommodate guest wireless access, depending upon the deployment model discussed in Additional ASA firewall ports may need to be opened to accommodate guest wireless access, depending upon the deployment model discussed in Chapter21, “BYOD Guest Wireless Access”
Differentiated Quality of Service Treatment
With this deployment model, a separate QoS policy can be applied to employee personal devices, different from guest wireless devices. This is because wireless employee personal devices are terminated on a separate WLAN from wireless guest devices. For CUWN wireless controllers, as of software version 7.2, QoS is applied per WLAN by way of a profile, as shown in Figure 18-18.
Figure 18-18 Example of QoS Profile Applied to a WLAN
NoteIOS XE based wireless controllers support much more extensive QoS capabilities. However they also have the ability to support similar QoS per WLAN based on the older profiles model of CUWN wireless controllers. This version of the design guide does not address QoS on IOS XE based wireless controllers. Future versions will discuss this topic more thoroughly. IOS XE based wireless controllers support much more extensive QoS capabilities. However they also have the ability to support similar QoS per WLAN based on the older profiles model of CUWN wireless controllers. This version of the design guide does not address QoS on IOS XE based wireless controllers. Future versions will discuss this topic more thoroughly.
This may be desirable if employee personal devices are going to be allowed to run virtual desktop client applications such as a Citrix client or VMware client or if employee personal devices run collaboration clients such as Cisco Jabber.
Note Chapter 21, “BYOD Guest Wireless Access” discusses rate limiting per-SSID and per-User. These features can be used for employee personal devices as they were for guest devices. Rate limiting is configured on the campus (foreign) controller and not the guest (anchor) controller.
Accessing Corporate Resources
Because employee devices are associated to the network from a DMZ interface, which is effectively outside of the corporate firewall, they do not have access to company resources located inside the firewall. This may be perfectly acceptable and desirable. Employee devices still have access to the public Internet. This enables them to connect to cloud-based resources such as Cisco WebEx or partner websites. The employee device is afforded some level of usability, making the device useful as a productivity tool.
Companies may want to offer access to additional resources but still maintain the security offered by restricting employee devices to the guest side of the firewall. There are various options available to accomplish this objective, including:
- Setting up a mirror of the company website
- Allowing VPN access
- Allowing virtual desktop client access
Securing Mirror Sites for Personal Devices
One approach to bringing services to employee personal devices accessing the guest network is to set up a mirror of the company website in another DMZ segment, referred to as an employee device security zone (EDSZ) within this section. If employee personal devices connect to the guest wireless network, the website will only be accessible after the user has completed the Web Auth process and accepted an Acceptable Use Policy (AUP) or End User Agreement (EUA). This website does not need to be an exact match of an internal website, but could contain relevant content that employees can use on their personal devices to make them more effective. In addition, the website could include content optimized for smaller mobile displays. Examples of applications that could be offered in the EDSZ include access to email, a team wiki page, or the company news site.
There are several methods available to setup a secure website. In general, the deployment is very similar to a typical DMZ web service, except that rather than residing in an Internet facing DMZ, the server is located on a subnet accessible by employee personal devices. The intent of this section is not to provide detailed guidance on the deployment of a presentation server, application server, and database server. Site administrators should be familiar with the approach that best fits their security environment. Some high level considerations when setting up the server include:
- Dual attachment—Usually this is considered to be more secure. The client-side NIC should implement firewall services that allow inbound connections on TCP port 80 or 443. Only session requests initiated by the client subnets should be allowed towards the server. Session requests initiated by the server should not be allowed towards the client subnets. If the employee device wireless network is encrypted, then some organizations may be comfortable allowing users to attach via HTTP.
- The back-end NIC should be used to move content between the server and the data store or application server. It may also be allowed for remote administration of the site. Single-attached servers are possible although usually a dedicated and secured gateway is setup for the server-to-server communications that is separate from the server-to-web client gateway.
- Content Delivery—Generally content is either static or dynamic. Static content can be pushed overnight or as needed to keep the website current. Dynamic content could allow the employee device to post information to the site. The website could use a local data store that is synchronized with an external data store or have a secured channel to an application server.
- User Authentication—Some method should be used to ensure only authorized and authenticated users are able to view site content. Utilizing Microsoft Active Directory or a local user database are two possible methods. Active Server pages (ASP.NET) can also be used to leverage the login controls used with Microsoft Internet Information Server (IIS) servers and provide a more sophisticated authentication model such as single sign-on (SSO). Local databases are easier to setup but require a high level of administrative overhead and are usually only appropriate in very small organizations.
- Secure Sockets—Websites in the employee device security zone (EDSZ) should implement secure socket layer (SSL) or transport layer security (TLS) if employees are sending sensitive information, such as their login credentials. This can be relaxed somewhat if the EDSZ has been implemented with wireless encryption. On the other hand, if employee devices reside in the traditional guest network where wireless packets are not typically protected with encryption and are co-mingled with actual guest traffic, then SSL/TLS websites are needed. This is particularly important if employees are passing their corporate credentials to a mirror website.
- Web Server software—There is a wide range of web server software available. Deciding which type of server to deploy impacts what security features are available. Common choices include Microsoft IIS, Apple, and Tomcat. Wikipedia has a comparison of web server software that can illustrate the choices available ( http://en.wikipedia.org/wiki/Comparison_of_web_server_software ). It is also possible to host sites on a secure cloud service. This service could be restricted to IP addresses or require client side certificates. With proper security precautions, a cloud-based site could also allow mobile employees access to some traditional corporate resources such as payroll or benefits that are increasingly finding their way to the cloud.
Figure 18-19 illustrates a simple scenario where static content is deployed in a DMZ dedicated for employees using personal devices. A Windows 2008 server is deployed with Microsoft IIS 7.0 as well as some other network services specific to the DMZ, such as DNS and Read-Only Directory Services (RODS). Users are authenticated against the corporate Microsoft Active Directory server. The RODS service requires DNS to be installed on the same server. The web server is typically a dedicated box. However, in some situations it may be desirable to run RODS and IIS on the same server to simplify basic authentication using Microsoft AD. It is more appropriate when supporting a small-to-modest number of employee devices.
Figure 18-19 Example of a Mirror Website for Employee Personal Devices
Moving content to the secured server can be done by various means. One approach is to use FTP, however because FTP is not secured, a better approach is to use either SFTP or FTP over SSL. By default, Microsoft IIS does not ship with a secure FTP server. Microsoft supports FTP over SSL rather than SFTP. Administrators must copy the installation package from Microsoft’s website ( http://learn.iis.net/page.aspx/310/what-is-new-for-microsoft-and-ftp-in-iis-7/ ) and install the feature on their server. If FTP is already running, the administrator needs to deselect the FTP feature from the services manager prior to installing the FTP over SSL server. The improved FTP over SSL server offers additional tools not available in the standard FTP package that are used to manage access to the FTP site, as shown in Figure 18-20.
Figure 18-20 Example of Tools Available with the FTP over SSL Server
Anonymous authentication should be disabled and at least basic authentication should be enabled. There are other options that may be appropriate from some organizations.
Instead of FTP over SSL, administrators can choose to use Web Distributed Authoring and Versioning (WebDAV). This method offers more flexibility than FTP because many operating systems allow the connection to be mounted to the file system. By providing a directory handle, web authoring applications as well as other applications can directly use the secured pipe. WebDAV is based on HTTP or HTTPS and provides the ability to authenticate and encrypt data. If employees are placed directly in the guest SSID, then WebDAV HTTPS should be used since passwords are sent. If employee devices are placed in an encrypted EDSZ, then WebDAV HTTPS could be used to provide an additional layer of encryption. The security considerations are detailed in section 20 of RFC4918.
Another option similar to WebDAV is CIFS. This protocol also allows local directory mounts of the remote site. It is commonly found in Microsoft environments, although Samba is available for non-Windows servers. Microsoft also supports SMB2 with Vista, Windows 7, and Windows 8, which is an update to CIFS. There are several other approaches that provide a secure path between either the web authoring site or the application server. A particular enterprise will likely leverage the same methods as the web servers located in the traditional DMZ.
The employee devices need access to a DNS server. If the EDSZ web server is using RODS, then DNS is already available on the Directory Server. It is installed by default when the RODS is setup unless the administrator explicitly chooses not to. Dynamic updates are secured and zone transfers are not enabled. If the web server is not using AD for employee authentication, then DNS will be a standalone service.
Outlook Web Access for Employee Devices
Email is a foundational service that can be offered to employee devices. This can be accomplished by deploying a web interface to the mail server such as Outlook Web Access (OWA) or ActiveSync for exchange environments. Some enterprises may already be offering this service for employees that need email while traveling. In this case, the employee devices can continue to use the current Internet facing OWA server.
Microsoft does not support the OWA server in a DMZ zone. Instead, the OWA server should be behind the firewall. Holes can be opened for port 443. Another option is to setup Apache in the EDSZ as a reverse proxy. The Microsoft recommended approach is to run OWA on the client access server (CAS) and publish the CAS with Microsoft’s Internet security and acceleration (ISA) server into the EDSZ. This is a full blown deployment and may not be appropriate as a method to grant employee personal device access due to the complexity involved versus other methods, such as simply opening a hole in the EDSZ DMZ firewall for HTTPS to the enterprise CAS.
Another option is subscribing to Office365, which is Microsoft’s cloud-based Exchange and Office environment. In this case, employees would use the public Internet service to gain access to their email or other cloud-based enterprise resources. At this time, there is not a native Office365 application for either Android or iOS devices and users would be restricted to HTTPS access unless they were using a Windows 8-based mobile device. This method would also allow Direct-To-Cloud over 3G/4G or off-premise accesses to the same resources. Microsoft is only one of many cloud based enterprise environments offering email services.
Future versions of this document will discuss mobile device managers (MDM) that are used to manage the configuration profiles of mobile devices and provide additional security features needed for lost or stolen devices. Some of the MDM functionality is licensed from Microsoft, including remote-wipe, PIN lock enforcement, and others. ActiveSync is used to synchronize email, calendar events, and contacts between the Microsoft Exchange server and the mobile device’s email application. Administrators may be interested in providing ActiveSync to devices in the employee device security zone (EDSZ). When properly configured and certified, ActiveSync can also provide the MDM security features mentioned previously. Providing this support is similar to OWA. The firewall policy in the EDSZ can be set to allow connections to ActiveSync on the CAS that may be published on an ISA server. ActiveSync is supported by WebDAV and should be used over HTTPS (TCP port 443).
Enterprises that restrict employee devices to a guest or dedicated EDSZ may want to allow a subset of these users the ability to launch the built-in VPN client to connect to the secured part of the network. There are two methods that can be employed. First, the device may already have access to the current Internet-facing VPN concentrator. In this case, the employee device would connect from the guest network out through the public Internet and then back in to the Internet DMZ where the VPN concentrator is located. If employee devices are co-mingled with actual guest traffic, then this may be the best approach. However, if a dedicated and secured SSID is deployed behind an ASA firewall specifically for employee personal devices, then this firewall could also provide VPN access for some privileged users. Alternatively, a dedicated VPN concentrator could be located in the EDSZ. After the device authenticates and joins the secured wireless domain, these users would connect to the VPN concentrator to gain additional secured access. Only employee devices in the dedicated security zone can reach the concentrator. The general layout of the network components are shown in Figure 18-21.
Figure 18-21 Employee Zone VPN Network Components
Apple iOS devices include a built-in Cisco IPSec client allowing ESP tunnel mode and XAUTH. Both Apple and Android devices offer L2TP with IPsec and pre-shared key (PSK). The ASA can be setup to accept both types of VPN clients. For this discussion, the focus is the Cisco VPN client found on Apple iOS devices.
The employee needs to know the name of the VPN concentrator, group, and group secret to configure the VPN client. Future version of this document will illustrate how the VPN configuration can be pushed to the employee device without user intervention. Certificates can also be pushed to the employee device to further secure access to the VPN concentrator. The use of certificates negates the need for a group and group secret.
Figure 18-22 iOS VPN Client Configuration
When the user connects to the VPN concentrator, they are asked for their Microsoft AD credentials. This information is passed by the Cisco ASA to the Cisco ISE server, where a policy decision can be made. This decision can include attributes from Microsoft Active Directory or any of the other parameters Cisco ISE can use to determine policy. If the user is authenticated and authorized by Cisco ISE, the ASA completes the VPN connection. Once connected, the ASA can apply additional security and access restrictions to the tunnel, further controlling what resources the employee device can reach. The ASA can also be used to monitor who is using the VPN portal, as shown in Figure 18-23.
Figure 18-23 ASA Management for VPN Connections
ASA provides additional information for managing VPN connections.
Virtual Desktop Client
Another available deployment model is to allow a virtual desktop to run on the employee device. The actual applications and associated data remain on the secured hosting server. Once the device disconnects from the network, the data is typically no longer available to the user. The enterprise can control which users are able to launch a virtual desktop and what applications are available on that desktop. The firewall between the EDSZ and the hosting server can be configured to allow specific connections.
There are a wide range of possibilities. In its simplest from, the employee could use VNC to connect back to their desktop or a dedicated server. A VNC client is available for both iOS and Android devices. This may be adequate for some small environments where availability and manageability are not a top priority. By default, the connection is not encrypted, which is a concern. Administrators may not have the necessary control over which applications are available on the hosting server. Employees may be tempted to attach to their desktop and send sensitive data to an external account via email or cloud file sharing services such as Dropbox and Google Drive. This temptation only arises as a means to bypass IT policy and should be considered before allowing remote desktops to attach to employee deployed VNC servers. The use case for employee devices with virtual VNC desktops needs careful review. The employee is likely sitting in front of the actual desktop, with a full keyboard and mouse and likely does not need a remote desktop. The best approach may be to block TCP port 5900 from traversing the firewall to unknown destinations.
Cisco also partners closely with Citrix in support of both the XenApp and XenDesktop products for deployment of a Virtual Desktop Infrastructure. Access to VDI for employee devices are best suited in environments where a centralized UCS server is securing and managing sessions. With VDI in place for corporate devices, extending access to employee devices may allow productivity gains. This can be done by opening the firewall to allow a connection to specific and well known servers. Beyond BYOD, virtual desktops are compelling because of the reduction in IT costs. Adding tablet support maximizes the benefit because the requirement for employee laptops is reduced. A small and lightweight VDI hardware appliance replaces the traditional desktop, and mobile device support un-tethers the employee from the cube. Tablets with virtual desktops can offer much of the same functionality as employee laptops, but at a reduced cost and with stronger tools to address lost and stolen devices plus centralized data security inherent in VDI.
Finally AnyConnect provides a centralized virtual desktop that integrates with the ASA firewall. This is a good approach because security is the foundation of the system. AnyConnect desktops attach to the ASA firewall via SSL. Virtual desktops are evolving in capabilities and will be covered in more detail the next release of this document.