LDAP https://store.theartofservice.com/itil-2011-foundation-complete-certification-kit-fourth-edition-study-guide-ebook-and-online-course.html.

Lightweight Directory Access Protocol - LDAP URLs
An LDAP URL format exists, which clients support in varying degrees, and servers return in referrals and continuation references (see RFC 4516):

ldap://host:port/DN?attributes?scope?filter?extensions

port is the network port (default port 389) of the LDAP server.

DN is the distinguished name to use as the search base.

attributes is a comma-separated list of attributes to retrieve.

scope specifies the search scope and can be "base" (the default), "one" or "sub".

extensions are extensions to the LDAP URL format.

For example, "ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com" refers to all user attributes in John Doe's entry in ldap.example.com, while "ldap:///dc=example,dc=com??sub?(givenName=John)" searches for the entry in the default server (note the triple slash, omitting the host, and the double question mark, omitting the attributes). As in other URLs, special characters must be percent-encoded.

There is a similar non-standard ldaps: URL scheme for LDAP over SSL. This should not be confused with LDAP with TLS, which is achieved using the StartTLS operation using the standard ldap: scheme.

LDAP The 'Lightweight Directory Access Protocol' ('LDAP'; ) is an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.[ LDAP: 'Framework', Practices, and Trends]

LDAP Directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.

LDAP Please return their full name, , title, and description.[ What is LDAP?]

LDAP A common usage of LDAP is to provide a single sign-on where one password for a user is shared between many services, such as applying a company login code to web pages (so that staff log in only once to company computers, and then are automatically logged into the company intranet).

LDAP - History Telecommunication companies' understanding of directory requirements was well developed after some 70 years of producing and managing telephone directories. These companies introduced the concept of directory services to information technology and computer networking, their input culminating in the comprehensive X.500 specification,The X.500 series - ITU-T Rec. X.500 to X.521 a suite of protocols produced by the ITU|International Telecommunication Union (ITU) in the 1980s.

LDAP - History X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol (DAP), which required the Open Systems Interconnection (OSI) protocol stack. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service protocols.

LDAP - History Standalone LDAP directory servers soon followed, as did directory servers supporting both DAP and LDAP. The latter has become popular in enterprises, as LDAP removed any need to deploy an OSI network. Today, X.500 directory protocols including DAP can also be used directly over TCP/IP.

LDAP - History Further development of the LDAPv3 specifications themselves and of numerous extensions adding features to LDAPv3 has come through the Internet Engineering Task Force|IETF.

LDAP - History In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol, or LDBP. It was renamed with the expansion of the scope of the protocol beyond directory browsing and searching, to include directory update functions. It was given its Lightweight name because it was not as network intensive as its DAP predecessor and thus was more easily implemented over the internet due to its relatively modest bandwidth usage.

LDAP - History LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP).

LDAP - Protocol overview
A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on Transmission Control Protocol|TCP TCP and UDP port|port and UDP [ port 389

The client may request the following operations:

* StartTLS — use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection

* Bind — Authentication|authenticate and specify LDAP protocol version

* Compare — test if a named entry contains a given attribute value

* Modify Distinguished Name (DN) — move or rename an entry

* Abandon — abort a previous request

* Extended Operation — generic operation used to define other operations

In addition the server may send Unsolicited Notifications that are not responses to any request, e.g. before the connection is timed out.

A common alternative method of securing LDAP communication is using an Secure Socket Layer|SSL tunneling protocol|tunnel. This is denoted in LDAP URLs by using the URL scheme ldaps. The default port for LDAP over SSL is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never standardized in any formal specification. This usage has been deprecated along with LDAPv2, which was officially retired in 2003.[ RFC3494]

LDAP - Directory structure
* An entry consists of a set of attributes.

* An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema (see below).

* Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN), constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as the full path|full file path and the RDN as its relative filename in its parent folder (e.g. if /foo/bar/myfile.txt were the DN, then myfile.txt would be the RDN).

A DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a Universally Unique Identifier|UUID might be provided in the set of the entry's operational attributes.

dn is the distinguished name of the entry; it is neither an attribute nor a part of the entry. cn=John Doe is the entry's RDN (Relative Distinguished Name), and dc=example,dc=com is the DN of the parent entry, where dc denotes 'Domain Name System|Domain Component'. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like cn for common name, dc for domain component, mail for address, and sn for surname.

A server holds a subtree starting from a specific entry, e.g. dc=example,dc=com and its children. Servers may also hold references to other servers, so an attempt to access ou=department,dc=example,dc=com could return a referral or continuation reference to a server that holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client.

LDAP rarely defines any ordering: The server may return the values of an attribute, the attributes in an entry, and the entries found by a search operation in any order. This follows from the formal definitions - an entry is defined as a set (computer science)|set of attributes, and an attribute is a set of values, and sets need not be ordered.

LDAP - Add The ADD operation inserts a new entry into the directory-server database.[ Add section of RFC4511] If the distinguished name in the add request already exists in the directory, then the server will not add a duplicate entry but will set the result code in the add result to decimal 68, entryAlreadyExists.[ LDAP result codes]

LDAP - Add * LDAP-compliant servers will never dereference the distinguished name transmitted in the add request when attempting to locate the entry, that is, distinguished names are never de-aliased.

