Authorization, Authentication, and Accounting – CompTIA Network+ N10-007 – 4.2


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.

Leave a Reply

Your email address will not be published. Required fields are marked *