]> git.sur5r.net Git - openldap/blobdiff - doc/guide/admin/intro.sdf
ITS#2497 value-level ACLs
[openldap] / doc / guide / admin / intro.sdf
index 90debedd594af6eed4433dfccf2d709e89271e6d..1c8f7d281f9bb3aa3910878e1d0f41a2201bf5dc 100644 (file)
@@ -1,5 +1,5 @@
 # $OpenLDAP$
-# Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 1999-2003, The OpenLDAP Foundation, All Rights Reserved.
 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
 H1: Introduction to OpenLDAP Directory Services
 
@@ -13,17 +13,16 @@ to directory services and, in particular, the directory services
 provided by {{slapd}}(8).
 
 
-
 H2: What is a directory service?
 
-A directory is specialized database optimized for reading, browsing
+A directory is specialized database optimized for reading, browsing
 and searching.  Directories tend to contain descriptive, attribute-based
 information and support sophisticated filtering capabilities.
 Directories generally do not support complicated transaction or
 roll-back schemes found in database management systems designed
 for handling high-volume complex updates.  Directory updates are
 typically simple all-or-nothing changes, if they are allowed at
-all.  Directories are tuned to give quick-response to high-volume
+all.  Directories are tuned to give quick response to high-volume
 lookup or search operations. They may have the ability to replicate
 information widely in order to increase availability and reliability,
 while reducing response time.  When directory information is
@@ -43,8 +42,8 @@ contain is spread across many machines, all of which cooperate to
 provide the directory service. Typically a global service defines
 a uniform {{namespace}} which gives the same view of the data no
 matter where you are in relation to the data itself.  The Internet
-{{TERM[expand]DNS}} is an example of a globally distributed directory
-service.
+{{TERM[expand]DNS}} (DNS) is an example of a globally distributed
+directory service.
 
 
 H2: What is LDAP?
@@ -54,8 +53,10 @@ it is a lightweight protocol for accessing directory services,
 specifically {{TERM:X.500}}-based directory services.  LDAP runs
 over {{TERM:TCP}}/{{TERM:IP}} or other connection oriented transfer
 services.  The nitty-gritty details of LDAP are defined in
-{{REF:RFC2251}} "The Lightweight Directory Access Protocol (v3)."
-This section gives an overview of LDAP from a user's perspective.
+{{REF:RFC2251}} "The Lightweight Directory Access Protocol (v3)"
+and other documents comprising the technical specification
+{{REF:RFC3377}}.  This section gives an overview of LDAP from a
+user's perspective.
 
 {{What kind of information can be stored in the directory?}} The
 LDAP information model is based on {{entries}}. An entry is a
@@ -64,8 +65,8 @@ collection of attributes that has a globally-unique {{TERM[expand]DN}}
 the entry's attributes has a {{type}} and one or more {{values}}.
 The types are typically mnemonic strings, like "{{EX:cn}}" for
 common name, or "{{EX:mail}}" for email address. The syntax of
-values depend on the attribute type is.  For example, {{EX:cn}}
-attribute might be the value {{EX:Babs Jensen}}.  A {{EX:mail}}
+values depend on the attribute type.  For example, a {{EX:cn}}
+attribute might contain the value {{EX:Babs Jensen}}.  A {{EX:mail}}
 attribute might contain the value "{{EX:babs@example.com}}". A
 {{EX:jpegPhoto}} attribute would contain a photograph in the JPEG
 (binary) format.
@@ -73,7 +74,7 @@ attribute might contain the value "{{EX:babs@example.com}}". A
 {{How is the information arranged?}} In LDAP, directory entries
 are arranged in a hierarchical tree-like structure.  Traditionally,
 this structure reflected the geographic and/or organizational
-boundaries.  Entries representing countries appeared at the top of
+boundaries.  Entries representing countries appear at the top of
 the tree. Below them are entries representing states and national
 organizations. Below them might be entries representing organizational
 units, people, printers, documents, or just about anything else
@@ -86,7 +87,7 @@ FT[align="Center"] Figure 1.1: LDAP directory tree (traditional naming)
 
 The tree may also be arranged based upon Internet domain names.
 This naming approach is becoming increasing popular as it allows
-for directory services to be locating using the {{TERM[expand]DNS}}.
+for directory services to be located using the {{DNS}}.
 Figure 1.2 shows an example LDAP directory tree using domain-based
 naming.
 
@@ -105,7 +106,7 @@ the entry itself (called the {{TERM[expand]RDN}} or RDN) and
 concatenating the names of its ancestor entries. For example, the
 entry for Barbara Jensen in the Internet naming example above has
 an RDN of {{EX:uid=babs}} and a DN of
-{{EX:uid=babs,ou=People,dc=example,dc=com}}". The full DN format
+{{EX:uid=babs,ou=People,dc=example,dc=com}}. The full DN format
 is described in {{REF:RFC2253}}, "Lightweight Directory Access
 Protocol (v3):  UTF-8 String Representation of Distinguished Names."
 
@@ -131,7 +132,7 @@ be useful to you.
 
 {{How is the information protected from unauthorized access?}} Some
 directory services provide no protection, allowing anyone to see
-the information. LDAP provides a mechanisms for a client to
+the information. LDAP provides a mechanism for a client to
 authenticate, or prove its identity to a directory server, paving
 the way for rich access control to protect the information the
 server contains.  LDAP also supports privacy and integrity security
@@ -156,9 +157,9 @@ H2: What about X.500?
 
 Technically, {{TERM:LDAP}} is a directory access protocol to an
 {{TERM:X.500}} directory service, the {{TERM:OSI}} directory service.
