In this lesson, we're going to
discuss the different authentication methods
used in our networks, including local authentication,
LDAP, Kerberos, SSO, SAML,
RADIUS, TACACS+ and time-based authentication.
First, let's talk about what authentication is.
Authentication is the process of determining whether someone
or something is in fact who they claim
or what they claim to be.
Now, if you walk into my classroom on the first Monday
of the semester and say,
"Hey, professor Dion, my name is John Smith,"
I might ask to see your student ID
or driver's license so I can verify you are who you claim
to be, after all, you and I have never met before
so I need a way to validate your claim
and authenticate you as the person you claim to be.
The same thing is going to happen when you go
to take your certification exam.
Before you take the exam, the proctor's going to look
over your official government identification,
like your driver's license or passport,
and compare that to what you look like, as well
as comparing the name on it to what you registered
to take the exam under.
For example, if you registered to take the exam
as Jason Dion, but your driver's license
says Michael Jordan, they're not going to let you take the exam
because you are not Jason Dion, and
therefore you have failed the authentication process.
Now, the first authentication mechanism we have
is what's known as local authentication.
When you first turn on your personal laptop
and you enter your username and password,
that is using local authentication most of the time.
Whenever you set up your laptop
for the first time, you picked out a username and password,
and that device saved an encrypted version of
that on your hard disk or storage device.
Now, every time you try to log in,
it's going to take wherever you enter, it's going to encrypt it,
and then compare what you entered as an encrypted data
against the stored username and password.
If they match, you've been authenticated
because you've met the single factor authentication
requirements of a standard laptop
by entering a username and password.
The second type of authentication we have is known as LDAP.
LDAP stands for the Lightweight Directory Access Protocol,
and it's essentially a database
that's used centralize information about your clients
and your objects on the network.
LDAP is essentially a simplified version of X.500,
which is considered to be a directory service,
and it contains a hierarchal organization of the users,
groups, servers, and systems located inside of your network.
LDAP will use Port 389 if you're
using the standard plaint text version of LDAP.
If you're using LDAP Secure, known as LDAPS,
then it's going to use Port 636 using either an SSL
or TLS tunnel to protect the data
as it crosses over your network.
Now, LDAP is used for validating a username
and password combination against an LDAP server as a form
of authentication, so this will be very similar
to local authentication except it's
going to happen over the network.
LDAP is considered to be cross-platform
and it works with Unix, Linux, Mac,
and even Windows systems,
but Microsoft also has created their own implementation
of LDAP and they call it AD or Active Directory.
Now, in a Windows domain environment,
active directory is going to be used to organize
and manage everything on your network,
including your clients, your servers, your devices,
your users, and your groups.
Active directory can also be used as part
of your security policies or access control policies
by implementing things like group policies in your domain.
Now, this brings us to our third authentication method,
and this one is known as Kerberos.
Kerberos is focused on authentication and authorization,
but within a Windows domain environment,
and it integrates nicely with active directory.
Kerberos was designed
to provide secure authentication services
over an insecure network.
Kerberos uses a system of tickets to authenticate a user,
and it completely avoids sending passwords over the network
as it relies on Kerberos' ticketing system
within the Windows domain.
Now, Kerberos is an authentication protocol
that's going to provide two-way or mutual authentication.
When a user logs into the domain,
they're first going to contact the domain controller,
which acts as the key distribution center or KDC.
This KDC has two basic functions,
authentication and ticket granting.
So if your client is authenticated properly,
the KDC will issue them a ticket granting ticket
known as a TGT.
This ticket granting ticket is then
provided to the domain controller anytime the user wants
to access a resource on the network,
like a file share or a printer.
The domain controller will also provide the user
with a service ticket or a session key to use,
whichever one's going to be appropriate
for their current needs on the network.
These tickets will be presented to the resource
and the access will then be granted
because the resource always
trusts the domain controllers provided tickets.
If your domain controllers running Kerberos,
port 88 will remain open on your domain controller
so it can receive those inbound service login requests
from your clients.
Because Kerberos relies on the domain controller to serve
as the key distribution center,
this can become a single point of failure in your domain,
so be aware of that as well.
Now, if the domain controller goes down,
your ticket granting services are also
going to be shut down.
To prevent this though, most people will have both a primary
and secondary Windows domain controller in a clustered
or active standby configuration.
This will give you the redundancy to ensure that Kerberos
and LDAP continue to run effectively in your environment.
Our fourth authentication method that we need
to discuss is known as Single Sign-On or SSO.
Now, due to the large number of resources
and websites that the average employee needs
to access on a daily basis, these days,
most organizations have started
adopting a single sign-on environment.
When adopted, the organization
establishes a default user profile for each user,
and then they link that profile
to all the different resources that
that user needs to have access to.
Under this kind of an SSO system, the user's able
to have a single long, strong password
that they can memorize, or even better,
they can use a multifactor authentication system.
This will then replace the 30
or 40 different logging credentials
that the average person is currently,
and this allows 'em to just memorize one set of credentials.
This makes accessing new resources much quicker
and easier too, and it simplifies user
and password management.
Now, the one major drawback
to using single sign-on is your environment, is
that if your user's credentials get compromised,
the attacker will now have every resource accessible to them
that the user already had access to.
I like to think about it like a master key.
Let's assume you have a single key that opens your office,
your car, and your house,
but as you went to the mall, you dropped it and lost it.
Unfortunately, for you, an evil person named Jason
found that key, and now they have access
to all three things of yours,
your office, your car, and your house.
Well, that's the big drawback to using single sign-on,
but again, if you're using multifactor authentication,
you're going to be able to help keep it more secure,
and this is actually more secure than using usernames
and passwords because now somebody has
to have both factors in order
to compromise all of your accounts.
Single sign-on works by creating trust relationships
between various applications
and resources that you as a user might want to have access to,
and then when you try to log into one of your accounts,
it's going to leverage that existing trust relationship
between all the accounts, so the user's going to authenticate
with only one service provider,
but all the other resources that they want
to access have a trust relationship with
that service provider, and this allows 'em
to authenticate a user's identity on behalf
of those resources.
Our fifth authentication method is known as SAML.
Now, SAML is an XML based data format that's used
to exchange authentication information
between a client and a service.
This is going to be used to send things like our authentication
for the user, the entitlement to the user,
and the attributes of that user,
and often we'll pair up this with SOAP, which is a protocol
that we can use to transfer the SAML information,
and that way we can pair them together
and get authorization and authentication.
Now, when we're dealing with SAML,
this is often going to be used to provide
that single sign-on service or SSO that I talked about,
or using a federated identity management system.
This will allow a service provider to establish
that trust relationship with the identity provider,
and this way the identity of the user,
which we call the principal, can be trusted
by the service provider without the user ever having
to authenticate directly with that service provider.
With SAML, we have three main roles.
We have the service provider, the user agent,
which will usually be your web browser,
and then we have the identity provider.
Let's pretend I'm the service provider
and you want to log into my website,
but I don't own the identities.
Instead, I'm going to allow you
to sign on using your Google account.
Now, in this example, Google is the identity provider,
so the first step is for you to go to my website
and you're going to request the Target resource, so you go
to diontraining.com and you click on login.
When that happens, your computer
and my website are going to do a little handshake
where they discover the identity provider.
For example, my site may tell your web browser,
"Hey, I support Google as a login.
Do you want to use Google?"
And you'd say, "Sure, I support Google. Let's do it."
And then you click on that login button
and you'll get redirected to the SSO service.
The single sign on service here will then go back
to your browser, and your browser will make the request
to Google Service as the identity provider.
Now, Google will do the identification with you
and make sure that your username and password are correct.
Then they'll take all the information they know about you
and provide it inside of what's known as an XHTML form.
This will be sent back to your web browser.
Now, your web browser can take that
and it will then do a request assertion
for consumer service.
Essentially, you're going to send the information you got
from the identity provider, that XHTML file,
which tells me about the person who's been authorized
and the permissions they have, and then you're going to send
that over to my website.
Now, once I get that as a service provider,
I say, "Ah, this is John.
I know John, John's allowed to access my videos.
Let's get John to login, and he
can the videos, and here you go.
Here's the first video," and you'll start watching it.
Then you'll say, "Okay, I finished watching this video.
Show me the next one."
And because you're already authorized,
I'm going to respond back
with that requested resource, which is video number 2,
and then video number 3 and then video number 4 and so on.
So you only had to log in once
and you never actually logged in me directly
with your username and password.
You did all that through your identity provider,
which in this case was Google.
Now, our sixth authentication method is known as RADIUS.
RADIUS is the remote authentication dial in user service,
and RADIUS provides us with a centralized administration
for dial up VPN and wireless authentication,
so you can use it with both 802.1x
and the extensible authentication protocol known as EAP.
RADIUS is considered to be a client server protocol,
and it's used to authenticate users, authorize them
to services and account for their usage of those services.
RADIUS uses the User Datagram Protocol
for making its connections,
and this makes it fairly fast during the authentication
and authorization functions.
RADIUS commonly uses Port 1812 for authentication messages
and Port 1813 for its accounting messages.
Although some proprietary versions
of RADIUS may use ports 1645 and 1646 instead.
Now, it's important to note that RADIUS is considered
to be a cross-platform standard
because our next authentication method we're going to talk
about is not cross-platform,
and it's actually a proprietary protocol.
This brings us to our seventh authentication method,
which is known as TACACS+.
TACACS+ was developed by Cisco,
and it stands for the Terminal Access Controller Access
Control System Plus, which can perform the role
of an authenticator in an 802.1x network.
Now, it's really up to you to determine which one is going to
be best for your organization's needs, whether
that's RADIUS or TACACS+.
Personally, I've used RADIUS almost exclusively
within my organizations, and I found
that TACACS+ is a little bit slower to operate
because it relies on TCP instead of UDP.
But TACACS+ does have some benefits
that you may want to consider since it can provide you
with some additional security features,
and it can be used to independently
conduct its authentication, authorization,
and accounting processes.
TACACS+ does support all major network protocols as well,
and RADIUS doesn't support every protocol out there.
For example, RADIUS doesn't
support the remote access protocol,
NetBIOS Frame Protocol, X.25 PAG connections,
and a few others.
Overall, TACACS+ is an excellent choice if you need
to support these other network protocols,
but remember, if you're going to do this, you have
to be using all Cisco devices across your entire network
because TACACS+ is proprietary to Cisco based networks.
Now, if you're using a mixed network, you're going to have
to choose RADIUS like I did, and this is
because it has that cross-platform capability.
Our eighth and final authentication method is known
as time-based authentication.
Time-based authentication
is most often implemented as time-based one-time passwords,
or TOTP and time-based authentication
is a security mechanism
that will generate a temporary dynamic password
or token that's valid only for a short period of time.
Time-based authentication algorithms
will generate these one-time passwords
by combining a shared secret key
with the current timestamp,
and this current timestamp will usually be routed
to a specific time interval, like every 30 seconds
or every 60 seconds.
This helps to create a password
that will change every time this interval changes.
Now, this method is commonly used as part
of multi-factor authentication systems, so
whenever a user attempts to log into the system,
they'll provide their regular password,
which is something they know, and a TOTP generated
by an app or a hardware token,
which is something they have.
Time-based authentication significantly
enhances the security by ensuring
that even if the password is intercepted
or stolen, it still can't be reused
because it'll expire under that short validity period.
You'll often see TOTP codes are going to be generated
by software tools like Google Authenticator
or Microsoft Authenticator,
or you can use a dedicated hardware device
like an RSA Key Fob or a YubiKey.
Some implementations also rely on sending emails
or text messages that allow you to get a one-time code
that's valid for the next 5 or 10 minutes,
so you can log in that way too.
These time-based authentication systems
do provide security advantages to us
because of the dynamic nature
of the time-based password that allows us to be resistant
to replay attacks, even if the attacker tries
to use a stolen password.
This is because even if the attacker manages
to intercept the time-based one-time password,
it's going to be useless
after that short expiration period anyway.
So remember, there are many ways
to conduct authentication, including local authentication,
LDAP, Kerberos, SSO, SAML, RADIUS, TACACS+
and time-based authentication.
At its core, authentication is just the process
of determining whether someone
or something is in fact, who they claim themselves to be.
By securing our authentication methods,
though, we're going to be able to ensure our networks
and our systems remain secure.