Cisco Bring Your Own Device (BYOD) CVD
BYOD Limited Use Case
Downloads: This chapterpdf (PDF - 3.2MB) The complete bookPDF (PDF - 62.3MB) | Feedback

Table of Contents

BYOD Limited Use Case—Corporate Devices

Whitelist Identity Group

Policy Enforcement for Security Group Access

Security Group Access Tags

Security Group ACL

Authorization Polices for SGT

Corporate Devices—Full Access

Simple and Compound Conditions

Permissions for Wireless Users

Centralized Campus with SGTs

Centralized Campus with ACLs

Branch with FlexConnect

Converged Access Branch or Campus

Corporate Wired Devices—Full Access

Wired Simple and Compound Conditions

Permissions for Wired Users

Campus Wired

Branch Wired

Converged Access Branch or Campus

ISE Authorization Policy

BYOD Limited Use Case—Corporate Devices

Revised: March 6, 2014

What’s New: In the previous version of the BYOD CVD, the authorization policies for a user accessing the network with a corporate device and enforced with the security group tags supported only a Centralized Unified Wireless Network (CUWN) architecture with CT-5508 as a controller.

In this version of the BYOD CVD, the authorization policies for a user accessing the network with a corporate device and enforced with security group tags support:

  • CUWN architecture using CT-5508 and CT-5760 controllers
  • Converged Access wireless design using Catalyst 3850

This chapter discusses design considerations and the construction of policy rules for providing network access to corporate devices, as well as the security policies enforced by the Cisco ISE. A corporate device is a corporate asset that is provided by the organization and has the approved configuration profiles and digital certificate to access the network. ISE allows the employee to on-board their corporate devices in a similar way personal devices are on-boarded, as discussed in Chapter15, “BYOD Enhanced Use Case—Personal and Corporate Devices”

Cisco ISE provides many ways to enforce security policies and determines what network resources each device is allowed to access. This chapter focuses on allowing full access to corporate devices. The ISE feature set is extremely flexible to meet diverse business requirements. The goal of this chapter is to highlight this flexibility of ISE and explain the steps to restrict access for corporate devices.

Figure 16-1 shows the different authorization rules used by ISE to grant full access to corporate devices. Different network components play a role in this process, including the wireless infrastructure, Active Directory, a CA server, etc.

Figure 16-1 Provisioning Corporate Devices

 

Whitelist Identity Group

An identity group is a logical list used to group endpoints according to their profiles and is an efficient way for ISE to enforce different permissions to different types of devices.

For this design guide, the Whitelist identity group was created for the purpose of uniquely identifying corporate devices. This identity group maintains a list of devices owned by the corporation. The Whitelist is manually updated by the IT administrator and contains the MAC addresses of devices that are granted full access. The assumption is that IT has added the devices to the Whitelist in advance.

The identity group provides an additional check when enforcing authorization rules. Endpoints may be moved to other identity groups, such as the Whitelist identity group or the Blacklist identity group, used when a device is lost or stolen. Chapter 22, “Managing a Lost or Stolen Device” has more details on the Blacklist identity group.


Note Endpoints can only be members of one identity group at a time.


To update an endpoint’s identity group, click Administration > Groups > Endpoint Identity Groups. Figure 16-2 shows endpoints as members of the Whitelist identity group.

Figure 16-2 Whitelist Identity Group

 

An Active Directory group could be used as an additional check, but for the purpose of this design guide the Whitelist identity group identifies a device as a corporate device. This model could easily be expanded to include AD groups to enforce additional policy requirements.

Figure 16-3 highlights the policy tested in this chapter, along with the different requirements and permissions. This policies, along with detailed configurations, is explained in this chapter.

Figure 16-3 Access Policies and Permissions

 

This chapter assumes that after employees have on-boarded their devices, they'll connect to the BYOD_Employee. Figure 16-4 highlights the connectivity flow granting full access to corporate devices. If the device has been on-boarded, it belongs to the Whitelist identity group and has a digital certificate, the device is granted full access.

Figure 16-4 Corporate Device BYOD Access

 

Policy Enforcement for Security Group Access

A new addition to this CVD is the use of Security Group Tags in creating role-based policies in addition to ACLs to enforce policies for campus wireless users. Enforcing policies for SGA in BYOD architecture consist of three main components:

  • Defining tags for the endpoints and the destination servers.
  • Defining and implementing the Security Group ACL in the switching infrastructure.
  • Defining firewall policies based on Security Group Tags if Security Group Firewall is implemented.