-Initially, LDAP clients accessed gateways to directory service.
-This gateway ran LDAP (between the client and gateway) and X.500's
-{{TERM[expand]DAP}} ({{TERM:DAP}}) (between the gateway and the
+Initially, LDAP clients accessed gateways to the X.500 directory service.
+This gateway ran LDAP between the client and gateway and X.500's
+{{TERM[expand]DAP}} ({{TERM:DAP}}) between the gateway and the
 X.500 server.  DAP is a heavyweight protocol that operates over a
 full OSI protocol stack and requires a significant amount of
 computing resources.  LDAP is designed to operate over
@@ -188,23 +189,25 @@ with slurpd}} chapter of this document for information regarding
 replication.
 
 
-H2: What the difference between LDAPv2 and LDAPv3?
+H2: What is the difference between LDAPv2 and LDAPv3?
 
-There are two versions of LDAP in use today on the Internet.
-LDAPv3 was developed in late 1990's to replace LDAPv2.  LDAPv3
-adds the following features to LDAP:
+LDAPv3 was developed in the late 1990's to replace LDAPv2.
+LDAPv3 adds the following features to LDAP:
 
  - Strong Authentication via {{TERM:SASL}}
- - Integrity and Confidential Protections via {{TERM:TLS}} (SSL)
+ - Integrity and Confidentiality Protection via {{TERM:TLS}} (SSL)
  - Internationalization through the use of Unicode
  - Referrals and Continuations
- - Extensibility (controls and extended operations)
  - Schema Discovery
+ - Extensibility (controls, extended operations, and more)
 
-Supporting both LDAPv2 and LDAPv3 simultaneously can be problematic
-and generally should be avoided.  As LDAPv3 is more consistenly
-implemented and supports all the features of LDAPv2, use of LDAPv3
-is highly recommended.
+LDAPv2 is historic ({{REF:RFC3494}}).  As most implementations
+(including {{slapd}}(8)) of LDAPv2 do not conform to the LDAPv2
+technical specification, interoperatibility amongst implementations
+claiming LDAPv2 support will be limited.  As LDAPv2 differs
+significantly from LDAPv3, deploying both LDAPv2 and LDAPv3
+simultaneously can be quite problematic.  LDAPv2 should be avoided.
+LDAPv2 is disabled by default.
 
 
 H2: What is slapd and what can it do?
@@ -242,18 +245,20 @@ and other criteria.  {{slapd}} supports both {{static}} and
 {{B:Internationalization}}: {{slapd}} supports Unicode and language
 tags.
 
-{{B:Choice of databases}}: {{slapd}} comes with a variety of
-different backend databases you can choose from. They include
-{{TERM:LDBM}}, a high-performance disk-based embedded database;
-SHELL, a database interface to arbitrary shell scripts; and PASSWD,
-a simple password file database.  LDBM utilizes either {{PRD:BerkeleyDB}}
-or {{PRD:GDBM}}.
+{{B:Choice of database backends}}: {{slapd}} comes with a variety
+of different database backends you can choose from. They include
+{{TERM:BDB}}, a high-performance transactional database backend;
+{{TERM:LDBM}}, a lightweight DBM based backend; {{SHELL}}, a backend
+interface to arbitrary shell scripts; and PASSWD, a simple backend
+interface to the {{passwd}}(5) file.  BDB utilizes {{ORG:Sleepycat}}
+{{PRD:Berkeley DB}}.  LDBM utilizes either {{PRD:Berkeley DB}} or
+{{PRD:GDBM}}.
 
 {{B:Multiple database instances}}: {{slapd}} can be configured to
 serve multiple databases at the same time. This means that a single
 {{slapd}} server can respond to requests for many logically different
-portions of the LDAP tree, using the same or different backend
-databases.
+portions of the LDAP tree, using the same or different database
+backends.
 
 {{B:Generic modules API}}: If you require even more customization,
 {{slapd}} lets you write your own modules easily. {{slapd}} consists
@@ -264,12 +269,13 @@ well-defined {{TERM:C}} {{TERM:API}}, you can write your own
 customized modules which extend {{slapd}} in numerous ways.  Also,
 a number of {{programmable database}} modules are provided.  These
 allow you to expose external data sources to {{slapd}} using popular
-programming languages ({{PRD:Perl}}, {{Shell}}, {{PRD:SQL}}, and
+programming languages ({{PRD:Perl}}, {{shell}}, {{PRD:SQL}}, and
 {{PRD:TCL}}).
 
-{{B:Threads}}: {{slapd}} is threaded for high performance. A single
-multi-threaded {{slapd}} process handles all incoming requests,
-reducing the amount of system overhead required.
+{{B:Threads}}: {{slapd}} is threaded for high performance.  A single
+multi-threaded {{slapd}} process handles all incoming requests
+using a pool of threads.  This reduces the amount of system overhead
+required while providing high performance.
 
 {{B:Replication}}: {{slapd}} can be configured to maintain replica
 copies of its database. This {{single-master/multiple-slave}}
@@ -283,8 +289,8 @@ single configuration file which allows you to change just about
 everything you'd ever want to change.  Configuration options have
 reasonable defaults, making your job much easier.
 
-{{slapd}} also has its limitations, of course.  The main LDBM
-database backend does not handle range queries or negation queries
+{{slapd}} also has its limitations, of course.  The main BDB
+backend does not handle range queries or negation queries
 very well.