As a network administrator, you need to log into your network devices. To do this, of course, you need a login ID and a password. And that raises the question of how you’ll manage this account information. There are many options.
The simplest option is to store this account information locally on each device, but that’s hard to manage if you have a lot of devices. A better alternative is to use an authentication protocol to allow the devices to get the account information from a central server.
The most commonly used authentication protocols are TACACS+, RADIUS, LDAP, and Active Directory. It’s important to understand these are not competing protocols. I’ve seen many environments that use all of them simultaneously — they’re just used for different things.
In this article, we discuss most commonly used protocols, and where best to use each one.
Before we start, you should know there are three key tasks to worry about, which is why different protocols are used for different situations. We summarize them with the acronym AAA for authentication, authorization, and accounting. Sometimes there’s a fourth A, for auditing.
With local accounts, you simply store the administrative user IDs and passwords directly on each network device. This has some serious drawbacks.
First, if you have a lot of devices, then making changes like adding or deleting a user across the network or changing passwords becomes a massive undertaking.
Second, if somebody gets physical access to one of these devices or even to its configuration file, they can quietly crack passwords, perhaps by brute force. Then, if the passwords are the same across many devices, you’re in serious trouble.
And third, it becomes extremely difficult to do central logging and auditing of things like failed login attempts or to lock out an account you think is compromised.
Having said all that, local accounts are essential in one key situation: When there’s a problem that prevents a device from accessing the central authentication server, you need to have at least one local account so you can still get in. (And, of course, when there’s an underlying problem to fix is when you’ll most desperately need to log into the device.)
The solution is to configure a privileged account of last resort on each device. It’s an account that’s never used if the authentication service is available. If you try to enter the local administrative credentials during normal operation, they’ll fail because the central server doesn’t recognize them.
The following code fragment shows how to configure a local user account on a Cisco device. It enables the AAA authentication mode and tells the devices they should use a locally defined method called “local_auth”.
! aaa new-model aaa authentication login local_auth local ! username kdooley privilege 15 password Aw3somE ! line vty 0 4 login authentication local_auth !
The “line vty” command associates this logon method with specific virtual terminal lines. Then I could have a separate authentication method for other types of users, such as remote VPN credentials.
In the example, I’ve created a single local user whose privilege level is 15. This isn’t always good practice. Many security-conscious organizations require you to log in as an unprivileged user and then use the “enable” command to gain super-user privileges. If that’s the case for you, leave out the “privilege 15” part of the command.
Terminal Access Controller Access Control System (TACACS) is the somewhat redundant name of a proprietary Cisco protocol for handling authentication and authorization. The plus sign distinguishes the modern version of the protocol from a very old one that nobody uses anymore.
TACACS+ has a couple of key distinguishing characteristics. It allows full encryption of authentication packets as they cross the network between the server and the network device. This prevents an attacker from stealing your logon credentials as they cross the network.
The most important and useful feature of TACACS+ is its ability to do fine granular command authorization. When you use command authorization with TACACS+ on a Cisco device, you can restrict exactly what commands different administrative users can type on the device.
For example, you could allow a help-desk user to look at the output of the “show interface brief” command, but not at any other “show” commands, or even at other “show interface” command options.
Command authorization is sometimes used at large organizations that have many different people accessing devices for different reasons. But the feature isn’t very meaningful in an organization where the network admins do everything on the network devices.
Configuring TACACS+ on a Cisco device is fairly straightforward, but there are a few extra steps.
! aaa new-model aaa authentication login default group tacacs+ local tacacs-server host 192.168.100.15 tacacs-server key V3ryS3cret ! username kdooley privilege 15 password Aw3somE ! line vty 0 4 login authentication default !
Note that the example shows a fallback admin account that can be used in case the TACACS+ server is unreachable. Without it, you could find yourself locked out of the device during a network failure.
The “aaa authentication” command shows a list of authentication methods to try in order. First it will try “group tacacs+”. Then, if there’s no response from any of the TACACS servers (we’ve only listed one, but you could easily list several), it will resort to the local username database.
It’s important to note that the device will only attempt the second authentication method if the first one fails to respond. If the TACACS+ server responds but says the username or password is wrong, it will stop.
The “tacacs-server host” command in this example defines the IP address of the server. The “key” command includes the key that the TACACS+ protocol will use to encrypt the data as it passes through the network. This key also provides authentication between the device and the server, ensuring that other devices on the local network can’t carry out brute force attacks against the credential database.
Remote Authentication Dial-In User Service (RADIUS) is rarely used for authenticating dial-up users anymore, but that’s why it was originally developed. It’s now a general-purpose protocol for user authentication.
Unlike TACACS+, RADIUS doesn’t encrypt the whole packet. Instead, it only encrypts the part of the packet that contains the user authentication credentials. This level of security is generally considered good enough, although I wouldn’t recommend passing it through the public Internet without additional encryption such as a VPN.
While RADIUS can be used for authenticating administrative users as they access network devices, it’s more typically used for general authentication of users accessing the network. For example, RADIUS is the underlying protocol used by 802.1X to authenticate wired or wireless users accessing a network.
A very common technique is to use RADIUS as the authentication protocol for things like 802.1X, and have the RADIUS server talk to an Active Directory or LDAP server on the backend. The Active Directory or LDAP system then handles the user IDs and passwords. Such a setup allows centralized control over which devices and systems different users can access.
Configuring RADIUS for user authentication is nearly identical to TACACS+.
! aaa new-model aaa authentication login default group radius local radius-server host 192.168.100.16 radius-server key RaDiU$S3cret ! username kdooley privilege 15 password Aw3somE ! line vty 0 4 login authentication default !
The “radius-server key”command provides encryption of the part of the RADIUS protocol packet payload that includes usernames and passwords. It also authenticates the device with the RADIUS server for security reasons.
Before we move on to discussing LDAP and Active Directory, another important function of the AAA feature set is the ability to provide central logging. To do this, you need to specify what you want to log and to where.
! aaa accounting exec default start-stop group radius !
The above example tells the device to send a message to the RADIUS server every time a user starts or ends an administrative session. A nearly identical command sends the same information to a TACACS+ server instead. In both cases, the information includes the user ID and the time of the event.
It’s different from the usual syslog logging, but may include some of the same information. In this case, the device will send authentication-specific information to the central server using either the TACACS+ or RADIUS protocol natively.
LDAP and Active Directory
Lightweight Directory Access Protocol (LDAP) and Active Directory are pretty much the same thing. Active Directory is essentially Microsoft’s proprietary implementation of LDAP—although it’s LDAP with a whole lot of extra features added on top.
Some network devices, particularly wireless devices, can talk directly to LDAP or Active Directory for authentication. But Cisco switches and routers don’t speak LDAP and Active Directory natively. If you’ve got Cisco gear, you’ll need to use something else, typically RADIUS, as an intermediate step.
Using RADIUS to talk to Active Directory just to hold a username and password sounds onerous, but it can actually streamline management of a large network. For example, if there’s a large number of administrative users, and they all need to access the Microsoft Windows services anyway, keeping their logon credentials in one central database makes sense.
It’s also very useful if you’re authenticating ordinary users through 802.1x, and not just administrators. In such a situation, there could be thousands of users, and it’s not easy to keep track of all of them in multiple databases.
There are two common ways to link RADIUS and Active Directory or LDAP. The first is to use a Cisco Access Control Server (ACS) and configure it to use Active Directory for its name store. The second is to run the native Microsoft RADIUS service on the Active Directory domain controllers.
In the ancient past, the all-Microsoft solution had scaling problems, so people tended to avoid it in larger deployments. However, this is no longer true. Now both options are excellent.
Centralized authentication improves both the manageability and security of your network. The ability to quickly and easily add a new user, and to update passwords everywhere throughout your network at one time greatly simplifies management. The ability to change passwords or lock out users on all devices at once provides better security. And with central logging, you can immediately tell if somebody is repeatedly attacking a particularly user’s credentials, even if they’re doing so across a range of network devices to hide their tracks.
All in, centralized authentication is something you’ll want to seriously consider for your network.