Depending on the SGA deployment scenario followed, the Security Group Egress Policy can be defined at the ISE and dynamically pushed to Catalyst 6500 infrastructure switches and the Nexus Data Center switches as Security Group ACLs (SGACL) or configured at the ASA Firewall as a SGT-based policy. These two choices are discussed in Chapter 23, “BYOD Policy Enforcement Using Security Group Access” as two different deployment scenarios.

Security Group Access Tags

The basic idea of Security Group Access is to define the tags for source and destination traffic flows and specify what source tags are able to reach other destination tags. For example, are devices tagged with an SGT 10 allowed to communicate with a server tagged with an SGT 40? This flow is either allowed or blocked at the enforcement point.

Using this tagging concept, unique tags have been defined for different types of source traffic generated by the endpoints. As explained in “Security Group Access for BYOD,” unique permissions are established for personal and corporate devices and unique tags have been defined for each use case.

Table 16-1 illustrates how tags are assigned to different devices.

 

Table 16-1 Source Tags

Device Type
Tag

Corporate device with Full Access

SGT 10

Personal device with Full Access

SGT 11

Personal device with Partial Access

SGT 12

Similarly, the destination servers also need to be associated with a particular tag. Table 16-2 illustrates how, based on their role, servers are assigned with a different tag.

 

Table 16-2 Destination Tags

Destination Server
Tag

Open Access

SGT 40

Corporate Server

SGT 50

Security Group ACL

After defining the source and destination tags, the next logical step is to define the egress policy that establishes the permissions for traffic between those tags. Table 16-3 illustrates the egress policy as an enforcement matrix.

 

Table 16-3 Enforcement Matrix

Device Type
SGT 40
SGT 50

SGT 10

Corporate device with Full Access

Yes

Yes

SGT 11

Personal device with Full Access

Yes

Yes

SGT 12

Personal device with Partial Access

Yes

No

As shown in Table 16-3 , corporate or personal devices granted full access will be allowed to reach servers that have been tagged with SGT 40 or SGT 50. Similarly, a personal device with a partial access is only allowed to connect with a server tagged with SGT 40.

The implementation of the SGACL depends upon the type of the deployment scenario. For the deployment scenario where Nexus is the enforcement point, the SGACL is designed in ISE and pushed to the Nexus switch. When the deployment scenario is using ASA as the enforcement point, then an SGT-based access rule is configured manually on the ASA firewall.

Authorization Polices for SGT

Based on policy matches and authorization profiles, the ISE assigns an SGT to campus wireless devices. Centralized Campus—Policy Enforcement using TrustSec in Chapter 9, “BYOD Wireless Infrastructure Design” provides information about the criteria used to determine when, based on the network device type of the wireless controller defined in ISE, an ACL versus an SGT should be returned upon successful authorization.

For the destination server tags, the configuration is done manually at the data center switch and the actual enforcement happens based on the deployment scenario. For more information about configuring tags for servers and the ASA, see Chapter23, “BYOD Policy Enforcement Using Security Group Access”.

Corporate Devices—Full Access

To provide full access to corporate devices, the Cisco ISE verifies the following:

  • The device has been on-boarded and has the right certificate and profile configurations.
  • The device has been added to the Whitelist identity group.
  • To uniquely identify the device and prevent spoofing, the Calling-Station-ID matches the Subject Alternative Name of the certificate.
  • The connection originated using EAP-TLS authentication.

Since the wireless designs presented in this design guide rely on different WLCs for FlexConnect branches, Centralized Controller campuses, and Converged Access campuses and branches, unique authorization rules are created for connections originating from each design. At a high level, Figure 16-5 shows how different authorization profiles are selected for connections originating from different locations with different wireless designs. Each authorization profile in turn enforces a unique permission using VLANs, SGTs, dynamic ACLs (either named or downloadable [DACL]), FlexConnect ACLs, etc.

Figure 16-5 Full Access Enforcement

 

To differentiate these connections, the ISE relies on Network Device Groups to group WLCs based on their location or device type. This allows a single ISE to enforce policies across different groups of devices.

Figure 16-6 shows the different locations created for branch and campus devices.

Figure 16-6 ISE Device Groups—Locations

 

Similarly, Figure 16-7 shows a device type called Converged which can be created for Catalyst 3850 Series switches and CT5760 wireless controllers and used in the authorization policy.

Figure 16-7 ISE Device Groups—Device Types

 


