Back in the Cretaceous era of my youth, I collected football cards. Lots of ‘em. In order to keep track of them all, I bought some spiffy card organizers. These organizers were great when I wanted to trade cards with friends and soon-to-be-ex-friends-who-stole-my-rookie-Joe-Montana-card (yeah, I’m talking about you, Kevin). Anyway, I learned that I needed to keep careful watch over my cards, often just opening the cases to ensure some of the cards were still there, especially after letting other kids look through my collection.

Most organizations use card organizers for their employees in the form of directory services – a centralized and secure hierarchical repository (i.e. database) for employee data, group membership, passwords, and other information. There are a number of directory services available – Microsoft’s Active Directory, Amazon Web Service (AWS) Directory Service, NetIQ eDirectory, and Covisint’s Cloud Identity Services are among the most popular.

Directory services aren’t limited to storing user information. Hardware, services, and applications running on the network can also be housed in directory services. Due to the sensitive nature of the data contained within, as well as the vendor-specific implementation architecture, a few companies got together to support an open, vendor-neutral, IP-based standard for data access called Lightweight Directory Access Protocol (LDAP).

A Lightweight (heh) LDAP Primer
LDAP is designed to allow speedy and efficient access to directory services – it is not the directory service itself. As a protocol (think CobraNet), LDAP doesn’t define or care how programs work on either the client or server side. It defines the “language” used for client programs to talk to servers, as well as servers to servers. A client can range from an email program, to a browser on a printer, or even an address book.

One of the most common uses for LDAP is to access centralized directory services to validate/authenticate login credentials. This is the basic premise for “single sign-on” (SSO), where one password for a user is shared between many services. An important feature to highlight is that LDAP does not require encryption, although it is available in LDAP v3 via the StartTLS extended operation. For security, using a TLS/SSL connection to encrypt the feed is highly recommended when transmitting user credentials. Otherwise, you’re sending credentials over the interwebs in clear text, which does not make IT happy (does anything, really?).

There are a few core aspects of LDAP that merit further discussion:

• A Directory Information Tree (DIT) is the tree-like hierarchy of entries contained in a directory server. Each node on the tree is an object that can be either an endpoint or a collection of other objects. The type of object is defined by its schema. The lowest layers of the DIT entries can represent any object, such as people, printers, application servers, and so on. The depth or breadth of the DIT structure is not fixed; it can be designed to suit different application requirements.
• Schemas are the meta language that describe each object type (person, organizational unit, etc.). They identify the attributes (name, telephone, locality) of each object type, whether these attributes are required or optional, as well as the type of each attribute (string, integer, etc.). For example, in the person schema, the attribute surname (sn) is required, but the attribute description is optional. Schema-checking ensures that all required attributes for an entry are present before an entry is stored.
• Attributes are the data entries defined by each object schema and appear as name-value pairs. Similar to a database, each attribute name must be unique; you can’t have two attributes named “surname” for the same object. Value is the actual data. In the example tel=5036417287, “tel” is the name, while “5036417287” is the value (mind blowing, I know). Some of the most frequently used attribute names are shown below, listed by their typical position in the DIT. Remember though, the DIT doesn’t require all of these levels:DC: domain component, refers to each component of the domain
  O: organization
  C: country
  ST: state or province
  OU: organizational unit
  L: location (locality)
  UID: user id
  CN: common name
  SN: surname
• A Distinguished Name (DN) is a name that uniquely identifies an entry and its position in the DIT. DNs are made up of a sequence of one or more relative distinguished names (RDNs) separated by commas. Each RDN is composed of an attribute value from each ascending tree node.cn=John Smith,ou=Marketing,ou=Departments,dc=example,dc=comis the distinguished name for a person with the common name (cn) John Smith under the organizational unit (ou) Marketing in the state (st) Oregon of the domain biamp.com (by combining the domain components).
  
  You may be saying to yourself “so LDAP syntax is like a folder directory structure.” Yes, both are read left to right, but DNs are completely opposite in structure, so no. Folder structures begin with the topmost folder or server and descend in granularity until reaching the individual file. DNs start with the most granular element and ascend to the broadest domain element. You can use that nugget as an ice breaker at your next party (results not guaranteed).

How LDAP Relates to AV
End users want to have the same (or at least similar) experience in a conference room that they have at their desks. They want to be able to access corporate directories for making calls and use the same password for accessing room technology that they use for network login. IT also benefits from user familiarity in conference rooms because they typically receive fewer trouble tickets (don’t get me started on users storing their passwords in browsers though. Just don’t.). So, if you’re not already connecting LDAP-enabled AV equipment, it’s likely you will be soon.

One of the biggest advantages of LDAP is that it’s probably already implemented by the client; IT is familiar with and often prefers or even requires using directory services to manage information. Being familiar with the basics of LDAP will help facilitate conversations with IT, which can make installations run a little more smoothly and can potentially act as a market differentiator for your company.

IT will be more comfortable knowing that they still manage passwords and can use policy-based management for easier change deployments of permission updates, group membership, and other functions. End users will appreciate – or at least not complain about – not having yet another login and password to remember (because everyone remembers their passwords, right?), and you’ll save a lot of time onsite if you can auto populate lists instead of hand entering data.

LDAP is a powerful tool – far more so than what can be covered in a blog entry (filters, aliases, referrals, etc.). Drop me a line if you have any questions – chances are I’ll be online looking for Joe Montana’s rookie card.