Cisco Bring Your Own Device (BYOD) CVD
BYOD Enhanced Use Case
Downloads: This chapterpdf (PDF - 7.49MB) The complete bookPDF (PDF - 68.29MB) | Feedback

Table of Contents

BYOD Enhanced Use Case—Personal and Corporate Devices

Active Directory Groups

Distributing Digital Certificates

Mobile Device On-boarding

Provisioning Flows

Provisioning Apple iOS Devices

Provisioning Android Devices

Provisioning Wired Devices

Key and Certificate Storage

Network Device Groups

Policy Enforcement for Security Group Access

Security Group Access Tags

Security Group ACL

Authorization Polices for SGT

Personal Wireless Devices—Full Access

Simple and Compound Conditions

Permissions

Centralized Campus with SGT

Converged Access Campus with SGT

Centralized Campus with ACLs

Branch with FlexConnect

Converged Access Branch or Campus

Personal Wireless Devices—Partial Access

Permissions

Centralized Campus with SGT

Converged Access Campus with SGT

Centralized Campus with ACLs

Branches with FlexConnect

Converged Access Branch or Campus

Personal Wireless Devices—Internet Only Access

Permissions

Centralized Campus with SGT or ACLs

Branches with FlexConnect

Converged Access Branch or Campus

Personal Wired Devices—Full Access

Wired Simple and Compound Conditions

Permission

Campus Wired

Branch Wired

Converged Access Branch or Campus

Personal Wired Devices—Partial Access

Permissions

Campus Wired

Branch Wired

Converged Access Branch and Campus

Personal Wired Devices—Internet Only Access

Permissions

Wired Campus

Branch Wired

Converged Access Branch and Campus

Android Devices—Deny Access

ISE Authorization Policy

BYOD Enhanced Use Case—Personal and 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 personal 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 personal device and enforced with security group tags support:

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

The BYOD Enhanced use case is a super-set of the BYOD Limited use case, covering both personal and corporate devices. This chapter defines the design scenarios for deploying BYOD for personal device access and the design considerations for each scenario. It also highlights how to deny access to personal devices based on their device type. Chapter 16, “BYOD Limited Use Case—Corporate Devices” provides the same design guidance for corporate devices. Hence the design guidance for corporate devices is not duplicated in this chapter.

One of the main objectives of a BYOD solution is to provide a simple way for employees to on-board their personal devices without requiring assistance from IT. Since the BYOD needs of the majority of employees will be met with either simple Internet access or Partial access, the only time an employee requires assistance from IT is when they may require full access to corporate resources.

Cisco ISE provides different ways to define security policies and determine what network resources each employee is allowed to access. The security policies are then enforced throughout the network infrastructure. The ISE feature set is extremely flexible, enabling different business policies to be enforced. This chapter explains the steps to on-board personal devices and how to apply different policies.

Figure 15-1 shows how a personal device is profiled and registered by ISE and the different network components (WLC, AD, CA) that play a role in the process. Different conditions are evaluated to provide the proper authorization and access to network resources, including digital certificates, Active Directory groups, etc.

Figure 15-1 Provisioning Personal Devices

 


NoteUnless otherwise specified, in the figures throughout this chapter “Wireless LAN Controllers” refers to either standalone devices such as the Cisco Flex 7500, CT5508, and CT5760 wireless controller or to wireless LAN controller functionality integrated within Catalyst 3850 Series converged access switches. Unless otherwise specified, in the figures throughout this chapter “Wireless LAN Controllers” refers to either standalone devices such as the Cisco Flex 7500, CT5508, and CT5760 wireless controller or to wireless LAN controller functionality integrated within Catalyst 3850 Series converged access switches.


Figure 15-2 shows how a personal device is restricted from accessing the network. Once the device connects and regardless of user authentication, ISE profiles the device and enforces the DenyAccess authorization rule.

Figure 15-2 Deny Access

 

Figure 15-3 shows the different permission levels configured in this chapter. These access levels are enforced using various mechanisms, including Access Control Lists (ACLs) in the Wireless LAN Controllers (WLCs) or Catalyst switches, Security Group Tag (SGT) assignment in the WLCs, and VLAN assignment in the Catalyst switches along with FlexConnect ACLs in access points.

Figure 15-3 Permission Levels for Personal Devices

 

Active Directory Groups

Active Directory groups can be used as an additional way to grant differentiated access to users. This chapter relies on the following three AD groups:

  • BYOD_Full_Access—Members of this group are granted full access to network resources.
  • BYOD_Partial_Access—Members of this group are granted partial access to network resources. With this permission, users are able to access the Internet and a subset of corporate applications, such as email, corporate directory, travel tools, etc.
  • Domain Users—All users are members of this system-generated group by default. Employees that are not members of the above mentioned groups are granted Internet access.

This model could easily be expanded to include other user groups with similar access requirements. A good example would be to create a new group and access list to grant access to contractors or partners.

Figure 15-4 highlights the different access policies validated for this chapter, along with the different requirements and permissions granted by each policy. These policies, along with detailed configurations, are explained later in this chapter.

Figure 15-4 Access Policies and Permissions

 


NoteThe location SGT refers to a Wireless LAN Controller which is dedicated for the purpose doing SGT only. The location SGT refers to a Wireless LAN Controller which is dedicated for the purpose doing SGT only.


To configure the Active Directory groups that can be available for use in the authorization policy conditions, click Administration > Identity Management > External Identity Sources > Active Directory > Groups and check the boxes next to the groups that will be used in the policy conditions and rules. Figure 15-5 includes the groups used in this design guide.

Figure 15-5 Active Directory Groups

 

This chapter assumes that after employees have on-boarded their devices, they will connect to the BYOD_Employee SSID. Figure 15-6 highlights the connectivity flow for personal devices.

If the endpoint connected from a wireless 802.1X EAP-TLS SSID and has a valid certificate, based on their AD group membership, employees will get:

  • Full Access if they belong to the BYOD_Full_Access group.
  • Partial Access if they belong to the BYOD_Partial_Access group.
  • Internet Access if they are a valid Active Directory member (Domain Users group)

Figure 15-6 Personal Device BYOD Access

 

Distributing Digital Certificates

Digital signatures, enabled by public key cryptography, provide a means to authenticate devices and users. In public key cryptography, such as the RSA encryption system, each user has a key pair containing both a public and a private key. The keys act as complements and anything encrypted with one of the keys can be decrypted with the other.

A digital signature is encrypted with the sender’s private key. The signature must be verified to confirm the sender’s identity. This is done by the receiver, who decrypts the signature with the sender’s public key. If the signature sent with the data matches the result of applying the public key to the data, the validity of the message is established.