Note One of the reasons a device type is used instead of a location for Converged Access designs is that the same authorization policy rules are used for Converged Access branch and campus designs within this design guide. Hence location—campus versus branch—is not particularly relevant from a Cisco ISE perspective to converged access designs presented in this design guide.


Each Wireless LAN Controller needs to be added to the proper device group by clicking Administration > Network Resources > Network Devices and specifying the proper location or device type from the pull-down menu.

Figure 16-8 shows how the dc-wlc-1 belongs to the Campus_Controllers location.

Figure 16-8 Campus Controller

 

Wireless LAN Controllers implementing a centralized (Local Mode) campus wireless design are assigned to the Campus_Controllers group.

To configure the authorization rules in ISE, click Policy > Authorization. Figure 16-9 highlights the authorization policy to grant full access to corporate devices.

Figure 16-9 Authorization Policies for Full Access

 

Looking at the first rule in more detail, ISE evaluates these conditions:

  • Whitelist—The endpoint has been added by an IT Administrator to the Whitelist identity group.
  • Wireless_EAP-TLS—The endpoint connected using EAP-TLS (defined as a compound condition).
  • The endpoint has a valid certificate. The Calling-Station-ID matches the MAC address included in the certificate’s Subject Alternative Name (defined as a simple condition).
  • The RADIUS authentication originated from a wireless controller which was a member of one of the following device groups: Campus_Controller, SGT_Controller, Branch_Controller, or Converged_Access (defined as a simple condition).

Note A wireless controller which is a member of the Converged_Access device group could be either a standalone device, such as a Cisco CT5760 wireless controller, or a switch with integrated wireless controller functionality, such as the Catalyst 3850.


Simple and Compound Conditions

To improve the readability of the authorization policy, simple and compound authorization conditions were defined to group different conditions. These conditions may be reused and modified without changing every authorization rule.

Table 16-4 shows the conditions used in the authorization rules.

 

Table 16-4 Wireless Simple and Compound Conditions

Wireless EAP-TLS (Compound)

Wireless_EAP-TLS (See Figure 16-11)

Radius:Service-Type Equals Framed

Radius:NAS-Port-Type Equals Wireless - IEEE 802.11

Network Access:EapAuthentication Equals EAP-TLS

Check for Valid Certificate (Simple)

Valid_Certificate (See Figure 16-12)

Radius:Calling-Station-ID EQUALS CERTIFICATE:Subject Alternative Name

WLC Location or Device Type (Simple)

SGT_Controller

Campus_Controller

Branch_Controller

Converged_Access

DEVICE:Location EQUALS All Locations#Campus_Controllers#SGT_Enabled

DEVICE:Location EQUALS All Locations#Campus_Controllers

DEVICE:Location EQUALS All Locations#Branch_Controllers

DEVICE:Device Type EQUALS All Device Types#Converged

To illustrate the value of using simple/compound conditions, Figure 16-10 shows how much longer and harder to read a rule can be when simple/compound conditions are not implemented.

Figure 16-10 Authorization Rule without Conditions

 

To define a new compound condition, click Policy > Conditions > Authorization > Compound Conditions. Figure 16-11 shows how the Wireless_EAP-TLS condition combines several conditions into one.

Figure 16-11 Wireless_EAP-TLS Condition

 

Figure 16-12 shows the Valid_Certificate simple condition.

Figure 16-12 Valid_Certificate Condition

 

The remaining conditions shown in Table 16-4 are defined in a similar way.

Permissions for Wireless Users

When all conditions in the authorization policy rule match, the rule invokes the proper permissions to provide Full Access, as shown in Table 16-5 .

 

Table 16-5 Permissions for Full Access

Permission name
Permission type
Purpose

SGT10_Campus_Corp

Standard result

To assign a SGT for 802.1X wireless devices connecting from an SGT-enabled controller.

Campus WiFi Full Access

Authorization profile

Provides Full Access for 802.1X wireless devices connecting from a centralized campus controller.

Branch WiFi Full Access

Authorization profile

To push a VLAN for 802.1X wireless devices connecting from a FlexConnect branch controller.

Converged WiFi Full Access

Authorization profile

Provides Full Access for 802.1X wireless devices connecting from a Converged Access controller.


Note A Converged Access infrastructure refers to a branch or campus deployment with Catalyst 3850 Series switches and/or CT5760 wireless controllers within this design guide.


Centralized Campus with SGTs

Figure 16-13 shows how the SGT10_Campus_Corp authorization profile is pushing the Security Group Tag whose value is 10 for a user of a corporate device, who is allowed to obtain full access.

Figure 16-13 SGT10_Campus_Corp

 

