 |
Deployment
Guide Netscape Directory Server |
|
Deployment
Guide Netscape Directory Server |
| Previous |
Contents |
Index |
DocHome | Next |
Your directory tree provides a way to refer to the data stored by your directory. The types of information you store in your directory, the physical nature of your enterprise, the applications you use with your directory, and the types of replication you use shape the design of your directory tree.
This chapter outlines the steps for designing your own directory tree. It includes the following sections:
Your directory tree provides a means for your directory data to be named and referred to by client applications. Your directory tree interacts closely with other design decisions, including the choices available to you when you decide on how to distribute, replicate, or control access to your directory data. Taking the time to design your directory tree well before deployment saves headaches later if you find it inadequate after you have launched your directory.
A well-designed directory tree provides the following:
The structure of your directory tree follows the hierarchical LDAP model. Your directory tree provides a way to organize your data, for example, by group, by people, or by place. It also determines how you partition data across multiple servers. For example, each database needs data to be partitioned at the suffix level. Without the proper directory tree structure, you may not be able to spread your data across multiple servers as you would like.
In addition, replication is constrained by what sort of directory tree
structure you use. You must carefully define partitions for replication
to work. If you want to replicate only portions of your directory tree,
you need to take that into account during the design process. If you
plan to use access controls on branch points, that is also a
consideration in your directory tree design.
|
|
|
|
Directory Server supports a new concept for hierarchical navigation and organization of directory information, the virtual directory information tree views. Be sure to read Virtual Directory Information Tree Views before you design your directory tree. |
|
|
|
|
This section guides you through the major decisions you make during the directory tree design process. The directory tree design process involves the following steps:
The following sections describe the directory tree design process in
more detail.
The suffix is the name of the entry at the root of your tree, below which you store your directory data. Your directory can contain more than one suffix. You may choose to use multiple suffixes if you have 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 needed by
internal directory operations (such as configuration information and
your directory schema). For more information on these standard
directory suffixes, see the Netscape Directory
Server Administrator's Guide.
All entries in your directory should be located below a common base entry, the root suffix. In naming the root directory suffix, consider the following recommendations for what the name should be:
In a single enterprise environment, choose a directory suffix that aligns with a DNS name or Internet domain name of your enterprise. For example, if your enterprise owns the domain name of example.com, then you should use a directory suffix of:
dc=example,dc=com
The dc (domainComponent) attribute represents your suffix by breaking your domain name into its component parts.
Normally, you can use any attribute that you like to name your root suffix. However, for a hosting organization, we recommend that the root suffix contain only the following attributes:
The presence of these attributes allows for interoperability with subscriber applications. For example, a hosting organization might use these attributes to create the following root suffix for one of its clients, example_a:
o=example_a,st=Washington,c=US
Using an organization name followed by a country designation is typical
of the X.500 naming convention for suffixes.
Each suffix that you use with your directory is a unique directory
tree. There are several ways that you can include multiple trees in
your directory. The first is to create multiple directory trees stored
in separate databases served by Directory Server. For example, you
could create separate suffixes for
example_a and
example_b and store them in separate databases as shown below:
The databases could be stored on a single server or multiple servers
depending upon resource constraints.
You need to decide whether you use a flat or hierarchical tree structure. As a general rule, strive to make your directory tree as flat as possible. However, a certain amount of hierarchy can be important later when you partition data across multiple databases, prepare replication, and set access controls.
The structure of your tree involves the following steps and considerations:
Design your hierarchy to avoid problematic name changes. The flatter a namespace is, the less likely the names are to change. The likelihood of a name changing is roughly proportional to the number of components in the name that can potentially change. The more hierarchical the directory tree, the more components in the names, and the more likely the names are to change.
Following are some guidelines for designing your directory tree hierarchy:
For example, even if you have multiple marketing organizations, each of which is responsible for a specific product line, create a single Marketing subtree. All marketing entries then belong to that tree.
Following are specific guidelines for the enterprise and hosting
environment.
Name changes can be avoided if you base your directory tree structure on information that is not likely to change. For example, base the structure on types of objects in the tree rather than organizations. Some of the objects you might use to define your structure are:
A directory tree organized using these objects might appear as shown below.
For a hosting environment, create a tree that contains two entries of the object class organization(o) and one entry of the organizationalUnit(ou) object class beneath the root suffix. For example, the ISP example branches their directory, as shown below.
As you decide how to branch your directory tree, you will need to decide what attributes you will use to identify the branch points. Remember that a DN is a unique string composed of attribute-data pairs. For example, the DN of an entry for Barbara Jensen, an employee of example.com Corporation, appears as follows:
Each attribute-data pair represents a branch point
in your directory
tree. For example, the directory tree for the enterprise
example.com Corporation appears as follows:
The directory tree for example, an
internet host, appears as follows:
Beneath the root suffix entry o=example,c=US, the tree is split into three branches. The ISP branch contains customer data and internal information for example. The internet branch is the domain tree. The groups branch contains information about the administrative groups.
There are some points to consider when choosing attributes for your branch points:
|
Attribute Name |
Definition |
|---|---|
|
c |
|
|
o |
An organization name. This attribute is typically used 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 should also use this attribute to represent a domain name as discussed in Suffix Naming Conventions. |
|
An organizational unit. This attribute is typically used to represent a smaller divisional branching of your enterprise than an organization. Organizational units are generally subordinate to the preceding organization. |
|
|
st |
A state or province name. |
|
l |
A locality, such as a city, country, office, or facility name. |
|
dc |
A domain component as discussed in Suffix Naming Conventions. |
|
|
|
|
A common mistake is to assume that you search your directory based on the attributes used in the distinguished name. However, the distinguished name is only a unique identifier for the directory entry and cannot be searched against. Instead, search for entries based on the attribute-data pairs stored on the entry itself. Thus, if the distinguished name of an entry is cn=Babs Jensen,ou=People,dc=example,dc=com, then a search for dc=example will not match that entry unless you have explicitly put dc:example as an attribute in that entry.
|
|
|
|
|
During directory tree design, consider which entries you are replicating. A natural way to describe a set of entries to be replicated is to specify the distinguished name (DN) at the top of a subtree and replicate all entries below it. This subtree also corresponds to a database, a directory partition containing a portion of the directory data.
For example, in an enterprise environment, you can organize your directory tree so that it corresponds to the network names in your enterprise. Network names tend not to change, so the directory tree structure will be stable. Further, using network names to create the top level branches of your directory tree is useful when you use replication to tie together different Directory Servers.
For instance, example.com Corporation has three primary networks known as flightdeck.example.com, tickets.example.com, and hanger.example.com. They initially branch their directory tree as follows:
After creating the initial structure of the tree, they create additional branches as follows:
As another example, the ISP example.com branches their directory as follows:
After creating the initial structure of their directory tree, they create additional branches as follows:
Both the enterprise and the hosting organization design their data
hierarchies based on information that is not likely to change often.
Introducing hierarchy into your directory tree can be used to enable certain types of access control. As with replication, it is easier to group together similar entries and then administer them from a single branch.
You can also enable the distribution of administration through a hierarchical directory tree. For example, if you want give an administrator from the marketing department access to the marketing entries and an administrator from the sales department access to the sales entries, you can do so through your directory tree design.
You can set access controls based on the directory content rather than the directory tree. The ACI filtered target mechanism lets you define a single access control rule stating that a directory entry has access to all entries containing a particular attribute value. For example, you could set an ACI filter that gives the sales administrator access to all the entries containing the attribute ou=Sales.
owever, ACI filters can be difficult to manage. You must decide which
method of access control is best suited to your directory:
organizational branching in your directory tree hierarchy, ACI filters,
or a combination of the two.
After designing the hierarchy of your directory tree, you need to decide which attributes to use when naming the entries within the structure. Generally, names are created by choosing one or more of the attribute values to form a relative distinguished name (RDN). The RDN is the left-most DN attribute value. The attributes you use depend on the type of entry you are naming.
Your entry names should adhere to the following rules:
A unique name ensures that a DN can refer to at most one entry in your directory.
When creating entries, define the RDN within the entry. By defining at least the RDN within the entry, you can locate the entry more easily. This is because searches are not performed against the actual DN but rather the attribute values stored in the entry itself.
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 (locality) to represent an organization, or c (country) to represent an organizational unit.
The following sections provide tips on naming entries:
The person entry's name, the DN, must be unique. Traditionally, distinguished names use the commonName, or cn, attribute to name their person entries. That is, an entry for a person named Babs Jensen might have the distinguished name of:
cn=Babs Jensen,dc=example,dc=com
While allowing you to recognize instantly the person associated with the entry, it might not be unique enough to exclude people with identical names. This quickly leads to a problem known as DN name collisions, multiple entries with the same distinguished name.
You can avoid common name collisions by adding a unique identifier to the common name. For example:
However, this can lead to awkward common names for large directories and can be difficult to maintain.
A better method is to identify your person entries with some attribute other than cn. Consider using one of the following attributes:
Whatever you decide to use for an attribute-data pair for person entry
RDNs, you should make sure that they are unique, permanent values.
Person entry RDNs should also be readable. For example, uid=bjensen,dc=example,dc=com
is preferable to
uid=b12r56A,dc=example,dc=com
because recognizable DNs simplify 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.
If a person is a subscriber to a service, the entry should be of object class inetUser, and the entry should contain the uid attribute. The attribute must be unique within a customer subtree.
If a person is part of the hosting organization, represent them as an inetOrgPerson
with the nsManagedPerson
object class.
Here are some guidelines for placing people entries in your directory tree:
There are four main ways to represent a group:
In a deployment containing hosted organizations, we recommend using the
groupOfUniqueNames
object class to
contain the values naming the
members of groups used in directory administration. In a hosted
organization, we also recommend that group entries used for directory
administration be located under the ou=Groups
branch.
The organization entry name, like other entry names, must be unique. Using the legal name of the organization along with other attribute values helps ensure the name is unique. For example, you might name an organization entry as follows:
You can also use trademarks; however, they are not guaranteed to be unique.
In a hosting environment, you need to include the following attributes in the organization's entry:
Your directory will contain entries that represent many things, such as localities, states, countries, devices, servers, network information, and other kinds of data.
For these types of entries, use the commonName(cn) attribute in the RDN if possible. Then, if you are naming a group entry, name it as follows:
However, sometimes you need to name an entry whose object class does not support the commonName attribute. Instead, use an attribute that is supported by the entry's object class.
There does not have to be any correspondence between the attributes
used for the entry's DN and the attributes actually used in the entry.
However, a correspondence between the DN attributes and attributes used
by the entry simplifies administration of your directory tree.
Once you have created entries, you can group them for ease of administration. The Directory Server supports several methods for grouping entries and sharing attributes between entries:
The following sections describe each of these mechanisms in more detail.
Roles are a new entry grouping mechanism. Your directory tree organizes information hierarchically. This hierarchy is a grouping mechanism, though it is not suited for short-lived, changing organizations. Roles provide another grouping mechanism for more temporary organizational structures.
Roles unify static and dynamic groups. You use static groups to create a group entry that contains a list of members. Dynamic groups allow you to filter entries that contain a particular attribute and include them in a single group.
Each entry assigned to a role contains the nsRole attribute, a computed attribute that specifies all of the roles an entry belongs to. A client application can check role membership by searching the nsRole attribute, which is computed by the directory and therefore always up-to-date.
Roles are designed to be more efficient and easier to use for applications. For example, applications can locate the roles of an entry rather than select a group and browse the members list.
You can use roles to do the following:
Each role has members, entries that possess the role. You can specify members either explicitly (meaning each entry contains an attribute associating it with a role) or dynamically (by creating a filter that assigns entries to roles depending upon an attribute contained by the entry). How you specify role membership depends upon the type of role you are using. There are three types of roles:
Both methods of grouping entries have advantages and disadvantages. Roles reduce client-side complexity at the cost of increased server complexity. With roles, the client application can check role membership by searching the nsRole attribute. From the client application point of view, the method for checking membership is uniform and is performed on the server side.
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. For static groups, the application must make sure the user is part of a particular UniqueMember attribute value. The method for determining group membership is not uniform.
You can use managed roles to do everything you would normally do with static groups. You can filter group members using filtered roles as you used to do with dynamic groups.
While roles are easier to use, more flexible, and reduce client complexity, they do so at the cost of increased server complexity. Determining role membership is more resource intensive because the server does the work for the client application.
A class of service (CoS) allows you to share attributes between entries in a way that is invisible to applications. With CoS, some attribute values may not be stored with the entry itself. Instead, they are generated by class of service logic as the entry is sent to the client application.
For example, your directory contains thousands of entries that all share the common attribute facsimileTelephoneNumber. Traditionally, to change the fax number, you would need to update each entry individually, a large job for administrators that runs the risk of not updating all entries. With CoS, you can generate the attribute dynamically. The facsimileTelephoneNumber attribute is stored in one place, and each entry points to that place to give a value to their fax number attribute. For the application, these attributes appear just like all other attributes despite not actually being stored on the entries themselves.
Each CoS is comprised of the following entries in your directory:
You can use different types of CoS depending upon how you want the value of your dynamic attributes to be generated. There are three types of CoS:
Roles and the Classic CoS can be used together to provide role-based attributes. These attributes appear on an entry because it possesses a particular role with an associated class of service template. For example, you could use a role-based attribute to set the server look through limit on a role-by-role basis.
The following sections provide examples of directory trees designed to
support a flat hierarchy as well as several examples of more
complicated hierarchies.
To support an international enterprise, root your directory tree in your Internet domain name, and then branch your tree for each country where your enterprise has operations immediately below that root point. In Suffix Naming Conventions, you are advised to avoid rooting your directory tree in a country designator. This is especially true if your enterprise is international in scope.
Because LDAP places no restrictions on the order of the attributes in your DNs, you can use the c(countryName) attribute to represent each country branch as follows:
However, some administrators feel that this is stylistically awkward, so instead you could use the l(locality) attribute to represent different countries:
Internet service providers (ISPs) may support multiple enterprises with their directories. If you are an ISP, consider each of your customers as a unique enterprise and design their directory trees accordingly. For security reasons, each account should be provided a unique directory tree with a unique suffix and an independent security policy.
You can assign each customer a separate database, and store these databases on separate servers. Placing each directory tree in its own database allows you to back up and restore data for each directory tree without affecting your other customers.
In addition, partitioning helps reduce performance problems caused by disk contention and reduces the number of accounts potentially affected by a disk outage.
For example, the directory tree for
example, an ISP, appears as follows:
Directory Server supports a new concept for hierarchical navigation and organization of directory information, the virtual directory information tree views or virtual DIT views.
|
|
|
|
In this release, virtual views are not entirely compatible with multiple backends in that the entries to be returned by the views must reside in the same backend; the search is limited to one backend. |
|
|
|
|
When considering directory namespace, you have the choice of creating either of the following:
The hierarchical DIT is useful for navigating the directory but is cumbersome and time consuming to change. The flat DIT, while requiring little to no change, does not provide a convenient way to navigate or manage the entries in the directory. A flat DIT also presents many management challenges as administration becomes more complex without any natural hierarchical groupings. On the other hand, a major organizational change to a hierarchical DIT can be an expensive and time-consuming operation as it usually involves considerable service disruption, which can only be minimized by operating during late hours and periods of low traffic. Also, moving millions of entries from one place in a hierarchy to another is a lot of work.
Figure 4-1 shows examples of a flat and an organizationally-based DIT.
Figure 4-1 Examples of a Flat and an Organizationally-Based DIT
Having decided upon a hierarchical DIT, a deployment must then decide upon the subject domain of the hierarchy. Only one choice can be made, and that tends to mean that only one natural choice is available: the organizational hierarchy.
This view of the organization serves well in many cases, but having just this one view can be very limiting for directory navigation and management. For example, an organization hierarchy is fine if you are looking for entries belonging to people in the Accounts department. However, this view is much less useful for finding entries that belong to people in a geographical location, say Mountain View, California. The second query is equally valid as the first one, yet it requires knowledge of the attributes contained in the entries and additional search tools. For such a case, navigation via the DIT is not an option.
In a similar vein, management of the directory is made very much easier by having a DIT that matches the requirements of the management function. The organization of your DIT may be affected by other factors, too, such as replication and migration considerations, that cause the DIT to have functional utility for those applications but very little practical utility in other cases.
From the above discussion, it is clear that hierarchies are a useful mechanism for navigation and management. Yet, to avoid the burden of making changes to an existing DIT, a deployment may elect to forgo a hierarchy altogether in favor of a flat DIT.
It would be advantageous for deployments if the directory provided a
way to create an arbitrary number of hierarchies that get mapped to
entries without having to move the target entries in question. The
virtual DIT views feature of Directory Server resolves the quandary of
deciding the DIT type you should elect for your directory deployment.
Virtual DIT views are a way to navigate hierarchically entries that do not require the physical existence of those entries in any particular place. The virtual DIT view uses information about the entries to place them in the view hierarchy. To client applications, virtual DIT views look just like ordinary container hierarchies. In a sense, virtual DIT views superimpose a DIT hierarchy over a set of entries, irrespective of whether those entries are in a flat namespace or in another hierarchy of their own.
Creating a virtual DIT view hierarchy is just like creating a normal DIT hierarchy. You create the same entries (for example, organizational unit entries) but with an additional object class (nsview) and a filter attribute (nsviewfilter) that describes the view. Once you add the additional attribute, the entries that match the view filter will instantly populate the view. Note that the target entries only appear to exist in the view; their true location never changes. Virtual DIT views act just like normal DITs in that a subtree or a one-level search can be performed with the expected results being returned.
For information about adding and modifying entries, refer to chapter 2, "Creating Directory Entries," in the Netscape Directory Server Administrator's Guide.
Figure 4-2 A Combined DIT with Added Features Using Views
The DIT shown in Figure 4-2 illustrates what happens when the two DITs shown in Figure 4-1 are combined using views. Because views inherently allow entries to appear in more than one place in a view hierarchy, this feature has been used to expand the ou=Sales entry to enable viewing the Sales entries either by location or by product.
Given a set of virtual DIT view hierarchies, a directory user can navigate using the view that makes the most sense to get to the required entries. For example, if your target entries were those which dwell in Mountain View, a view which starts out navigating down using location-based information is most appropriate. If it were an organizational question, the organization view would work better. The point to note is that both of these views exist in the Directory Server at the same time and operate on the same entries--they just have different concerns or objectives when displaying their version of the directory structure.
The entries in the views-enabled directory depicted in Figure 4-2 are contained in a flat namespace just below the parent of the top most view in the hierarchy. This is not a must. The entries can exist in a hierarchy of their own. The only concern that a view has about the placement of an entry is that it must be a descendent of the parent of the view hierarchy.
Figure 4-3 A DIT with a Virtual DIT View Hierarchy
The DIT illustrated in Figure 4-3 shows a view hierarchy.
Note that these are leaf nodes because they do not contain the real
entries. However, when a client application searches these views, it
will find Entry
A under ou=Sunnyvale
and Entry B
under
ou=Mountain View. This virtual search space is described by the nsviewfilter
attributes of all ancestor views. A search made from
a view will return both entries from the virtual search space and those
from the actual search space. This enables the view hierarchies to
function as a conventional DIT or turn a conventional DIT into a view
hierarchy.
Your deployment decisions become easier with virtual DIT views:
The flexibility of having more than one way to view and query directory
information allows end users to find what they need intuitively through
hierarchical navigation and for new applications to take advantage this
feature.
The LDIF entries below show a virtual DIT view hierarchy that is based on location. Any entry which resides below dc=example,dc=com and fits the view description will appear 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 would return all entries below dc=example,dc=com which match the filters(l=Sunnyvale) ,(l=Santa Clara), or(l=Cupertino), whereas a one-level search would return no entries other than the child view entries because all qualifying entries reside in the three descendent 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 restrict the entries contained in the view further. Any view may omit the filter. Although the example filters are very simple, the filter used may be of arbitrary complexity.
It may be desirable to limit the type of entry that the view is to contain. For example, to limit this hierarchy to contain only people entries, simply 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 descendent views while descendent views with filters also restrict their ancestor's contents. For example, creating the top view ou=Location Views first along with the new filter mentioned above would create a view with all entries with the organizational object class. When you add the descendent views that further restrict entries, the entries that now appear in the descendent views are removed from the ancestor views. This demonstrates how virtual DIT views mimic the behavior of traditional DITs.
Although virtual DIT views mimic the behavior of traditional DITs,
views can do something that traditional DITs cannot; that is, entries
may appear in more than one place. For example, if it were required
that Entry B
be associated with both Mountain View
and Sunnyvale
(see Figure 4-3), you can
accomplish that by simply
adding the Sunnyvale
value to the location attribute, and the entry would
appear in both views.
Both class of service and roles features of the Directory Server support views; see Grouping Directory Entries. When adding a class of service or a role under a view hierarchy, the entries that are both logically and actually contained in the view are considered within scope; for information on using these features, refer to chapter 5, "Advanced Entry Management," in the Netscape Directory Server Administrator's Guide. This means that roles and class of service can be applied using a virtual DIT view, but the effects of that application can be seen even when querying the flat namespace.
Access control with views must be performed slightly differently than is usual. Because there is currently no explicit support for ACLs in views, it is recommended that you create role-based ACIs at the view parent and add the roles to the appropriate parts of the view hierarchy. In this way, you can take advantage of the organizational property of the hierarchy.
To clarify any doubts that you have about the effects of views on
searching, understand that if the base of the search is a view and the
scope of the search is not a base, then it is a views-based search.
Otherwise, it is a conventional search. For example, if you perform a
search with a base of
dc=example,dc=com, then no entries from the virtual search space
will be returned -- in
fact, no virtual-search-space search is performed. Views processing
occurs only if the search base is ou=Location Views
(or below). This way, views ensure that your
search does not result in entries from both places (you would would get
entries back from both places if it were a conventional DIT).
The performance of views-based hierarchies is dependent on the make up of the hierarchy itself and the number of entries in the DIT. In general, you may see a marginal change in performance (within a few percentage points of equivalent searches on a conventional DIT) if virtual DIT views are enabled in your directory. If a search does not invoke a view, then there is no performance impact. As always, we recommend that before deployment, you must test your virtual DIT views against expected search patterns and loads.
We also recommend that the attributes used in view filters be indexed if the views are to be used as general-purpose navigation tools in the organization. Further, when a sub-filter used by views matches a configured virtual list view index, that index will be used in views evaluation.
There is no need to tune any other part of the directory specifically
for views.
Virtual DIT views are designed to mimic conventional DITs to a high degree. Most applications should continue to work without any knowledge that they are working with views. Except for a few specialized cases, there is no need for directory users to know that views are being used in a Directory Server instance--views look and act like conventional DITs.
Certain types of applications may have problems working with a views-enabled directory. For example:
Take a look at the following links for more information about designing your directory tree:
| Previous |
Contents |
Index |
DocHome | Next |