LDAP - Add * LDAP-compliant servers will ensure that the distinguished name and all attributes conform to naming standards

LDAP - Add * The entry to be added must not exist, and the immediate superior must exist.

dn: uid=user,ou=people,dc=example,dc=com
LDAP - Add dn: uid=user,ou=people,dc=example,dc=com

LDAP - Add In the above example, uid=user,ou=people,dc=example,dc=com must not exist, and ou=people,dc=example,dc=com must exist.

LDAP - Bind (authenticate)
When an LDAP session is created, that is, when an LDAP client connects to the server, the 'authentication state' of the session

is set to anonymous. The BIND operation establishes the authentication state for a session.

Simple BIND and SASL PLAIN can send the user's DN and password in plaintext, so the connections utilizing either Simple or SASL PLAIN

should be encrypted using Transport Layer Security (TLS). The server typically checks the password against the userPassword

attribute in the named entry. Anonymous BIND (with empty DN and password) resets the connection to anonymous state.

Simple Authentication and Security Layer|SASL (Simple Authentication and Security Layer) BIND provides authentication services through a

BIND also sets the LDAP protocol version. The version is an integer and at presentWP:RELTIME| must be either 2 (two) or 3 (three), although the

standard supports integers between 1 and 127 (inclusive) in the protocol. If the client requests a version that the server does not support,

the server must set the result code in the BIND response to the code for a protocol error. Normally clients should use LDAPv3, which is the

default in the protocol but not always in LDAP libraries.

BIND had to be the first operation in a session in LDAPv2, but is not required in LDAPv3 (the current LDAP version). In LDAPv3, each

successful BIND request changes the authentication state of the session and each unsuccessful BIND request resets the authentication state

LDAP - Delete To delete an entry, an LDAP client transmits a properly formed delete request to the server.[ RFC4511: delete request]

LDAP - Delete * A delete request must contain the distinguished name of the entry to be deleted* Request controls may also be attached to the delete request* Servers do not dereference aliases when processing a delete request* Only leaf nodes (entries with no subordinates) may be deleted by a delete request

LDAP - Search and Compare
The Search operation is used to both search for and read entries. Its parameters are:

; scope : What elements below the baseObject to search. This can be BaseObject (search just the named entry, typically used to read one entry), singleLevel (entries immediately below the base DN), or wholeSubtree (the entire subtree starting at the base DN).

Note that a common misconception is that LDAP data is case-insensitive, whereas in fact matching rules and ordering rules determine matching, comparisons, and relative value relationships

; attributes : Which attributes to return in result entries.

; sizeLimit, timeLimit : Maximum number of entries to return, and maximum time to allow search to run. These values, however, cannot override any restrictions the server places on size limit and time limit.

; typesOnly : Return attribute types only, not attribute values.

The server returns the matching entries and potentially continuation references. These may be returned in any order. The final result will include the result code.

The Compare operation takes a DN, an attribute name and an attribute value, and checks if the named entry contains that attribute with that value.

LDAP - Modify The MODIFY operation is used by LDAP clients to request that the LDAP server make changes to existing entries.[ Modify Section of RFC4511] Attempts to modify entries that do not exist will fail. MODIFY requests are subject to access controls as implemented by the server.

LDAP - Modify The MODIFY operation requires that the distinguished name (DN) of the entry be specified, and a sequence of changes. Each change in the sequence must be one of:

* add (add a new value, which must not already exist in the entry)
LDAP - Modify * add (add a new value, which must not already exist in the entry)

LDAP - Modify LDAP Data Interchange Format|LDIF example of adding a value to an attribute:

LDAP - Modify To replace the value of an existing attribute, Use the replace keyword. If the attribute is multi-valued, the client must specify the value of the attribute to delete.

LDAP - Modify To delete an attribute from an entry, use the keyword delete and the changetype designator modify. If the attribute is multi-valued, the client must specify the value of the attribute to delete.

LDAP - Modify There is also a modify-increment extension which allows an incrementable attribute value to be incremented by a specified amount. The modify-increment extension uses object identifier The following example using LDIF increments employeeNumber by 5:

dn: uid=user.0,ou=people,dc=example,dc=com
LDAP - Modify dn: uid=user.0,ou=people,dc=example,dc=com

LDAP - Modify An LDAP client should not assume that it connects to the same directory server for each request because architects may have placed load-balancers or LDAP proxies or both between LDAP clients and servers.

LDAP - Modify DN Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name), optionally the new parent's DN, and a flag that says whether to delete the value(s) in the entry that match the old RDN. The server may support renaming of entire directory subtrees.

LDAP - Modify DN An update operation is atomic: Other operations will see either the new entry or the old one. On the other hand, LDAP does not define transactions of multiple operations: If you read an entry and then modify it, another client may have updated the entry in the meantime. Servers may implement extensions[ INTERNET-DRAFT LDAP Transactions draft-zeilenga-ldap-txn-15.txt ] that support this, though.

LDAP - Extended operations
The Extended Operation is a generic LDAP operation that can define new operations that were not part of the original protocol specification. StartTLS is one of the most significant extensions. Other examples include Cancel and Password Modify.