See Chapter 23, “BYOD Policy Enforcement Using Security Group Access” for details regarding how SGT 10 is given full access for a campus which implements a centralized controller (Local Mode) design with SGTs.

Centralized Campus with ACLs

Figure 16-14 shows how the Campus WiFi Full Access authorization profile is using the ACCESS_ACCEPT Access Type to allow full access.

Figure 16-14 Campus WiFi Full Access

 

Since full access is allowed with this authorization profile, no Named ACL for access control needs to be specified by ISE.

Branch with FlexConnect

Endpoints connecting from a branch location dynamically get assigned to VLAN 10, which has been configured without an ACLs thus providing full access.

Figure 16-15 Branch WiFi Full Access

 

Converged Access Branch or Campus

Within this design guide, a Converged Access infrastructure refers to a branch or campus deployment with Catalyst 3850 Series switches and/or CT5760 wireless controllers.

Figure 16-16 shows how the Converged WiFi Full Access authorization profile is using the ACCESS_ACCEPT Access Type to allow full access.

Figure 16-16 Converged WiFi Full Access

 

Again, since full access is allowed with this authorization profile, no Named ACL for access control needs to be specified by ISE.

Corporate Wired Devices—Full Access

The authorization policy rules for wired devices follow the same logic as wireless devices. Corporate approved wired devices are assumed to be pre-configured with the correct configuration profiles after being on-boarded.

To provide full access to corporate wired devices, the Cisco ISE verifies the following:

  • The device has been on-boarded and has the right certificate and profile configurations.
  • The device has been added to the Whitelist identity group.
  • To uniquely identify the device and prevent spoofing, the Calling-Station-ID matches the Subject Alternative Name of the certificate, in this case, the MAC address of the endpoint.
  • The connection originated using EAP-TLS authentication.

Since the wired designs presented in this design guide rely on slightly different access control mechanisms for converged access campuses and branches, for campuses and branches that do not implement converged access infrastructures unique authorization rules are created for connections originating from each design.


Note For the purpose of clarity within this design guide, converged access branches refer to designs in which Catalyst 3850 Series switches are deployed at the access-layer of the branch network. From a wired perspective, branches which do not implement converged access infrastructures are branches which deploy other Catalyst access-layer switches, such as the Catalyst 3750X Series. Unless otherwise specified, these are referred to simply as “branches” within the design guide. Similarly, converged access campuses refer to designs in which Catalyst 3850 Series switches are deployed at the access-layer of building distribution modules within the campus. From a wired perspective, campuses which do not implement converged access infrastructures are campuses which deploy other Catalyst access-layer switches, such as the Catalyst 3750X Series. Unless otherwise specified, these are referred to simply as “campuses” within this design guide. This is in order to reduce the use of verbose phrases such as “branches which do not implement converged access infrastructure” and “campuses which do not implement converged access infrastructure”.


At a high level, Figure 16-17 shows how different authorization profiles are selected for connections originating from different locations with different infrastructure (converged access versus non-converged access) designs. Each authorization profile in turn enforces a unique permission using VLANs, dynamic ACLs (either named or downloadable [DACL]), etc.

Figure 16-17 Full Access Wired Enforcement

 


Note Wired assignment of Security Group Tags (SGTs) is not discussed within the design guide. Hence there is no wired policy enforcement via SGTs in Figure 16-17. Future versions of this design guide may address wired SGT assignment.


To differentiate these connections, the ISE relies on Network Device Groups to group Catalyst switches based on their location or device type. This allows a single ISE to enforce policies across different groups of devices. Each Catalyst switch needs to be added to the proper device group by clicking Administration > Network Resources > Network Devices and specifying the proper location or device type from the pull-down menu.

Figure 16-18 shows the details of authorization profile configured in ISE for wired devices.

Figure 16-18 Authorization Policies for Wired Full Access

 

Looking at the rules in more detail, ISE evaluates the following conditions:

  • WhiteList—The endpoint has been added by an IT Administrator to the WhiteList identity group.
  • Wired_EAP-TLS—The endpoint connected using EAP-TLS (defined as a compound condition).
  • The endpoint has a valid certificate. The Calling-Station-ID matches the MAC address included in the certificate’s Subject Alternative Name (defined as a simple condition).
  • The RADIUS authentication originated from a Catalyst switch which was a member of one of the following device groups: Campus_Switches, Branch_Switches, or Converged_Access (defined as a simple condition).

Wired Simple and Compound Conditions

