|
| |
| Sun Java System Directory Proxy Server 5 2004Q2 Administration Guide | |
Chapter 2
Directory Proxy Server Deployment ScenariosThere are several ways you may want to deploy Directory Proxy Server, depending on your computing environment. This chapter describes and illustrates typical deployments, including:
An Internal High Availability ConfigurationIn the configuration shown in Figure 2-1, the customer has deployed an LDAP infrastructure for internal enterprise use only. There is no requirement for external network access to any of the enterprise LDAP services. The customer has deployed an enterprise firewall that will reject any access to internal LDAP services originating from outside the firewall. All client LDAP requests initiated internally must still go through Directory Proxy Server via the Cisco Local Director (for high availability), which is shown here only as an example of IP packet switching that ensures clients have access to at least one Directory Proxy Server. The customer prevents direct access to the directory servers by everyone except the hosts running Directory Proxy Servers; this can be achieved by using firewalls to protect the hosts running the directory server and Directory Proxy Server.
Figure 2-1 Internal High Availability Configuration
Distributed LDAP Directory InfrastructureThe following sections explain the role of Directory Proxy Server in a distributed LDAP directory infrastructure:
Customer Scenario
In the configuration shown in Figure 2-2, a large financial institution is headquartered in London with data centers in London, New York, and Hong Kong. Currently, the vast majority of the data available to employees resides centrally in legacy RDBMS repositories in London. All access to this data from the financial institution's client community is via the Wide Area Network (WAN). The financial institution is experiencing scalability and performance problems with this centralized model and has decided to move to a distributed data model. The financial institution has also decided to deploy an LDAP directory infrastructure at the same time. The data in question is considered "mission critical" and should therefore be deployed in a highly available, fault tolerant infrastructure. An analysis of client application profiles has revealed that 95 percent of data accessed by a geographical client community is specific to that community since the data is customer based. It is rare for a client in Asia to access data for a customer in North America but it does happen infrequently. The client community also has a need to update customer information from time to time.
Figure 2-2 A Distributed LDAP Directory Infrastructure
Customer Deployment
Given the profile of 95 percent local data access, the financial institution decided to distribute its LDAP directory infrastructure geographically. It deployed multiple directory consumer servers in each geographical location (i.e., Hong Kong, New York, and London; London consumer servers are not shown in the diagram). Each of these consumer servers is configured to hold the customer data specific to the location. Data for European and Middle East customers is held in the London consumer servers, data for North and South American customers is held in the New York consumer servers, and data for Asian and Pacific Rim customers is held in the Hong Kong consumer servers. With this deployment, the overwhelming data requirement of the local client community is located in the community. This provides significant performance improvements over the centralized model since client requests are processed locally, thereby reducing the network overhead; the local directory servers are effectively partitioning the directory infrastructure, thereby providing increased directory server performance and scalability. Each set of consumer directory servers is configured to return referrals if a client submits an update request or if a client submits a search request for data located elsewhere.
LDAP Request Flow
Client LDAP requests are sent to the Directory Proxy Server via the Cisco LocalDirector. The LocalDirector product is shown here only as an example of IP packet switching that ensures clients always have access to at least one Directory Proxy Server. The locally deployed Directory Proxy Server initially routes all requests to the array of local directory servers holding the local customer data. The instances of Directory Proxy Server are configured to load balance across the array of directory servers, thereby providing automatic failover and failback. Client search requests for local customer information are satisfied by a local directory and appropriate responses returned to the client via Directory Proxy Server. Client search requests for geographically "foreign" customer information are initially satisfied by the local directory server by returning a referral back to Directory Proxy Server.
This referral contains an LDAP URL that points to the appropriate geographically distributed Directory Proxy Server instance. The local Directory Proxy Server processes the referral on behalf of the local client and sends the search request to the appropriate distributed instance of Directory Proxy Server. The distributed Directory Proxy Server forwards the search request on to the distributed directory server and receives the appropriate response. This response is then returned to the local client via the distributed and the local instances of Directory Proxy Server.
Update requests received by the local Directory Proxy Server are also satisfied initially by a referral returned by the local directory server. Again, Directory Proxy Server follows the referral on behalf of the local client but this time forwards the update request onto the supplier directory server located in London. The supplier directory server applies the update to the supplier database and sends a response back to the local client via the local Directory Proxy Server. Subsequently, the supplier directory server will propagate the update down to the appropriate consumer directory servers.
All the Directory Proxy Servers are configured to start up and look for their configuration in the supplier directory server. This allows you to distribute multiple instances of Directory Proxy Server geographically but manage their configurations centrally.
A Centralized LDAP Directory InfrastructureThe following sections explain the role of Directory Proxy Server in a centralized LDAP directory infrastructure:
Customer Scenario
Figure 2-3 depicts a large global enterprise, with customers and employees distributed throughout the world, that wanted to deploy a corporate white and yellow pages (electronic phone book) to reduce the cost of printing a paper phone book, to increase the accuracy of the corporate information, and to reduce the use of environmental resources. The white and yellow pages information had to be available to both customers and employees with appropriate access controls. They also had to be available 24x7 and were classified as mission critical due to customers and employees being distributed throughout the world across all time zones.
Figure 2-3 A Centralized LDAP Directory Infrastructure
Customer Deployment
The global enterprise decided to deploy a centralized LDAP directory infrastructure to support the deployment of the white and yellow pages. A centralized deployment was chosen in this instance because the white and yellow pages are for corporate employee information only. This was not to be a customer database although the intent was for customers to have access to some of the information. It was decided that the projected size of the directory database (~200,000 entries) was not sufficient to require a more complex distributed deployment model since neither scalability nor performance were anticipated to be a problem.
Since there was a high availability requirement, the enterprise decided to deploy multiple consumer directory server replicas supplied by a single supplier directory server. To remove the single point of failure introduced by a single supplier directory server, the enterprise deployed a backup supplier directory server.
Directory Proxy Servers were deployed for three different reasons. First, to provide the load balancing and automatic failover and failback between all LDAP clients and the array of directory server replicas. Second, to be able to differentiate between external and internal clients and to set appropriate access controls accordingly. Third, to provide compatibility between the LDAP clients using the white and yellow pages and the directory servers themselves. In addition to utilizing a custom-built white and yellow pages application, the LDAP clients also used a number of off-the-shelf LDAP enabled applications that came with fixed schema requirements. These schema requirements did not always match the directory schema designed by the enterprise, therefore requiring some basic schema attribute mapping. In addition, not all the LDAP enabled applications used by the clients were capable of processing referrals received from the directory servers correctly. The Directory Proxy Servers were configured to follow these referrals on behalf of the clients.
LDAP Request Flow
All client requests, whether from internal or external clients and whether search requests or update requests, are sent to instances of Directory Proxy Server via the Cisco LocalDirector. The LocalDirector product is shown here only as an example of IP packet switching that ensures clients always have access to at least one Directory Proxy Server. Multiple instances of Directory Proxy Server are deployed to ensure there is no single point of failure. The instances of Directory Proxy Server load balance all the requests received from the clients across all the consumer directory servers in the array. Directory Proxy Server will also detect the failure of any of the consumer servers and failover to the available consumer servers in the array.
Since consumer servers are read-only replicas, they are configured to return an LDAP referral when an update request is received from a client. This referral contains an LDAP URL pointing to the supplier directory server. When the directory server returns the referral, the Directory Proxy Server recognizes it and follows the referral on behalf of the client. It binds to the supplier directory server and sends the update request to it. The supplier directory server applies the update to the supplier database and sends a response back to the client via Directory Proxy Server. Subsequently, the supplier directory server will propagate the update down to the appropriate consumer directory servers.
Search requests sent by clients get routed via the Directory Proxy Servers to the array of consumer directory server replicas. Directory Proxy Servers can be configured to "inspect" these search requests before sending them on to the directory servers and filter out any requests that don't meet the access control and security rules configured for a particular client group and perform any necessary mappings. Directory Proxy Server can also be configured to "inspect" the search result returned by the directory server and again perform appropriate filtering and mapping. In the example shown in Figure 2-3, both internal and external clients have requested a search for the entry belonging to "Trevor." These inbound requests are treated identically by Directory Proxy Server irrespective of the client type. The directory server executes the request successfully and returns the entry for "Trevor" back to the Directory Proxy Server. Directory Proxy Server has been configured to manipulate the search result differently depending on whether the original request came from an internal or external client. In the case of the external client, both the mobile phone number and the home phone number fields in the entry are filtered out since they are deemed to be data inappropriate for customers. Note also that the ou: development attribute/value pair has been mapped to department: development. This is necessary because one of the applications the client is using to access the directory (e.g., Outlook, Outlook Express) has fixed schema elements that do not match the schema elements deployed in the enterprise directory servers. In the case of the internal client it was determined that the mobile phone number was an important data element to share among employees whereas the home phone number was not. So for internal clients, Directory Proxy Server is configured to filter out only the home phone number and to permit the client to see the mobile phone number. Note the same mapping of the ou attribute to the department attribute is also performed.
All Directory Proxy Servers are configured to start up and look for their configuration in the supplier directory server. This allows for the management of multiple Directory Proxy Server configurations centrally from a directory.
Deploying Directory Proxy Server With a Single FirewallYour organization's firewall must be configured like that shown in Figure 2-4 to allow only LDAP clients to access the machine and port on which the Directory Proxy Server is running. Typically, LDAP clients will connect on TCP port 389. This will protect the host running Directory Proxy Server from clients who may try to gain unauthorized access to it. Also, placing the host running the proxy server on its own LAN, by using the router switch, will protect your internal network from denial of service attacks such as flooding your network with unnecessary traffic. The firewall should also disallow LDAP access to the machine(s) and port(s) on which the LDAP directory server(s) are "hiding," thereby protecting the LDAP directory database(s).
Figure 2-4 Directory Proxy Server Setup With One Firewall
Deploying Directory Proxy Server With Two FirewallsThe configuration shown in Figure 2-5 has all the benefits of the configuration shown in Figure 2-4 with some additional security. Installing two firewalls creates a zone of control around the "proxies," allowing the site administrator to rate limit traffic from the external networks. It also ensures that a compromise of one of the "proxy" servers cannot be used directly to attack other machines in the interior network. Firewall A would be configured to allow only incoming packets if the destination IP address is that of the proxy handling that TCP or UDP protocol. Firewall B would be configured to allow only packets from the proxy machines that are appropriate to the servers that the proxy needs to access.
Figure 2-5 Directory Proxy Server Setup With Two Firewalls
