10.2. Design Example: A Multinational Enterprise and Its Extranet

This example builds a directory infrastructure for Example Corp. International. The Example Corp. from the previous example has grown into a large, multinational company. This example builds on the directory structure created in the last example for Example Corp., expanding the directory design to meet its new needs.
Example Corp. has grown into an organization dispersed over three main geographic locations: the US, Europe, and Asia. Example Corp. now has more than 20,000 employees, all of whom live and work in the countries where the Example Corp. offices are located. Example Corp. decides to launch a company-wide LDAP directory to improve internal communication, to make it easier to develop and deploy web applications, and to increase security and privacy.
Designing a directory tree for an international corporation involves determining how to collect directory entries logically, how to support data management, and how to support replication on a global scale.
In addition, Example Corp. wants to create an extranet for use by its parts suppliers and trading partners. An extranet is an extension of an enterprise's intranet to external clients.
The following sections describe the steps in the process of deploying a multinational directory service and extranet for Example Corp. International.

10.2.1. Multinational Enterprise Data Design

Example Corp. International creates a deployment team to perform a site survey. The deployment team determines the following from the site survey:
  • A messaging server is used to provide email routing, delivery, and reading services for most of Example Corp.'s sites. An enterprise server provides document publishing services. All servers run on Red Hat Enterprise Linux 7.
  • Example Corp. needs to allow data to be managed locally. For example, the European site will be responsible for managing the Europe branch of the directory. This also means that Europe will be responsible for the master copy of its data.
  • Because of the geographic distribution of Example Corp.'s offices, the directory needs to be available to users and applications 24 hours a day.
  • Many of the data elements need to accommodate data values of several different languages.

    Note

    All data use the UTF-8 characterset; any other characterset violates LDAP standards.
The deployment team also determines the following about the data design of the extranet:
  • Parts suppliers need to log in to Example Corp.'s directory to manage their contracts with Example Corp. Parts suppliers depend on data elements used for authentication, such as name and user password.
  • Example Corp.'s partners will use the directory to look up contact details of people in the partner network, such as email addresses and phone numbers.

10.2.2. Multinational Enterprise Schema Design

Example Corp. builds upon its original schema design by adding schema elements to support the extranet. Example Corp. adds two new objects, the exampleSupplier object class and the examplePartner object class.
The exampleSupplier object class allows one attribute, the exampleSupplierID attribute. This attribute contains the unique ID assigned by Example Corp. International to each automobile parts supplier with which it works.
The examplePartner object class allows one attribute, the examplePartnerID attribute. This attribute contains the unique ID assigned by Example Corp. International to each trade partner.
For information about customizing the default directory schema, see Section 3.4, “Customizing the Schema”.

10.2.3. Multinational Enterprise Directory Tree Design

Based on the expanded requirements, Example Corp. creates the following directory tree:
  • The root of the directory tree is the dc=com suffix. Under this suffix, Example Corp. creates two branches. One branch, dc=exampleCorp,dc=com, contains data internal to Example Corp. International. The other branch, dc=exampleNet,dc=com, contains data for the extranet.
  • The directory tree for the intranet (under dc=exampleCorp,dc=com) has three main branches, each corresponding to one of the regions where Example Corp. has offices. These branches are identified using the l (locality) attribute.
  • Each main branch under dc=exampleCorp,dc=com mimics the original directory tree design of Example Corp. Under each locality, Example Corp. creates an ou=people, an ou=groups, an ou=roles, and an ou=resources branch. See Figure 10.1, “Directory Tree for Example Corp.” for more information about this directory tree design.
  • Under the dc=exampleNet,dc=com branch, Example Corp. creates three branches. One branch for suppliers (o=suppliers), one branch for partners (o=partners), and one branch for groups (ou=groups).
  • The ou=groups branch of the extranet contains entries for the administrators of the extranet as well as for mailing lists that partners subscribe to for up-to-date information on automobile parts manufacturing.
The following diagram illustrates the basic directory tree resulting from the design steps listed above:
Basic Directory Tree for Example Corp. International

Figure 10.6. Basic Directory Tree for Example Corp. International

The following diagram illustrates the directory tree for the Example Corp. intranet:
Directory Tree for Example Corp. International's Intranet

Figure 10.7. Directory Tree for Example Corp. International's Intranet

The entry for the l=Asia entry appears in LDIF as follows: 
dn: l=Asia,dc=exampleCorp,dc=com

objectclass: top

objectclass: locality

l: Asia

description: includes all sites in Asia
The following diagram illustrates the directory tree for Example Corp.'s extranet:
Directory Tree for Example Corp. International's Extranet

Figure 10.8. Directory Tree for Example Corp. International's Extranet

10.2.4. Multinational Enterprise Topology Design

At this point, Example Corp. designs its database and server topologies. The following sections describe each topology in more detail.

10.2.4.1. Database Topology

The following diagram illustrates the database topology of one of Example Corp.'s main localities, Europe:
Database Topology for Example Corp. Europe

Figure 10.9. Database Topology for Example Corp. Europe