LDAP - StartTLS The StartTLS operation establishes Transport Layer Security (the descendant of Transport Layer Security|SSL) on the connection

LDAP - StartTLS Servers also often support the non-standard LDAPS (Secure LDAP, commonly known as LDAP over SSL) protocol on a separate port, by default LDAPS differs from LDAP in two ways:

LDAP - StartTLS 1) upon connect, the client and server establish TLS before any LDAP messages are transferred (without a StartTLS operation) and

2) the LDAPS connection must be closed upon TLS closure.
LDAP - StartTLS 2) the LDAPS connection must be closed upon TLS closure.

LDAP - StartTLS It should be noted that some LDAPS client libraries only encrypt communication, they do not check the host name against the name in the supplied certificate.[ Shibboleth Security alert ]

LDAP - Abandon The Abandon operation requests that the server abort an operation named by a message ID. The server need not honor the request. Neither Abandon nor a successfully abandoned operation send a response. A similar Cancel extended operation does send responses, but not all implementations support this.

LDAP - Unbind The Unbind operation abandons any outstanding operations and closes the connection. It has no response. The name is of historical origin, and is not the opposite of the Bind operation.[ Tools.ietf.org]

LDAP - Unbind Clients can abort a session by simply closing the connection, but they should use Unbind.[ Tools.ietf.org] Unbind allows the server to gracefully close the connection and free resources that it would otherwise keep for some time until discovering the client had abandoned the connection

LDAP - LDAP URLs An LDAP Uniform Resource Locator|URL format exists, which clients support in varying degrees, and servers return in referrals and continuation references (see RFC 4516):

ldap://host:port/DN?attributes?scope?filter?extensions
LDAP - LDAP URLs ldap://host:port/DN?attributes?scope?filter?extensions

LDAP - LDAP URLs * host is the Fully qualified domain name|FQDN or IP address of the LDAP server to search.

* port is the network port (default port 389) of the LDAP server.
LDAP - LDAP URLs * port is the network port (default port 389) of the LDAP server.

* DN is the distinguished name to use as the search base.
LDAP - LDAP URLs * DN is the distinguished name to use as the search base.

* attributes is a comma-separated list of attributes to retrieve.
LDAP - LDAP URLs * attributes is a comma-separated list of attributes to retrieve.

LDAP - LDAP URLs * scope specifies the search scope and can be base (the default), one or sub.

* extensions are extensions to the LDAP URL format.
LDAP - LDAP URLs * extensions are extensions to the LDAP URL format.

LDAP - LDAP URLs For example, ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com refers to all user attributes in John Doe's entry in ldap.example.com, while ldap:///dc=example,dc=com??sub?(givenName=John) searches for the entry in the default server (note the triple slash, omitting the host, and the double question mark, omitting the attributes). As in other URLs, special characters must be percent-encoding|percent-encoded.

LDAP - Schema The contents of the entries in a subtree are governed by a logical schema|directory schema, a set of definitions and constraints concerning the structure of the directory information tree (DIT).

LDAP - Schema The schema of a Directory Server defines a set of rules that govern the kinds of information that the server can hold. It has a number of elements, including:

LDAP - Schema * Attribute Syntaxes—Provide information about the kind of information that can be stored in an attribute.

LDAP - Schema * Matching Rules—Provide information about how to make comparisons against attribute values.

LDAP - Schema * Matching Rule Uses—Indicate which attribute types may be used in conjunction with a particular matching rule.

LDAP - Schema * Attribute Types—Define an object identifier (OID) and a set of names that may be used to refer to a given attribute, and associates that attribute with a syntax and set of matching rules.

LDAP - Schema * Object Classes—Define named collections of attributes and classify them into sets of required and optional attributes.

LDAP - Schema * Name Forms—Define rules for the set of attributes that should be included in the RDN for an entry.

LDAP - Schema * Content Rules—Define additional constraints about the object classes and attributes that may be used in conjunction with an entry.

LDAP - Schema * Structure Rule—Define rules that govern the kinds of subordinate entries that a given entry may have.

LDAP - Schema Attributes are the elements responsible for storing information in a directory, and the schema defines the rules for which attributes may be used in an entry, the kinds of values that those attributes may have, and how clients may interact with those values.

LDAP - Schema Clients may learn about the schema elements that the server supports by retrieving an appropriate subschema subentry.

LDAP - Schema The schema defines object classes. Each entry must have an objectClass attribute, containing named classes defined in the schema. The schema definition of the classes of an entry defines what kind of object the entry may represent - e.g. a person, organization or domain. The object class definitions also define the list of attributes that must contain values and the list of attributes which may contain values.

LDAP - Schema A parallel to the schema of an objectClass is a Class (computer science)|class definition and an Instantiation (computer science)|instance in Object-oriented programming, representing LDAP objectClass and LDAP entry, respectively.

LDAP - Schema Directory servers may publish the directory schema controlling an entry at a base DN given by the entry's subschemaSubentry operational attribute. (An operational attribute describes operation of the directory rather than user information and is only returned from a search when it is explicitly requested.)

LDAP - Schema Server administrators can add additional schema entries in addition to the provided schema elements. A schema for representing individual people within organizations is termed a white pages schema.

LDAP - Variations A lot of the server operation is left to the implementor or administrator to decide. Accordingly, servers may be set up to support a wide variety of scenarios.

