< Zurück | Inhalt | Weiter >

21.3.2 Common Directory Services

Now that you have seen the concepts, we can cover a few common implemen- tations of naming and directory services. Domain Name Service (DNS)

This is probably the most familiar naming and directory system. It is used all the time to resolve Internet host names to IP addresses, and it is commonly used to obtain the names of mail servers for domains. It also has less often used

features to look up arbitrary data for domains. These features are not used often because standard DNS has no authentication and authorization controls. Information in DNS is, inherently, public information. Filesystems

The UNIX filesystems, NTFS, FAT, and other filesystems provide name-to- data mappings that are compatible with JNDI. When they are combined with networked filesystems, such as SMB, CIFS, NFS, and even rsync and FTP, files can be made available over the network through JNDI. LDAP

LDAP is the “Lightweight Directory Access Protocol.” There is an old joke that a platypus is a swan put together by a committee. If that is so, then it often seems that LDAP is the platypus of name and directory services.

To be fair, LDAP has the heavy burden that goes with any standards that are produced by a large committee-driven process. It has to try to be all things to all people. LDAP is a query and transport protocol specification of the ISO X.500 naming and directory service standard.4 Like other ISO and ANSI standards, the specification is robust to the point of uselessness. LDAP is de- signed to allow every possible name system in the Universe to be subsumed into a single, uniquely addressable Directory Information Tree. Every entry in LDAP has a distinguished name, which is an unambiguous specification of the name from the root of the tree. So far, this is like the other naming systems. There is a root, there are nodes at each layer, and then, at the bottom, there is data. What makes X.500 and LDAP different is that each node consists of not just a name, but of a type/name pair. An example of an LDAP name might be:

url=http://www.multitool.net/,cn=M. Schwarz,o=MAS Consulting,st=MN,c=us


4. If you are dying to know, X.500 is a naming and directory services standard from the Inter- national Standards Organization (ISO), an international technical standards body. X.500 has a transport and query protocol specification of its own, but it uses the ISO OSI (Open Systems Interconnection) network protocol standard. OSI is rarely used because TCP/IP took off first and has been hacked and hacked again to keep it alive and well. At one time, it looked like IP address space limitations would push the world to OSI protocols, but hacks like CIDR, private subnets, and now the (less hackish) IPv6 make it look like TCP/IP will be here for quite a while. In a sense, then, LDAP is X.500 over TCP/IP. Or, to put it another way, LDAP is a TCP/IP implementation of ISO X.500.

At each node there is a type (c, cn, url, and so on) and a name (or value) for that type. The definitions of these types and the lists of types permitted at a particular level depend on a schema which is controlled by whoever controls the server that serves the given level of the hierarchy. In other words, as with DNS, if you want to be part of the public, global namespace, you have to play by the rules of the ancestor nodes. You can do what you want with your point of control and below, but you must obey the naming schema of all of your ancestors.5

This explains why so few organizations actually use LDAP globally (i.e., integrating directly with all other public LDAP servers in the world). In- stead, they tend to use LDAP by setting up schema and servers that are com- pletely internal and private so that they do not have to use the many required parent nodes it would take to hook up to the global LDAP namespace.6

LDAP can (and does) fill books of its own. The type/name pairs are bulky to type and hard to remember, but they allow you to easily map in entire other naming systems, by simply assigning a type to a naming system and allowing that system’s names to be values at that level. Remember that these names are hierarchical, so everything under cn (normally used for “common name”) ap- plies to (in this case) Michael Schwarz. If I defined the schema for my space, I could put anything I wanted under that name.

A common use of LDAP is for centralizing authentication and authoriza- tion data for users. Users authenticate to LDAP and all systems in an organiza- tion can validate a single credential to authenticate the user—the holy grail of single sign-in. Alas, doing this right is nontrivial because LDAP doesn’t specify any mandatory authentication and encryption scheme. (Thus it is often the hacker’s holy grail of single sniff-in and 0wn3d systems.)


5. We want to be clear: You only have to do this if you wish to give those ancestors and outside users access to your directories. You are free to create entirely private directory structures that need not conform to anyone else’s schema. It all depends on the purpose and audience of your directory.

6. Another reason is that LDAP itself has no cryptographically secure authentication or trans- port mechanisms. That means that hooking up all your directory data to the global Internet gives hackers a one-stop opportunity to steal your data. Not good. Of course, as with other protocols, there are several add-on security mechanisms for LDAP. Novell Directory Service (NDS)

Novell, the folks behind Netware, came up with NDS, which provides full di- rectory services like LDAP/X.500, but (according to the computer press—let us confess right now that we have never directly used NDS or Microsoft’s Ac- tive Directory) with a simpler API and easier administration. We don’t know enough about it to comment on it. But we do know that JNDI can access it. Microsoft’s Active Directory

We have to do the same hand-waving here. Active Directory provides similar functionality to NDS and LDAP. We don’t know enough about it to comment on it. But, again, JNDI can talk to it.