This process relies on the receiver having a copy of the public key of the sender and a high degree of certainty that this key belongs to the sender, not to someone pretending to be the sender.

Deploying digital certificates on mobile devices requires a unique process, as many of these devices do not natively support all the features and functionality to create, download, and install digital client certificates in the same manner as traditional PC-based devices. At the same time, some endpoints do not support Simple Certificate Enrollment Protocol (SCEP) natively.

For example, for users to install digital client certificates using SCEP on Apple iOS devices, the IT administrator needs to manually create the configuration profile using the iPhone Configuration Utility and distribute the profile to user devices via email, USB, or web pages.

Traditional full-featured PC-based devices are more apt to take advantage of the many services, such as Microsoft’s NDES, to provide certificate enrollment. However, with the onset of many Android and Apple iOS devices on the market, it cannot be assumed that these devices can natively interoperate with many of the enterprise services currently deployed.

ISE solves this problem by distributing digital certificates to endpoints using the SCEP Proxy feature, which allows endpoints to obtain digital certificates through ISE. Moreover, this feature is combined during the initial registration process, thereby preventing different registration steps. The next section on mobile devices discusses how the endpoints obtain their digital certificates during the registration process.

Mobile Device On-boarding

Deploying digital certificates to endpoint devices requires a network infrastructure that provides the security and flexibility to enforce different security policies. Figure 15-7 highlights the general steps that are followed when a mobile device connects to the network using dual SSIDs.

1. A new device connects to a provisioning SSID. This SSID (open or secured with PEAP) is configured to redirect the user to the Guest Registration portal.

2. The certificate enrollment and profile provisioning begins once the user is properly authenticated.

3. The provisioning service requests information from the mobile device user and provisions the configuration profile, which includes a WiFi profile with the required parameters to connect to the secured Employee SSID.

4. For subsequent connections, the device uses the Employee SSID and is granted access to network resources based on different ISE authorization rules.

Figure 15-7 Enrollment and Provisioning—Dual SSID

 

The on-boarding steps may also be configured with a single SSID used for provisioning and secure access. The general steps followed when the mobile device connects are similar, redirecting the user to the Guest registration portal and provisioning the device with a digital certificate and configuration profiles.

Provisioning Flows

This section explains the interaction between the endpoints and the Guest Registration portal and the steps required to enroll the digital certificate and configuration profile. The way Windows and Mac devices are provisioned is similar. Chapter 8, “Summary of Configuring the Infrastructure” points to the chapters with the steps required to configure the different network components.

Provisioning Apple iOS Devices

The following steps take place while provisioning Apple iOS devices:

  • The device is redirected to the Guest Registration Portal.
  • After successful authentication, the Over-The-Air (OTA) enrollment begins.
  • Device sends unique identifier (MAC address) and other information.
  • Certificate enrollment information is sent to the device.
  • A SCEP request is made to ISE, which returns a certificate.
  • Wireless profile for BYOD_Employee is sent to the device.
  • Once the enrollment is complete, the user manually connects to BYOD_Employee SSID.

Figure 15-8 Provisioning Flow for Apple iOS Devices

 

For more details on Over-the-Air Enrollment and configuration for iOS devices, review the iPhone OS Enterprise Deployment Guide: http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf .

Provisioning Android Devices

The following steps take place while provisioning Android devices:

  • The device is redirected to the Guest Registration portal.
  • After successful authentication, the self-registration portal page redirects the user to the Google Play.
  • The user installs the Supplicant Provisioning Wizard (SPW).
  • The SPW is launched to perform provisioning of the supplicant. The SPW performs the following functions:

Discovers the ISE and downloads the profile from the ISE.

Creates a certificate/key pair for EAP TLS.

Makes a SCEP proxy request to ISE and gets the certificate.

Applies the wireless profile to allow connectivity to BYOD_Employee SSID.

  • The SPW triggers re-authentication and connects to BYOD_Employee SSID automatically.

NoteThe Android agent must be downloaded from Google Play and is not provisioned by the ISE. Endpoints must be able to reach Google Play on the Internet. The Android agent must be downloaded from Google Play and is not provisioned by the ISE. Endpoints must be able to reach Google Play on the Internet.



NoteACL_Provisioning_Redirect must redirect all traffic sent to enroll.cisco.com. The Cisco Configuration Assistant for Android devices requires this redirect to discover the ISE server. This is shown as part of step 3 in ACL_Provisioning_Redirect must redirect all traffic sent to enroll.cisco.com. The Cisco Configuration Assistant for Android devices requires this redirect to discover the ISE server. This is shown as part of step 3 in Figure 15-9. This is not a concern if the guidance presented in the CVD is followed since all Internet traffic except Google Play is redirected back to ISE.


Figure 15-9 Provisioning Flow for Android Devices

 

Provisioning Wired Devices

BYOD applies to both wired and wireless devices. Wired devices can be provisioned, registered, authenticated, and authorized in much the same way as wireless devices. The following are some of the advantages of provisioning wired devices:

  • Certificate provisioning can be done during the provisioning process, which alleviates the burden on IT to support another model to provision certificates on the devices.
  • The native supplicants on the device can be configured with the right protocols during the provisioning process. If this is left to the user, it may often lead to incorrect configurations and additional management overhead for IT.
  • Provides easier methods for IT to obtain visibility into who is accessing the network and also methods to remove network access for devices that are lost or stolen.

Figure 15-10 shows a high-level overview of the components used to deploy wired devices. ISE uses several building blocks, such as AD group membership, the EndPoints:BYODRegistration attribute, and Digital Certificates to authenticate and authorize devices. Examples on how to construct these polices are explained in this design guide.

Figure 15-10 Wired Device Deployment

 


NoteUnless otherwise specified, in the figures throughout this chapter “Access Layer Switches” refers to either switches such as the Catalyst 3750X Series and Catalyst 4500 Series or to Catalyst 3850 Series converged access switches. Unless otherwise specified, in the figures throughout this chapter “Access Layer Switches” refers to either switches such as the Catalyst 3750X Series and Catalyst 4500 Series or to Catalyst 3850 Series converged access switches.


The following are high-level steps that occur when a wired device connects to the access layer switch:

1. The switch must detect that the wired endpoint is not configured for dot1x and should authenticate using MAB.

2. The ACL_Provisioning_Redirect ACL is used to match web traffic.

3. The URL redirect must point to the ISE Guest Registration portal.

4. The ACL_Provisioning ACL must be downloaded on the port that restricts access in this state.

5. The user opens a browser and attempts to access any resource.

6. The switch redirects the user to an ISE self-registration portal.

