CCNP Security SISAS 300-208 Official Cert Guide (2015)

---

1. True or False? To allow endpoints without configured supplicants to connect to a network where IEEE 802.1X has been enabled, the administrator must disable 802.1X on the endpoints’ switch port.

a. True

b. False

2. Which of the following is true?

a. With nonauthenticating endpoints, the authenticator takes over the EAP communication instead of the endpoint.

b. With nonauthenticating endpoints, the authenticator can be configured to send the MAC address of the endpoint to the authentication server in a RADIUS Access-Request message.

c. The endpoint’s supplicant uses RADIUS to communicate the endpoint’s MAC address to the authentication server.

d. The authenticator can use TACACS+ to send the endpoint’s MAC address to the authentication server.

3. Which of following is an accurate statement when using MAC authentication bypass (MAB)?

a. An administrator is limited in the types of authorization results that can be sent and is restricted to a simple Permit-All or Deny-All result.

b. An administrator can assign all authorization results, except for VLAN assignment.

c. An administrator can assign all authorization results, except for security group tags (SGTs).

d. An administrator is not limited in the types of authorization results that can be sent, which can include dACL, VLAN Assignment, SGT, and others.

4. True or False? With centralized web authentication (CWA), ISE sends the username and password to the authenticator.

a. True

b. False

5. Which of following accurately describes local web authentication (LWA)?

a. With LWA, the authenticator redirects the end user’s web traffic to a centralized portal hosted on the authentication server, which is then returned to the local device (authenticator).

b. With LWA, the authenticator hosts a local web portal, which is coded to send an HTTP POST to the authentication server containing the credentials of the end user. The authentication server returns an HTTP POST with the Access-Accept or Access-Reject.

c. With LWA, the authenticator receives the credentials from the end user through a locally hosted web portal, and it is the authenticator that sends the credentials to the authentication server through a RADIUS Access-Request.

d. With LWA, the authenticator receives the credentials from the end user through a locally hosted web portal, and the authenticator sends the credentials to the authentication server through a TACACS+ Access-Request.

6. Which of the following lists are non-802.1X authentications?

a. WebAuth, MAB, RA VPN

b. Remote Access, WebAuth, EAP-MSChapV2

c. PAP, LWA, RA VPN

d. WebAuth, EAP-GTC, HTTP POST

7. True or False? Cisco recommends changing the VLAN for a guest user after that visitor has authenticated through Web Authentication to put that guest user into an isolated “guest network.”

a. True

b. False

8. Which non-802.1X authentication method uses specialized authorization results to connect a user’s credentials to a MAB session?

a. Remote access

b. Local web authentication with a centralized portal

c. Centralized web authentication (CWA)

d. Local web authentication

9. What is one of the main reasons that MAB is used in modern-day networks?

a. Most endpoints, such as printers and IP phones, do not have supplicants and therefore cannot use 802.1X.

b. The endpoints can have a supplicant, but the enablement and configuration of that supplicant could be overcomplicated or operationally difficult for the company. Therefore, the company opts to use MAB instead.

c. The endpoints mostly do have supplicants, but those are not compatible with Cisco networks.

d. MAB is equally as secure as 802.1X and therefore is chosen often to save the company the operational difficulties of configuring the supplicants on such disparate endpoints.

10. True or False? Web authentication can be used for guest users as well as internal employees.

a. True

b. False

Foundation Topics

Devices Without a Supplicant

As described in Chapter 4 and the introduction to this chapter, the IEEE standardized 802.1X for a port-based network access control solution. The original predictions for how quickly 802.1X would catch on and be universally deployed were greatly exaggerated. More than a decade later, we are now seeing 802.1X truly take hold and become the de-facto solution deployed everywhere on both wired and wired networks.

With 802.1X, a supplicant and an authenticator exchange EAP messages, and if the endpoint connected to the authenticator (switch) does not have a supplicant, the EAP identity request messages go unanswered. This results in an authentication timeout, and with the original concept of identity networking and 802.1X, the endpoint is denied access to the company network. In other words, only devices that can authenticate and have authenticated to the network are allowed on the network.

In practice, the belief that all ports would be authenticating with 802.1X or no access would be granted did not happen for a myriad of reasons. When designing a secure network access solution, there is a tendency to consider only the managed desktops, laptops, and now tablet devices when thinking about network authentication. However, organizations tend to possess a plethora of devices beyond those. Think about the printers, IP cameras, IP phones, thin-client terminals, building automation, and other “headless” devices that exist in a modern network.

