Directory Services
Directory services can sometimes be an obscure endeavor if you have not delved into the guts of it.
I believe at times it can be confusing because people can misuse terms unintentionally.
On it's surface it is somewhat simple. If you dig a little deeper it can get quite complex.
There are multiple flavors of directory services as well and though they are similar they are not exactly the same. I have mostly worked with Microsoft's Active Directory directory service and it is what I am most familiar with. Anything discussed in this section will be specifically towards AD (Active Directory) because it is what I have used. It may or may not cross over to the other directory services. At its core though the principals are similar.
I like to think of directory services as being similar to a file structure or a SQL type database. If I recall at one point one of my friends at Microsoft mentioned that they were looking at porting AD directly into SQL but I don't know what ever became of that. When you look at it on the surface that is what it resembles.
It contains a schema which keeps track of the bits and pieces of the structure just like a database. Organizational units called OUs are similar to file folders. Similar to file folders that they can contain objects such as group objects, user objects, computer objects, etc. Are you catching the referal to objects? Each object is a specific object class and contains specific properties, just like a class object. These classes are defined within the schema. Does this sound familiar? It should. From a coding perspective it is very similar to classes in programming. (see page on classes) Classes
If you are planning on coding against directory services then it can be quite beneficial to look at the directory from a gui first because you get the feeling of how the directory is laid out. Though it is certainly possible to work with directory services from a coding perspective only, it is kind of like reaching into a dark closet without knowing what is in there and trying to grab a striped dress shirt. There are many programs that will give you a graphical representation of directory services. Microsoft's version is ADUC.
So how do you get data from directory services?
Well, it is quite easy actually and it is designed for that by offering a query language called LDAP. This is where I see directory services mislabled. Many people call it LDAP. It is not LDAP. LDAP is a lightweight protocol query language that allows you to interact with directory services. I will have another section on using LDAP queries which by the way can be fired from SQL in a Microsoft environment. (With limitations) By filtering your LDAP queries based on object classes you can filter the amount of work your query has to do so it is usually beneficial to use the object class when conducting queries. No sense in searching through a bunch of computre objects when you are looking for a group.Search Base If you think of the directory service as a file/tree structure while performing searches it can improve the time it takes to look for what you need. This can be good and bad, but in most cases good.
If your directory is structured where you have a root OU and then underneath it you have an OU for accounts, an OU for computers and an OU for groups you can start your search in the OU that contains the object classes you are looking for. Like the example above, there is no reason to search for a user account under the computer OU... it should not contain any users. This is where LDAP can be very efficient as long as everyone has stuck to the rules. If you start at the root, it will search all of them, waisting unnecessary resources. This is where I have seen people have problems because in one directory the OU for users may be named different. You need to know where you are searching to be able to do this because like in a file directory you cannot search for a file under Fred when there is only a directory called Barney. You can certainly start from the root if you are not sure, but again it is not as efficient. If you are returning values to a web page, time is money. I have seen large queries that can timeout a web interface. In a small directory this is not an issue but when you start working with hundreds of thousands of objects it can cause devistation to a web page.
Permissions
I have seen this as a major stumbling block for many coders. For you to be able to query against directory services you must be granted the ability to do so. In most cases, this is handled by a service account. This is a computer account within the directory that has permissions to perform LDAP queries. No ticky.. no laundry.
In the case of Microsoft's AD, this can also become tricky. AD domains (directories) are based on trusts. There is two way trusts, one way trusts, transitive trusts, etc. In a single directory trusts do not come in to play, but when you have multiple directories, or domains in the case of AD you can run into problems if you hitting one domain and trying to grab objects from another domain. I normally request to have a service account in every domain I may query and switch my connection accounts as I switch domains. This way trusts do not come into play. In the most simplest of examples, if you have domain A and domain B and you need to query both. If you have a service account in domain A and there is a two way trust, you can query both domain A and domain B. If domain B only trusts domain A and not vice-versa, your service account would have to be in domain B to query domain A. It can get confusing. If I have a service account in A and B.. each time I query either domain, I use the service account in the domain I am going to query. In Microsoft's case, this means that when you connect, you must include the domain in the account name. i.e. domain\serviceAccount. If you do not include the domain, this can get tricky leaving you to wonder which account actually had the permissions to do the query. When it works that is fine and does not matter, but when it fails it is harder to determine why it failed. I have seen it even grab the domain of the server you were making the query from and fail miserably.
LDAP vs LDAPS
In todays world, everything really must be secure. You do not really want unencrypted data floating across your network. This will depend on your circumstance of course and may depend on the data you are passing on the network. PCI data MUST be secure. You do not want to be the one who was passing SS numbers on the network in plain text. Another misconception in the case of Microsoft's AD is that using LDAP over LDAPS sends unencrypted data. This is not the case. If you are on a Microsoft server and connecting to a Microsoft directory services AD domain controller the data will be encrypted. The two servers will negotiate a secure protocol, I believe using a MS proprietory server protocol. You can use a packet capture to see this for yourself. Now if you are using a linux server to query a Microsoft domain controller then all bets are off and the data will not be encrypted across standard LDAP. Forcing LDAPS in a Microsoft environment can be a bit tricky because you will need to obtain certificates to allow the communication to proceed. I will try to add a section on secure communications but it is not my forte.
My first experience with Microsoft's Active Directory was circa the year 2000 and I have been coding against it every since. It has not changed much in those 18 years which to me is a great thing! I will try to explain in simple terms how to get things that you are looking for, display them, etc. Hopefully you can get something out of it.
ABitOWhit
There are multiple flavors of directory services as well and though they are similar they are not exactly the same. I have mostly worked with Microsoft's Active Directory directory service and it is what I am most familiar with. Anything discussed in this section will be specifically towards AD (Active Directory) because it is what I have used. It may or may not cross over to the other directory services. At its core though the principals are similar.
I like to think of directory services as being similar to a file structure or a SQL type database. If I recall at one point one of my friends at Microsoft mentioned that they were looking at porting AD directly into SQL but I don't know what ever became of that. When you look at it on the surface that is what it resembles.
It contains a schema which keeps track of the bits and pieces of the structure just like a database. Organizational units called OUs are similar to file folders. Similar to file folders that they can contain objects such as group objects, user objects, computer objects, etc. Are you catching the referal to objects? Each object is a specific object class and contains specific properties, just like a class object. These classes are defined within the schema. Does this sound familiar? It should. From a coding perspective it is very similar to classes in programming. (see page on classes) Classes
If you are planning on coding against directory services then it can be quite beneficial to look at the directory from a gui first because you get the feeling of how the directory is laid out. Though it is certainly possible to work with directory services from a coding perspective only, it is kind of like reaching into a dark closet without knowing what is in there and trying to grab a striped dress shirt. There are many programs that will give you a graphical representation of directory services. Microsoft's version is ADUC.
So how do you get data from directory services?
Well, it is quite easy actually and it is designed for that by offering a query language called LDAP. This is where I see directory services mislabled. Many people call it LDAP. It is not LDAP. LDAP is a lightweight protocol query language that allows you to interact with directory services. I will have another section on using LDAP queries which by the way can be fired from SQL in a Microsoft environment. (With limitations) By filtering your LDAP queries based on object classes you can filter the amount of work your query has to do so it is usually beneficial to use the object class when conducting queries. No sense in searching through a bunch of computre objects when you are looking for a group.Search Base If you think of the directory service as a file/tree structure while performing searches it can improve the time it takes to look for what you need. This can be good and bad, but in most cases good.
If your directory is structured where you have a root OU and then underneath it you have an OU for accounts, an OU for computers and an OU for groups you can start your search in the OU that contains the object classes you are looking for. Like the example above, there is no reason to search for a user account under the computer OU... it should not contain any users. This is where LDAP can be very efficient as long as everyone has stuck to the rules. If you start at the root, it will search all of them, waisting unnecessary resources. This is where I have seen people have problems because in one directory the OU for users may be named different. You need to know where you are searching to be able to do this because like in a file directory you cannot search for a file under Fred when there is only a directory called Barney. You can certainly start from the root if you are not sure, but again it is not as efficient. If you are returning values to a web page, time is money. I have seen large queries that can timeout a web interface. In a small directory this is not an issue but when you start working with hundreds of thousands of objects it can cause devistation to a web page.
Permissions
I have seen this as a major stumbling block for many coders. For you to be able to query against directory services you must be granted the ability to do so. In most cases, this is handled by a service account. This is a computer account within the directory that has permissions to perform LDAP queries. No ticky.. no laundry.
In the case of Microsoft's AD, this can also become tricky. AD domains (directories) are based on trusts. There is two way trusts, one way trusts, transitive trusts, etc. In a single directory trusts do not come in to play, but when you have multiple directories, or domains in the case of AD you can run into problems if you hitting one domain and trying to grab objects from another domain. I normally request to have a service account in every domain I may query and switch my connection accounts as I switch domains. This way trusts do not come into play. In the most simplest of examples, if you have domain A and domain B and you need to query both. If you have a service account in domain A and there is a two way trust, you can query both domain A and domain B. If domain B only trusts domain A and not vice-versa, your service account would have to be in domain B to query domain A. It can get confusing. If I have a service account in A and B.. each time I query either domain, I use the service account in the domain I am going to query. In Microsoft's case, this means that when you connect, you must include the domain in the account name. i.e. domain\serviceAccount. If you do not include the domain, this can get tricky leaving you to wonder which account actually had the permissions to do the query. When it works that is fine and does not matter, but when it fails it is harder to determine why it failed. I have seen it even grab the domain of the server you were making the query from and fail miserably.
LDAP vs LDAPS
In todays world, everything really must be secure. You do not really want unencrypted data floating across your network. This will depend on your circumstance of course and may depend on the data you are passing on the network. PCI data MUST be secure. You do not want to be the one who was passing SS numbers on the network in plain text. Another misconception in the case of Microsoft's AD is that using LDAP over LDAPS sends unencrypted data. This is not the case. If you are on a Microsoft server and connecting to a Microsoft directory services AD domain controller the data will be encrypted. The two servers will negotiate a secure protocol, I believe using a MS proprietory server protocol. You can use a packet capture to see this for yourself. Now if you are using a linux server to query a Microsoft domain controller then all bets are off and the data will not be encrypted across standard LDAP. Forcing LDAPS in a Microsoft environment can be a bit tricky because you will need to obtain certificates to allow the communication to proceed. I will try to add a section on secure communications but it is not my forte.
My first experience with Microsoft's Active Directory was circa the year 2000 and I have been coding against it every since. It has not changed much in those 18 years which to me is a great thing! I will try to explain in simple terms how to get things that you are looking for, display them, etc. Hopefully you can get something out of it.
ABitOWhit
- Log in to post comments
