This schema defines the types of mailboxes and mail−access protocols to use (IMAP, POP3
and so on).
Interacting with the Database
It is rare for an application to deal with an LDAP database on the protocol level. However, there is also a real lack of standard interfaces that you can use to interact at the language−independent API level, such as relational databases offer with JDBC/ODBC and SQL. Of course, this lack is the result of the fundamental difference between LDAP, which is a protocol definition, and SQL, which is a language definition. Although we introduce JNDI in the next chapter, in this one we have a difficult time formulating a generic description of how to interact with an LDAP server.
The closest thing that LDAP has to a standard interface is a set of command−line tools for addition, deletion, and viewing the database: ldapadd, ldapremove, and ldapsearch, respectively. All of the concepts we introduce in this section will discuss how to interact with an LDAP database in terms of these tools.
Connecting to the database
Connecting to an LDAP database should not involve any tricks that you are not already familiar with. Just as with any good enterprise service, you need to (usually) supply a user name and password to access the database as well as supplying the host and port to talk to.
Typically that user name is required to be in an LDAP style, consisting of a name−value pair. In every case that we're aware of, the attribute name is cn followed by the value of the user name. The host and port are the usual domain name and port number — the default port number for LDAP is 389.
Searching an LDAP database
Searching an LDAP database is the most common task you will perform. A search is just like an SQL
SELECT — you name the table to look in (which branch of the directory tree), what you want to find (the name of the entry), and a filter to return only parts of the matching rows (attributes within the matching entry(s)).
Branch selection to narrow the search
Although it is not required, because you are always in the same tree, setting the branch of the tree to search in is a good idea. Unlike SQL, because we have a single hierarchy tree, there is no requirement to set the branch to search in — it is always the same tree. However, for efficiency reasons, it is a good idea to try to limit the 165
Chapter 8: Working with Directory Services and LDAP
scope as much as possible. Say you are looking up a customer name: You do not need to search through all the product and order areas, so you might as well confine your search to the customer area. Now, since you know that you've organized the customer area by domain name, and you have the domain name from the user's login, you can further restrict your search by setting the DN for the search criteria to be the area defined by that e−mail address. Say you wanted to look up Justin Couch. You can set the search DN to be the following:
dc=vlc,dc=com,c=au,ou=customers,o=ExampleApp
Now, when you want to look up Couch's user information, that search criteria has just limited the number of possible solutions from a million to maybe a thousand. Your search command on the command line starts with the following (note that it is supposed to be on a single line!): ldapsearch –b "dc=vlc,dc=com,c=au,ou=customers,o=ExampleApp"
But you cannot run this command as is, because you have not told it what you are looking for yet.
Setting the search criteria
To set the search criteria for that branch, you supply the name or names of the attribute(s) you are using as the key, and then supply the value you are looking for. You can also supply a wildcard (*) character if you want all the values that match a given attribute name.
So if you want to do a search for all users whose first name is Justin, you can set the search criteria to the following:
ldapsearch "sn=justin"