Take Cisco IP phones, for example. These are devices that do have a supplicant, which can be configured individually at the keypad and does not scale very well (imagine having to configure a supplicant on every phone in an organization with hundreds of thousands of phones). Cisco IP phone supplicants can also be configured centrally from the Call Control Server (formerly named the Cisco Call Manager). What about the other devices? Do they also have a central management platform capable of configuring each supplicant across large numbers of devices deployed at scale?

One of the original “solutions” to deal with these nonauthenticating devices was to not configure 802.1X on the individual switch ports where the nonauthenticating endpoint would be plugged into the network. Take a moment and think about that for a minute or two—it would enable anyone to simply unplug the nonauthenticating endpoint and plug his laptop into the port. Voila! The device would have full network access without any challenge whatsoever.

What about when a device (such as a printer) needs to be moved? That might require the network team to be involved for the move and enable 802.1X on the old switch port while disabling 802.1X on the new switch port, which poses significant management burden on the IT department. It’s just is not a sustainable business model.

Next, what happens when an employee who should have network access has a misconfigured supplicant or an expired credential or is using a temporary device? What about guest users who only need access to the Internet?

A series of bandages needed to be created to deal with all these variations and to deal with them in a sustainable way (where possible).

MAC Authentication Bypass

The first bandage to help with non-authenticating policies is for the authenticator to act on behalf of the endpoint that does not have a supplicant. In this scenario, the authenticator crafts a RADIUS Access-Request message and sends it to the authentication server. The authenticator uses the endpoint’s MAC address as the identity.

The authentication server (the RADIUS server) performs an authentication lookup using that MAC address as the credential. If that MAC address is in a list to be given access to the network, a RADIUS Access-Accept message is sent back from the authentication server to the authenticator. This process is known as a MAC Authentication Bypass (MAB).

Figure 5-1 illustrates the process of MAB.

Figure 5-1 MAB.

Examining Figure 5-1, there is a nonauthenticating endpoint (a printer) with a MAC address of 00.00.0c.ab.cd.ef. There is also a switch, which is the authenticator, and an ISE server acting as the authentication server. Let’s take a look at the steps that occurred:

Step 1. Because the printer does not have a supplicant, the authenticator crafted a RADIUS Access-Request message using the printer’s MAC address as the identity.

Step 2. The authentication server (ISE) receives the RADIUS Access-Request and performs an identity lookup, which determines whether it is a known MAC address.

Step 3. The authentication server (ISE) determines whether the device should be granted access to the network, and if so, what level of access to provide.

Step 4. The authentication server (ISE) sends the RADIUS response (Access-Accept) to the authenticator, allowing the printer to access the network.

It is also important to note that although 802.1X is a standard, MAB is not. MAB is something that each vendor could implement differently if they so choose, just as long as the RADIUS communication complies with the standard for RADIUS.

How does a switch (authenticator) know when the endpoint that is plugged into it does not have a supplicant? Following the 802.1X standard, the method is simply a timeout. The authenticator is meant to send EAP over LAN identity request frames every 30 seconds by default. After 3 timeouts—a period of 90 seconds by default—it is accepted that the endpoint must not have a supplicant. As with most Cisco switch features, timers are adjustable. Figure 5-2 shows the timeouts occurring 3 times before MAB begins.

Figure 5-2 EAP Timeout for MAB.

Keep in mind that MAB is inherently not a secure technology. When implementing MAB, you are bypassing the stronger security of 802.1X by allowing specific MAC addresses to gain access without authentication. MAC addresses are easily spoofed, meaning it is easy to configure an endpoint to use a MAC address other than the one burned into the hardware. When using MAB, always follow a defense-in-depth approach. This means when authorizing a MAB’d device for network access, the endpoint should be granted access only to the networks and services that device is required to speak to.

In other words, don’t provide full access to devices that have been MAB’d; instead provide them with an authorization that is more limited. Because MAB is a standard RADIUS authentication and the authorization decision is being sent from the authentication server (ISE), there really are no limitations to the type of authorization results that can be sent to the authenticator.

Some examples include, but are not limited to, the following:

Downloadable ACLs (dACLs)

Dynamic VLAN assignment (dVLAN)

URL redirection

Security group tag (SGT)

Smart port macros

Keep in mind that if an endpoint does not have a supplicant, it is not recommended to ever change its VLAN. When changing a VLAN assigned to an endpoint, that endpoint must know (somehow) to renew the DHCP request. The best solution is to not use VLAN changes on open networks because there is nothing on the client to detect the VLAN change and trigger the DHCP renewal. When the network uses 802.1X, a supplicant exists on the client to do the VLAN change detection (is gateway reachable, and so on) and trigger the DHCP renewal.