To improve the readability of the authorization policy, simple and compound authorization conditions were defined to group different conditions. These conditions may be reused and modified without changing every authorization rule.

Table 16-6 shows the conditions used in the authorization rules.

 

Table 16-6 Wired Simple and Compound Conditions

Wired EAP-TLS (Compound)

Wired_EAP-TLS

Radius:Service-Type Equals Framed

Radius:NAS-Port-Type Equals Ethernet

Network Access:EapAuthentication Equals EAP-TLS

Check for Valid Certificate (Simple)

Valid_Certificate

Radius:Calling-Station-ID EQUALS CERTIFICATE:Subject Alternative Name

WLC Location or Device Type (Simple)

Campus_Switches

Branch_Switches

Converged_Access

DEVICE:Location EQUALS All Locations#Campus_Switches

DEVICE:Location EQUALS All Locations#Branch_Switches

DEVICE:Device Type EQUALS All Device Types#Converged

Permissions for Wired Users

When all conditions in the authorization policy rule match, the rule invokes the proper permission. The permissions can be of different forms, such as an authorization profile or a standard result. In this design guide, for wired access the authorization policy is used as permission to the policy rules match. Table 16-7 explains the permissions used for the full access for wired users.

 

Table 16-7 Permissions Used for Wired Full Access

Permission Name
Permission Type
Purpose

Campus Wired Full Access

Authorization profile

Provides Full Access for 802.1X wired devices connecting from campus location.

Branch Wired Full Access

Authorization profile

To push a VLAN for 802.1X wired devices connecting from a branch location.

Converged Wired Full Access

Authorization profile

To push a named ACL for 802.1X wired devices connecting from either a campus or branch location with Converged Access.

Campus Wired

Figure 16-19 shows how the Campus Wired Full Access authorization profile is defined in ISE.

Figure 16-19 Campus Wired Full Access Authorization Profile

 


Note Cisco Catalyst switches support both downloadable ACLs (DACLs) and named ACLs. This design guide shows and validates the use of downloadable ACLs for access control of wired devices when implementing a non-converged access infrastructure and the use of named ACLs for access control of wired devices when implementing a converged access infrastructure. This is done to show the depth and range of capabilities for access control available on Cisco IOS-based platforms. Note that the same wired policy enforcement for converged access and non-converged access designs can be achieved if the customer desires by simply using either downloadable ACLs (DACLs) or named ACLs for both designs. Both downloadable and named ACLs have advantages and disadvantages, depending upon where they are deployed within the network. ACL Complexity and Considerations in Chapter 5, “Campus and Branch Network Design for BYOD” discusses some of these advantages and disadvantages.


The downloadable ACL (DACL), which allows all IP traffic, overrides the default-ACL configured on the switch port. The default-ACL is used as an additional preventative measure in case the downloadable ACL is not applied to the switch port for some reason.


Note ISE 1.2 has the ability to check the DACL syntax. This feature should be utilized in order to minimize the possibility that the DACL is not applied due to a syntax error.


Branch Wired

Figure 16-20 shows how a similar authorization profile is constructed for devices connected at a branch which does not have a Converged Access infrastructure. The authorization profile pushes VLAN information along with the ACL information.

Figure 16-20 Branch Wired Full Access Authorization Profile

 

Once this profile is downloaded to the Catalyst switch, the endpoint gets full access to the network.

Converged Access Branch or Campus

Figure 16-21 shows how the Converged Access Wired Full Access authorization profile is defined in ISE.

Figure 16-21 Converged Wired Full Access Authorization Profile

 

For the converged access design, a named ACL is implemented, meaning that the ACL must be configured on the Catalyst 3850 switch rather than being downloaded from ISE. Using the RADIUS Filter-ID attribute-value pair, ISE instructs the Catalyst 3850 to apply the ACL_Full_Access ACL. The following configuration example shows the contents of this ACL as defined in the Catalyst 3850 switch.

!
ip access-list extended ACL_Full_Access
permit ip any any
!
 

ISE Authorization Policy

For reference purposes, the complete authorization policy used during testing is shown in Figure 16-22. The figure highlights the following sections:

1. Used for blacklisting lost or stolen devices.

2. On-boarding and MDM registration/remediation.

3. Wireless devices connecting from an access point in a SGT_Enabled location.

4. Wireless devices connecting from an access point in the campus or branch locations.

5. Wired devices connecting from a campus or branch locations.

6. Wired and Wireless devices connecting from a converged location.

7. Guest and Basic Access.

Figure 16-22 Complete Authorization Policy