The Politics of Costs

Understanding and Deploying LDAP Directory Services > 9. Topology Design > Authentication in a Distributed Directory

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012006221255146158023153234

Authentication in a Distributed Directory

Handling 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:

  1. The directory client connects to Server 1 and authenticates.

  2. If the client's authentication credentials are successfully verified , Server 1 returns a success code to the client.

  3. The client submits a search operation to Server 1.

  4. Server 1 determines that it does not hold the appropriate partition, so it chains the operation to Server 2.

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:

  • Server 1 might tell Server 2 who the client is, and Server 2 might simply choose to believe Server 1. This requires that Server 2 trusts Server 1 to correctly verify authentication credentials.

  • Server 1 might pass on to Server 2 the client's identity and authentication credentials. Server 2 could then independently verify the credentials. This requires that Server 1 trust Server 2 not to misuse the authentication credentials (for example, if the credentials are a plaintext password, Server 2 must not reveal them to a third party).

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 Implications

Both 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 Partitioning

For 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:

  • The number of entries is too great for a single partition or server.

  • Your directory-enabled applications tend only to read and modify entries from the local workgroup.

  • The amount of replication traffic from a single partition is too great.

  • Partitioning allows data and update traffic to remain local and avoid spanning WAN links.

  • Directory use will expand significantly in the future, beyond the point where a single partition is feasible .

You should maintain your directory data in a single partition if the following are true:

  • All your directory entries fit easily within a single partition and server.

  • Your directory-enabled applications tend to read and modify entries across the whole enterprise.

  • Not much replication traffic is generated.

  • The entire organization is centrally located on a single high-speed network.

  • Directory size will remain fairly static, or you know that it will not exceed the capabilities of your software.

We will discuss these partitioning issues in more detail when we look at a sample design later in this chapter.



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing

<  BACK CONTINUE  >

Index terms contained in this section

authentication
          distributed 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.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net