view Side-By-Side changes
An Approach for Using Domains in LDAP Distinguished Names
<draft-ietf-asid-ldap-domains-00.txt>
<draft-ietf-asid-ldap-domains-01.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
1. Abstract
The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible
Distinguished Names
distinguished names for providing unique identifcation identification of entries.
Distinguished Names
distinguished names in currently-deployed X.500 directories have the
properties that they are descriptive, hierarchical, and follow common
organizational models. However, there is not today a universal registration
mechanism to permit individuals and organizations to obtain
Distinguished Names. distinguished
names, regardless of their physical location.
This document describes an experimental defines a mechanism by which a name registered with the
Internet Domain Name Service, Service [1], for which there is an are active registration service,
services, can be represented as a Distinguished Name distinguished name so that it may be
used with the LDAP protocol. This is not intended to have LDAP replace
the DNS protocol, but to permit further deployment of LDAP into
organizations connected to the Internet.
This algorithm automatically assigns a distinguished name to any
enterprise which has obtained a domain name for use in the Internet.
This distinguished name may be used as a prefix for their names of
entries in that enterprise.
This document does not define how to represent objects which do not have
domain names. Several RFCs, such as [3] and [4], and more recent
documents provide additional guidance on representing and structuring
information in these entries. Nor does this document define the procedure
to locate an enterprises' LDAP directory server, given their domain name.
Such as procedure may be defined in future RFCs.
Kille, Wahl Page 1
INTERNET-DRAFT Domains in LDAP DNs February 1997
2. Introduction to Domain Names and Distinguished Names
The Domain (Nameserver) System (DNS) provides a hierarchical resource
labelling system [1].
labeling system. A name is made up of an ordered set of components,
each of which are short strings. An example domain name would be
"CRITICAL-ANGLE.COM".
Entries usually have a single name, although pointers to entries
may be provided by CNAME records. Information (resource records) is
associated with each entry. Name two
components are typically chosen to would be
shortish (e.g., "WWW").
INTERNET-DRAFT draft-ietf-asid-ldap-domains-00.txt July 31, 1996
Kille, Wahl An Approach for Using Domains in LDAP DNs Page 2 "CRITICAL-ANGLE.COM".
The X.500 Directory provides a very more general hierarchical naming framework.
A primary difference in specification of Distinguished Names distinguished names from
domain names is that each component of an distinguished name has an
explicit attribute type indication. (It is also possible to have multiple
components in the same level, but that is not commonly done today).
An example Distinguished Name distinguished name represented in the LDAP string format [2]
is "CN=Mark Wahl, O=Critical Angle Incorporated, ST=Texas, C=US". "DC=CRITICAL-ANGLE,DC=COM". As with a domain name, the most significant
component, closest to the root of the namespace, is written last.
3. Mapping Domain Names into Distinguished Names
This section defines a subset of the X.500 naming structure for use in
representing names allocated in the Internet Domain Name System. It is
expected that it would be possible to algorithmically transform any
Internet domain name into a Distinguished Name, distinguished name, and to be able to convert
such a name back into a domain name.
The algorithm for transforming a domain name is to begin with a an empty
DN of
"O=Internet", and then attach RDNs for each component of the domain, most significant
first. Each of these RDNs have a single AttributeTypeAndValue, where the
type is domainComponent (abbreviated "DC") DC and the value is an IA5 string. string containing the component.
Thus the domain name
CS.UCL.AC.UK "CS.UCL.AC.UK" can be transformed into
DC=CS, DC=UCL, DC=AC, DC=UK, O=Internet
And
DC=CS,DC=UCL,DC=AC,DC=UK
and similarly
11.168.192.IN-ADDR.ARPA "11.168.192.IN-ADDR.ARPA" to
DC=11, DC=168, DC=192, DC=IN-ADDR, DC=ARPA, O=Internet
DC=11,DC=168,DC=192,DC=IN-ADDR,DC=ARPA
X.500 Distinguished Names distinguished names in which the first RDN is "O=Internet", and there are one or more following RDNs, each all with
the attribute type
domainComponent, DC, can be mapped back into domain names. Note that there
will
this document does not be an algorithmic define a domain name equivalence for all any other
Distinguished Names, such as:
CN=Steve Kille, DC=ISODE, DC=COM, O=Internet
O=ISODE Consortium, C=GB
distinguished names.
4. Limitations on Use Attribute Type and Object Class Definitions
The DC (short for domainComponent) attribute type is defined as follows:
( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 'IA5String' SINGLE-VALUE )
The value of this Mechanism
This naming mechanism attribute is primarily intended for experimental or single-site
pilot projects, or where the directory service does not currently intend to
connect to any established service, but still requires a globally unique
name.
If an organization is running a service in a locality for which there is an
official registration authority for distinguished names, an officially
registered distinguished name should be used instead of this mechanism.
These names are typically based on the concatenation of an organization's
registered name and the location of that registry, such as "O=IC, C=GB".
If an organization intends to connect to an established directory service,
then the guidelines string holding one component of that service should be followed.
INTERNET-DRAFT draft-ietf-asid-ldap-domains-00.txt July 31, 1996
Kille, Wahl An Approach for Using Domains in LDAP DNs Page 3
5. Attribute Type and Object Class Definition
The domainComponent or DC attribute type is defined in [3], and is
reproduced here for convenience.
domainComponent ATTRIBUTE ::= {
WITH SYNTAX IA5String
EQUALITY MATCHING RULE iA5EqualityMatchingRule
SINGLE VALUE TRUE
ID {pilotAttributeType 25} } a domain
name. The encoding of IA5String for use in LDAP is simply the characters
of the string itself. The equality matching rule is case insensitive, as
is today's DNS.
The
Kille, Wahl Page 2
INTERNET-DRAFT Domains in LDAP DNs February 1997
Objects with names derived from their domain object class would name using the algorithm of
section 3 may be used represented as an entry in the directory. This allows
information (attributes) to be associated with that entry. The entry
will have as its structural object class the "domain" object class, or
a subclass of
entries whose distinguished names "domain".
( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL
MUST dc
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l $ description $ o $
associatedName ) )
The optional attributes of the domain class are generated according to used for describing the algorithm
object represented by this domain, and may also be useful when searching.
The semantics of these attributes are defined in section 3. X.520 [5].
The DC attribute is used for naming entries of the domain class. This is
reflected by the following name form rule.
( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain OBJECT-CLASS ::= {
SUBCLASS OF { top } MUST CONTAIN { domainComponent }
MAY CONTAIN {
associatedName,
organizationName,
organizationalAttributeSet }
ID {pilotObjectClass 13} }
domainNameForm NAME-FORM ::= {
NAMES domain
WITH ATTRIBUTES { domainComponent }
ID {enterprises 1466 345 }} ( dc ) )
If it is desired to be able to store or retrieve DNS-specific DNS record attributes
of the domain via LDAP, the dNSDomain object class can be used as well.
6. Directory Information Structure
This algorithm assigns to any organization which has obtained a domain name
for use object class should only be present in the Internet a distinguished name for use as a prefix for their
own entry's names.
Thus a small organization which holds entry if the domain name
CRITICAL-ANGLE.COM
Might have DNS records
are listed as their directory entries:
CN=Mark Wahl, DC=CRITICAL-ANGLE, DC=COM, O=Internet
CN=Postmaster, DC=CRITICAL-ANGLE, DC=COM, O=Internet attributes.
( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP domain STRUCTURAL
MAY dNSRecord )
The dNSRecord attribute may take one or more values.
( 0.9.2342.19200300.100.1.26 NAME 'dNSRecord'
EQUALITY caseExactIA5Match SYNTAX 'IA5String' )
5. Relationship between LDAP and DNS Directories
Implementations should be aware of the differences in deployment between
LDAP and DNS directories.
To effectively search the entries in an LDAP service, it is necessary to
know the base object of the entries held by that service. Generally that
base object will be in one of the naming contexts in the LDAP service.
While most objects with domain names are listed in an organization DNS-capable
directory system, it is currently expected that only a small subset of
the objects with multiple subdomains might structure their
entries as:
CN=Steve Kille, DC=Richmond, DC=ISODE, DC=COM, O=Internet
CN=Greg Lavender, DC=Austin, DC=ISODE, DC=COM, O=Internet
INTERNET-DRAFT draft-ietf-asid-ldap-domains-00.txt July 31, 1996 domain names will be listed in LDAP-capable directories.
Kille, Wahl An Approach for Using Page 3
INTERNET-DRAFT Domains in LDAP DNs Page 4
There are a number of RFCs, such as [4] and [5], which provide guidance
on representing and structuring information in February 1997
Furthermore, there may not necessarily be exactly one LDAP-capable
directory entries which
would listing service for many top-level domains (such as ".COM" or
".US"). There many be applicable.
7. Relationship multiple distinct entries with LDAP when Browsing
To effectively search the entries same name held
by different, disconnected directory services. There may be some objects
accessible in an LDAP server connected to a global directory system, it is necessary to know the base object of service, for which the entries
a server maintains.
If a client does superior objects are not have
held by any information on a search base to use, then
there are three possible approaches:
1. Interrogate the server for the naming contexts it holds.
2. Create a search base directory server.
LDAP client implementations should not assume that subtree searches may
be based on at the domain name root of the contacted server.
3. Browse by searching DIT, or at immediately subordinate to the root.
Approach 1 is recommended if the client and server both support entries.
Nor should LDAP
version 3 or higher. If this is not the case and there is no other
information available to the client, then approach 2 is recommend.
Approach 2 makes use of the mechanism defined in this document, with client implementations assume that a name transformed from
a
slight extension. If the least significant component of the contacted server's domain name is "ldap" or "x500", this component is ignored, and
the remainer of the domain name is transformed into will be a distinguished name.
Thus for example if context prefix held by that
server. If the client was asked to contact the server
ldap.critical-angle.com and browse, it would using approach 2 issue its
searches with the base object "DC=CRITICAL-ANGLE, DC=COM, O=Internet".
Approach 3 is not recommended, as the server both implement LDAP version 3, the
client may chain or refer interrogate the
operation to another server which holds entries subordinate to for the root
(such as countries).
8. naming contexts it holds.
6. References
[1] P. Mockapetris. Domain names - concepts and facilities.
RFC 1034, November 1987.
[2] S. Kille, M.Wahl. Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names.
INTERNET DRAFT draft-ietf-asid-ldapv3-dn-00.txt. July 1996.
[3] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet
X.500 schema. Request for Comments RFC 1274, November 1991.
[4] P. Barker, S. Kille, T. Lenggenhager, "Naming and Structuring
Guidelines for X.500 Directory Pilots". RFC 1617 May 1994.
[5]
[4] B. Jennings, "Building an X.500 Directory Service in the US",
RFC 1943, May 1996.
9.
7. Security Considerations
This memo does not address describes how attributes of objects may be discovered and
retrieved. Servers should ensure that an appropriate security issues.
INTERNET-DRAFT draft-ietf-asid-ldap-domains-00.txt July 31, 1996
Kille, Wahl An Approach for Using Domains in LDAP DNs Page 5
10. policy
is maintained.
8. Author's Address
Steve Kille
ISODE Consortium
Isode Ltd.
The Dome
The Square
Richmond, Surrey
TW9 1DT
England
Phone: +44-181-332-9091
EMail: S.Kille@ISODE.COM
Mark Wahl
Critical Angle Inc.
4815 W. Braker Lane #502-385
Austin, TX 78759
USA
EMail: M.Wahl@critical-angle.com
Kille, Wahl Page 4
----