The database links point to databases stored locally in each country. For example, operation requests received by the Example Corp. Europe server for the data under the l=US branch are chained by a database link to a database on a server in Austin, Texas. For more information about database links and chaining, see Section 6.3.2, “Using Chaining”.
The master copy of the data for dc=exampleCorp,dc=com and the root entry, dc=com, is stored in the l=Europe database.
The data center in Europe contains the master copies of the data for the extranet. The extranet data is stored in three databases, one for each of the main branches. The master copy of the data for o=suppliers is stored in database one (DB1), that for o=partners is stored in database two (DB2), and that for ou=groups is stored in database three (DB3).
The database topology for the extranet is illustrated below:
Database Topology for Example Corp. International's Extranet

Figure 10.10. Database Topology for Example Corp. International's Extranet

10.2.4.2. Server Topology

Example Corp. develops two server topologies, one for the corporate intranet and one for the partner extranet.
For the intranet, Example Corp. decides to have a master database for each major locality. This means it has three data centers, each containing two supplier servers, two hub servers, and three consumer servers.
The following diagram illustrates the architecture of Example Corp. Europe's data center:
Server Topology for Example Corp. Europe

Figure 10.11. Server Topology for Example Corp. Europe

The data master for Example Corp.'s extranet is in Europe. This data is replicated to two consumer servers in the US data center and two consumer servers in the Asia data center. Overall, Example Corp. requires ten servers to support the extranet.
The following diagram illustrates the server architecture of Example Corp.'s extranet in the European data center:
Server Topology for Example Corp. International's Extranet

Figure 10.12. Server Topology for Example Corp. International's Extranet

The hub servers replicate data to two consumer servers in each of the data centers in Europe, the US and Asia.

10.2.5. Multinational Enterprise Replication Design

Example Corp. considers the following points when designing replication for its directory:
  • Data will be managed locally.
  • The quality of network connections varies from site to site.
  • Database links will be used to connect data on remote servers.
  • Hub servers that contain read-only copies of the data will be used to replicate data to consumer servers.
The hub servers are located near important directory-enabled applications such as a mail server or a web server.
Hub servers remove the burden of replication from the supplier servers, so the supplier servers can focus on write operations. In the future, as Example Corp. expands and needs to add more consumer servers, the additional consumers do not affect the performance of the supplier servers.
For more information on hub servers, see Section 7.2.3, “Cascading Replication”.

10.2.5.1. Supplier Architecture

For the Example Corp. intranet, each locality stores the master copy of its data and uses database links to chain to the data of other localities. For the master copy of its data, each locality uses a multi-master replication architecture.
The following diagram illustrates the supplier architecture for Europe, which includes the dc=exampleCorp,dc=com and dc=com information:
Supplier Architecture for Example Corp. Europe

Figure 10.13. Supplier Architecture for Example Corp. Europe

Each locality contains two suppliers, which share master copies of the data for that site. Each locality is therefore responsible for the master copy of its own data. Using a multi-master architecture ensures the availability of the data and helps balance the workload managed by each supplier server.
To reduce the risk of total failure, Example Corp. uses multiple read-write supplier Directory Servers at each site.
The following diagram illustrates the interaction between the two supplier servers in Europe and the two supplier servers in the US:
Multi-Master Replication Design for Example Corp. Europe and Example Corp. US

Figure 10.14. Multi-Master Replication Design for Example Corp. Europe and Example Corp. US

The same relationship exists between Example Corp. US and Example Corp. Asia, and between Example Corp. Europe and Example Corp. Asia.

10.2.6. Multinational Enterprise Security Design

Example Corp. International builds upon its previous security design, adding the following access controls to support its new multinational intranet:
  • Example Corp. adds general ACIs to the root of the intranet, creating more restrictive ACIs in each country and the branches beneath each country.
  • Example Corp. decides to use macro ACIs to minimize the number of ACIs in the directory.
    Example Corp. uses a macro to represent a DN in the target or bind rule portion of the ACI. When the directory gets an incoming LDAP operation, the ACI macros are matched against the resource targeted by the LDAP operation. If there is a match, the macro is replaced by the value of the DN of the targeted resource.
    For more information about macro ACIs, see the Red Hat Directory Server Administrator's Guide.
Example Corp. adds the following access controls to support its extranet:
  • Example Corp. decides to use certificate-based authentication for all extranet activities. When people log in to the extranet, they need a digital certificate. The directory is used to store the certificates. Because the directory stores the certificates, users can send encrypted email by looking up public keys stored in the directory.
  • Example Corp. creates an ACI that forbids anonymous access to the extranet. This protects the extranet from denial of service attacks.
  • Example Corp. wants updates to the directory data to come only from an Example Corp. hosted application. This means that partners and suppliers using the extranet can only use the tools provided by Example Corp. Restricting extranet users to Example Corp.'s preferred tools allows Example Corp. administrators to use the audit logs to track the use of the directory and limits the types of problems that can be introduced by extranet users outside of Example Corp. International.