Understanding and Deploying LDAP Directory Services > 9. Topology Design > Authentication in a Distributed Directory |
Authentication in a Distributed DirectoryHandling authentication of directory clients in a distributed directory presents some challenges. The server or servers that ultimately handle a client request must verify the identity of the client so that they can enforce access control restrictions. This is true even if the server handling the request is not the server to which the client originally authenticated. For example, consider what happens when a directory client connects and authenticates to a server and then submits a search operation chained to another server (see Figure 9.11). Figure 9.11 Authentication in a chained topology.The following steps describe how authentication is performed in a chained environment:
For Server 2 to enforce access control while performing the search operation, it needs to know the identity of the client. There are two ways it might learn this information:
In a chained environment, the chaining server (Server 1) can pass along the identity of the client when it chains the operation. If the server it chains to (Server 2) trusts the other server (presumably because the chaining server authenticated to Server 2, and the server is on a list of trusted servers), the operation can proceed. This is, in fact, how X.500 servers handle authentication in a distributed environment if the client uses simple authentication. If, on the other hand, the client has authenticated to Server 1 using certificate-based client authentication, Server 1 can just pass along the digitally signed request and allow Server 2 to verify the client's identity directly because the digital signature contains the identity of the client. This is how X.500 servers operate when certificate-based client authentication is used. This is also how NDS servers operate (all NDS authentication is handled with digital signatures). In a directory distributed via referrals, the client resubmits its request to each server it is referred to during the course of processing an operation. Therefore, each server it refers to authenticates the client directly. This means that no pre-arranged trust relationships need to be established between servers. If simple authentication is used, the server referred to will likely need to verify the client's password by contacting another server because it's unlikely to contain the actual entry corresponding to the client identity. For example, if a client submits a bind operation to the Netscape Directory Server, and the bind DN is not held in any of the server's naming contexts, the server attempts to locate and contact the server that does hold the entry. If it can locate the server, it verifies the credentials by binding to that server using the credentials supplied by the client. Note In order for certificate-based client authentication to work in a distributed directory, all servers must trust some common set of certification authorities. If this is not the case, it's possible for one server to successfully authenticate a client while another server rejects the client's credentials during chaining or following referrals. This can lead to end- user confusion. Security ImplicationsBoth methods of combining directory partitions ”chaining and referral ”require some careful thought about security. When you construct a distributed directory using referrals, you should take precautions to ensure that you have absolute control over the referrals contained in your directory. Additionally, you should allow referrals only to directories you trust. This is important because some directory clients may choose to automatically resubmit any referred operations and authenticate to the referred-to server using the same credentials that were used when authenticating to the original server. This means that if a rogue referral were placed in a directory, the directory clients might be tricked into resubmitting their authentication credentials to the rogue server. If the authentication method in use does not preclude a replay attack (for example, if the authentication credentials are in the clear), the rogue server can record the credentials and use them to masquerade as the client. To prevent this possibility, you should ensure that the ability to place a ref attribute in the directory is limited to a set of people you trust so that rogue referrals cannot end up in the directory. In addition, consider using an authentication method impervious to replay attack, such as public-key cryptography or Kerberos. With these authentication systems, even if a rogue server happens to capture a client's authentication credentials, those credentials cannot be used indefinitely to masquerade as the client. When you construct a distributed directory using chaining, you must use caution when establishing any trust relationships between servers.You should trust only remote servers under your direct control or run by organizations you trust. In both types of environments, if you are using certificate-based client authentication, you should trust only digital signatures signed by a trusted certification authority. This requires that you trust that certification authority to issue certificates only to persons who have adequately proven their identity. Usually, this means that you trust only those certificates granted by your in-house certification authority. But in an extranet environment, you might choose to relax this restriction and accept certificates from your trading partners ' certification authorities, assuming you trust them or an independent certification authority such as VeriSign. As with all complex distributed systems, designing a secure directory requires careful thought and planning. It's always useful to think like a "bad guy" and imagine ways you might compromise the security of the system you're designing. More information on directory security may be found in Chapter 11, "Privacy and Security Design." Advantages and Disadvantages of PartitioningFor many smaller directory deployments, it is perfectly reasonable to keep all your directory data in one partition. This generally results in better search performance because a single server can provide the data requested by the client without requiring that other servers be contacted. If you have only a few thousand entries in your directory, there is probably no benefit to partitioning regardless of the type of server software you are using. Even larger partitions (sometimes as big as millions of entries) are supported by certain server software. Consult your server documentation to determine the largest number of entries that is reasonable to place in a single partition. If the number of entries stored in your directory significantly exceeds the number that can be practically stored in a single partition, you should split your directory into multiple partitions. Otherwise, try to limit your directory to one or just a few partitions. Another reason to maintain a single large partition has to do with the types of directory-enabled applications you are using. Some applications tend to search the entire directory namespace repeatedly; these types of applications perform best if they have to search only one server to obtain the data they need. For example, the Netscape Messaging Server, when delivering electronic mail, must look up the recipient's email address in the directory to determine routing information. It's quite likely that the entire directory namespace of your enterprise must be searched to perform this function. If your directory is split into a very large number of partitions, this can have a significant negative impact on the performance of such a directory-enabled application. If your directory services these types of applications, try to limit the number of directory partitions or point these applications to a server that aggregates all the partitions into a single location. We describe this configuration in more detail in the design example later in this chapter. Another factor to consider is the amount of replication traffic required to service your replicated servers. If your directory services a large number of write operations and sends updates to many replica servers (a replica server holds a copy of a partition), the amount of replication traffic may be a significant burden on each server. By partitioning your directory, you reduce the number of entries contained within each server and therefore reduce the amount of update traffic that any given server must generate. Of course, the total amount of update traffic on your network is still the same; each server simply needs to handle less of it. You may also want to partition your directory if your physical network topology includes many slower WAN links and partitioning the directory enables you to place partitions close to the applications and users that use the data in that partition. For example, if you are running Novell's IntranetWare and NDS, it often makes sense to construct a namespace that reflects the physical WAN structure of the company and assign partitions to servers located in each location. When users log in to NDS, their login preferences and scripts are retrieved from the directory. If the partition is assigned to a server located with its users and traffic does not need to span a WAN link, performance is improved. If, on the other hand, your organization's network is well-connected ”perhaps if all links are T1 or faster ”there isn't much to be gained from this type of approach. These are only general guidelines, and you need to examine your network layout and application needs carefully . Finally, if you know that your directory will expand significantly in the future and exceed one of the limitations, it may be best to partition the directory sufficiently to accommodate the growth without having to redesign your partitioning scheme. Although it is certainly possible to split and combine partitions, this is generally a time-consuming task. Avoid it if you can. Following is a summary of the factors to examine when deciding whether to partition your directory. You should consider partitioning your directory if the following are true:
You should maintain your directory data in a single partition if the following are true:
We will discuss these partitioning issues in more detail when we look at a sample design later in this chapter.
|
Index terms contained in this sectionauthenticationdistributed directories 2nd chained environments 2nd 3rd partitioning 2nd 3rd 4th 5th 6th 7th 8th security issues 2nd 3rd via referrals 2nd chaining authentication 2nd 3rd security issues 2nd 3rd design topologies authentication 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th directories topologies authentication 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th distibuted directories topologies authentication 2nd 3rd 4th 5th 6th 7th distributed directories topologies authentication 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th expansion limitations partitioning issues partitioning distributed directories 2nd 3rd 4th 5th expansion limitations replication traffic 2nd ref attribute security issues referrals authentication 2nd security issues 2nd 3rd replication traffic partitioning issues 2nd security authentication distributed directories 2nd 3rd 4th 5th 6th 7th 8th 9th 10th topologies authentication 2nd chained environments 2nd 3rd partitioning 2nd 3rd 4th 5th 6th 7th 8th security issues 2nd 3rd via referrals 2nd traffic replication partitioning issues 2nd |
2002, O'Reilly & Associates, Inc. |