7. ISE authenticates the user against AD and pushes the SPW package.

8. The SPW package helps the user register and obtain a digital certificate from ISE.

9. CoA occurs and the user reconnects to the network using the obtained digital certificate.

Figure 15-11 illustrates the flow for wired device provisioning.

Figure 15-11 Wired Device Provisioning Flow

 

Key and Certificate Storage

Being able to store digital certificates and their associated keys safely is critical for every device. Storage is implemented differently, depending on the operating system or media used. Table 15-1 shows the different platforms tested in this design guide and their certificate stores.

 

Table 15-1 Platform and Certificate Storage

Device
Certificate Store
How to Access

Microsoft Windows

Machine Certificate Store

Use the Certificates snap-in from the mmc.exe utility

Mac OS

Device Certificate Store

Use the Keychain Access application

Apple iPad

Device Certificate Store

Settings > General > Profile

Android

Credential Storage

Settings > Location & Security

Once provisioned, the certificates have the following attributes, which can be used by ISE to enforce different permissions:

Common Name (CN) of the Subject:
User identity used for authentication
 
Subject Alternative Name:
MAC address(es) of the endpoint.

Network Device Groups

To differentiate between different 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. Click Administration > Network Resources > Network Device Groups to define locations for branch, campus, and SGT enabled controllers.

Figure 15-12 shows the different locations used in the authorization policy.

Figure 15-12 ISE Device Groups—Locations

 

Similarly, Figure 15-13 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 15-13 ISE Device Groups—Device Types

 


NoteOne 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. Note that if location is relevant, the customer can always modify the design presented here and choose to deploy separate authorization policy rules for branch and campus Converged Access designs as well. 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. Note that if location is relevant, the customer can always modify the design presented here and choose to deploy separate authorization policy rules for branch and campus Converged Access designs as well.


Each Wireless LAN Controller, previously defined as a Network Device, 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 15-14 shows how the dc-wlc-1 Wireless LAN Controller belongs to the Campus_Controllers Network Device Group.

Figure 15-14 ISE Network Devices—Campus Controller

 

These device groups will be used in the authorization rules of the following sections to enforce full, partial, or Internet only access.

Policy Enforcement for Security Group Access

Enforcing policies for SGA in BYOD architecture consist of two main components:

  • Defining tags for the endpoints and the destination servers.
  • Defining and implementing the Security Group ACL or Security Group Firewall (SG-FW) policy.

In this design, the Security Group ACL is implemented either on the Catalyst and Nexus Data Center switching infrastructure or on the ASA Firewall as an SG-FW policy. These two choices are discussed in Chapter 5, “Campus and Branch Network Design for BYOD” as two different deployment scenarios.

Security Group Access Tags

The basic idea of Security Group Access is to associate a device or server’s IP address with a Security Group Tag and then create role-based policies that either permit or deny traffic flows based on these source and destination SGTs. 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 each device accessing the network as a client. As explained in Chapter 5, “Campus and Branch Network Design for BYOD” unique permissions are granted to personal and corporate devices and hence unique tags have been defined for each use case.

Table 15-2 illustrates how tags are assigned to different devices.

 

Table 15-2 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 15-3 illustrates how based on their role, servers are assigned with a different tag.

 

Table 15-3 Destination Tags

Destination Server
Tag

Open Access

SGT 40

Corporate Server

SGT 50

Security Group ACL

After defining the source tags and destination tags, the next logical step is to define the egress policy matrix that defines the enforcement policy between a source and destination tag. Table 15-4 illustrates the egress policy matrix.

 

Table 15-4 Egress Policy 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 15-4 , 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 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 defined in ISE and pushed to the Nexus switch whereas 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 tag to endpoints. Centralized Campus with SGT, found later in this chapter, provides information as to the criteria used to determine when an ACL versus an SGT should be returned upon successful authorization based on the network device type of the wireless controller defined in ISE.

For the destination tags assigned to servers, the configuration is done manually at the data center switch, and the actual enforcement happens based on the deployment scenario. To obtain more information on how to configure tags for servers and on the ASA, refer to Chapter12, “Security Group Access for BYOD”

Personal Wireless Devices—Full Access

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

  • The employee has completed the on-boarding process through the Guest Registration portal.
  • 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.
  • The user is a member of the BYOD_Full_Access Active Directory group.

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 15-15 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.

Figure 15-15 Full Access Enforcement

 

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

Figure 15-16 Authorization Policies for Full Access

 

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

  • 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 user belongs to a specific Active Directory group (defined as a simple condition).
  • The RADIUS authentication originated from a wireless controller which was a member of one of the following device groups—SGT_Converged_Controller, Campus_Controller, SGT_Controller, Branch_Controller, or Converged_Access (defined as a simple condition).

NoteA 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. 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 15-5 shows the conditions used in the authorization rules:

 

Table 15-5 Simple and Compound Conditions

Wireless EAP-TLS (Compound)

Wireless_EAP-TLS (See Figure 15-18)

Radius:Service-Type Equals Framed AND

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

Network Access:EapAuthentication Equals EAP-TLS

Check for Valid Certificate (Simple)

Valid_Certificate (See Figure 15-19)

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

Active Directory Group (Simple)

AD_ Full_Access

AD_ Partial_Access

AD_Domain_users

AD1:ExternalGroups EQUALS sdulab.com/Users/BYOD_Full_Access

AD1:ExternalGroups EQUALS sdulab.com/Users/BYOD_Partial_Access

AD1:ExternalGroups EQUALS sdulab.com/Users/Domain User

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 15-17 shows how much longer and harder to read a rule can be when simple/compound conditions are not implemented.

Figure 15-17 Authorization Rule without Conditions

 

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

Figure 15-18 Wireless_EAP-TLS Condition

 

Figure 15-19 shows the Valid_Certificate simple condition.

Figure 15-19 Valid_Certificate Condition

 

Figure 15-20 shows the AD_Full_Access simple condition.

Figure 15-20 AD_Full_Access Condition

 

The remaining conditions mentioned in Table 5 are defined in a similar way.

Permissions

Permission is a result of an authorization policy match, and the permission can be of different types such as an authorization profile, or a standard result. Table 15-6 explains the permissions used for full access.

 

Table 15-6 Permissions for Full Access

Permission name
Permission type
Purpose

C_SGT11_Campus_Pers_Full

Standard result

To Assign a SGT for 802.1X wireless devices connecting from a Converged Access SGT enabled controller and allowing full access.

SGT11_Campus_Pers_Full

Standard result

To Assign a SGT for 802.1X wireless devices connecting from an SGT-enabled controller allowing full access.

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.


