AAA and 802.1X Authentication

(Rene Molenaar) #1

This topic is to discuss the following lesson:

(Tim W) #2

What’s the name of the follow-up lesson? “In another lesson I will give you a configuration example how to implement this on a Cisco Catalyst Switch.”

Or does it not yet exist?

(Rene Molenaar) #3

Hi Tim,

I just added a link in the lesson, or you can use this one:

AAA Configuration on Cisco Catalyst Switch


(francesco r) #4

Radius and tacacs are used to authenticate user for only management of intermediary device ,or to access at intranet domain and my be go out to internet??

(Rene Molenaar) #5

Hi Francesco,

We use RADIUS and TACACS+ for both user authentication and management. For example, with wireless networks we use RADIUS for user authentication (WPA2-enterprise). This allows us to use client and server certificates and it’s a far more secure solution than using pre-shared keys only.

For network management, it’s useful since you can centralize all your authentication instead of creating usernames/passwords on each and every router, switch, firewall, etc on your network.

It’s used on local networks, the only time you might use it on the Internet is if you have a branch office and you want to use the RADIUS/TACACS+ server on the main site. In that case, you would use a VPN tunnel.


(Thinh C) #6

Hi Rene,
Which’s standard of RFC that I can follow when learning the TACACS+?
Many thanks!

(Lazaros Agapides) #7

Hello Thinh

The original TACACS is defined in RFC 1492 as it is an open IETF standard. TACACS+ however was developed by Cisco so it has no corresponding RFC. Cisco developed it as an open standard so many vendors can and do use it.

There is however a Cisco RFC TACACS+ Draft available on the IETF web site that you can check out. There are also additional drafts that have been added, the most recent of which can be found here.

I hope this has been helpful!


(Thinh C) #8

oh, thank you so much, i looked it out :slight_smile:



Can you please explain what you mean at the beginning of the lesson, that port security cannot prevent the connection of a Wi-Fi router to the switch? Could not we just configure the switch to accept only specific MAC addresses on its interfaces via port security? How is NAT also affecting the whole process? Thank you in advance!


(Lazaros Agapides) #10

Hello Markos

Using port security we can do several things. We can restrict the use of a switch port to only one specific preconfigured MAC address or we can specify that only a single MAC address should be seen to be using this port. We can even use IP source guard to determine which will be the allowed source IP address that can use the interface, even on an L2 switch.

The first case will allow us to lock the port down such that only a specific computer having a specific MAC address can connect to that port. If this were implemented, then port security would indeed block the use of an access point. It would actually block the use of ANY device other than the computer with the specified MAC address. However, this port security scheme is not used that often because it has a very large administrative overhead, especially in environments where many moves adds and changes take place.

The more common port security scenario, and the one that Rene is referring to in this lesson, is when port security is implemented so that only a single MAC address will be allowed on a port of a switch. This prevents users from bringing their own switches and connecting multiple devices to it because each of those devices will send a different source MAC address to the switch and will trigger the port security threshold. Additional port security scenarios include the use of IP source guard where packets from the specific IP address associated with the single allowed MAC address will only be permitted and all other hosts will be rejected.

These port security features cannot be used to prevent the use of a rogue access point because the access point will create a separate subnet for its wireless users and it will use NAT to translate all of those users to a single IP address for the switch-facing interface. Any and all traffic from users on the impromptu wireless network will appear to the switch using the legitimate single MAC address allowed and the legitimate single associated IP address. Thus, all traffic will be allowed through.

I hope this has been helpful!


(Edgar M) #11

Just a quick real work question. Im wondering about the ramifications in a windows domain environment. If a host machine is booted i assume all traffic from machine is blocked prior to the login. I assume the windows SSO can also act as a 802.1X supplicant. If so then i get my windows logon AND network access at the same time ? How does this work in a scenario if one user logs off and a second logs on ? or if (in a windows 7+ environment a “switch user” is performed? Any light you can shed on how 802.1x works with AD login, login scripts group policy etc would be appreciated.

Thanks so much!

(Rene Molenaar) #12

Hello Edgar,

Good question. From the “network engineer” perspective, 802.1X is layer two authentication so how the operating system deals with it is a system engineer issue :grin:

You really need to dive into windows authentication to figure out how this exactly works.

Some items to consider:

  • When you provision a new machine, it has to join the domain so somehow it requires access to the domain. IAS/NPS probably supports a fallback VLAN so when authentication fails (it does because it’s a new machine), you can add it to a “provision” VLAN which allows access to the domain and provision it.

  • Another option is MAB. You could create a script that adds the MAC address automatically when you provision the new machine.

  • When you provision the machine, you can use a GPO to configure your 802.1x settings and enroll certificates.

  • You can enroll user or machine certificates. You could use the machine certificate to authenticate the computer with 802.1X and use the user account only for domain authentication. I believe when you do this, machine authentication works automatically before the user attempts to log in.

  • With SSO, the user credentials are used for 802.1X as well. I’m not sure how it works when you switch a user though…that’s something to test :slight_smile: