-: Identity systems.
Let's dig a little bit deeper into
the different types of identity systems there are.
So when we talk about those identity systems,
they're going to provide you a lot of common functionality.
They have identity creation and management,
authentication and authorization,
as we talked about in the last lesson,
and federation of identity information.
To provide these functions, we're going to use things like
directories, authentication services,
Identity Management Platforms and federated identity tools.
We'll talk about each of these
as we go through the next couple of lessons.
Now directory services are used in networks
to provide information about the systems and the users.
The most common one out there is LDAP,
which is the Lightweight Directory Access Protocol,
and the most common one you're going to here about is
Microsoft's Active Directory,
but there's many other ones out there.
For example, there's Oracle's Internet Directory,
IBM's Security Directory.
There's open source ones like OpenLDAP,
389 Directory Server, ApacheDS, and OpenDJ,
but again, Microsoft's Active Directory
is really the one that's used most often
in the business world because Microsoft
has such a large presence in our corporate networks.
Now these can be used to make organizational information
available to email and other programs out there.
So for instance, if you're in a
corporate domain environment, you can open up
Microsoft Outlook, you can open up the address book,
and in there, you'll find people's names, their addresses,
their office locations, their phone numbers,
their email addresses, all sorts of information.
And all of that is coming from that LDAP Active Directory,
where it pulls essentialized information from.
Now when we look at LDAP, it has
a directory of a hierarchical structure.
So if I use the example of my domain, diontraining,
we have two groups underneath it.
We have the admin group, and we have the training group,
and each of those are what's call OUs,
or organizational units.
So under training, I have two types of roles.
I have students and I have teachers.
And on the admin side I have two types of roles.
I have staff and I have interns.
And so if I hire you on as an intern in my organization,
I would put you in the intern group,
and that would give you certain
rights and privileges by being part of that group,
which is part of the admin organizational unit.
And based on that, I can set up security
that's going to keep you in certain areas of our network
based on which group I place you into.
That's the whole idea with LDAP hierarchical structures,
is that by putting you into certain groups,
I can assign rights, roles, and responsibilities
based on those groups.
Now when we talk about securing LDAP,
there's a lot of things you need to think about.
The first one is you want to enable
and require TLS for LDAP query
because LDAP queries originally
were done in an unsecured manner
and this would allow people to sniff traffic
on your network and steal that information.
So by creating this TLS tunnel
between your client and the server
it's going to protect that information.
The next one is you wanna set your
password storage to use salted hashes.
So if you have a centralized directory
like a domain controller or some other directory,
whatever kind of LDAP you're using,
if you have all these passwords stored
in something like an MB5 format, it's really easy to break.
So instead you wanna use a salted hash
and you wanna use a strong hash,
something like SHA-256 or more.
Now the next thing you wanna worry about
is disabling unauthenticated access
or anonymous access to your LDAP
because these sometimes are enabled by default
and instead you wanna require a username and password,
because again there's so much
valuable information inside these directories.
Even just querying Jason Dion and getting my phone number
and my email address and my directory information,
I could then use that to craft
a spear phishing attack against Jason, right?
So we wanna make sure we protect that information.
Next you wanna make sure you're
replicating your LDAP to redundant servers.
This will help you prevent anything
from outages to Denial of Service attacks
because even if you come after my primary server,
my backup server can come back online
and then provide services.
And finally, you wanna use strong ACLs
or Access Control Lists on your LDAP servers.
This will limit access to objects using least privilege,
and again prevent some future attacks.
We'll talk much more about LDAP attacks later,
but I just wanted to give you a quick overview
of how you can start securing these things.
Now one of the attacks that we have
is what's called an LDAP Injection
and it's very similar to like an SQL Injection
except we're injecting into LDAP.
Now this is a type of attack where
improperly filtered input going through a web application
can send arbitrary LDAP queries to the server.
Again, very much like an SQL inject.
Now you can prevent this by escaping all variables
using the right LDAP encoding functions in your web coding.
You can also do things like validating your input
and creating a white list of
what is and what is not allowed.
You can use frameworks that will
automatically protect you from injection,
like LINQ for Active directory,
and you again can minimize your
privileges assigned to the LDAP web apps
because that will help prevent them
even if they are getting injected into
from running and executing exploits
and code against your other servers.
So when we talk about authentication protocols,
we have to think about the three big ones out there,
and that's TACACS+, RADIUS, and Kerberos.
These protocols are used to supply verification
of a user's identity to a relaying system.
So the first one we wanna talk about is TACACS+
and TACACS+ is Cisco's extension to the
Terminal Access Control Access Control System.
Now TACACS+ uses TCP to provide those
AAA services we've talked about in previous lectures.
It does lack integrity checking of the data it sends
and so therefore it is subject to replay attacks.
TACACS+ is kinda old and a little bit vulnerable,
so you really don't want to use it
in your networks these days.
It has encryption flaws in it because
the encryption key can be discovered by an attacker,
and bottom line is you just don't wanna use TACACS+ anymore.
It's just old, and unless you're using it
on an isolated network not connected to the internet,
I just wouldn't use it because it is very very flawed.
The next one we wanna talk about is RADIUS,
and RADIUS stands for the
Remote Authentication Dial-in User Service.
Now this is the most common AAA server
for networks, wireless networks, and other servers.
It operates over TCP or UDP modes in a client server model.
This will actually obscure the password inside RADIUS
using a shared secret key and an MD5 hash.
But again, we've talked about those before.
MD5 is not considered strong, and neither is
a shared secret key, so RADIUS again
is not really really strong and probably
is not the best thing to be using.
RADIUS traffic, if you're gonna use it,
needs to be encrypted using IPSec between your endpoints
to really provide you the protection you need.
But it is still one of the more
commonly used things out there,
so if you're gonna use it, use an IPSec tunnel,
add some encryption there and that's gonna help
secure it a little bit better.
Now Kerberos.
Kerberos is widely used in windows environments.
Kerberos was designed with security in mind by Microsoft.
It operates on untrusted networks
using encryption of the data as it sends it
back and forth, again giving us some security.
Principles, also known as users in this case,
are comprised of three different elements.
Primary, instance, and realm.
Primary is usually your thing like a username,
so in my case it might be Jason Dion, right?
Or Jason dot Dion or whatever it happens to be.
An instance is a unique ID that's used
in case the usernames are similar.
So there may be two Jason Dions on your network,
so maybe I am Jason Dion one, he's Jason Dion two,
and we each have our own unique instance.
If you look at Windows, they are very long,
unique instant keys to make sure
that they have variety in them.
And then the third thing we have is the realm
and the realm is a group of primaries.
So these are these groupings, right?
The admin group, this is the student group,
the teacher group, the instructor group,
those kind of things.
Now Kerberos replaced NTLM for AAA in Windows domains,
which is great because NTLM is very very vulnerable.
The one thing you need to make sure you have done though
is turned off backwards compatibility for NTLM
or you can introduce vulnerabilities into your system.
Now the way Kerberos works is the client is going to send
an authorization request to the authentication server,
as shown by the red line here.
It's gonna then send back a Client Ticket Granting Ticket.
This client then takes that, it's gonna send it
back to the client server to get
a Client Server Ticket, which goes back to the client,
and then it uses that ticket to then
communicate with any services it wants,
like email or web browsing, etc.,
using that ticket that it has.
So Kerberos is all about tickets.
Again, we're not gonna go deep into Kerberos
and the way it works here because
you should know that based on Security+
because Security+ is one of the prerequisites
to understanding CSA+ well.
If you don't understand Kerberos or
you haven't done Security+ yet,
I recommend picking up a quick YouTube video
or do a quick search and you can dig into it,
but you're not going to get a lot of
in depth questions on the way Kerberos works
on the CSA+ exam, so I don't want to
waste your time with it right now.
Now the next thing we want to talk about is Single-Sign-On
or SSO and Single-Sign-On is one of
the great things you can do for your users.
This is gonna allows users to authenticate just once
and then be able to use multiple systems.
You can do this using LDAP if you're
in a Windows environment or even other environments
and you can do this using what's called
Central Authentication Service.
So for example, the college IT chat,
you logon once to a Central Authentication Service
and then I can go into the paycheck area
with HR and benefits.
I can go into the login area
to help answer emails to my students.
I can go into the learning area,
where I can give students assignments
and grade their assignments.
All using the same username or password,
I login once and then it pushes me into
each of those other systems using Single-Sign-On.
The benefits of this, it reduces password reuse.
I don't have to remember five different
usernames and five different passwords.
Instead I remember a single username or password.
So I can create one good, long, strong password
and just use it once.
This prevents users from writing them down
and it prevents them from using that password
on multiple systems, so if one system gets hacked,
then all of them are gonna get hacked,
because they're gonna know your password.
But in this case, they're gonna have to break into
the identity server to be able to break into
the Single-Sign-On to get your username and password,
and so instead, we'll protect one place instead of
having to protect 500 places, right?
And there's fewer password resets and support calls,
which is great on your IT service management side
because as a user, if I have 20 different passwords,
I've gotta reset 20 different passwords
because I keep forgetting them.
So Single-Sign-On is great for your users
and its great for your security,
because it really allows you to focus your efforts
and protect one single identity management solution.
Now the last thing I wanna talk about
in this lecture is Shared Authentication.
There are four main terms you have to
understand with Shared Authentication,
and we're gonna talk more about them in a future lesson,
but for right now I want you to understand
OpenID, OAuth, OpenID Connect, and Facebook Connect.
Now, what are those things?
Well OpenID is an open standard
for decentralized authentication.
So instead of me having my website, at JasonDion.com,
having to authenticate you and have you
create and account on my server,
I can just trust Google, or LinkedIn, or Flickr,
or Facebook's authentication of you
and allow you to come into my site.
So you can use Google ID, for instance,
to logon to many different sites,
even ones outside of Google.
Now OAUth is an open authentication standard
to share that directory information,
those elements of identity, with third parties.
So maybe on my site, I don't need you to login,
but I do want to know your name.
It might have a popup that says,
"Share your name and email with Jason."
And you can hit that and Google
will then send me that information.
That's using OAuth.
The next one is OpenID Connect.
Now OpenID Connect takes that OAuth information,
and then adds an authentication layer,
so then you can then create an account on my site
using the information from OAuth
and be able to use your Google ID to login to my website.
And the fourth one here is Facebook Connect,
which does the same type of things,
but using Facebook's proprietary standard,
as opposed to the OpenID one, that was an open-source.