NoteA Converged Access infrastructure refers to a branch or campus deployment with Catalyst 3850 Series switches and/or CT5760 wireless controllers 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 within this design guide.


Centralized Campus with SGT

As explained in Policy Enforcement for Security Group Access, the personal device with permissions for full access will be assigned an SGT value of 11. Once the personal device obtains the tag value of 11, it can then connect with all the servers in the data center.


NoteCentralized Campus with SGT refers to a Wireless LAN Controller which is part of Centralized Wireless LAN Architecture and is enabled with SGT capability. Centralized Campus with SGT refers to a Wireless LAN Controller which is part of Centralized Wireless LAN Architecture and is enabled with SGT capability.


Figure 15-21 shows how the SGT11_Campus_Pers_Full authorization profile uses SGT 11 for personal devices granted full access.

Figure 15-21 SGT11_Campus_Pers_Full

 

See Policy Enforcement for Security Group Access for details regarding the SGT egress policy matrix which defines the permissions for SGT11 allowing full access for a campus which implements a centralized controller (Local Mode) design with SGTs.

Converged Access Campus with SGT

The authorization result used in this rule is same as the one used in the Centralized Campus with SGT, but the key difference is that it is initiated by a Converged Access Switch in a Campus network. The Conditions that are part of this rule match for Converged Access Switches only.

Centralized Campus with ACLs

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

Figure 15-22 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 which implements FlexConnect dynamically get assigned to VLAN 10, which has been configured to provide full access. Figure 15-23 shows the Branch WiFi Full Access authorization profile.

Figure 15-23 Branch WiFi Full Access

 

Since full access is allowed with this authorization profile, no FlexConnect ACL for access control needs to be associated with VLAN 10 on the access point.

Converged Access Branch or Campus

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

Figure 15-24 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.

Personal Wireless Devices—Partial Access

To provide partial access to personal devices, the Cisco ISE verifies the following:

  • The employee has completed the on-boarding process through the Guest Registration portal.
  • 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.
  • The user is member of the BYOD_Partial_Access Active Directory group.

At a high level, Figure 15-25 shows how different authorization profiles are selected for devices accessing the network from different locations with different wireless designs. Each authorization profile in turn enforces a unique permission using either VLANs, SGTs, dynamic ACLs, FlexConnect ACLs, etc.

Figure 15-25 Partial Access Enforcement

 

To configure the authorization rules in ISE, click Policy > Authorization. Figure 15-26 highlights the authorization policy to grant partial access to personal devices.

Figure 15-26 Authorization Policies for Partial Access

 

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

  • 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 user belongs to a specific Active Directory group (defined as a simple condition).
  • The RADIUS authentication originated from a wireless controller which was a member of one of the following device groups—SGT_Converged_Controller, Campus_Controller, SGT_Controller, Branch_Controller, or Converged_Access (defined as a simple condition).

Simple and Compound Conditions explains the different conditions used in the rules.

Permissions

Permission is a result of an authorization policy match and the permission can be of different types such as an authorization profile or a standard result. Table 15-7 explains the permissions used for partial access.

 

Table 15-7 Permissions Used for Wireless Partial Access

Permission name
Permission type
Purpose

SGT12_Campus_Pers_partial

Standard result

To Assign a SGT for 802.1X wireless devices connecting from an SGT-enabled controller granting partial access to some servers in the data center.

Converged Campus SGT

Standard result

To Assign a SGT for 802.1X wireless devices connecting from a Converged Access SGT enabled controller and allowing partial access.

Campus WiFi Partial Access

Authorization profile

To push a named ACL for 802.1X wireless devices connecting from a centralized campus controller.

Branch WiFi Partial Access

Authorization profile

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

Converged WiFi Partial Access

Authorization profile

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

Centralized Campus with SGT

As explained in Policy Enforcement for Security Group Access, the personal device with permissions for partial access will be assigned an SGT value of 12. Once the personal device obtains the tag value of 12 it can then connect with only those servers with an SGT of 50 in the data center.

Figure 15-27 shows how the SGT12_Campus_Pers_Partial authorization profile is configured to assign SGT 12 to personal devices thus allowing partial access.

Figure 15-27 SGT12_Campus_Pers_Partial

 

See Policy Enforcement for Security Group Access for details regarding the SGT egress policy matrix which defines the permissions for SGT12 allowing full access for a campus which implements a centralized controller (Local Mode) design with SGTs.

Converged Access Campus with SGT

This authorization result used in this rule is same as the one used in the Centralized Campus with SGT, but the key difference is that it is initiated by a Converged Access Switch in a Campus network. The Conditions that are part of this rule matche for Converged Access Switches only.

Centralized Campus with ACLs

For devices connecting from a campus location which implements a centralized (Local Mode) wireless design, the Campus WiFi Partial Access authorization profile relies on the ACL_Partial_Access access list, enforced by the WLC. Figure 15-28 shows the authorization profile.

Figure 15-28 Campus WiFi Partial Access

 

Cisco Wireless LAN Controllers support named ACLs, meaning that the ACL must be previously configured on the controller rather than being downloaded from ISE. Using the RADIUS Airespace-ACL Name attribute-value pair, ISE instructs the WLC to apply the ACL_Partial_Access ACL. Figure 15-29 shows the contents of this ACL, as defined in the CT5508 WLC campus controller.

Figure 15-29 ACL_Partial_Access on Wireless Controller

 

The access-list shown in Figure 15-29 specifies the following access:

  • Allow IP access to and from the DNS server (10.230.1.45).
  • Allow IP access to and from the ISE Server (10.225.49.15).
  • Allow IP access to and from the DHCP server (10.230.1.61) .
  • Allow IP access to and from the MDM Server (203.0.113.10).
  • Allow IP access to and from specific subnet (10.230.4.0 /24).
  • Deny IP access to and from data center subnets (10.230.0.0 /16).
  • Deny IP access to and from campus subnets (10.225.0.0 /16).
  • Allow access to and from all other subnets (Internet access).

NoteNote that Access Control Entries (ACEs) for the MDM server are included within the ACLs in this chapter. These are not used for the Enhanced Access use case discussed within this chapter. The Advanced Access use case, discussed in Note that Access Control Entries (ACEs) for the MDM server are included within the ACLs in this chapter. These are not used for the Enhanced Access use case discussed within this chapter. The Advanced Access use case, discussed in “BYOD Advanced Use Case—Mobile Device Manager Integration,” makes use of the same authorization policy rules and authorization profiles.


The access list shown in Figure 15-29 is a generic example used to enforce a hypothetical use case and is not intended to work for every organization. An ACL should be more specific and only allow access to specific IP addresses and protocols in the required direction. A common practice is to make the ACLs as detailed as possible and to define every entry down to the port level.


