Chapter 4. Designing the directory tree
You can see the data stored with Directory Server by using the directory tree. The design of the directory tree is based on the types of information stored in the directory, the physical nature of the enterprise, the applications used with the directory, and the types of replication implemented.
4.1. Introduction to the directory tree
You can name the directory data and refer to a client application by using the directory tree. The directory tree can interact with other design decisions, including the choices available for distributing, replicating or controlling access to the directory data. You can design the directory tree before deployment which can save time and effort both during the deployment phase and later when the directory service is in operation.
With a well-designed directory tree, you can:
- Simply maintain the directory data.
- Flexibly create replication policies and access controls.
- Support the applications using the directory service.
- Simplify directory navigation for users.
The structure of the directory tree follows the hierarchical LDAP model. A directory tree provides a way to organize the data in different logical ways, such as by group, personnel, or place. You can also determine how to partition data across multiple servers by using the directory tree. For example, each database needs data to be partitioned at the suffix level. You cannot spread the data across multiple servers efficiently without the proper directory tree structure.
In addition, replication is constrained by the type of directory tree structure used. When you want to replicate only portions of the directory tree, take that into account during the design process.
4.2. Designing a directory tree
When you plan the directory tree, you make the following major decisions:
- You choose a suffix to contain the data.
- You determine the hierarchical relationship among data entries by creating the directory tree structure.
- You name the entries in the directory tree hierarchy.
4.2.1. Choosing the suffix
A suffix is the name of the entry at the root of the directory tree, and the directory data is stored beneath it. The directory can contain more than one suffix. You can use multiple suffixes if there are two or more directory trees of information that do not have a natural common root. By default, the standard Directory Server deployment contains multiple suffixes, one for storing data and the others for data required by internal directory operations, such as configuration information and the directory schema.
Conventions for naming suffix
You should locate all entries in the directory in a common base entry, the root suffix. When you choose a name for the root directory suffix, to make the name effective it must be:
- Globally unique
- Static
- Short, so that you can read the entries beneath it easily
- Easy, for a person to type and remember
In a single enterprise environment, you can choose a directory suffix that aligns with a DNS name or Internet domain name of the enterprise. For example, if the enterprise owns the domain name of example.com, then the directory suffix is dc=example,dc=com. The dc attribute represents the suffix by breaking the domain name into its component parts. Normally, you can use any attribute to name the root suffix. However, for a hosting organization, you must limit the root suffix to the following attributes:
dc- Defines a component of the domain name.
c- Contains the two-digit code representing the country name, as defined by ISO.
l- Identifies the county, city, or other geographical area where the entry is located or that is associated with the entry.
st- Identifies the state or province where the entry is located.
o- Identifies the name of the organization to which the entry belongs.
These attributes provide interoperability with subscriber applications. For example, a hosting organization can use these attributes to create a root suffix o=example_a, st=Washington,c=US for one of its clients example_a.
Using an organization name followed by a country designation is typical according to the X.500 naming convention for suffixes.
Naming multiple suffixes
Each suffix in a directory is a unique directory tree. You can create multiple directory trees stored in separate databases Directory Server serves.
For example, you can create separate suffixes for example_a and example_b and store them in separate databases.
You can store databases on a single server or multiple servers depending on resources limits.
4.2.2. Creating the directory tree structure
Decide whether to use a flat or a hierarchical tree structure. Try to make the directory tree as flat as possible. However, a certain amount of hierarchy can be important later when information is partitioned across multiple databases, when preparing replication, or when setting access controls.
The structure of the tree involves the following steps and considerations:
- Branching the directory
- Identifying branch points
- Replication considerations
- Access control considerations
4.2.2.1. Branching the directory
The namespace must be as flat as possible to avoid problematic name changes. The more hierarchical the directory tree, the more components in the names, and the more likely the names are to change.
Use the following guidelines for designing the directory tree hierarchy:
- Branch the tree to represent only the largest organizational sub-divisions in the enterprise. You should limit branch points to divisions, such as Corporate Information Services, Customer Support, Sales, and Engineering. Make sure that the divisions used to branch the directory tree are stable. Do not perform this kind of branching if the enterprise reorganizes frequently.
-
Use functional or generic names rather than actual organizational names for the branch points. When you rename sub-trees, if suffixes have many children, the name change process is resource-intensive and long. For example, use
Engineeringinstead ofWidget Research and Development. -
If you have multiple organizations that perform similar function, try creating a single branch point for that function. For example, even if there are multiple marketing organizations, each of which is responsible for a specific product line, create a single
ou=Marketingsub-tree. All marketing entries then belong to that tree.
Branching in an enterprise environment
You can avoid name changes if you plan the directory tree structure based on information that is not likely to change. For example, if you base the structure on types of objects in the tree rather than organizations.
Use the following common objects to define the structure:
-
ou=people -
ou=groups -
ou=contracts -
ou=services
The following diagram presents a directory tree organized by using these objects:
Branching in a hosting environment
For a hosting environment, create a tree that contains two entries of the object class organization (o) and one entry of the object class organizationalUnit (ou) beneath the root suffix. For example, internet service provider named Example ISP branches their directory the following way:
4.2.2.2. Identifying branch points
When planning the branches in the directory tree, decide what attributes to use to identify the branch points. A branch point is an attribute-data pair, such as ou=people, l=Japan, cn=Barbara Jansen or another. Remember that a DN is a unique string composed of these attribute-data pairs. For example, the DN of an entry for Barbara Jensen, an employee of Example Company, will be as follows:
uid=bjensen,ou=people,dc=example,dc=com.
See the example of a directory tree for Example Company that has ou=people, ou=groups, cn=Barbara Jensen, cn=Billie Holiday branch points in the following diagram:
See the example of a directory tree for an internet provider Example ISP in the following diagram:
Beneath the root suffix entry o=example,c=US the tree is split into three branches. The o=ISP branch contains customer data and internal information for Example ISP. The o=internet branch is the domain tree. The ou=groups branch contains information about the administrative groups.
Consider the following recommendation when choosing attributes for the branch points:
Be consistent.
Some LDAP client applications may not find the distinguished name (DN) if the DN format is inconsistent across the directory tree. If
ouis underoin one part of the directory tree, then make sureouis underoin all other parts of the directory service.Try to use only the traditional attributes.
When you use traditional attributes, it increases the likelihood that Directory Server is compatible with third-party LDAP client applications. Using the traditional attributes also means that the default directory schema knows them.
| Traditional attribute | Description |
|---|---|
|
|
An element of the domain name, such as |
|
| A country name. |
|
| An organization name. Used this attribute to represent a large divisional branching such as a corporate division, academic discipline (the humanities, the sciences), subsidiary, or other major branching within the enterprise. You can use this attribute to represent a domain name. |
|
| An organizational unit. Used this attribute to represent a smaller divisional branching of the enterprise than an organization. Organizational units are generally subordinate to the preceding organization. |
|
| A state or province name. |
|
| A locality, such as a city, country, office, or facility name. |
A common mistake is to assume that the directory is searched based on the attributes used in the distinguished name. The distinguished name is only a unique identifier for the directory entry and cannot be used as a search key. Instead, search for entries based on the attribute-data pairs stored on the entry itself. Thus, if the distinguished name of an entry is uid=bjensen,ou=People,dc=example,dc=com, then a search for dc=example does not match that entry unless dc:example has explicitly been added as an attribute in that entry.
4.2.2.3. Replication considerations
Plan which entries you want to replicate. You can specify the DN at the top of a subtree and replicate all entries below it. This subtree also corresponds to a database, a directory part that contains a portion of the directory data.
For example, in an enterprise environment, you can organize the directory tree so that it corresponds to the network names in the enterprise. Network names tend not to change, so the directory tree structure is stable.
For example, the Example Company has three primary networks known as flightdeck.example.com, tickets.example.com, and hangar.example.com. The company initially branches its directory tree into three main groups for their major organizational divisions. See the initial branching of the directory tree in the following picture:
After creating the initial structure of the tree, the company creates additional branches. See extended branching in the following picture:
In another example, the internet provider Example ISP has the following initial branching to meet the provider needs:
Later, Example ISP creates additional branches for logical subgroups. See extended branching in the following picture:
Both the enterprise Example Company and the hosting organization Example ISP design their data hierarchies based on information that do not change often.
4.2.2.4. Access control considerations
You can use a hierarchy in the directory tree to enable certain types of access control. As with replication, it is easier to group similar entries and then administer them from a single branch.
You can administer through a hierarchical directory tree. For example, to give an administrator from the marketing department access to the marketing entries and an administrator from the sales department access to the sales entries, design the directory tree according to those divisions.
In addition, you can set access control based on the directory content rather than the directory tree. With the access control instruction (ACI) mechanism, you can allow a particular entry to have access to all entries that contain a particular attribute value. For example, set an ACI that gives the sales administrator access to all the entries that contain the attribute value ou=Sales.
However, ACIs can be difficult to manage. Decide the best method of access control: organizational branching in the directory tree hierarchy, ACIs, or a combination of the two.
4.2.3. Naming entries
You need to decide which attributes to use when naming the entries within the structure after designing the hierarchy of the directory tree. When you choose one or several attribute values, you form a relative distinguished name (RDN). The RDN is the left-most part of a DN, and the attribute you choose for that part is the naming attribute. The naming attribute sets a unique name for the entry. For example, the DN uid=bjensen,ou=people,dc=example,dc=com has the RDN uid=bjensen.
The attributes you choose depend on the type of entry you are naming.
Consider the following when naming entries:
- You should not change the attribute selected for naming.
- The name must be unique across the directory. A unique name ensures that a DN refers to only one entry in the directory.
When you create entries, define the RDN within the entry. With the defined RDN within the entry, the entry can be located more easily. This is because searches look for entries based on attribute values stored in the entry itself and not based on the actual DN.
Attribute names have a meaning, so try to use the attribute name that matches the type of entry it represents. For example, do not use l (location) to represent an organization, or c (country) to represent an organizational unit.
4.2.3.1. Naming the person entries in the directory tree
The person entry name must be unique. Usually, to name person entries, you use the commonName, or cn, attribute to form a relative distinguished name (RDN). For example, an entry for a person named Babs Jensen may have the distinguished name (DN) as cn=Babs Jensen,dc=example,dc=com.
Note that using only common names in RDNs may not be enough to make the entry name unique and several identical entries may be created leading to DN name collisions.
Avoid common name collisions by adding a unique identifier to the common name, such as cn=Babs Jensen+employeeNumber=23,dc=example,dc=com. However, this can lead to awkward common names for large directories and can be difficult to maintain.
A better method is to identify the person entries with some attribute other than cn. Consider using one of the following attributes:
- uid
-
Use the
uidattribute to specify some unique value of the person, such as a user login ID or an employee number. Identify a subscriber in a hosting environment by theuidattribute. -
The
mailattribute contains a person email address that is always unique. This attribute can lead to awkward DNs that include duplicate attribute values, such asmail=bjensen@example.com,dc=example,dc=com. Use this option only if you can not find some unique value for theuidattribute. For example, use themailattribute instead of theuidattribute if the enterprise does not assign employee numbers or user IDs for temporary or contract employees. - employeeNumber
-
For employees of the
inetOrgPersonobject class, use theemployeeNumberattribute.
Whatever you use for an attribute-data pair for person entry RDNs, make sure that they are unique, permanent values. Person entry RDNs should also be readable. For example, the DN uid=bjensen,dc=example,dc=com is more preferable than uid=b12r56A,dc=example,dc=com and it simplifies some directory tasks, such as changing directory entries based on their distinguished names. Also, some directory client applications assume that the uid and cn attributes use human-readable names.
Considerations for person entries in a hosted environment
If a person is a subscriber to a service, the entry should have inetUser object class and contain the uid attribute. The attribute must be unique within a customer subtree.
If a person is a part of the hosting organization, use the inetOrgPerson attribute with the nsManagedPerson object class.
Placing person entries in the directory tree
Use the following guidelines for placing person entries in the directory tree:
- Locate people in an enterprise below the organization entry in the directory tree.
-
Locate subscribers to a hosting organization below the
ou=peoplebranch for the hosted organization.
4.2.3.2. Naming group entries in the directory tree
You can use the following ways to represent a group:
A static group explicitly defines its members. The
groupOfNamesorgroupOfUniqueNamesobject classes contain values that name the members of the group. Static groups are suitable for groups with few members, such as the group of directory administrators, and not suitable for groups with thousands of members.Static group entries must contain a
uniqueMemberattribute value becauseuniqueMemberis a mandatory attribute of thegroupOfUniqueNamesobject. This object class requires thecnattribute, which you can use to form the DN of the group entry.- A dynamic group specifies a filter, and all entries that match the filter are members of the this group.
- Roles unify the static and dynamic group concept.
In a hosted environment, consider using the groupOfUniqueNames object class to contain the values naming the members of groups used in directory administration.
Also, locate group entries that you use for directory administration under the ou=Groups branch.
Additional resources
4.2.3.3. Naming organization entries
The organization entry name must be unique. When you use the legal name of the organization with other attribute values it helps to ensure the name is unique, such as o=example_a+st=Washington,o=ISP,c=US.
You can also use trademarks, however they may not be unique.
In a hosting environment, include the following attributes in the organization entry:
-
o(organizationName) -
objectClasswith values oftop,organization, andnsManagedDomain
4.2.3.4. Naming other entries
The directory contains entries that represent different information, such as localities, states, countries, devices, servers, network information, and other data types. Use the cn attribute in the RDN for these types of entries. You can also name a group entry as cn=administrators,dc=example,dc=com.
Sometimes an entry object class does not support the commonName attribute. Instead, use an attribute that the entry object class supports. The naming attributes do not have to correspond to the attributes you actually use in the entry. However, administration of the directory tree is easier if you have some correlation between the DN attributes and attributes used in the entry.
4.2.4. Renaming entries and subtrees
The entry names define the directory tree structure. Each branch point creates a new link in the hierarchy.
dc=example,dc=com => root suffix
ou=People,dc=example,dc=com => org unit
st=California,ou=People,dc=example,dc=com => state/province
l=Mountain View,st=California,ou=People,dc=example,dc=com => city
ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com => org unit
uid=jsmith,ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com => leaf entry
When you change the naming attribute of an entry, the entry RDN, you perform a modrdn operation. This modifying operation moves the entry within the directory tree. For leaf entries (entries with no children), modrdn operations change only an RDN part, the parent entries stay the same.
For subtree entries, the modrdn operation renames the subtree entry itself and also changes the DN components of all of the children entries under the subtree.
Subtree modrdn operations also move and rename all of the child entries under the subtree entry. For large subtrees, this can be a time and resource-intensive process. Plan the naming structure of your directory tree hierarchy so that it will not require frequent subtree rename operations.
A similar action to renaming a subtree is moving an entry from one subtree to another. This expanded type of modrdn operation simultaneously renames the entry, even if it is the same name, and sets a newsuperior attribute that moves the entry from one parent to another.
Directory Server uses entryrdn.db index to perform new superior and subtree rename operations. Directory Server identifies each entry by a self link, parent link, and any children links. The entryrdn.db index presents parents and children as attributes to an entry and describes every entry by a unique ID and its RDN, rather than the full DN.
The entryrdn.db index has the following format:
numeric_id:RDN => self link ID: ; RDN: "rdn"; NRDN: normalized_rdn P:RDN => parent link ID: ; RDN: "rdn"; NRDN: normalized_rdn C:RDN => child link ID: #; RDN: "rdn"; NRDN: normalized_rdn
For example, the ou=people subtree has the dc=example,dc=com parent and the uid=jsmith child entries. The entryrdn.db index has the following content:
4:ou=people ID: 4; RDN: "ou=people"; NRDN: "ou=people" P4:ou=people ID: 1; RDN: "dc=example,dc=com"; NRDN: "dc=example,dc=com" C4:ou=people ID: 10; RDN: "uid=jsmith"; NRDN: "uid=jsmith"
Consider the following when you perform rename operations:
- You cannot rename the root suffix.
- You do not need to reconfigure a replication agreement. Directory Server applies replication agreements to an entire database, not a subtree within the database.
- You may need to reconfigure all synchronization agreements after subtree rename operations. Sync agreements are set at the suffix or subtree level, so renaming a subtree may break synchronization.
- You need to reconfigure manually all subtree-level ACIs set for the subtree and all entry-level ACIs set for child entries of the subtree.
- You can rename a subtree with children, but you cannot delete a subtree with children.
-
When you try to change the component of a subtree, like moving from
outodc, it may fail with a schema violation. For example, theorganizationalUnitobject class requires theouattribute. The subtree operation fails if the operation tries to removeouattribute from theorganizationalUnitobject class.
4.3. Grouping directory entries
To simplify directory administration, group entries that you created. Directory Server supports the following ways to group entries methods:
- Groups
- Roles
4.3.1. About groups in Directory Server
A group is a collection of users. Directory Server has several group types that reflect the type of memberships allowed, such as certificate groups, URL groups, and unique groups that have only unique members. You define each type of group by an object class, such as groupOfUniqueNames, and a corresponding member attribute, such as uniqueMember.
The type of group identifies the type of members. The group configuration depends on how Directory Server adds members to the group. Directory Server has two group types:
- Static groups
- A static group has a finite and defined list of members. You add members manually to the group entry.
- Dynamic groups
- A dynamic group uses filters to add members to the group. Thus, the number of members constantly changes because the number of entries that match the group filter changes.
Groups do not perform any operation on entries, however LDAP clients can manage groups to perform operations.
4.3.1.1. Listing group membership in user entries
Groups are lists of user DNs. By default, only group entries contain membership information and user entries do not contain this information.
The MemberOf plug-in uses the group member entries to update user entries dynamically and reflect to which groups the user belongs. The plug-in automatically scans group entries with a specified member attribute, traces back all of the user DNs, and creates a corresponding memberOf attribute in the user entry with the name of the group.
The name of every group to which a user belongs is listed as a memberOf attribute and you can manage the values of memberOf attributes.
By default, the MemberOf plug-in only searches for potential members within users that Directory Server stores in the same database as a group. If Directory Server stores users and the group in different databases, then the MemberOf plug-in does not update user entries because the plug-in can not define the relationship between users and the group.
Enable memberOfAllBackends attributes to configure the MemberOf plug-in to search through all configured databases.
You can configure a single instance of the MemberOf plug-in to manage multiple types of groups by setting the multi-valued memberofgroupattr in the plug-in entry.
4.3.1.2. Adding automatically new entries to groups
You can apply password policies, access control lists, and other rules based on group membership. With groups, you can apply policies consistently and reliably across the directory.
Automatically assigning new entries to groups when a new entry is created ensures that Directory Server immediately applies appropriate policies and functionality to those entries without administrator actions.
With the Automembership plug-in, a static group can act like a dynamic group. The Automembership plug-in uses a set of rules based on entry attributes, directory location, and regular expressions to assign a user automatically to a specified group.
There can be instances where the entries that match the LDAP search filter should be added to different groups depending on the value of other attributes. For example, you need to add machines to different groups depending on their IP address or physical location. Or you need to place users to different groups depending on their employee ID number.
Automember definitions are a set of nested entries, with the Auto Membership plug-in container, then the automember definition, and then any regular expression conditions for that definition.
Directory Server assigns entries to a group automatically only when entries are newly added to Directory Server. For existing entries or entries that you modified to meet an automember rule, run the fix-up task to assign the proper group membership.
4.3.2. About roles in Directory Server
Roles behave as both a static and a dynamic group. With a group, Directory Server adds entries to a group entry as members. With a role, Directory Server adds the role attribute to an entry and then uses that attribute to identify members in the role entry automatically.
With roles, you can organize users in the following ways:
- Explicitly list role members. When you view a role, you can see the complete list of members for this role. You can query the role to check membership which is not possible with a dynamic group.
-
View to which roles an entry belongs. When you view an entry, you can see the roles to which the entry belongs because Directory Server determines role membership by an attribute in the entry. It is similar to the
memberOfattributes for groups, the only difference is that you do not need to enable or configure a plug-in instance for this functionality to work. - Assign the appropriate roles. Directory Server assigns role membership through an entry, not through a role. Thus, you can easily assign and remove the roles to which a user belongs by editing the entry, in a single step.
Managed roles can do everything that you can do with static groups. You can filter the role members by using filtered roles, similar to the filtering with dynamic groups. Roles are easier to use than groups because they are more flexible in their implementation and reduce client complexity.
You can specify members explicitly or dynamically by using role types. Directory Server supports the following types of roles:
- Managed roles
- Managed roles have an explicit list of members.
- Filtered roles
- Directory Server assigns entries to a filtered role if the entry has a specific attribute defined in the role. The role definition specifies an LDAP filter for the target attributes. Entries that match the filter possess (are members of) the role.
- Nested roles
- Nested roles are roles that contain other roles.
You can activate or inactivate entire groups of entries in just one operation. You can temporarily disable the members of a role by inactivating the role to which they belong.
When you inactivate a role, a user still can bind to the server by using a role entry. However, the user cannot bind to the server by using any of the entries that belong to this role. Entries that belong to an inactivated role have the nsAccountLock attribute set to true.
When you inactivate a nested role, a user cannot bind to the server if it is a member of any role within the nested role. All entries that belong to a role that are direct or indirect members of the nested role have nsAccountLock set to true. Inactivating a nested role at any point in the nesting inactivates all roles and users under it.
4.3.3. Deciding between groups and roles
Roles and groups can accomplish the same goals. Managed roles can do everything that static groups can do, while filtered roles can filter and identify members the same way as dynamic groups. Both roles and groups have advantages and disadvantages. Deciding whether to use roles, or groups, or a mix depends on balancing your requirements and server resources.
Roles reduce client-side complexity. With roles, the client application can check role membership by searching the nsRole operational attribute in entries. This multi-valued attribute identifies every role to which the entry belongs. From the client application point of view, the method for checking membership is uniform and is performed on the server side.
However, roles require increased server complexity. Evaluating roles is more resource-intensive for the Directory Server than evaluating groups because the server does the work for the client application.
Groups require smarter and more complex clients to use them effectively. For example, dynamic groups, from an application point of view, offer no support from the server to provide a list of group members. Instead, the application retrieves the group definitions and then runs the filter. User entries contain group membership information only if you configure the appropriate plug-ins.
You can use MemberOf plug-in to balance managing group membership. The MemberOf plug-in dynamically creates memberOf attribute in a user entry whenever a user is added to a group. A client can run a single search on a group entry to get a list of all of its members, or a single search on a user entry to get a complete list of all the groups it belongs to.
The server only has maintenance overhead when the membership is modified. Since Directory Server stores both the specified member (group) and memberOf (user) attributes in the database, searches do not require extra processing, which makes the searches from the clients very efficient.
Additional resources
4.4. Virtual directory information tree views
Directory Server supports virtual directory information tree views, virtual views. Virtual views are an optional layer of structure in addition to your standard directory tree to categorize and search entries.
Virtual views are not entirely compatible with multiple backends. Entries that virtual views return must reside in the same backend because the search is limited to one backend.
For more information about virtual DIT views, see Using views to create a virtual directory hierarchy
4.4.1. Virtual DIT view example
The LDIF entries below show a virtual view hierarchy that is based on location. Any entry that resides below dc=example,dc=com and fits the view description appears in this view, organized by location.
dn: ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Location Views description: views categorized by location dn: ou=Sunnyvale,ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Sunnyvale nsViewFilter: (l=Sunnyvale) description: views categorized by location dn: ou=Santa Clara,ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Santa Clara nsViewFilter: (l=Santa Clara) description: views categorized by location dn: ou=Cupertino,ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Cupertino nsViewFilter: (l=Cupertino) description: views categorized by location
A subtree search based at ou=Location Views,dc=example,dc=com returns all entries below dc=example,dc=com which match the filters (l=Sunnyvale), (l=Santa Clara), or (l=Cupertino). However, a one-level search returns no entries other than the child view entries because all qualifying entries reside in the three descendant views.
The ou=Location Views,dc=example,dc=com view entry itself does not contain a filter. This feature facilitates hierarchical organization without the requirement to further restrict the entries contained in the view. Any view may omit the filter.
Although the example filters are very simple, the filters you use can be as complex as necessary. You can limit the type of entry that the view should contain. For example, to limit this hierarchy to contain only people entries, add an nsfilter attribute to ou=Location Views,dc=example,dc=com with the filter value (objectclass=organizationalperson).
Each view with a filter restricts the content of all descendant views, while descendant views with filters also restrict their ancestor contents. For example, creating the top view ou=Location Views first together with the new filter mentioned above would create a view with all entries with the organization object class. When the descendant views are added that further restrict entries, the entries that now appear in the descendant views are removed from the ancestor views. This demonstrates how virtual DIT views emulate the behavior of traditional DITs.
Although virtual DIT views emulate the behavior of traditional DITs, views can do something that traditional DITs cannot: entries can appear in more than one location. For example, to associate Entry B with both Mountain View and Sunnyvale, add the Sunnyvale value to the location attribute, and the entry appears in both views.
4.5. Directory tree design examples
Find examples of a directory tree for an international enterprise and for an ISP.
Directory tree for an international enterprise
Use the Internet domain name as the root entry for the directory tree. Then branch the tree below that root entry for each country where the enterprise has operations.
To represent different countries, use the l (location) attribute:
However, the c (country) attribute also can represent each country branch:
LDAP places no restrictions on the order of the attributes in your DNs.
Directory tree for ISP
Internet service providers (ISP) can support multiple enterprises with their directories. An ISP should consider each customer as a unique enterprise and design its directory trees accordingly. For security reasons, provide a unique directory tree with a unique suffix and an independent security policy for each customer.
Assign each customer a separate database and store these databases on separate servers. When you place each directory tree in its own database, you can back up and restore the data for each directory tree without affecting the other customers.
In addition, partitioning reduces performance problems caused by disk contention and the number of customers that disk outage can potentially affect.