LDAP - Variations For example, data storage in the server is not specified - the server may use flat files, databases, or just be a gateway to some other server. Access control is not standardized, though there has been work on it and there are commonly used models. Users' passwords may be stored in their entries or elsewhere. The server may refuse to perform operations when it wishes, and impose various limits.

LDAP - Variations Most parts of LDAP are extensible. Examples: One can define new operations. Controls may modify requests and responses, e.g. to request sorted search results. New search scopes and Bind methods can be defined. Attributes can have options that may modify their semantics.

LDAP - Other data models
As LDAP has gained momentum, vendors have provided it as an access protocol to other services. The implementation then recasts the data to mimic the LDAP/X.500 model, but how closely this model is followed varies. For example, there is software to access SQL databases through LDAP, even though LDAP does not readily lend itself to this.[ Openldap.org] X.500 servers may support LDAP as well.

Similarly, data previously held in other types of data stores are sometimes moved to LDAP directories. For example, Unix user and group information can be stored in LDAP and accessed via Pluggable Authentication Modules|PAM and Name Service Switch|NSS modules. LDAP is often used by other services for authentication.

An example of such data model is the GLUE Schema,[ SourceForge : Project Home] which is used in a distributed information system based on LDAP that enable users, applications and services to discover which services exist in a Grid infrastructure and further information about their structure and state.

LDAP - Usage An LDAP server may return referrals to other servers for requests that it cannot fulfill itself. This requires a naming structure for LDAP entries so one can find a server holding a given DN or distinguished name, a concept defined in the X.500 Directory and also used in LDAP. Another way of locating LDAP servers for an organization is a DNS server resource record (SRV).

LDAP - Usage An organization with the domain example.org may use the top level LDAP DN dc=example,dc=org (where dc means domain component). If the LDAP server is also named ldap.example.org, the organization's top level LDAP URL becomes ldap://ldap.example.org/dc=example,dc=org.

LDAP - Usage Primarily two common styles of naming are used in both X.500 [2008] and LDAPv3