NoteThe CT5508 WLC supports a maximum of 64 ACLs with a maximum of 64 lines per ACL. The CT5508 WLC supports a maximum of 64 ACLs with a maximum of 64 lines per ACL.


Branches with FlexConnect

For devices connecting from a branch location which implements a FlexConnect wireless design, the Branch WiFi Partial Access authorization profile dynamically assigns the device to VLAN11, which is dedicated for devices obtaining Partial Access. Figure 15-30 shows this authorization profile.

Figure 15-30 Branch WiFi Partial Access

 

Deploying ACLs on the branch is slightly different than using ACLs with a centralized WLC. For branch locations, the Cisco 7500 Flex Wireless Controller relies on FlexConnect ACLs to enforce policy permissions within this design guide. FlexConnect ACLs are created on the WLC and configured with the VLAN defined on the AP or the FlexConnect Group using the VLAN-ACL mapping for dynamic or AAA override VLANs. These FlexConnect ACLs are pushed to the APs when the authorization policy matches. This design guide relies on FlexConnect groups to enforce Flex ACLs for each VLAN. The steps are as follows:

1. Create a FlexConnect ACL for each branch.

2. Apply the FlexConnect ACL on the FlexConnect group for each branch.

3. Define the VLAN-ACL mapping for each VLAN.

On the FlexConnect 7500 Controller, click Security > Access Control Lists > FlexConnect ACLs and define the ACL rules for Partial Access. Figure 15-31 shows the Branch1_ACL_Partial_Access ACL, which allows access to the Internet and some internal resources.


NoteA unique ACL may be needed for each branch since each branch location may have its own local resources and unique IP address space. A unique ACL may be needed for each branch since each branch location may have its own local resources and unique IP address space.


Figure 15-31 Branch1_ACL_Partial_Access

 

The above ACL specifies the following access:

  • Allow IP access to and from the DNS server (10.230.1.45).
  • Allow IP access to and from the ISE Server (10.225.49.15).
  • Allow IP access to and from the DHCP server (10.230.1.61).
  • Allow IP access to and from the MDM Server (203.0.113.10).
  • Allow IP access to and from specific subnet (10.230.4.0 /24). Similar ACL entries could be added to allow access to Branch1 subnets/servers.
  • Deny IP access to and from data center subnets (10.230.0.0 /16).
  • Deny IP access to and from campus subnets (10.225.0.0 /16).
  • Allow access to and from all other subnets (Internet access).

NoteThe access list shown is a generic example used to implement an arbitrary use case and not intended to work for every organization. An ACL should be more specific and only allow access to specific IP addresses and protocols in the required direction. A common practice is to make the ACLs as detailed as possible and to define every entry down to the port level. The access list shown is a generic example used to implement an arbitrary use case and not intended to work for every organization. An ACL should be more specific and only allow access to specific IP addresses and protocols in the required direction. A common practice is to make the ACLs as detailed as possible and to define every entry down to the port level.


For the purposes of this design guide, a FlexConnect group is defined for each branch, which allows for multiple FlexConnect access points in the branch to share configuration parameters.

On the FlexConnect 7500 controller, click Wireless > FlexConnect Groups and select the FlexConnect group for a particular branch location, as shown in Figure 15-32.

Figure 15-32 FlexConnect Groups

 

In Figure 15-33, the FlexConnect group for Branch1 is applying the Branch1_ACL_Partial_Access ACL to endpoints connecting to VLAN 11.

Figure 15-33 FlexConnect Group for Branch1

 

Converged Access Branch or Campus

For devices connecting from campus or branch locations which implement a Converged Access design, the Converged WiFi Partial Access authorization profile relies on the ACL_Partial_Access access list, enforced by the Catalyst 3850 Series switch. Figure 15-34 shows the authorization profile.

Figure 15-34 Converged WiFi Partial Access

 

Cisco Catalyst 3850 Series switches (and CT5760 wireless controllers) support both named ACLs and downloadable ACLs. 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 WLC to apply the ACL_Partial_Access ACL. The following configuration example shows the contents of this ACL, as defined in the Catalyst 3850 switch.

!
ip access-list extended ACL_Partial_Access
permit udp any eq bootpc any eq bootps
permit ip any host 10.230.1.45
permit ip any host 10.225.49.15
permit ip any host 203.0.113.10
permit ip any 10.230.4.0 0.0.0.255
permit ip any host 10.230.6.2
permit ip any host 10.225.100.10
deny ip any 10.230.0.0 0.0.255.255
deny ip any 10.225.0.0 0.0.255.255
deny ip any 10.200.0.0 0.0.255.255
permit ip any any
!
 

The access list shown in above similar to the access list shown in Figure 15-29, but configured on a Catalyst switch instead of a wireless controller. Hence the structure of the access list is slightly different. The access list specifies the following access:

  • Allow IP access to and from the DNS server (10.230.1.45).
  • Allow IP access to and from the ISE Server (10.225.49.15).
  • Allow IP access to and from the MDM Server (203.0.113.10).
  • Allow IP access to and from specific servers (10.230.6.2 and 10.225.100.10).
  • Deny IP access to and from data center subnets (10.230.0.0 /16).
  • Deny IP access to and from campus subnets (10.225.0.0 /16).
  • Deny IP access to and from branch subnets (10.200.0.0 /16).
  • Allow access to and from all other subnets (Internet access).

Again, the access list shown in this example is generic and not intended to work for every organization. An ACL should be more specific and only allow access to specific IP addresses and protocols in the required direction. A common practice is to make the ACLs as detailed as possible and to define every entry down to the port level.


NoteThis design guide shows the use of the Radius:Airespace-ACL-Name AV pair for specifying a named ACL on CUWN wireless controller platforms, such as the CT5508 and Flex 7500 wireless controllers. However, it shows the use of the Radius:Filter-Id AV pair for specifying a named ACL on Cisco IOS-based wireless controller platforms, such as the CT5760 wireless controller and Catalyst 3850 Series switch. For wireless devices, this is simply to highlight the fact that the network administrator can utilize the legacy Airespace-ACL-Name AV pair or the RADIUS standard method of the Filter-Id AV pair within the BYOD implementation. It is recommended that the network administrator standardize on one of the two methods to specify a named ACL where possible in actual deployments. This design guide shows the use of the Radius:Airespace-ACL-Name AV pair for specifying a named ACL on CUWN wireless controller platforms, such as the CT5508 and Flex 7500 wireless controllers. However, it shows the use of the Radius:Filter-Id AV pair for specifying a named ACL on Cisco IOS-based wireless controller platforms, such as the CT5760 wireless controller and Catalyst 3850 Series switch. For wireless devices, this is simply to highlight the fact that the network administrator can utilize the legacy Airespace-ACL-Name AV pair or the RADIUS standard method of the Filter-Id AV pair within the BYOD implementation. It is recommended that the network administrator standardize on one of the two methods to specify a named ACL where possible in actual deployments.