If you still choose to change the VLAN on open networks, then you have only a few choices (none are considered a best practice). You can set the DHCP lease time to something very low, so it will renew the address frequently. You also can use an ActiveX or Java Applet on the portal that will do the VLAN change detection in lieu of a supplicant.

The topics of defense-in-depth, authorization results, and applying the correct level of access to the correct device types are covered in much more detail in Chapter 11, “Authorization Policies.”

Web Authentication

Just because there is no configured supplicant on an endpoint does not mean that the user of that endpoint does not need to authenticate. Consider the use cases of guests or visitors, or maybe just a misconfiguration or expired credential for the end user. Based on who the user is, she still can require network access and be granted access to the network.

Enter web authentication, commonly referred to as just WebAuth. An authenticator would be able to send a user to a locally hosted web page—in other words a web page hosted on the local device itself, such as the switch, the wireless controller, or even the firewall or VPN concentrator. It is a simple thing, really; it’s just a very basic web page where a user can submit her username and password.

The username and password that are submitted to the web portal are then sent from the authenticator to the authentication server in a standard RADIUS Access-Request packet. So, in a similar fashion to what occurs with MAB, the switch is sending the request for the endpoint because the endpoint is not authenticating to the switch. Figure 5-3 illustrates the WebAuth concept.

Figure 5-3 Web authentication.

The credential that gets submitted through the WebAuth page could be Active Directory (AD) credentials of an employee. The credentials also could be guest credentials for someone who is only temporarily allowed to have Internet acces, and no other access. The use of WebAuth is really not limited to one type or another.

Keep in mind that WebAuth is an effective authentication method only for a device that is interactive. In other words, it would not make sense to try to use WebAuth for a printer. There is no user to interactively enter his credentials and click Submit.

As with MAB, WebAuth is not a standard. There are multiple ways to perform WebAuth, with benefits and downsides to each one.

Local Web Authentication

Local web authentication (LWA) is the original WebAuth. As described in the preceding paragraphs, the authenticator will redirect web traffic (HTTP and/or HTTPS) to a locally hosted web portal where a user can enter her username and password.

The credentials are submitted through the web portal, and the authenticator (switch, wireless controller, and so on) sends the RADIUS Access-Request to the authentication server, using the username and password from the form. It is key to remember that any time the switch is sending the credentials for the user, it is considered LWA.

Storing the web authentication portal on the local authenticator can often limit the customization capabilities of the web pages themselves. On a Cisco switch, the pages are virtually not customizable at all. Some organizations not only prefer, but require, that the web portals be customized to match the corporate branding. For those companies, traditional LWA is not usually an acceptable solution, at least not for wired WebAuth.

Additionally, when using LWA with Cisco switches, there is no native support for advanced services such as Acceptable Use Policy acceptance pages, client provisioning, password changing capabilities, self registration, or device registration. For those advanced capabilities, a company needs to consider using centralized web authentication.

Cisco switches as well as a variety of other 802.1X-compliant switches have a configuration option that assigns a special VLAN to endpoints when the authentication timer expires, meaning they don’t have a supplicant. This is known as the Guest VLAN. It is an option that was available before the more powerful policy servers—such as Cisco ISE—existed. Many production deployments of 802.1X today still use this Guest VLAN to provide wired guests access to the Internet. However, it is important to note that once the switch makes a local decision, such as assigning the Guest VLAN, LWA is no longer an option.

In addition to LWA and Guest VLAN being mutually exclusive, there are some other interesting bits of information about LWA. LWA does not support VLAN assignment, so you are basically limited to ACL assignment. LWA is also restricted from change of authorization (COA) support; therefore, access policy cannot be changed based on posture or profiling state, or even an administrative change as a result of malware or other need to quarantine the endpoint.

Local Web Authentication with a Centralized Portal

Many modern authenticators provide an option to redirect the LWA to a centralized web portal. Utilizing a centralized portal enables the organization to customize the portal with corporate branding and provide the right look and feel for their organization.

With Cisco switches, the locally stored web pages can contain the redirection string that sends the users’ web traffic to the centrally hosted portal. That hosted portal is configured to send the credentials entered into it to the source NAD through an HTTP POST method, or returned to the NAD through a hidden i-frame.