Multi-master replication - OpenLDAP
The widely used open source LDAP server implements multi-master replication since its version 2.4 (October 2007) [

Directory service - LDAP implementations
* 'Active Directory:' Microsoft's modern directory service for Windows, originating from the X.500 directory, created for use in Exchange Server, first shipped with Windows 2000 Server and is supported by successive versions of Windows.

* 'Novell eDirectory|eDirectory:' This is Novell's implementation of directory services. It supports multiple architectures including Microsoft Windows|Windows, NetWare, Linux and several flavours of Unix and has long been used for user administration, configuration management, and software management. eDirectory has evolved into a central component in a broader range of Identity management products. It was previously known as Novell Directory Services.

* 'Red Hat Directory Server:' Red Hat released a directory service, that it acquired from AOL's 'Netscape Security Solutions' unit,[ ] as a commercial product running on top of Red Hat Enterprise Linux called Red Hat Directory Server and as the community supported 389 Directory Server project.

ViewDS is LDAPv3 compliant and is also the world's first Directory to support the XACML[ XACML-based directory server]

* 'Open Directory:' Apple Computer|Apple's Mac OS X Server uses a directory service named Apple Open Directory|Open Directory, which implements Lightweight Directory Access Protocol|LDAP using a customized build of OpenLDAP and integrates support for both Simple Authentication and Security Layer|SASL and Kerberos (protocol)|Kerberos authentication. It uses a plugins architecture to work with other LDAPv3 directories, including proprietary solutions like Active Directory and eDirectory.

* 'Apache Directory Server:' Apache Software Foundation offers a directory service called Apache Directory Server|ApacheDS.

* 'CA Directory:' CA Directory contains pre-caching engine which can index all attributes that are used in LDAP search filters, and caching all attributes returned in search results.

* 'Alcatel-Lucent Directory Server:' CTIA G Service Creation Development Award Winner offering enhanced performance, high availability and proven efficiencies

* 'Sun Java System Directory Server:' Sun Microsystems' current directory service offering

* 'OpenDS:' An open source directory service implementation from scratch in Java, backed by Sun Microsystems

* 'IBM Tivoli Directory Server' It is a customized build of an old release of OpenLDAP.

* 'OpenLDAP' Derived from the original University of Michigan reference LDAP implementation (as are the Netscape/Red Hat/Fedora/Sun JSDS servers) but significantly evolved. It supports all current computer architectures, including Unix and Unix derivatives, Linux, Windows, z/OS, and a variety of embedded/realtime systems.

There are also plenty of open-source tools to create directory services, including OpenLDAP and the Kerberos (protocol)|Kerberos protocol, and Samba software which can act as a Windows Domain Controller with Kerberos (protocol)|Kerberos and LDAP backends. Administration is done using GOsa or Samba provided Samba software|SWAT.

OpenLDAP Several common Linux distributions include OpenLDAP Software for LDAP support

OpenLDAP - Project history and core team
The OpenLDAP Project was started in 1998 by Kurt Zeilenga. The project started by cloning the LDAP reference source from the University of Michigan where a long-running project had supported development and evolution of the LDAP protocol until that project's final release in 1996.

OpenLDAP - Project history and core team
As of April, 2006, the OpenLDAP Project has three Core Team members: Howard Chu (Chief Architect), Pierangelo Masarati, and Kurt Zeilenga. There are numerous other important and active contributors including Luke Howard, Hallvard Furuseth, Quanah Gibson-Mount, and Gavin Henry.

OpenLDAP - Components of OpenLDAP Software
* slapd – stand-alone LDAP daemon (computer software)|daemon and associated modules and tools,

* libraries implementing the LDAP Protocol (computing)|protocol and ASN.1 Basic Encoding Rules (BER), and

Additionally, the OpenLDAP Project is home to a number of subprojects:

OpenLDAP - Overall concept
Historically the OpenLDAP server (slapd, the Standalone LDAP Daemon) architecture was

backend which deals strictly with data storage. This split design was a feature of the

original University of Michigan code written in 1996http:// and carried on in all subsequent

OpenLDAP releases. The original code included one main database backend and two

experimental/demo backends. The architecture is modular and many

different backends are now available for interfacing to other technologies, not just

Note: In older (1.x) releases, the terms backend and database were often used interchangeably.

backend. The slapd server can use arbitrarily many backends at once, and can have arbitrarily

OpenLDAP - Available backends
Currently 16 different backends are provided in the OpenLDAP distribution, and various

** back-bdb: the first transactional backend for OpenLDAP, built on BerkeleyDB

** back-hdb: a variant of back-bdb that is fully hierarchical and supports subtree renames

** back-ldif: built on plain text LDIF files

** back-mdb: a transactional backend built on OpenLDAP's [ Lightning] memory-mapped database (MDB)

** back-ndb: a transactional backend built on MySQL's NDB cluster engine

** back-meta: proxy with meta-directory features

** back-passwd: uses a Unix system's passwd and group data

** back-null: a sink/no-op backend, analogous to Unix /dev/null

** back-perl: invokes arbitrary perl modules in response to LDAP requests

** back-shell: invokes shell scripts for LDAP requests

** back-sock: forwards LDAP requests over IPC to arbitrary daemons

Some backends available in older OpenLDAP releases have been retired from use,

most notably back-ldbm which was inherited from the original UMich code, and

Support for other backends will soon be withdrawn as well. back-ndb is deprecated now since the partnership with MySQL that led to its development was terminated by Oracle after Oracle acquired MySQL. back-bdb and back-hdb will be deprecated in favor of back-mdb soon since back-mdb is superior in all aspects of performance, reliability, and manageability.

In practice, backends like -perl, -shell, and -sock allow interfacing to any arbitrary programming language, thus providing limitless capabilities for customization and expansion. In effect the slapd server becomes an RPC engine with a compact,

well-defined and ubiquitous API.

When the backend completes a request, it returns a result to the frontend, which then sends the result to the LDAP client

Overlays provide a simple means to augment the functionality of a database without requiring that an entirely new backend be written, and allow new functionalities to be added in compact, easily debuggable and maintainable modules. Since the introduction

of the overlay feature in OpenLDAP 2.2 many new overlays have been contributed from the OpenLDAP community.

OpenLDAP - Available overlays
Currently there are 21 overlays in the core OpenLDAP distribution, with another 15 overlays in the user-contributed code section, and more awaiting approval for inclusion.

* The core overlays include:

** auditlog: log server activity in a flat text file

** collect: implement X.500-style collective attributes (aka Netscape Class Of Service)

** constraint: restrict the acceptable values for particular attributes

** deref: return information about entries referenced in a given search result

** dyngroup: simple dynamic group support

** dynlist: more sophisticated dynamic group support plus more

** memberof: support for memberOf and similar backlink attributes

** pcache: cache search results, mainly to improve performance for proxied servers

** ppolicy: LDAP Password Policy – password quality, expiration, etc.

** retcode: set predetermined return codes for various operations; used for client debugging

** rwm: rewrite module, for various alterations of LDAP data

** seqmod: serialize writes to individual entries

** sssvlv: Server Side Sorting and Virtual List Views

** translucent: Semi-transparent pass-through, for locally augmenting data on a proxied server

** unique: for enforcing uniqueness of attribute values within a tree

** valsort: maintain various sort orders for values of an attribute

* The contrib overlays include:

** addpartial: receive Add requests and turn them into Modifies if the target entry already exists

** allop: returns all operational attributes, for clients that don't know how to request them

** autogroup: dynamically managed static groups

** cloak: hide attributes unless explicitly requested in a search

** denyop: reject arbitrarily configured requests

** lastbind: record the timestamp of a user's last successful authentication

** nops: filter out redundant modifies

** noopsrch: count entries that would be returned by a search

** nssov: Answer NSS and PAM requests directly in slapd, replaces nss-ldap and pam-ldap.

** proxyOld: support an obsolete encoding of ProxyAuthz used by Sun et al.

** usn: Update Sequence Numbers (as in Microsoft AD, not yet released)

OpenLDAP - Other modules
Backends and overlays are the two most commonly used types of modules. Backends were typically built into the slapd binary,

but they may also be built as dynamically loaded modules, and overlays are usually built as dynamic modules. In addition,

slapd supports dynamic modules for implementing new LDAP syntaxes, matching rules, controls, and extended operations, as

well as for implementing custom access control mechanisms and password hashing mechanisms.

OpenLDAP also supports SLAPI, the plugin architecture used by Sun and Netscape/Fedora/Red Hat. In current releases,

the SLAPI framework is implemented inside a slapd overlay. While many plugins written for Sun/Netscape/Fedora/Red Hat

are compatible with OpenLDAP, very few members of the OpenLDAP community use SLAPI.

OpenLDAP - Available modules
* Native slapd modules

** acl/posixgroup – support posixGroup membership in access controls

** comp_match – support component-based matching

** passwd/ – additional password hashing mechanisms. Currently includes Kerberos, Netscape, RADIUS, and SHA2.

** addrdnvalue – add RDN value to an entry if it was omitted in an Add request

OpenLDAP - Release summary
The major (functional) releases of OpenLDAP Software include:

* OpenLDAP Version 1 was a general clean-up of the last release from the University of Michigan project (release 3.3), and consolidation of additional changes.

* OpenLDAP Version 2.0, released in August 2000, included major enhancements including LDAP version 3 (LDAPv3) support, Internet Protocol version 6 (IPv6) support, and numerous other enhancements.

* OpenLDAP Version 2.1, released in June 2002, included the transactional database backend (based on Berkeley DB|Berkeley Database or BDB), Simple Authentication and Security Layer (SASL) support, and Meta, Monitor, and Virtual experimental backends.

* OpenLDAP Version 2.2, released in December 2003, included the LDAP sync Engine with replication support (syncrepl), the overlay interface, and numerous database and RFC-related functional enhancements.

* OpenLDAP Version 2.3, released in June 2005, included the Configuration Backend (dynamic configuration), additional overlays including RFC-compliant Password Policy software, and numerous additional enhancements.

* OpenLDAP Version 2.4, released in October 2007, introduced N-way MultiMaster replication, Stand-by master, and the ability to delete and modify Schema elements on the fly, plus many more.

OpenLDAP - Replication
OpenLDAP supports replication using Content Synchronization as specified in RFC This spec is hereafter referred to as syncrepl. In addition to the base specification, an enhancement known as delta-syncrepl is also supported. Additional enhancements have been implemented to support multi-master replication.

OpenLDAP - syncrepl In the OpenLDAP implementation of the RFC 4533, this cookie includes the latest CSN that has been received from the provider (called the contextCSN).

OpenLDAP - syncrepl The provider then returns as search results (or, see optimization below, sync info replies) the present (unchanged entry only used in the present phase of the refresh stage) (no attributes), added, modified (represented in the refresh phase as an add with all current attributes), or deleted (no attributes) entries to put the consumer into a synchronized state based on what is known via their cookie

OpenLDAP - syncrepl The search can be done in either refresh or refreshAndPersist mode, which implies what stages occur

The present phase is differentiated from the delete phase as follows
OpenLDAP - syncrepl The present phase is differentiated from the delete phase as follows

OpenLDAP - syncrepl Once the persist stage begins, the provider sends search results that indicate only the add, modify and delete of entries (no present unchanged entry indications) for those entries changed since the refresh stage completed

OpenLDAP - delta-syncrepl
This protocol keeps a persistent database of write accesses (changes) and can represent each modify precisely (meaning only the attributes that have changed). It is still built on the standard syncrepl specification, which always sends changes as complete entries. But in delta-syncrepl, the transmitted entries are actually sent from a log database, where each change in the main database is recorded as a log entry. The log entries are recorded using the LDAP Log Schema.

AAA protocol - Usage of AAA servers in LDAP networks
AAA servers in Code division multiple access|CDMA data networks are entities that provide Internet Protocol (IP) functionality to support the functions of authentication, authorization and accounting. The AAA server in the CDMA wireless data network architecture is similar to the Home_Location_Register#Home_location_register_.28HLR.29|HLR in the CDMA wireless voice network architecture.

*'Access Network AAA (AN-AAA)' – Communicates with the Radio Network Controller|RNC in the Access Network (AN) to enable authentication and authorization functions to be performed at the AN. The interface between AN and AN-AAA is known as the A12 Authentication|A12 interface.

*'Broker AAA (B-AAA)' – Acts as an intermediary to proxy AAA traffic between roaming partner networks (i.e., between the H-AAA server in the home network and V-AAA server in the serving network). B-AAA servers are used in CRX networks to enable CRX providers to offer billing settlement functions.

*'Home AAA (H-AAA)' – The AAA server in the roamer's home network. The H-AAA is similar to the HLR in voice. The H-AAA stores user profile information, responds to authentication requests, and collects accounting information.

*'Visited AAA (V-AAA)' – The AAA server in the visited network from which a roamer is receiving service. The V-AAA in the serving network communicates with the H-AAA in a roamer's home network. Authentication requests and accounting information are forwarded by the V-AAA to the H-AAA, either directly or through a B-AAA.

Current AAA servers communicate using the RADIUS protocol. As such, Telecommunications Industry Association|TIA specifications refer to AAA servers as RADIUS servers. However, future AAA servers are expected to use a successor protocol to RADIUS known as Diameter (protocol)|Diameter.

The behavior of AAA servers (radius servers) in the CDMA2000 wireless IP network is specified in TIA-835.

LDAP Data Interchange Format
The 'LDAP Data Interchange Format' ('LDIF') is a standard plain text data interchange format for representing Lightweight Directory Access Protocol|LDAP (Lightweight Directory Access Protocol) directory content and update requests. LDIF conveys directory content as a set of records, one record for each object (or entry). It also represents update requests, such as Add, Modify, Delete, and Rename, as a set of records, one record for each update request.

LDIF was designed in the early 1990s by Tim Howes, Mark C. Smith, and Gordon Good while at the University of Michigan. LDIF was updated and extended in the late 1990s for use with Version 3 of LDAP. This later version of LDIF is called version 1 and is formally specified in RFC 2849, an Internet Engineering Task Force|IETF Standard Track Request for Comment|RFC. RFC 2849, authored by Gordon Good, was published in June 2000 and is currently a Proposed Standard.

A number of extensions to LDIF have been proposed over the years. One extension has been formally specified by the IETF and published. RFC 4525, authored by Kurt Zeilenga, extended LDIF to support the LDAP Modify-Increment extension. It is expected that additional extensions will be published by the IETF in the future.

LDAP Data Interchange Format - Content Record Format
Each content record is represented as a group of attributes, with records separated from one another by blank lines

LDAP Data Interchange Format - LDIF fields
This refers to the name that uniquely identifies an entry in the directory.

This refers to each component of the domain. For example would be written as DC=www,DC=google,DC=com

This refers to the organizational unit (or sometimes the user group) that the user is part of. If the user is part of more than one group, you may specify as such, e.g., OU= Lawyer,OU= Judge.

This refers to the individual object (person's name; meeting room; recipe name; job title; etc.) for whom/which you are querying.

LDAP Data Interchange Format - Examples of LDIF
This is an example of a simple directory entry with several attributes, represented as a record in LDIF:

This is an example of an LDIF record that modifies multiple single-valued attributes for two different directory entries (this format is used by Microsoft's LDIFDE tool):

dn: CN=John Smith,OU=Legal,DC=example,DC=com

replace: extensionAttribute6

dn: CN=Jane Smith,OU=Accounting,DC=example,DC=com

Note: the - character between each attribute change is required. Also note that each directory entry ends with a - followed by a blank line. The final - is required.

This is an example of an LDIF file that adds a telephone number to an existing user:

dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=US

LDAP Application Program Interface
The 'LDAP Application Program Interface', described by 'RFC 1823', is an Informational Request for Comments|RFC that specifies an application programming interface in the C (programming language)|C programming language for version 2 of the Lightweight Directory Access Protocol. Version 2 of LDAP is historic. Commonly available LDAP C APIs do not strictly adhere to this specification.

Directory services - LDAP implementations
* 'Apache Directory Server:' Directory service written in Java, supporting LDAP, Kerberos 5 and the Change Password Protocol. LDAPv3 certified. The Apache Directory Server is also a top level project of the Apache Software Foundation.

* 'NetIQ eDirectory|eDirectory:' This is NetIQ's implementation of directory services. It supports multiple architectures including Microsoft Windows|Windows, NetWare, Linux and several flavours of Unix and has long been used for user administration, configuration management, and software management. eDirectory has evolved into a central component in a broader range of Identity management products. It was previously known as Novell Directory Services.

* 'Red Hat Directory Server:' Red Hat released a directory service, that it acquired from AOL's 'Netscape Security Solutions' unit,[ ] as a commercial product running on top of Red Hat Enterprise Linux called Red Hat Directory Server and as the community supported 389 Directory Server project.

There are also plenty of open-source tools to create directory services, including OpenLDAP and the Kerberos (protocol)|Kerberos protocol, and Samba software, which can act as a Windows Domain Controller with Kerberos (protocol)|Kerberos and LDAP backends. Administration is done using GOsa or Samba provided Samba software|SWAT.

Ambiguous name resolution - LDAP ANR
The Lightweight Directory Access Protocol LDAP uses default attributes flagged for ambiguous name resolution to filter results of an input query. In Microsoft Active Directory the searchFlags attribute is a bit flag that defines special properties related to searching with the attribute.

Ambiguous name resolution - LDAP ANR
In Windows 2000 the following attributes are set by default for ANR:

List of LDAP software The following is a list of software programs that can communicate with and/or host directory services via the Lightweight Directory Access Protocol (LDAP).

List of LDAP software - Cross-platform
* [ Admin4] - an open source LDAP browser and directory client for Linux, OS X, and Microsoft Windows, implemented in Python (programming language)|Python.

* Apache Directory Server|Apache Directory Server/Studio - an LDAP browser and directory client for Linux, OS X, and Microsoft Windows, and as a plug-in for the Eclipse (software)|Eclipse development environment.

* [ COGNITUM] - a J2EE development platform that enables the rapid design and deployment of business applications and web services based on directories and relational databases.

* FusionDirectory, a web application under license Gplv2#Version 2|GNU General Public License developed in PHP for managing LDAP directory and associated services.

* JXplorer - a Java (programming language)|Java-based browser that runs in any operating environment.

* JXWorkBench - a Java (programming language)|Java-based plugin to JXplorer that includes directory reporting using the JasperReports reporting engine.

* LDAP Account Manager - a PHP based webfrontend for managing various account types in an LDAP directory.

* SLAMD - an open source load generation software suite, for testing multiple application protocols, including LDAP. Also contains tools for creating test data and test scripts.

* RoundCube - an open source and free PHP IMAP client with support with LDAP based address books.

* Teleform - a document imaging tool with support for LDAP based authentication.

* Kofax Capture - a document imaging tool with support for LDAP based authentication.

* GOsa² - provides a powerful framework for managing accounts and systems in LDAP databases

* [ Atlassian Crowd] - Crowd provides single sign-on (SSO) across a number of applications.

List of LDAP software - Linux/UNIX
* Evolution (software)|Evolution - the contacts part of GNOME's PIM can query LDAP servers.

* KAddressBook - the address book application for KDE, capable of querying LDAP servers.

* [ Ldapscripts] - Shell scripts to manage POSIX accounts in an OpenLDAP directory

List of LDAP software - OS X
* Contacts (application)|Contacts - an LDAP-aware address book application built into Mac OS X.

* Directory Utility - a utility for configuring access to several types of directory servers, including LDAP; built into Mac OS X.

* Workgroup Manager - a utility for configuring access to several types of directory servers, including LDAP; built into Mac OS X Server and one of Apple's Server Admin Tools.

List of LDAP software - Microsoft Windows
* Ldap admin|LDAP Admin - a free, open source LDAP directory browser and editor

List of LDAP software - Middleware
* [ Rest2LDAP] - a Representational state transfer|REST-to-LDAP gateway (computer program)|gateway

Linux adoption - LDAP servers
There are various freely available implementations of List of LDAP software#SERVER|LDAP servers. Additionally, Univention Corporate Server, as an integrated management system based on Debian, supports the functions provided by Microsoft Active directory for the administration of computers running Microsoft Windows.

Slavery in the colonial United States - San Miguel de Gualdape
The first enslaved Africans arrived in what is now the United States as part of the San Miguel de Gualdape colony (most likely located in the Winyah Bay area of present-day South Carolina), founded by Spanish explorer Lucas Vásquez de Ayllón in 1526

Slavery in the colonial United States - San Miguel de Gualdape
In 1565, the colony of Saint Augustine in Florida, founded by Pedro Menéndez de Avilés became the first permanent European settlement in North America, and included an unknown number of free and enslaved Africans that were part of this colonial expedition.

Remote Supervisor Adapter - LDAP authentication generally unusable
LDAP authentication fails if a user is a member of more than one posixGroup, which is usually the case in non-trivial directories. IBM privately acknowledged the problem has existed for over four years, but still has not published a fix. The problem is that it considers only first posixGroup in resultset, so if you manage to reorganize directory to return your matching group first, you can succeed on the auth (with openldap ldif dump, delete and restore tends to keep results ordered).

Jaldapara National Park
Today, it has the largest population of the Indian rhinoceros|Indian one horned rhinoceros in the state, an animal threatened with extinction, and is a Habitat management area (Category IV).[ Jaldapara Wildlife Sanctuary, India] The nearby Chilapata Forests is an elephant corridor between Jaldapara and the Buxa Tiger Reserve[ Wildlife Times: Elephants of North Bengal] Near by is the Gorumara National Park, known for its population of Indian rhinoceros.

Jaldapara National Park - History
Toto tribes used to stay in this area before At that time this place was known as “Totapara”. Jaldapara Wildlife Sanctuary was established in 1941 for the purpose of protecting the Indian one-horned rhinoceros. In May 2012 it was declared a national park.

Jaldapara National Park - Flora and fauna
The forest is mainly savannah covered with tall elephant grasses. The main attraction of the park is the Indian rhinoceros|Indian one-horned rhinoceros. The park holds the largest rhino population in India after Kaziranga National Park in Assam. Other animals in the park include leopard, elephants, sambar (deer)|sambar, muntjac|barking deer, chital|spotted deer, hog deer, wild pigs, and bison.

Jaldapara National Park - Flora and fauna
Jaldapara is a paradise for bird watchers. It is one of the very few places in India, where the Bengal florican is sighted. The other birds to be found here are the crested eagle, Pallas's fish eagle, shikra, Finn's weaver, jungle fowl, peafowl (peacock), partridge, and Malabar pied hornbill|lesser pied hornbill. Python (genus)|Pythons, monitor lizards, kraits, cobras, geckos, and about eight species of fresh water turtles can also be found here.

For More Information, Visit:
The Art of Service

LDAP https://store.theartofservice.com/itil-2011-foundation-complete-certification-kit-fourth-edition-study-guide-ebook-and-online-course.html.

Similar presentations

Presentation on theme: "LDAP https://store.theartofservice.com/itil-2011-foundation-complete-certification-kit-fourth-edition-study-guide-ebook-and-online-course.html."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

LDAP https://store.theartofservice.com/itil-2011-foundation-complete-certification-kit-fourth-edition-study-guide-ebook-and-online-course.html.

Similar presentations

Presentation on theme: "LDAP https://store.theartofservice.com/itil-2011-foundation-complete-certification-kit-fourth-edition-study-guide-ebook-and-online-course.html."— Presentation transcript:

Similar presentations

About project

Feedback