Since a single ISE policy rule is defined for partial access of personal wireless devices from either a branch or campus with a converged access infrastructure, the access list can be customized to the specific branch or campus location as needed. The specific example ACL shown above is consistent with the ACL discussed in the campus centralized (Local Mode) controller design previously discussed.

Personal Wireless Devices—Internet Only Access

To provide Internet Only access to personal devices, the Cisco ISE verifies the following:

  • The employee has completed the on-boarding process through the Guest Registration portal.
  • 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.
  • The user is a member of the Domain Users Active Directory group.

At a high level, Figure 15-35 shows how different authorization profiles are selected for devices coming from different locations with different wireless designs. Each authorization profile in turn enforces a unique permission using VLANs, SGTs, named ACLs, FlexConnect ACLs, etc.

Figure 15-35 Internet Only Enforcement

 

To configure the authorization rules in ISE, click Policy > Authorization. Figure 15-36 highlights the authorization policy to grant Internet Only access to personal devices.

Figure 15-36 Authorization Policies for Internet Only Access

 

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

  • 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 user belongs to the Domain Users Active Directory group (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).

Simple and Compound Conditions explains the different conditions used in the rules.

Permissions

When all conditions in the authorization policy rules match, the rule invokes the proper permission. In the previous sections the permission result was either an authorization profile (non-SGT based access), or a standard result for SGT based access. However, in this section only the authorization profile will be used for the reasons explained below.

  • Campus WiFi Internet Only for 802.1X wireless devices connecting from a SGT_enabled controller or from a campus location with a centralized (Local Mode) wireless design. Both the campus controller and the SGT_enabled controller use the same authorization profiles. SGTs are not used to tag Internet only traffic since SGT relies on source and destination tags and the destination tag for the Internet is unknown.
  • Branch Wireless Internet Only for 802.1X wireless devices connecting from a branch location which implements a Flexconnect wireless design.
  • Converged WiFi Internet Only for 802.1X wireless devices connecting from either a campus or branch location which implements a Converged Access infrastructure design.

Centralized Campus with SGT or ACLs

For devices connecting from a campus location which implements a centralized (Local Mode) wireless design or from a SGT_enabled controller, the Campus WiFi Internet Only authorization profile relies on the ACL_Internet_Only access list enforced by the WLC. Figure 15-37 shows how the authorization profile instructs the WLC to apply the ACL.

Figure 15-37 Campus WiFi Internet Only

 

Cisco Wireless LAN Controllers support named ACLs, meaning the ACL must be previously configured on the controller, rather than being downloaded from ISE. Using the RADIUS Airespace-ACL Name attribute-value pair, ISE instructs the WLC to apply the ACL_Internet_Only ACL.

Figure 15-38 shows the contents of this ACL, as defined in the CT5508 WLC campus controller.

Figure 15-38 ACL_Internet_Only

 

The access list specifies the following access:

  • Allow IP access to and from the DNS server (10.230.1.45).
  • Allow IP access to and from the ISE Server (10.225.49.15).
  • Allow IP access to and from the DHCP server (10.230.1.61).
  • Deny IP access to and from internal network address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
  • Allow access to and from all other subnets (Internet access).

Once again, the access list is generic and not intended to work for every organization. An ACL should be more specific and only allow access to specific IP addresses and protocols in the required direction. A common practice is to make the ACLs as detailed as possible and to define every entry down to the port level.

Branches with FlexConnect

For devices connecting from a branch location which implements a FlexConnect wireless design, the Branch WiFi Internet Only authorization profile dynamically assigns the device to VLAN12, which is dedicated for devices obtaining Internet_Only access.

Figure 15-39 shows this authorization profile.

Figure 15-39 Branch WiFi Internet Only

 

For branch locations which implement FlexConnect wireless designs, the Cisco 7500 Flex Wireless Controller relies on FlexConnect ACLs to enforce policy permissions. FlexConnect ACLs are created on the WLC and configured with the VLAN defined on the AP or the FlexConnect Group using the VLAN-ACL mapping for dynamic or AAA override VLANs. These FlexConnect ACLs are pushed to the APs when the authorization policy matches.

1. Create a FlexConnect ACL for each branch.

2. Apply the FlexConnect ACL on the FlexConnect group for each branch.

3. Define the VLAN-ACL mapping for each VLAN.

On the FlexConnect 7500 Controller, click Security > Access Control Lists > FlexConnect ACLs and define the ACL rules for Internet_Only access. Figure 15-40 shows an example of the Branch_ACL_Internet_Only ACL, which only allows access to the Internet. This ACL is the same for all branches.

Figure 15-40 Branch_ACL_Internet_Only

 

The access list specifies the following access:

  • Allow IP access to and from the DNS server (10.230.1.45).
  • Allow IP access to and from the ISE Server (10.225.49.15).
  • Allow IP access to and from the DHCP server (10.230.1.61).
  • Deny IP access to and from internal network address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
  • Allow access to and from all other subnets (Internet access).

The access list is generic and not intended to work for every organization. An ACL should be more specific and only allow access to specific IP addresses and protocols in the required direction. A common practice is to make the ACLs as detailed as possible and to define every entry down to the port level.

For the purposes of this design guide, a FlexConnect group is defined for each branch, which allows for multiple FlexConnect access points in the branch to share configuration parameters.

On the FlexConnect 7500 controller, click Wireless > FlexConnect Groups and select the FlexConnect group for a particular branch location, as shown in Figure 15-41.

Figure 15-41 FlexConnect Groups

 

In Figure 15-42, the FlexConnect group for Branch1 is applying the Branch_ACL_Internet_Only ACL to endpoints connecting to VLAN 12.

Figure 15-42 FlexConnect Group for Branch1 Internet Only

 

Converged Access Branch or Campus

For devices connecting from campus or branch locations which implement a Converged Access design, the Converged WiFi Internet Only authorization profile relies on the ACL_Internet_Only access list, enforced by the Catalyst 3850 Series switch. Figure 15-43 shows the authorization profile.

Figure 15-43 Converged WiFi Internet Only

 

Cisco Catalyst 3850 Series switches (and CT5760 wireless controllers) support both named ACLs and downloadable ACLs. 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 WLC to apply the ACL_Internet_Only ACL. The following configuration example shows the contents of this ACL, as defined in the Catalyst 3850 switch.

