If you are managing a large network, then you probably have at least one AAA server. In this video, you’ll learn about authorization, authentication, and accounting services.
<< Previous Video: Physical Security Next: Multi-factor Authentication >>
Being able to log in and gain access to resources is one of the most important parts of anyone’s network. In this video, we’ll look at AAA, which is authorization, authentication, and accounting. If you’re logging into the network, you’re connecting to a VPN, or you’re gaining access to the command line of a switch, you’re probably using a AAA framework.
The first step in using this AAA framework is first identifying yourself. We usually use a user name to do this. But there are many different ways that you could use to identify who you are. At that point, we need to provide some other type of authentication, some way that we can really prove that we are who we say we are. This is usually a password or one of a number of different authentication factors. Once the authentication process is approved, you can then gain access to the resources that would be appropriate for your particular username. If you’re logging in as an administrator, you will have different authorization than someone who’s logging in with a guest account.
And with the last of A of accounting, we’re tracking all of this information. We know when you logged in. We know what data was sent back and forth. We may be tracking the different resources that you’re gaining access to. And we’re determining when the log out time might be. Here’s how this AAA framework operates for someone who might be authenticating to a VPN concentrator. So from your client workstation, you would communicate across the network, and log in to that concentrator. In this case, it’s also a firewall. Because we’ve not provided any authentication yet to log in to this VPN, our username and often location information will be passed to a AAA server that’s usually somewhere else inside of your network. The AAA server will authenticate the information you provided, and if those credentials match, you’re approved to gain access to internal resources.
Now that this authentication has been approved, the VPN concentrator will allow traffic to flow back and forth from your client to the rest of the network. In our previous example, we could have chosen a number of different protocols to provide the authentication between the VPN concentrator and the AAA server.
One of the most popular protocols is RADIUS. This stands for Remote Authentication Dial In User Service. And you’ll find RADIUS services available on a number of different operating systems, and we use it for many different purposes on our networks, not just the dial in that’s in the RADIUS name, but it can be used to authenticate anyone who happens to be on your network. For example, we can centralize all of your authentication using RADIUS.
So if you’re logging in to a router, or a switch, or a firewall, you can use your same credentials to log into a server, to log in to the remote VPN access, or to log into your wireless network with a 802.1X. One of the reasons RADIUS has become so popular is that you can find RADIUS services for almost any operating system. So if you’re running Windows, or Linux, or MAC OS 10, you can find a RADIUS service that will run on those operating systems, and many others.
An alternative to RADIUS would be TACACS. This is the Terminal Access Control or Access Control System. This is another remote authentication protocol very similar to RADIUS, but it was created to provide access to dial up lines on the older ARPANET. Cisco took this TACACS configuration and created a customized version of it for Cisco devices called Extended TACACS, or XTACACS. This extended a number of the features and TACACS to include additional accounting and auditing functions.
These days, if you’re using TACACS to provide authentication, you’re probably using TACACS+. This is the latest version of TACACS, and it’s not backwards compatible with any of those other versions. Although many people associate TACACS with Cisco, you can find TACACS+ services for many operating systems that work across many different services. If you’re managing a group of switches or routers, and you’re using TACACS or RADIUS to provide that authentication, you know that you have to provide a user name and password each time you log in to a separate device. But on today’s networks, we want to log in one time, and then automatically have access to all of the resources associated with our login.
To enable that functionality, we use Kerberos. Kerberos is a network authentication protocol where you can authenticate one time and then you’re trusted by the entire system. Kerberos can also provide mutual authentication, where you would authenticate to the server, and the server would also authenticate to you. Kerberos also takes advantage of extensive asymmetric encryption, which means it can prevent man-in-the-middle or replay attacks from occurring. Kerberos has been around for a long time. It was created at the Massachusetts Institute of Technology in the 1980s. And then Microsoft started using Kerberos in their server operating systems starting with Windows 2000. And now, when you log into a Windows domain, it’s Kerberos that’s providing that single sign on in the background.
The single sign on functionality of Kerberos is enabled using cryptographic tickets. These tickets are granted to someone who is logged in properly, and then that ticket can be shown to other resources on the network to gain access. This means that you only need to provide your authentication credentials one time, and from that point on all of the other devices can accept your credentials. This obviously would only work if all of the devices were able to communicate with these Kerberos protocols. If you’re trying to authenticate to a switch that doesn’t understand Kerberos, then you’ll have to find a different authentication method.
We’ve been using directories to associate information for a very long period of time. A good example is a phone book that might associate your name and your address with a phone number. We have similar directories on our networks. And one way that we can access those directories is with the protocol named LDAP, for Lightweight Directory Access Protocol. This allows us to read and write information to a directory that’s on our network. LDAP uses a standard called X.500. It was a standard that was written by the International Telecommunications Union, or the ITU. This means if you create an LDAP database, then other devices can use the standard X.500 to be able to read and write information.
Early versions of LDAP were called DAP. This was the directory access protocol that ran on the older OSI protocols. LDAP is a lightweight version of this DAP protocol that uses tcp/389 and udp/389 to communicate. If you have a directory that’s in Windows Active Directory, Apple Open Directory, or Open LDAP, then you can use this X.500 standard to communicate to any of these directory types. LDAP pairs together an attribute and a value, and uses multiples of those attributes to be able to define a particular object in the database.
For example, you can have a number of descriptors for an object that might show that the common name is WIDGETWEB in an organizational unit of marketing. It happens to be an organization called Widget in a locality of London, in a state of London, in the country of Great Britain. And then you can have domain components that would be associated with this. For example, widget.com would be described as DC=widget and DC=com.
These attributes create a hierarchy. And if we were to map out this hierarchy, you can see that it creates a tree of information. The country of Great Britain, an organization called Widget, an organizational unit of marketing, and then within that organizational unit, you can have other items in the tree. We call these devices at the end of the tree the leaf objects. These might be users, computers, files, and other devices that you might need access to. This means we could associate an attribute with one of these leaf objects, for example, the webmaster. And if somebody wanted to log in as the webmaster, they would use all of these attributes to specify the object, and then the authentication process would check the password, and then provide authentication.
Having everything in a centralized database and being able to have single sign ons is very convenient. But there may be times when you do not want to authenticate to a centralized database. In those cases, you may want to use local authentication. So if you’re logging into a server, a router, a switch, you might want to use a set of credentials that are stored on that local device. And many devices that you install into your infrastructure will have an initial local account configured. And many of them will require during the setup process that you change the password for that local account. That way you can be assured that no one can use default user names and passwords to gain access to these resources.
Local accounts is probably not something that you’d want to use for all users who are logging into this device. If you need to make a change to someone’s password, you would have to log in to every single device that needs to make that change and then manually perform those updates. This is obviously very different than using AAA, where there’s a centralized server, and if you need to change your password, you simply change it on that single server. Most people are using local accounts to be able to gain access to these devices if the AAA server is no longer accessible. This means that if the AAA server had a problem, you would still be able to access your switches, routers, firewalls, and other infrastructure devices.
We can also use certificates to gain authentication. With public and private keys, we can create a certificate that would be private to you, and no one else would have access to that particular certificate. Many people will put these certificates on a smart card. So you would have to slide the smart card into your computer, usually provide a personal identification number, and then you would gain access to that system.
The US federal government uses a PIV card. This is a Personal Identity Verification card, where the smart card information is the ID card itself. You simply slide your ID card in to be able to read the certificate that’s on that card. If you work for the US Department of Defense, then you’re probably using a CAC, which is a Common Access Card. But of course, you don’t have to use a card to have access to these certificates. You could store the certificate on a laptop, or maybe store the certificate on a USB drive, and you would access that certificate during the log in process.
With these centralized authentication functions, we can gather a lot of information about who’s using the network and when. We can see exactly who’s logging in, where they’re logging in from, and what resources they’re accessing. With all of this information logged, we can then go back and provide audits of this information. We can make sure that right people are logging in from the right locations, and that everyone is accessing the correct resources for their particular login. We want to know exactly how these resources are being used after the authentication, and we want to be sure all of our systems and applications are secure.
We can even start creating rules for our AAA server that are based on the time of day. For example, if there’s a lab that no one should be accessing after normal working hours, we can create a rule in our AAA server that would prevent access to those resources after a particular time of day.
By combining these authentication logs with access and resource logs from other servers, we can begin to build a picture of exactly what’s happening on our network. So we can understand when a successful log in has occurred, we know when users log off of the network. And when they log in, we can determine if new processes or applications are being used. Since we’re collecting all of these log in events, we can determine exactly when someone may be logging on, or, for example, when a log in was unsuccessful. This might give us the information we need to prevent any unauthorized access to our network.