Network authentication protocols are well defined, industry standard ways of confirming the identity of a user when accessing network resources.
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. How does the network device know the login ID and password you provided are correct? In short, it checks the login ID and password you provided against existing user account records.
But how are these existing account records stored? The simplest option is storing the 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 a protocol to allow devices to get the account information from a central server.
The most commonly used authorization and authentication protocols are Oauth 2, TACACS+, RADIUS, Kerberos, SAML, and LDAP/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, your network security is at risk.
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.
Your Guide to Selling Managed Network Services
Get templates for network assessment reports, presentations, pricing & more—designed just for MSPs.
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.
Now, let’s move on to our discussion of different network authentication protocols and their pros and cons.
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 authentication 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 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 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. Due to the granular nature of authorization, management of permissions on TACACS+ can become cumbersome if a lot of customization is done.
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 authentication 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.
If you need network authentication protocols to allow non-secure points to communicate with each other securely, you may want to implement Kerberos. This protocol uses a system of tickets to provide mutual authentication between a client and a server. It is named for the three-headed guard dog of Greek mythology, and the metaphor extends: a Kerberos protocol has three core components, a client, a server, and a Key Distribution Center (KDC).
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 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.
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.
As with most things these days, Active Directory has also moved to the cloud—Azure Active Directory, while not exactly the same as Active Directory, brings together most of the benefits of traditional on-premise Active Directory and cloud-based authentication protocols like Oauth and SAML in a cloud-based platform.
Oauth 2 is the second iteration of the protocol Oauth (short for Open Authentication), an open standard authorization protocol used on the internet as a way for users to allow websites and mobile apps to access their credentials without giving them the passwords. It is employed by many popular sites and apps, including Amazon, Google, Facebook, Twitter, and more.
Because this protocol is designed to work with HTTP, it essentially permits “access tokens” to be applied to a third-party with the permission of the resource owner. Think of it like granting someone a separate “valet key” to your home.
Why use Oauth 2? The main benefit of this protocol is its ease of use for end users. They receive access to a site or service without having to create an additional, specific account for that purpose.
However, there are drawbacks, chiefly the security risks. By using one account for many services, if that main account is ever compromised, users risk compromising many more instances. Additionally, Oauth 2 is a protocol for authorization, but it’s not a true authentication protocol. It does’t validate ownership like OpenID, it relies on third-party APIs.
SAML stands for Security Assertion Markup Language. It’s an open standard for exchanging authorization and authentication data. It also has an associated protocol with the same name. The protocol is a package of queries that request the authentication, attribute, and authorization for a user (yes, another AAA).
Typically, SAML is used to adapt multi-factor authentication or single sign-on options. Its strength lies in the security of its multiple queries. The downside to SAML is that it’s complex and requires multiple points of communication with service providers.
Centralized network authentication protocols improve both the manageability and security of your network. The ability to quickly and easily add a new users and 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 have improved network visibility—you can immediately tell if somebody is repeatedly attacking a particular 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.
What do you think?
Share your thoughts and read what others have to say