ip access-list extended ACL_Internet_Only
permit udp any eq bootpc any eq bootps
permit ip any host 10.230.1.45
permit ip any host 10.225.49.15
permit ip any host 10.225.100.10
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any
!

The access-list shown in above is similar to the access list shown in Figure 15-38, but configured on a Catalyst switch instead of a wireless controller. Hence the structure of the access-list is slightly different. However the access-list specifies the following access:

  • Allow DHCP access (bootpc and bootps).
  • Allow IP access to and from the DNS server (10.230.1.45).
  • Allow IP access to and from the ISE server (10.225.49.15).
  • Deny IP access to and from the rest of the internal network IP address space (10.0.0.0 /8, 172.16.0.0 /12, 192.168.0.0 /16).
  • Allow access to all other addresses (Internet addresses).

NoteThe MDM above is shown with private RFC1918 address. In practice, the MDM must be reachable from the public Internet and may not require a specific line entry in the ACL. The MDM above is shown with private RFC1918 address. In practice, the MDM must be reachable from the public Internet and may not require a specific line entry in the ACL.


Again, the access list shown in this example is generic and not intended to work for every organization. An ACL should be more specific and only allow access to specific IP addresses and protocols in the required direction. A common practice is to make the ACLs as detailed as possible and to define every entry down to the port level.

Personal Wired Devices—Full Access

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

  • The employee has completed the on-boarding process through the Guest Registration portal.
  • 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.
  • The user is a member of the BYOD_Full_Access Active Directory group.

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 which do not implement Converged Access infrastructures, unique authorization rules are created for connections originating from each design.


NoteFor 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 will be 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 will be referred to simply as “campuses” within this design guide. This is in order to minimize the use of verbose phrases such as “branches which do not implement Converged Access infrastructure” and “campuses which do not implement Converged Access infrastructure”. 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 will be 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 will be referred to simply as “campuses” within this design guide. This is in order to minimize 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 15-44 shows how different authorization profiles are selected for connections originating from different locations with different infrastructure designs. Each authorization profile in turn enforces a unique permission using VLANs, dynamic ACLs (either named or downloadable [DACL]), etc.

Figure 15-44 Full Access Wired Enforcement

 


NoteWired assignment of Security Group Tags (SGTs) is not discussed within this version of the design guide. Hence, there is no wired policy enforcement via SGTs in Wired assignment of Security Group Tags (SGTs) is not discussed within this version of the design guide. Hence, there is no wired policy enforcement via SGTs in Figure 15-44. 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 15-45 shows the details of authorization profile configured in ISE for wired devices.

