What is LDAP
LDAP is a strange term. People use it to mean a directory. But technically it is not a directory, but a language or communication protocol to talk to a directory. There are a number of LDAP compliant directories. These would include Microsoft Active Directory, NetIQ (formerly Novell) eDirectory, and SunOne Directory to name a few. A number of SQL databases have an LDAP interface that is available if you want to use them for a directory as well. Many email systems will have an LDAP interface to their directory as well. Most identity management tools have an LDAP driver or connector to be able to link into LDAP directories if they don't have a native connector to the particular directory.
So what does an LDAP (compliant) directory actually look like? Well first and foremost they are a hierarchical directory. This means that they have a tree structure akin to that found on a computer file system. There is a root or base of the tree. Then there are branches below that root to hold the information. At the most basic level there are two types of objects in a directory. There are containers and there are leaf objects.
A container is just as it sounds, something that holds something else. It is similar to a folder or subfolder in a file system. Each directory has a slightly different feel for what you will see at the very top of the tree. With SunOne directory and Active Directory you will regularly see the top of the tree linked to DNS and the containers will be listed as dc= for the container type. The dc stands for domain component. If you are using eDirectory the most common container type will be organization and be expressed as o=, although some implementations will start with country which will be c=. Once you get into the deeper part of the tree the main container is the organizational unit. It is expressed as ou=. Just as folders in a file system can hold other folders containers in LDAP directories can hold other containers.
A leaf object is the directory version of a file. It is a bit different than a file in that it can be a user, a group, a printer object, or any other type of object. The name of the object is it's cn or common name. It could be the users name, a group name, or the name of the printer. Unlike a file system, a directory string starts with the leaf object and goes from left to right with the top of the tree expressed at the right side of the expression. So in eDirectory you might see something like cn=bob,ou=accounting,ou=finance,o=supercompany in an ldap query. In Active Directory cn=bob,ou=accounting,ou=finance,dc=supercompany,dc=com might be the listing for a user. LDAP uses commas to separate the different parts of the string.
So what does an LDAP (compliant) directory actually look like? Well first and foremost they are a hierarchical directory. This means that they have a tree structure akin to that found on a computer file system. There is a root or base of the tree. Then there are branches below that root to hold the information. At the most basic level there are two types of objects in a directory. There are containers and there are leaf objects.
A container is just as it sounds, something that holds something else. It is similar to a folder or subfolder in a file system. Each directory has a slightly different feel for what you will see at the very top of the tree. With SunOne directory and Active Directory you will regularly see the top of the tree linked to DNS and the containers will be listed as dc= for the container type. The dc stands for domain component. If you are using eDirectory the most common container type will be organization and be expressed as o=, although some implementations will start with country which will be c=. Once you get into the deeper part of the tree the main container is the organizational unit. It is expressed as ou=. Just as folders in a file system can hold other folders containers in LDAP directories can hold other containers.
A leaf object is the directory version of a file. It is a bit different than a file in that it can be a user, a group, a printer object, or any other type of object. The name of the object is it's cn or common name. It could be the users name, a group name, or the name of the printer. Unlike a file system, a directory string starts with the leaf object and goes from left to right with the top of the tree expressed at the right side of the expression. So in eDirectory you might see something like cn=bob,ou=accounting,ou=finance,o=supercompany in an ldap query. In Active Directory cn=bob,ou=accounting,ou=finance,dc=supercompany,dc=com might be the listing for a user. LDAP uses commas to separate the different parts of the string.
Attributes and classes
So a directory is made up of containers and leaf objects. But what makes one container or leaf object different than another? Well it is the attributes of the object. And those attributes are defined by the object classes that are assigned to the object. An object class is an attribute container. It can be thought of in general as a grouping. Let's think about Bob a minute and use life as an analogy. So Bob is a human. So he would be object class human. Bob is also a father. So he would also be object class parent. Bob might belong to a bowling league. Thus he would be in object class bowling. Each of these classes would have attributes that are unique to them that would help define who Bob is. As a human he would have a first name and last name. He would have a father and a mother. He would have a sex. He would have a hair color. Each of these are attributes of being human. As a parent he would have at least one child. The child would have a name. The child would have a sex. These would be attributes of his role as a parent. In the bowling league he has a team he plays on. He might be the captain. He has a handicap. These would be his bowling attributes. Interestingly in all of this object class is both the attribute container and an attribute called objectclass. So Bob's objectclass attribute would be a listing of all the object classes that pertain to Bob.
As you might have noticed attributes are things that describe an object. In an LDAP directory each object has a set of object classes that it is part of, and so it can then have the attributes associated with those object classes populated with information to describe it. Sometimes an object class stands on it's own. Sometimes it has a parent object class that it will inherit attributes from. If it inherits attributes then anyone associated with that object class can have the attributes both of the class and it's parent class defined. Often object classes will have at least one or two attributes that are required to be populated. For example for a user object class the cn is required because you must have a name to refer to that user. Often at least the surname or sn is required. When a user is created those attributes must be defined at creation or the system won't let the object get created. The other attributes are optional.
When attributes are defined they have a particular structure that is assigned them. First, they might be single value or multi value. A single value attribute can only hold one value at a time. It is similar to a basic variable in programming. A multi value attribute can hold multiple values. A multi value attribute is basically like an array in programing. Actually if you query the directory and ask for the information in a multi value attribute the directory returns it as an array, even if there is only a single value in the directory. Some attributes might surprise you that they are multi valued. For example, description often is multi valued. You can have multiple lines for description. Each line can be really long. And each line is returned as one element of the array. One that is even more surprising is cn as a multi valued attribute. You can actually assign multiple cn names to a single object. This one tripped me up when I was first programming against LDAP. It is very unusual to see more than one value in cn on an object, but it is most definitely possible.
Another thing about the attribute definition is that they will be a particular data type. If you program this will make a lot of sense. By and large the attributes will be created as case insensitive strings. But you can have case sensitive strings. You can also have boolean types where it is either a true or false. There are other types too. The data type is defined at the time you create the attribute in the directory. Some directories will also have other features like maybe immediate sync that you can define too.
Defining attributes brings up the topic of schema. A directory will have a schema that holds all the information about what object classes and attributes are used in the directory. There will be a base schema defined when the directory is installed. From there often you will need to extend the schema to handle your particular needs. How a schema is extended varies from one directory to another and is out of the scope of this discussion. One thing is true that for the most part once you extend the schema you cannot go back. So you best think it through. The one exception of this typically is aux classes. Some directories will let you get rid of an aux class from a directory. You do need to make sure that no objects in the directory have that as one of their object classes though. So my advice is to think it through before you extend the schema.
When you search the directory for an object the directory by default will return all the attributes you have rights to see. Well it will return all the attributes you have a right to see that are populated. This is something I regularly see people get confused about. An object class might have say 20 different attributes as part of it. But you might have a user that only 5 of the attributes have had values assigned to them. So the directory will only return those 5 attributes. The others are all null, and so you will not see them in the return at all. At first people think those attributes are not even available to the user. What it really means is that particular attribute simply has never had a value assigned. LDAP is pretty efficient that way. You won't even get the label of the attribute in the return. You might have two users returned and one might have email in the list and the other does not have that at all. It simply means no one ever entered the email address for that user. They could add it. It is an available attribute. It is simply null at the moment. Also, if you search on say the mail attribute it is only going to return the name of those objects that actually have some value in that attribute. Say you set the search filter to "email=*" when you search. It will return all objects that have something in the email attribute. It will not return objects that could have an email but don't. Oh, you can even search for all objects of a particular object class. So if you do "objectclass=organizationalunit" it will show all the organizational units in the tree below where you start the search.
One final thing on this LDAP overview. There are a few attributes that are called system attributes. Often they won't show up in the return of an LDAP query. If you use something like Softerra LDAP Browser or Apache Directory Studio you will need to set an option to return the system attributes. And if you are using the command line ldap search you will need to specify the system attributes to return them. These are attributes that are read only that the system uses line createtimestamp, modifytimestamp, and logintime. They are very useful, especially from a security standpoint. For example you can use modifytimestamp and logintime to identify possible stale accounts that got left behind after a person left the organization and are potential security holes.
As you might have noticed attributes are things that describe an object. In an LDAP directory each object has a set of object classes that it is part of, and so it can then have the attributes associated with those object classes populated with information to describe it. Sometimes an object class stands on it's own. Sometimes it has a parent object class that it will inherit attributes from. If it inherits attributes then anyone associated with that object class can have the attributes both of the class and it's parent class defined. Often object classes will have at least one or two attributes that are required to be populated. For example for a user object class the cn is required because you must have a name to refer to that user. Often at least the surname or sn is required. When a user is created those attributes must be defined at creation or the system won't let the object get created. The other attributes are optional.
When attributes are defined they have a particular structure that is assigned them. First, they might be single value or multi value. A single value attribute can only hold one value at a time. It is similar to a basic variable in programming. A multi value attribute can hold multiple values. A multi value attribute is basically like an array in programing. Actually if you query the directory and ask for the information in a multi value attribute the directory returns it as an array, even if there is only a single value in the directory. Some attributes might surprise you that they are multi valued. For example, description often is multi valued. You can have multiple lines for description. Each line can be really long. And each line is returned as one element of the array. One that is even more surprising is cn as a multi valued attribute. You can actually assign multiple cn names to a single object. This one tripped me up when I was first programming against LDAP. It is very unusual to see more than one value in cn on an object, but it is most definitely possible.
Another thing about the attribute definition is that they will be a particular data type. If you program this will make a lot of sense. By and large the attributes will be created as case insensitive strings. But you can have case sensitive strings. You can also have boolean types where it is either a true or false. There are other types too. The data type is defined at the time you create the attribute in the directory. Some directories will also have other features like maybe immediate sync that you can define too.
Defining attributes brings up the topic of schema. A directory will have a schema that holds all the information about what object classes and attributes are used in the directory. There will be a base schema defined when the directory is installed. From there often you will need to extend the schema to handle your particular needs. How a schema is extended varies from one directory to another and is out of the scope of this discussion. One thing is true that for the most part once you extend the schema you cannot go back. So you best think it through. The one exception of this typically is aux classes. Some directories will let you get rid of an aux class from a directory. You do need to make sure that no objects in the directory have that as one of their object classes though. So my advice is to think it through before you extend the schema.
When you search the directory for an object the directory by default will return all the attributes you have rights to see. Well it will return all the attributes you have a right to see that are populated. This is something I regularly see people get confused about. An object class might have say 20 different attributes as part of it. But you might have a user that only 5 of the attributes have had values assigned to them. So the directory will only return those 5 attributes. The others are all null, and so you will not see them in the return at all. At first people think those attributes are not even available to the user. What it really means is that particular attribute simply has never had a value assigned. LDAP is pretty efficient that way. You won't even get the label of the attribute in the return. You might have two users returned and one might have email in the list and the other does not have that at all. It simply means no one ever entered the email address for that user. They could add it. It is an available attribute. It is simply null at the moment. Also, if you search on say the mail attribute it is only going to return the name of those objects that actually have some value in that attribute. Say you set the search filter to "email=*" when you search. It will return all objects that have something in the email attribute. It will not return objects that could have an email but don't. Oh, you can even search for all objects of a particular object class. So if you do "objectclass=organizationalunit" it will show all the organizational units in the tree below where you start the search.
One final thing on this LDAP overview. There are a few attributes that are called system attributes. Often they won't show up in the return of an LDAP query. If you use something like Softerra LDAP Browser or Apache Directory Studio you will need to set an option to return the system attributes. And if you are using the command line ldap search you will need to specify the system attributes to return them. These are attributes that are read only that the system uses line createtimestamp, modifytimestamp, and logintime. They are very useful, especially from a security standpoint. For example you can use modifytimestamp and logintime to identify possible stale accounts that got left behind after a person left the organization and are potential security holes.
Home |
About |
Services |
Copyright © 2016