802.1X

- [Instructor] Before we look at configuring 802.1x, let's take an overview of what this is and how this works. 802.1x is a standard for network access control predominantly used in wireless networks. Although that is also used with wired networks. This essentially ensures that the network is disconnected until authentication is completed. Depending on the results of the authentication, the user will be either granted or denied access to the network. When we're using 802.1x, there are three roles involved. We have the supplicant, the authenticator and the authentication server. The supplicant is our end point. The good news is that Windows and Mac OS now both have native supplicant software installed. That's also offered by the Cisco AnyConnect software as well. The supplicant software will communicate identity credentials through EAP over LAN, providing those to the authenticator. The authenticator is the piece that controls access to the network based on the authentication status of the endpoint. Commonly, this is either a typical switch or a wireless LAN controller. This device receives EAP encapsulated packets from the supplicant and re-encounter insulates those into radius packets. Those radius packets are then forwarded to the final piece, which is the authentication server. You've probably already guessed that the authentication server is a radius server. Tech X-Plus is not supported for use with 802.1x. So this would need to be a server providing radius services. The authentication server receives the information from the authenticator and validates the identity information that was sent originally by the supplicant. The server will then respond with either a radius accept or radius deny message, which would be sent back to the authenticator. There are numerous EAP types or EAP methods. The most commonly used methods are based on Transport Layer Security or TLS. When we're choosing an EAP type, we want to consider our network security requirements. In other words, which EAP type is going to best meet our security goals for the network. And also, which EAP type is supported by the authentication server we're using and our end points. We have inner authentication methods and tunneled or outer authentication methods. Inter methods are tunneled within the tunneled outer methods. Tunnel methods use an outer TLS tunnel between the supplicant and the authentication server. This is very similar to the way an HTTPS session is established between a secure website and a local web browser. Let's take a look at few of the most common EAP authentication methods. There are many, many options out there, but these are a few of the most common. EAP MD5 uses the MD5 algorithm to hash supplicant credentials. The limitation of EAP MD5 is that this is a one-way authentication. So the authentication server would validate the supplicants but the supplicant does not validate the authentication server as a valid authority. So there is an opportunity for an attacker to impersonate a valid server and to begin communicating with an endpoint using this method. EAP-TLS does provide mutual authentication between the client and the server. With this method, the supplicant and the server are both assigned a digital certificate that is signed by a certificate authority or a CA. This is the most secure method but it's also the most cumbersome to deploy because it requires a certificate to be signed and installed on each client. PEAP or protected EAP only requires the authentication server to have a certificate. This method creates a TLS tunnel between the supplicant and the server. Since no client certificate is required, this is less of an administrative burden. With protected EAP, a tunnel is established using TLS as the outer method and then an inner method is used to pass credentials through the outer TLS tunnel. One of the inner methods used by PEAP can be EAP MSCHAP version two. This is used for communication within an MSCHAP version two session and it is the most common inner method that we see used. This uses a symbol, username and password to communicate with a radius server, which can authenticate using Microsoft active directory information. EAP-GTC is another inner method, which is the Cisco alternative to MSCHAP version two. This allows for more generic authentications using E directory, LDAP, token servers and more. And EAP-TLS as the inner method is another option. So this would essentially be a TLS tunnel running within an outer TLS tunnel which would obviously be the most secure option. This is fairly rare to see due to all of these certificate requirements on both the supplicants and the server. So it's pretty complex to configure and to manage. The outer method is called EAP-FAST. This is similar to PEAP but this is Cisco's own alternative to provide faster reauthentications and wireless roaming. This also forms a TLS outer tunnel just as PEAP does, but the difference is PEAP's fast ability to reauthenticate using what are called Protected Access Credentials or PACs. These can be thought of as similar to a secure cookie. This is locally stored on the client as proof of authentication. And the last one we'll mention EAP-TTLS. This is functionally similar to PEAP but it's much less widely supported. If you remember those inner EAP methods that we just looked at with PEAP, EAP-TTLs supports inner authentication methods other than EAP. This would include things like PAP, CHAP and MS-CHAP. So that's an overview of how we use 802.1x as a method of network access control, including some of the most popular types of EAP in use today. Let's jump into Cisco ISE and take a look at this from the perspective of that appliance. From the perspective of configuration within Cisco ISE, we can go to the main policy menu at the top and under the policy elements section, we can choose results. Here, we're going to see our default authentication policy. And if we click on that, you'll see that several protocols for authentication are already enabled here, including PAP, which is Password Authentication Protocol, PEAP and EAP-TLS. Now, let's go to our main policy tab at the top once again and let's choose policy sets. From here, you can see that we have an option. If we scroll to the right, we have an arrow that will let us view these. So let's click that and let's take a look at our default policy sets. If we expand our authentication policy section that we see here at the top, you'll see that we currently have three authentication policies in place. One of those options happens to be .1x. So let's go and expand the options for that, that we see here. And you'll see that once we expand that, we have some options that are already in place. We are set to reject if auth fails. Also notice, we're configured to use the all user ID stores. This means we're going to examine our internal user list configured within Cisco ISE, if those exist. We're going to look at any guest users in ISE, and we're going to look at any instance where we have joined an active directory domain. So if you're using active directory, it's probably a good idea to change that to only authenticate with that active directory instance specifically here. If we scroll back to the top, you'll see that under the allowed protocols section, this is set to default network access which is of course, our default policy that we looked at prior to this section. So this ensures that we have things like PEAP or EAP-TLS enabled. So we do currently have an 802.1x policy in place. Remember that we have three pieces with 802.1x. We have a supplicant, which will be the client's attempting to authenticate. We have an authenticator, which is the device the supplicant is trying to connect to such as a switch. And we have an authentication server, which is our Cisco ISE in this instance. Let's go under the main administration tab that we see here at the top and under the network resources section, let's choose a network devices. If we click on one of our switches that we see here, for example, we see a switch listed here, let's go ahead and click on that. And once we do, if we scroll down, you'll see that this switch already has some radius authentication settings in place. So this switch has been added in Cisco ISE as a radius device. Now we would, of course, also want to configure our switch for radius authentication and point that to the IP address of this Cisco ISE server using the same share key that we have in place here. If we go to our context of visibility menu that we have at the top, let's choose the user section. And from here, we would have the ability to click on a username. Let's click on this username and let's look at these devices. We can see that they have a endpoint MAC address listed here. So if we click on that, and let's go to the attributes tab that we see and we can scroll down to see some other attributes about this. You can see that at the moment, this is using ISE as our triple a server. Further down that list, we should see the authentication status. We do see that here, we're told that authentication has passed. You can also see the authentication method used was MSCHAP version two. So this was one of the allowed protocols in our policy. Now we can of course verify this from our actual switch as well if we want to see all of the successful associations, we could run a command show .1x all summary, and that would display a list of every authenticated supplicant for that particular switch. We can also see live radius logs from Cisco ISE. If we go under the operations menu at the top, you'll see a section for radius and we can choose live logs. This is going to show us real time information about authentication or our identities. So that's a look at 802.1x. What that means and the different methods we can use. And also we'll look at how we would configure that from the perspective of Cisco ISE.