Figure 15-45 Authorization Policies for Wired Full Access

 

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

  • 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 user belongs to a specific Active Directory group (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 15-8 shows the conditions used in the authorization rules.

 

Table 15-8 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

Active Directory Group (Simple)

AD_ Full_Access

AD_ Partial_Access

AD_Domain_users

AD1:ExternalGroups EQUALS sdulab.com/Users/BYOD_Full_Access

AD1:ExternalGroups EQUALS sdulab.com/Users/BYOD_Partial_Access

AD1:ExternalGroups EQUALS sdulab.com/Users/Domain User

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

Permission

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 15-9 explains the permissions used for the full access for wired users.

 

Table 15-9 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 15-46 shows how the Campus Wired Full Access authorization profile is defined in ISE.

Figure 15-46 Campus Wired Full Access Authorization Profile

 


NoteCisco Catalyst switches support both downloadable ACLs (DACLs) and named ACLs. This design guide shows 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 range of capabilities for access control available on Cisco IOS-based platforms. The same wired policy enforcement for Converged Access and non-Converged Access infrastructure can be achieved if the customer desires, simply by 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. Cisco Catalyst switches support both downloadable ACLs (DACLs) and named ACLs. This design guide shows 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 range of capabilities for access control available on Cisco IOS-based platforms. The same wired policy enforcement for Converged Access and non-Converged Access infrastructure can be achieved if the customer desires, simply by 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. 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. Figure 15-47 shows the dACL definition which must be configured in ISE:

Figure 15-47 dACL Definition in ISE that Grants Full Access to the Users

 


NoteISE 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. 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 15-48 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—in this case the VLAN name—along with the ACL information.

Figure 15-48 Branch Wired Full Access Authorization Profile

 

Once this profile is downloaded to the Catalyst switch, the endpoint gets full access to the network. Figure 15-49 shows an example of the state of the port when this profile is downloaded by using the switch command show authentication session interface Gi0/23.

Figure 15-49 Catalyst Switch Port

 

Converged Access Branch or Campus

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

Figure 15-50 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 converged access switch 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
!

This ACL is used to override the default-ACL configured on the switch port. The default-ACL is used as an additional preventative measure in case ACL_Full_Access is not configured on the switch.

Personal Wired Devices—Partial Access

Partial Access grants access to corporate resources, in addition to Internet access. As mentioned in Personal Wireless Devices—Partial Access, once a device authenticates to ISE, an authorization profile is applied. For wired devices, the authorization profile is applied to the access layer switch.

To provide partial access to personal wired devices, the Cisco ISE verifies the following:

  • The employee has completed the on-boarding process through the Guest Registration portal.
  • 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.
  • The user is a member of the AD_Partial_Access Active Directory group.

At a high level, Figure 15-51 shows how different authorization profiles are selected for devices coming from different locations with different wired infrastructure designs. Each authorization profile in turn enforces a unique permission using VLANs, dynamic ACLs (either named or downloadable [DACL]), etc.

Figure 15-51 Wired Partial Access Enforcement

 

Figure 15-52 shows the details of authorization profile configured in ISE for wired devices.

Figure 15-52 Authorization Policies for Wired Partial Access

 

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

  • 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 user belongs to a specific Active Directory group (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 explains the different conditions used in the rules.

Permissions

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 15-10 explains the permissions used for the partial access for wired users.

 

Table 15-10 Permissions Used for Wired Partial Access

Permission name
Permission type
Purpose

Campus Wired Partial Access

Authorization profile

To push a dACL for 802.1X wired devices connecting from campus location.

Branch Wired Partial Access

Authorization profile

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

Converged Wired Partial 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

For devices connecting from a campus location, the Campus Wired Partial Access authorization uses a DACL named ACL_Partial_Access enforced by the access layer switch, as shown in Figure 15-53.

Figure 15-53 Campus Wired Partial Access

 

The dACL overrides the default-ACL configured on the switch. Figure 15-54 shows an example of this ACL, which is configured within ISE.

Figure 15-54 ACL_Partial_Access within ISE

 

The above ACL specifies the following access:

  • Allow DHCP access (bootpc and bootps).
  • Allow DNS access to the DNS server (10.230.1.45).
  • Allow IP access to and from the ISE Server (10.225.49.15).
  • Allow IP access to and from specific subnet (10.230.4.0 /24).
  • Allow IP access to and from specific servers (10.230.6.2 and 10.225.100.10).
  • Deny IP access to and from internal network address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
  • Allow access to and from all other subnets (Internet access).

Branch Wired

For devices connecting from a branch location, the Branch Wired Partial Access authorization pushes a VLAN assignment along with a downloadable ACL.

Figure 15-55 shows the details of the authorization profile configured in ISE.

Figure 15-55 Branch Wired Partial Access Authorization Profile

 

The DACL allows all IP traffic, so that the traffic initiated by the host reaches the branch router where the router-ACL is applied.

See VLAN Design at Branch Locations in Chapter 11, “BYOD Wired Infrastructure Design” for details regarding how this assignment of VLAN 14 is given full access for a branch which does not implement a Converged Access infrastructure.

Converged Access Branch and Campus

Figure 15-56 shows how the Converge Wired Partial Access authorization profile is defined in ISE.

Figure 15-56 Converged Wired Partial Access Authorization Profile

 

For the Converged Access design a named ACL is implemented. Using the RADIUS Filter-ID attribute-value pair, ISE instructs the converged access switch to apply the ACL_Partial_Access ACL. This is the same ACL discussed for converged access infrastructure in Personal Wireless Devices—Partial Access. For wired devices, the ACL is used to override the default-ACL configured on the switch port. The default-ACL is used as an additional preventative measure in case ACL_Partial_Access is not configured on the switch.

Personal Wired Devices—Internet Only Access

To provide Internet Only access to personal devices, the Cisco ISE verifies the following:

  • The employee has completed the on-boarding process through the Guest Registration portal.
  • 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.
  • The user is a member of the Domain Users Active Directory group.

At a high level, Figure 15-57 shows how different authorization profiles are selected for devices coming from different locations with different wired infrastructure designs. Each authorization profile in turn enforces a unique permission using VLANs, dynamic ACLs (either named or downloadable [DACL]), etc.

Figure 15-57 Wired Internet Only Access Enforcement

 

Figure 15-58 highlights the authorization policy to grant Internet Only access to personal wired devices.

Figure 15-58 Authorization Policies for Wired Internet Only Access

 

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

  • 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 user belongs to a specific Active Directory group (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 explains the different conditions used in the rules.

Permissions

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 15-11 explains the permissions used for Internet access.

 

Table 15-11 Permissions Used for Wired Internet Access

Permission name
Permission type
Purpose

Campus Wired Internet Only

Authorization profile

To push a dACL for 802.1X wired devices connecting from a campus location.

Branch Wired Internet Only

Authorization profile

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

Converged Wired Internet Only

Authorization profile

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

Wired Campus

For devices connecting from a campus location, the Campus Wired Internet Only authorization profile uses the DACL named ACL_Internet_Only, which is pushed to the access layer switch port. Figure 15-59 shows the Authorization profile.

Figure 15-59 Campus Wired Internet Only Authorization Profile

 

The DACL overrides the default-ACL configured on the switch. Figure 15-60 shows an example of this ACL, which is configured within ISE.

Figure 15-60 ACL_Internet_Only DACL

 

The access list specifies the following access:

  • Allow DHCP access (bootpc and bootps).
  • Allow DNS access to the DNS server (10.230.1.45).
  • Allow IP access to and from the ISE Server (10.225.49.15).
  • Deny IP access to and from internal network address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
  • Allow access to and from all other subnets (Internet access).

This access list is generic and not intended to work for every organization. An ACL should be more specific and only allow access to specific IP addresses and protocols in the required direction. A common practice is to make the ACLs as detailed as possible and to define every entry down to the port level.

Branch Wired

For devices connecting from a branch location, the Branch Wired Internet Only authorization pushes a VLAN assignment along with a downloadable ACL. Figure 15-61 illustrates the Branch Wired Internet_Only authorization profile, used to grant Internet_Only access to personal devices connecting from the branch.

Figure 15-61 Branch Wired Internet Only Authorization Profile

 

The ACL_Full_Access DACL is pushed to the access-layer switch to override the default-ACL on the port and allow all IP traffic to flow up to the branch router.

See VLAN Design at Branch Locations in Chapter 11, “BYOD Wired Infrastructure Design” for details regarding how this assignment of VLAN 15 is given full access for a branch which does not implement a Converged Access infrastructure.

Converged Access Branch and Campus

Figure 15-62 shows how the Converge Wired Internet Only authorization profile is defined in ISE.

Figure 15-62 Converged Wired Internet Only Authorization Profile

 

For the Converged Access design a named ACL is implemented. Using the RADIUS Filter-ID attribute-value pair, ISE instructs the converged access switch to apply the ACL_Internet_Only ACL. This is the same ACL discussed for converged access infrastructure in Personal Wireless Devices—Internet Only Access. For wired devices, the ACL is used to override the default-ACL configured on the switch port. The default-ACL is used as an additional preventative measure in case ACL_Internet_Only is not configured on the switch.

Android Devices—Deny Access

Rather than allowing differentiated access to the network which was depicted in the previous use cases, this use case discusses on how to deny access permission for some BYOD devices from connecting to the network. For example, some organizations may decide to have a more restrictive BYOD environment and grant access only to a specific type of device (e.g., Android, Apple iOS, etc.).

This example focuses on denying access to Android devices, relying on the profiling capabilities of ISE.

To deny access to Android devices, the Cisco ISE verifies the following:

  • The employee attempts to connect to the network.
  • The ISE profiler identifies the device type.
  • If the device type is Android, deny access.

To configure the authorization rules in ISE, click Policy > Authorization. Figure 15-63 highlights the authorization policy to deny access to Android devices.

Figure 15-63 Deny Android Devices

 

The DenyAccess authorization profile is used to enforce the permissions and deny access to Android devices. The DenyAccess profile is a standard ISE profile and cannot be edited. This reserved profile cannot be edited but may be found under Policy > Results> Authorization Profiles.

Figure 15-64 shows an entry from ISE’s log, highlighting the fact that the device has been profiled as an Android device and the DenyAccess authorization rule has been enforced.

Figure 15-64 DenyAccess

 

ISE Authorization Policy

For reference purposes, the complete authorization policy used during validation is shown in Figure 15-65. The figure highlights the following sections:

1. Used for blacklisting lost or stolen devices.

2. On-boarding and MDM registration/remediation (required for the advanced use case).

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 15-65 Complete Authorization Policy