Front cover - IBM Redbooks

346 Lotus Security Handbook
DN= uid=bhinkle2,cn=users,dc=acme,dc=com
cn=Bill Hinkle
mail=b_hinkle@acme.com
Note in the example entries that it is difficult, or even impossible, to know which
user we intend to select based on the DN. Our applications, such as e-mail, need
to incur extra overhead to retrieve attributes for the entry in addition to the DN so
the user or application can determine the proper entry. In the example, the
common name would allow us to distinguish the person we want to select. But in
large organizations, duplicate or similar common names will exist with significant
frequency. So another attribute, such as department or location, would then need
to also be queried. So if we revisit the tree to make it “taller” (or less “flat”), we
can easily create DNs that provide more granular information for the entries
without the need to access additional attributes:
DN= uid=bhinkle,ou=sales,dc=acme,dc=com
mail=b_c_hinkle@acme.com
DN= uid=bhinkle2,ou=hr,dc=acme,dc=com
mail=b_hinkle@acme.com
Using either OU or DC branches beneath the root is typically advisable in smaller
organizations (under 10,000 entries) only if the user administration is distributed.
This is because access controls are easier to implement at a branch node rather
than on each individual leaf (user) node. As for whether the traditional X.500
country root or a DNS domain component root is better, this is the subject of
debate. Considering that an international X.500 service has never materialized to
link the country roots together in a unified manner, a domain structure has
become the more popular approach. In theory, using the DNS domain
components might eventually support the ability to obtain someone’s X.500
public certificate for sending encrypted SMIME messages. But we feel that this
will not realistically happen for at least three to five years, if it happens at all. Our
experience has been that commercial organizations are unlikely to ever provide
a publicly accessible directory service for their internal users. The concerns over
misuse, such as SPAM, are most certainly justifiable. But given the ubiquity of
DNS, we would most likely recommend a domain component DIT for
organizations that are contemplating a new LDAP implementation.
Defining the DIT requires a great deal of planning. It usually involves a trade-off
between granular organization and ease of administration. And it is very often
difficult to change once in place and the directory populated. The DIT that proves
to be a good “fit” for one organization may be completely inappropriate for
another organization, even though both might be in the same industry.