Figure 5-4 illustrates the process of the user entering his credentials into the centrally located portal (in this case it’s hosted on ISE), and Figure 5-5 shows the HTML POST occurring from the browser to the network device (authenticator).

Figure 5-4 Centrally hosted portal for LWA.

Figure 5-5 HTTP POST occurs from browser to authenticator.

The POST method and the i-frame method both have pros and cons. The i-frame method does not work with newer browsers such as Internet Explorer 9 and newer. The POST method does not work with some mobile browsers, and it is very unsecure because the user’s credentials are passed from the central portal through the network, destined to the authenticator. The web portal needs to have the intelligence to determine which methods to use with each browser type by examining the user-agent string from the browser.

The Cisco Wireless LAN Controller (WLC) version 7.0 required the use of either POST or i-frame method, to support LWA with a centralized portal on ISE. Traditional LWA would always still be available.

Even though the portal is centralized, the same restrictions associated with traditional LWA are still in effect. CoA will not function, nor will client provisioning and other advanced functionality.

Centralized Web Authentication

Centralized web authentication (CWA) is what Cisco ISE uses throughout the Secure Access solution. Although Cisco ISE is still capable of supporting LWA methods, those methods are typically reserved for non-Cisco network devices.

Just like LWA, CWA is only for interactive users that have a web browser, where the user will manually enter the username and password, and just as before, the WebAuth and Guest VLAN functions remain mutually exclusive.

CoA works fully with CWA, which leads to the support for all the authorization results, such as ACL and VLAN authorization. Any time you change VLANs on an endpoint, the endpoint must be able to detect the VLAN change and trigger an IP address renewal. With 802.1X, the supplicant takes care of the VLAN change detection and address renewal. However, when using CWA there normally is no supplicant on the endpoint. Therefore, the portal must use an ActiveX or Java applet to handle the renewal of the IP address after the VLAN assignment.

CWA also supports all the advanced services, such as client provisioning, posture assessments, acceptable use policies (AUPs), password changing, self registration, and device registration

Now that you’ve read all the things it can do, you must be wondering how it works and what makes it different from the other WebAuth options. The authenticator only sees a MAB, and the rest is handled on the authentication server (ISE). Figure 5-6 shows the MAB occurring with a redirection to the centralized portal, and Figure 5-7 illustrates that the switch still sees only a MAB request while ISE is maintaining the user authentication.

Figure 5-6 URL-redirected MAB.

Figure 5-7 The credentials are never sent to authenticator.

The following steps detail what is occurring in Figures 5-6 and 5-7:

Step 1. The endpoint entering the network does not have a configured supplicant.

Step 2. The authenticator performs a MAB, sending the RADIUS Access-Request to Cisco ISE (the authentication server).

Step 3. The authentication server (ISE) sends the RADIUS result, including a URL-redirection, to the centralized portal on the ISE server itself.

Step 4. The end user enters his credentials into the centralized portal. Unlike the LWA options, the credentials are never sent to the switch; they are stored within the ISE session directory and tied together with the MAB coming from the switch.

Step 5. ISE sends a reauthentication change of authorization (CoA-reauth) to the switch. This causes the switch to send a new MAB request with the same SessionID to ISE, which is processed.

Step 6. ISE sends the final authorization result to the switch for the end user.

CWA is covered in more detail in Chapter 13, “Web Authentication,” where the configuration of CWA and the policies involved are examined in depth.

Remote Access Connections

So far this chapter has been focused on wired and wireless connections where the endpoint was not using 802.1X. However, there is a third network access use case that is one of the “holy trinity.” That trinity is made up of wired, wireless, and remote access. More commonly nowadays, it’s referred to as wired, wireless, and VPN.

When connecting an endpoint to a corporate network from another location, it is known as remote access (RA). This used to be handled mainly by dial-up networking and in fact is where RADIUS got its name. RADIUS stands for remote access dial up service. In today’s world, using a virtual private network (VPN) to join the endpoint to the company’s network through a public Internet is much more common.

With this type of connection, the VPN concentrator (usually a Cisco ASA) is the authenticator and ISE is still the authentication server. The remote client forms a secure tunnel between the VPN software (usually AnyConnect) and the VPN headend (usually a Cisco ASA). The tunnel can be formed using IPSec or SSL, and the user’s credentials are passed inside that secure tunnel.

The VPN head sends the RADIUS Access-Request to ISE, which directs the identity lookup to the appropriate identity store, most often a one-time password (OTP) server. The user’s credentials with remote access VPN using the ASA will be sent through either PAP or MSCHAPv2 from the ASA to ISE.