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.

The following steps describe how authentication is performed in chained environments such as that depicted in Figure 10.10.

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

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

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

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

Figure 10.10. Authentication in a Chained Topology

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:

1. Server 1 might tell Server 2 who the client is, and Server 2 might simply choose to believe Server 1. This approach requires that Server 2 trust Server 1 to verify authentication credentials correctly. This is the approach used by Netscape Directory Server 6 when it makes use of the LDAPv3 Proxied Authorization control.

2. Server 1 might pass to Server 2 the client's identity and authentication credentials. Server 2 could then independently verify the credentials. This approach requires that Server 1 trust Server 2 not to misuse the authentication credentials (for example, if the credentials consist of a plaintext password, Server 2 must not reveal it 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), the operation can proceed. This is, in fact, how X.500 servers handle authentication in a distributed environment, and it is how Netscape Directory Server 6 handles authentication when configured to chain operations.

On the other hand, if 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 Novell eDirectory servers operate (all eDirectory authentication is handled with digital signatures).

Microsoft Active Directory uses a variant of this technique. User credentials based on Kerberos v5 accompany directory operations submitted by clients. These credentials can be verified by any server in the domain, and they can be verified by servers outside the domain if explicit trust relationships are established between domains.

Note

For certificate-based client authentication to work in a distributed directory, all servers must trust a 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. Such discrepancies can lead to end-user confusion.

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 prearranged 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 Netscape Directory Server 6, and the bind DN is not held in any of the server's directory partitions, the server attempts to locate and contact the server that does hold the entry. If it can locate that server, it verifies the credentials by binding to that server using the credentials supplied by the client.

Security Implications

Both methods of combining directory partitions ”client-side and server-side knowledge reference processing ”require some careful thought about security. When you construct a distributed directory using client-side processing, take precautions to ensure that you have absolute control over the referrals contained in your directory. In addition, allow referrals and search result continuation references only to directories you trust.

Such caution is important because some directory clients may choose to automatically resubmit any referred operations and authenticate to the server to which they were referred. 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.

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. Administrators of Active Directory also need to be concerned with the trustworthiness of a domain's administrators before establishing a trust relationship.

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 setup 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. In an extranet environment, however, you might choose to relax this restriction and accept certificates from your trading partners ' certification authorities, assuming that you trust them, or from an independent certification authority such as VeriSign.

As with all other 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 can be found in Chapter 12, Privacy and Security Design.