LDAP and Secure LDAP – CompTIA Security+ SY0-401: 5.1

| September 18, 2014 | 0 Comments


Most organizations maintain a centralized database that’s used for authentication, user identification, and many other purposes. In this video, you’ll learn how LDAP and Secure LDAP can be used to efficiently manage these large user databases.

<< Previous Video: KerberosNext: SAML >>


In our computing environments, we have large directories of information. We probably have a list of everybody in our organization. We have their location, their telephone numbers, their email addresses. And this very large index is called a directory. There are protocols that then allow us to work with these large directories, and one of those is called LDAP. And this stands for Lightweight Directory Access Protocol.

This LDAP protocol is very standardized and it uses a standard called X.500. This is a specification that was written by the International Telecommunications Union, who obviously have a very big need to be able to interact with different telephone directories. The original LDAP was simply called DAP, the Directory Access Protocol. And it ran using the OSI protocol stack, a protocol stack we don’t often see running any longer.

These days we use a lightweight version of DAP called LDAP, and it uses TCP/IP to communicate over TCP port 389 and UDP port 389. If you need to update or modify things in a directory that is X.500 compliant, then you’re going to use the LDAP protocol. And it’s very common to see this on all of our major operating systems. If you’re running Active Directory with Microsoft Windows, you’re running Apple’s Open Directory, or you’re running Novell eDirectory, then you’re using LDAP for each one of those directory services.

X.500 has a very particular way of defining what’s in the directory. It does this using distinguished names. It puts information in pairs where you have an attribute, an equal sign, and then what the attribute value happens to be. The most specific attributes tend to be specified first in the big list of these distinguished names.

For instance, this is the distinguished name for a web server called WIDGETWEB. In fact, it has an attribute at the beginning of CN, and I have a number of the popular attributes here. CN stands for the common name of that device. So the common name is WIDGETWEB, which is the web server that we’re specifying here. It is in an organizational unit of Marketing.

It is in an organization called Widget located in a locality of London. It is in a state of London. The country is Great Britain. The domain component– this is used a lot when you’re trying to describe the components within this– are widget and a domain component of com. This describes this web server as being the one used on Widget.com.

So you see all of these working together allow us to provide a very specific representation and directory of this particular web server. This modular nature of the distinguished names in LDAP allows us to build a tree of different devices. And a good example is the picture that we have here.

We’ve broken the tree out into two pieces. We have container objects that store other objects within it. Objects such as the country, the organization, and the organizational units. Within these containers, we have leaf objects which are the individual devices, such as users, computers, printers, and the files. And you can see how you might build a tree based on this.

For instance, we have the country of Great Britain. Inside of Great Britain is a Widget object. You also have a container object within the Widget object of Marketing, Accounts, and Mis. And within Marketing, you then have separate devices such as the Webmaster and such as the WIDGETWEB. All of these can now be easily defined and you can put the objects into the proper object container, or you can define exactly what container they belong to.

There are number of additional security layers that you can have within LDAP. One is called the simple authentication and security layer, or SASL. And this is in LDAP version three. There’s different types of authentication that this would allow us to have to these directories. The first would be no authentication, which means that anybody gets access to the data.

You can have anonymous users that would gain whatever type of access they would need to have in that particular data store. There might be simple authentication, where the client is providing a distinguished name and a password and that then provides the access to the directory. Or you could have a simple authentication and security layer where you’re integrating with something like Kerberos or TLS to provide an additional layer of security on top of SASL.

Once someone is authenticated into the directory, they generally would have one of two levels of access. You would have a read-only access, where you could simply query the information. And then you might have a read-write access, where you might update the information. It wouldn’t be uncommon to allow anonymous users to have read-only access, but have your normal users and administrators have read-write access to the directory.

One important consideration regardless of the authentication type is that you are limiting the access to this information. So if this is an LDAP database that is accessible from outside of your network, you may want to consider putting a firewall in place to prevent unauthorized users from trying to authenticate to your LDAP information.

Another security layer that can be added to LDAP is LDAPS. This stands for LDAP over SSL. The LDAP protocol itself sends all of this information over the network in clear text. And obviously, it’s very easy to be able to retrieve these packets off of the network and view that plain text information. We want to therefore be able to encrypt this information, and the common way to do this is using LDAP over SSL.

This is using SSL– or what is now called TLS– to encrypt the information as it goes over the network. It’s very common to see LDAPS being used in Microsoft environments. The Active Directory database can be accessed via these LDAP protocols, and instead of using TCP port 389 and using LDAP in the clear, it’s very common to use TCP port 636 that’s connecting using LDAPS.

If you do have a policy in place that restricts any type of in the clear LDAP communication, then you may want to firewall LDAP ports 389 just to make sure that the only protocol that’s going to be using this LDAP directory is LDAPS over TCP port 636.

Tags: , , , , , , ,

Category: CompTIA Security+ SY0-401

X