Networking / Beginners

---

LDAP

LDAP services are used to access a wide variety of information that's stored in a directory. On a network, consider that the directory catalogs the name and information on every user, computer, printer, and other resource on the network.The information on a user alone may include their username, password, first name, last name, department, phone number and extension, e-mail address, and a slew of other attributes that are related to the person's identity.The sheer volume of this data requires that LDAP directories are effectively organized, so that the data can be easily located and identified in the directory structure.

LDAP Directories

Because LDAP is a lightweight version of DAP, the directories used by LDAP are based on the same conventions as X.500. LDAP directories follow a hierarchy, much in the same way that the directories on your hard drive are organized in a hierarchy. Each uses a tree like structure, branching off of a root with containers (called organizational units in LDAP; analogous to folders on a hard drive) and objects (also called entries in LDAP's directory; analogous to files on a hard drive). Each of the objects has attributes or properties that provide additional information. Just as a directory structure on a hard disk may be organized in different ways, so can the hierarchy of an LDAP directory. On a network, the hierarchy may be organized in a numbers of ways, following the organizational structure, geographical location, or any other logical structure that makes it easy to manage the objects representing users, computers, and other resources.

Because LDAP directories are organized as tree structures (sometimes called the Directory Information Tree [DIT]), the top of the hierarchy is called the root.The root server is used to create the structure of the directory, with organizational units and objects branching out from the root. Because the directory is a distributed database, parts of the directory structure may exist on different servers. Segmenting the tree based on organization or division and storing each branch on separate directory servers increases the security of the LDAP information. By following this structure, even if one directory server is compromised, only a branch of the tree (rather than the entire tree) is compromised.

Organizational Units

The hierarchy of an LDAP directory is possible because of the various objects that make up its structure. These objects represent elements of the network, which are organized using containers called organizational units (OUs). Each OU can be nested in other OUs, similar to having subfolders nested in folders on your hard disk. In the same way the placement of folders on your hard disk makes a directory structure, the same occurs with OUs and objects in an LDAP directory.

The topmost level of the hierarchy generally uses the domain name system (DNS) to identify the tree. For example, a company named Abc might use abc.com at the topmost level. Below this, organizational units are used to identify different branches of the organization or network. For example, you might have the tree branch off into geographical locations, like PARIS, LONDON, and TORONTO, or use them to mimic the organizational chart of the company, and create OUs with names like ADMINISTRATION, RESEARCH,TECHNOLOGY, etc. Many companies will even use a combination of these methods, and use the OUs to branch out by geographical location, and then create OUs for divisions of the company within the OUs representing locations.

To identify the OUs, each has a name that must be unique in its place in the hierarchy. For example, you can't have two OUs named PRINTERS in a container named SALES. As with many elements of the directory it is analogous to the directory structure of a hard disk where you can't have two subfolders with the same name in the same folder.You can however have OUs with the same name in different areas of the hierarchy, such as having an OU named PRINTERS in the SALES container and another OU named PRINTERS in an OU named SERVICE.

The structure of the LDAP directory is not without its own security risks, as it can be a great source of information for intruders. Viewing the placement of OUs can provide a great deal of information about the network structure, showing which resources are located in which areas of the organization. If an administrator followed a particular scheme of designing the hierarchy too closely, a hacker could determine its structure by using information about the organization. For example, companies often provide their organizational charts on the Internet, allowing people to see how the company is structured. If an administrator closely followed this chart in designing a hierarchy, a hacker could speculate how the LDAP directory is laid out. If the hacker can gain access to the directory using LDAP queries, he or she could then use this information to access objects contained in different OUs named after departments on the chart. Using naming conventions internal to the company (such as calling a London base of operations DISTRICT1) or using some creativity in naming schemes (such as calling an OU containing computer accounts WK instead of WORKSTATIONS) will make the hierarchy's structure less obvious to outsiders. While using the organizational chart of a company and geographical locations can be used as a basis for designing the hierarchy, it should not be an easy-to-guess blueprint of the directory and network infrastructure.

Objects, Attributes and the Schema

As mentioned, entries in the directory are used to represent user accounts, computers, printers, services, shared resources, and other elements of the network.These objects are named, and as we discussed with organizational units, each object must have a name that's unique to its place in the namespace of the hierarchy. Just as you can't have two files with the same name in a folder on your hard disk, you can't have two objects with the same name in an OU.The name given to each of these objects is referred to as a common name, which identifies the object but doesn't show where it resides in the hierarchy.

The common name is part of the LDAP naming convention. Just as a filename identifies a file, and a full pathname identifies its place in a directory structure, the same can be seen in the LDAP naming scheme.The common name identifies the object, but a distinguished name can be used to identify the object's place in the hierarchy. An example of a distinguished name is the following, which identifies a computer named DellDude that resides in an organizational unit called Marketing in the tacteam.net domain:

DN: CN=DellDude,OU=Marketing,DC=tacteam,DC=net

The distinguished name is a unique identifier for the object, and is made up of several attributes of the object. It consists of the relative distinguished name, which is constructed from some attribute(s) of the object, followed by the distinguished name of the parent object.

Each of the attributes associated with an object are defined in the schema.The schema defines the object classes and attribute types, and allows administrators to create new attributes and object classes specific to the needs of their network or company. For example, a "supervisor" attribute in a user account might contain the name of the user's manager, while a "mail" attribute would contain the user's e-mail address. Object classes define what the object represents (i.e., user, computer, and so forth), and a list of what attributes are associated with the object.

Because LDAP is binary, to view the attributes of an object, the information can be represented in LDAP Data Interchange Format (LDIF). LDIF is used to show directory entries in an easy-tofollow format, and used when requests are made to add, modify, or delete entries in the directory.The following is an LDAP directory entry with several attributes represented in LDIF:

dn: cn=Jane Baker, dc=example, dc=com
cn: Jane Baker
givenName: Jane
sn: Baker
telephoneNumber: 805 333 1312
ext: 1234
employeeID: 4321
mail: jbaker@nonexist.com
manager: Milli Sane
objectClass: organizationalPerson

As you can see by this entry, the attributes provide a wide degree of information related to the person represented by the object. By looking at this information, we can see contact information, employee identification numbers, the person's manager, and other data. Other attributes could include the person's Social Security Number or Social Insurance Number, home address, photo, expense account numbers, credit card numbers issued to the person, or anything else the company wished to include. While this example reflects a user account, a similar wealth of information can be found in objects representing computers and printers (which would include IP addresses) and other resources on the network. As stated earlier, while useful to authorized users, it is also useful for unauthorized intruders who could use the information for identity theft, hacking specific computers, or any number of other attacks.