This action might not be possible to undo. Are you sure you want to continue?
The Lightweight Directory Access Protocol (LDAP; /ˈɛldæp/) is an application protocol for reading and editing directories over an IP network. A directory in this sense is an organized set of records: for example, a telephone directory is an alphabetical list of persons and organizations with an address and phone number in each "record". The latest version of LDAP is Version 3, which is specified in a series of Internet Engineering Task Force (IETF) Standard Track Requests for comments (RFCs) as detailed in RFC 4510.
Origin and influences
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, a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s. 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. 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. The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of Isode Limited, and Wengyik Yeong of Performance Systems International, circa 1993. Mark Wahl of Critical Angle Inc., Tim Howes, and Steve Kille started work in 1996 on a new version of LDAP, LDAPv3, under the aegis of the Internet Engineering Task Force (IETF). LDAPv3, first published in 1997, superseded LDAPv2 and added support for extensibility, integrated the Simple Authentication and Security Layer, and better aligned the protocol to the 1993 edition of X.500. Further development of the LDAPv3 specifications themselves and of numerous extensions adding features to LDAPv3 has come through the IETF. 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 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).
however.g. which follow the 1993 edition of the X. The attributes are defined in a schema (see below). It uses textual representations for a number of ASN. Be aware that a DN may change over the lifetime of the entry.dc=example. • Each entry has a unique identifier: its Distinguished Name (DN). LDAP is defined in terms of ASN.LDAP 2 Protocol overview A client starts an LDAP session by connecting to an LDAP server. then myfile.dc=com cn: John Doe givenName: John . A common alternate method of securing LDAP communication is using an SSL tunnel. a UUID might be provided in the set of the entry's operational attributes. the client does not need to wait for a response before sending the next request. called a Directory System Agent (DSA). This consists of its Relative Distinguished Name (RDN). Directory structure The protocol accesses LDAP directories.500 model: • A directory is a tree of directory entries. when entries are moved within a tree. before it times out a connection. e. which was officially retired in 2003. The client then sends an operation request to the server. With some exceptions. Think of the DN as the full file path and the RDN as its relative filename in its parent folder (e. and the server sends responses in return. if C:\foo\bar\myfile.g.txt would be the RDN). and protocol messages are encoded in the binary format BER. This usage has been deprecated along with LDAPv2. constructed from some attribute(s) in the entry. followed by the parent entry's DN. for instance. The client may request the following operations: • • • • • • • • • • Start TLS — use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection Bind — authenticate and specify LDAP protocol version Search — search for and/or retrieve directory entries Compare — test if a named entry contains a given attribute value Add a new entry Delete an entry Modify an entry Modify Distinguished Name (DN) — move or rename an entry Abandon — abort a previous request Extended Operation — generic operation used to define other operations • Unbind — close the connection (not the inverse of Bind) In addition the server may send "Unsolicited Notifications" that are not responses to any request. • An attribute has a name (an attribute type or attribute description) and one or more values. An entry can look like this when represented in LDAP Data Interchange Format (LDIF) (LDAP itself is a binary protocol): dn: cn=John Doe. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never standardized in any formal specification.txt were the DN. and the server may send the responses in any order. To reliably and unambiguously identify entries. by default on TCP port 389.1. The default port for LDAP over SSL is 636.1 fields/types. This is denoted in LDAP URLs by using the URL scheme "ldaps". • An entry consists of a set of attributes.
dc=com" and its children. "mail" for e-mail address and "sn" for surname. and sets need not be ordered. During TLS negotiation the server sends its X. for example where all modifies must be directed from replicas to a master directory. the client requests the server derive its identity from credentials provided at a lower level (such as TLS). It can provide data confidentiality (to protect data from being observed by third parties) and/or data integrity protection (which protects the data from tampering). by default 636. "dc=example. LDAP rarely defines any ordering: The server may return the values of an attribute. By using the SASL/EXTERNAL. A server holds a subtree starting from a specific entry. typically the server will use the identity information established by TLS. and the entries found by a search operation in any order. The use of LDAPS is deprecated. LDAPS was used with LDAPv2. Servers also often support the non-standard "LDAPS" ("Secure LDAP".dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top "dn" is the distinguished name of the entry. . especially modify. Servers may also hold references to other servers. like "cn" for common name. "cn=John Doe" is the entry's RDN (Relative Distinguished Name).dc=com" could return a referral or continuation reference to a server which holds that part of the directory tree. because the StartTLS operation had not yet been defined. "dc" for domain component. The client may also send a certificate to prove its identity.an entry is defined as a set of attributes.LDAP sn: Doe telephoneNumber: +1 888 555 6789 telephoneNumber: +1 888 555 1232 mail: firstname.lastname@example.org=example. 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. and an attribute is a set of values. where "dc" denotes 'Domain Component'. and "dc=example. commonly known as "LDAP over SSL") protocol on a separate port. LDAPS differs from LDAP in two ways: 1) upon connect. The other lines show the attributes in the entry. the client may then use SASL/EXTERNAL. which means the server contacts the other server and returns the results to the client. The client can then contact the other server.com manager: cn=Barbara Doe. Some servers also support chaining. the attributes in an entry. and modern software should only use StartTLS. e. Attribute names are typically mnemonic strings. This follows from the formal definitions . 3 Operations Expand discussion of referral responses to various operations. it's not an attribute nor part of the entry. After doing so.509 certificate to prove its identity. StartTLS The StartTLS operation establishes Transport Layer Security (the descendant of SSL) on the connection.g. so an attempt to access "ou=department.dc=com" is the DN of the parent entry.dc=example. Though technically the server may use any identity information established at any lower level.
The Compare operation takes a DN. an attribute name and an attribute value.g. Anonymous Bind (with empty DN and password) resets the connection to anonymous state. sizeLimit. which is the default in the protocol but not always in LDAP libraries. scope What elements below the baseObject to search. typically used to read one entry). and maximum time to allow search to run. SASL (Simple Authentication and Security Layer) Bind provides authentication services through a wide range of mechanisms. The server typically checks the password against the userPassword attribute in the named entry. not attribute values. Kerberos or the client certificate sent with TLS. Simple Bind can send the user's DN and password in plaintext.LDAP 4 Bind (authenticate) The Bind operation authenticates the client to the server. The final result will include the result code. attributes Which attributes to return in result entries. filter Criteria to use in selecting elements within scope. but is not required in LDAPv3 (the current LDAP version). and checks if the named entry contains that attribute with that value. timeLimit Maximum number of entries to return. Bind had to be the first operation in a session in LDAPv2. These may be returned in any order. The server returns the matching entries and potentially continuation references. typesOnly Return attribute types only. Normally clients should use LDAPv3. derefAliases Whether and how to follow alias entries (entries which refer to other entries). For example. the filter (&(objectClass=person)(|(givenName=John)(mail=john*))) will select "persons" (elements of objectClass person) who either have the given name "John" or an e-mail address that begins with the string "john". This can be BaseObject (search just the named entry. so the connection should be protected using Transport Layer Security (TLS). or wholeSubtree (the entire subtree starting at the base DN). e. Search and Compare The Search operation is used to both search for and read entries. . Bind also sets the LDAP protocol version. singleLevel (entries immediately below the base DN). Its parameters are: baseObject The DN (Distinguished Name) of the entry at which to start the search.
port is the network port of the LDAP server. and a flag which says whether to delete the value(s) in the entry which match the old RDN. LDAP does not define transactions of multiple operations: If you read an entry and then modify it. Servers may implement extensions  which support this. . are optional. add new values. and which servers return in referrals and continuation references (see RFC 4516): ldap://host:port/DN?attributes?scope?filter?extensions Most of the components. Examples include the Cancel and Password Modify. and Modify DN . Unbind The Unbind operation abandons any outstanding operations and closes the connection. A similar Cancel extended operation has therefore been defined which does send responses. 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. • extensions are extensions to the LDAP URL format. Extended operations The Extended Operation is a generic LDAP operation which can be used to define new operations. An update operation is atomic: Other operations will see either the new entry or the old one. LDAP URLs An LDAP URL format exists which clients support in varying degree. Clients can abort a session by simply closing the connection. and to not send responses for operations that cannot be canceled. Unfortunately. which are described below. or replace the current values with the new ones. The server may support renaming of entire directory subtrees. but not all implementations support this. On the other hand. The server need not honor the request. though. • • • • • • host is the FQDN or IP address of the LDAP server to search. Abandon The Abandon operation requests that the server abort an operation named by a message ID. attributes is a comma-separated list of attributes to retrieve. but they should use Unbind. Modify takes a list of attributes to modify and the modifications to each: Delete the attribute or some values. optionally the new parent's DN. "one" or "sub". Delete. neither Abandon nor a successfully abandoned operation send a response. The name is of historical origin. filter is a search filter.LDAP 5 Update Data Add. Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name). It also instructs the server to cancel operations that can be canceled. scope specifies the search scope and can be "base" (the default). another client may have updated the entry in the mean time.all require the DN of the entry that is to be changed. It has no response. and is not the opposite of the Bind operation. Add operations also can have additional attributes and values for those attributes. For example (objectClass=*) as defined in RFC 4515. DN is the distinguished name to use as the search base.
a person. • Object Classes—Define named collections of attributes and classify them into sets of required and optional attributes. There is a similar non-standard ldaps: URL scheme for LDAP over SSL. "ldap://ldap. organization or domain. • Content Rules—Define additional constraints about the object classes and attributes that may be used in conjunction with an entry. Each entry must have an objectClass attribute. an entry representing a person might belong to the classes "top" and "person". including: • • • • Attribute Syntaxes—Provide information about the kind of information that can be stored in an attribute. and associates that attribute with a syntax and set of matching rules. and how clients may interact with those values. A schema for representing individual people within organizations is termed a white pages schema. while "ldap:///dc=example. containing named classes defined in the schema. representing LDAP objectClass and LDAP entry. For example. 6 Schema The contents of the entries in a subtree are governed by a schema known as a directory information tree (DIT).dc=example. Clients may learn about the schema elements that the server supports by retrieving an appropriate subschema subentry.com/cn=John%20Doe. special characters must be percent-encoded. • Name Forms—Define rules for the set of attributes that should be included in the RDN for an entry.g.com. A parallel to the schema of an objectClass is a class definition and an instance in Object-oriented programming. The object class definitions also define the list of attributes that must contain values and the list of attributes which may contain values. the kinds of values that those attributes may have. Matching Rules—Provide information about how to make comparisons against attribute values.LDAP For example.example. Attribute Types—Define an OID and a set of names that may be used to refer to a given attribute. and the schema defines the rules for which attributes may be used in an entry.dc=com??sub?(givenName=John)" searches for the entry in the default server (note the triple slash. respectively. Directory servers may publish the directory schema controlling an entry at a base DN given by the entry's subschemaSubentry operational attribute. "telephoneNumber". and other attributes. The schema of a Directory Server defines a set of rules that govern the kinds of information that the server can hold. ObjectClasses can be inherited. It has a number of elements. The schema defines object classes. • Structure Rule—Define rules that govern the kinds of subordinate entries that a given entry may have. which is achieved using the StartTLS operation using the standard ldap: scheme. Matching Rule Uses—Indicate which attribute types may be used in conjunction with a particular matching rule.) Server administrators can add additional schema entries in addition to the provided schema elements. Membership in the "person" class would require the entry to contain the "sn" and "cn" attributes. Since entries may have multiple ObjectClasses values. (An operational attribute describes operation of the directory rather than user information and is only returned from a search when it is explicitly requested. and the double question mark. omitting the host. Attributes are the elements responsible for storing information in a directory. and a single entry can have multiple ObjectClasses values which define the available and required attributes of the entry itself. . This should not be confused with LDAP with TLS. omitting the attributes). and allow the entry also to contain "userPassword". As in other URLs. The schema definition of the classes of an entry defines what kind of object the entry may represent e.dc=com" refers to all user attributes in John Doe's entry in ldap.example. each entry has a complex of optional and mandatory attribute sets formed from the union of the object classes it represents.
g.500 model. For example. to request sorted search results.the server may use flat files. An "anonymous" and an "unauthenticated" Bind are different Bind methods that both produce anonymous authentication state. or the contents of an attribute in a directory. LDAP is often used by other services for authentication.500. other examples are due to its historical origins. X. Attributes can have options that may modify their semantics. An "attribute" may be the attribute type. the entry names will typically reflect the organization's internal structure or needs rather than DNS names.LDAP 7 Variations A lot of the server operation is left to the implementor or administrator to decide. . e. as they do in X. data which were previously held in other types of data stores are sometimes moved to LDAP directories. Access control is not standardized. Below the top level. Controls may modify requests and responses. other times to the protocol and the data. For example. Examples: One can define new operations.500 services that use different terminology.dc=org.dc=org (where dc means domain component). others arise when used with non-X. The server may refuse to perform operations when it wishes. Terminology The LDAP terminology one can encounter is rather cumbersome.org.example. so both terms are being used for both variants. Since such a structure already exists in the Domain name system (DNS). Similarly. For example. or an attribute description (an attribute type with options). or just be a gateway to some other server. Usage Naming structure Since an LDAP server can return referrals to other servers for requests the server itself will not/can not serve.500 servers may support LDAP as well. Other data models As LDAP has gained momentum. though there has been work on it and there are commonly used models. For example. but how closely this model is followed varies.org. and impose various limits. Users' passwords may be stored in their entries or elsewhere. Accordingly. even though LDAP does not readily lend itself to this. An "LDAP directory" may be the data or also the access point. If an organization has domain name example. a naming structure for LDAP entries is needed so one can find a server holding a given DN. New search scopes and Bind methods can be defined.example. If the LDAP server is also named ldap. vendors have provided it as an access protocol to other services. servers' top level names often mimic DNS names. databases. its top level LDAP entry will typically have the DN dc=example. Unix user and group information can be stored in LDAP and accessed via PAM and NSS modules. The implementation then recasts the data to mimic the LDAP/X. Most parts of LDAP are extensible. Some of this is due to misunderstandings. data storage in the server is not specified . servers may be set up to support a wide variety of scenarios. "LDAP" is sometimes used to refer to the protocol. the organization's top level LDAP URL becomes ldap://ldap.org/dc=example. there is software to access SQL databases through LDAP.
Good.iana.500 to X.uk (http://www.com/articles/ troubleshooting-ldap-ssl-connection-issues-between-microsoft-ilmmiis--novell-edirectory-873.skills-1st. and LDAP. and Administer LDAP Services. X.ietf.org (http:/ / www. LDAP schema design • Capitalhead.manning.org/assignments/sasl-mechanisms) registered at IANA • This article was originally based on material from the Free On-line Dictionary of Computing. LDAP Programming.informit.co. org/ html/ draft-zeilenga-ldapv2-04) INTERNET-DRAFT LDAP Transactions draft-zeilenga-ldap-txn-15. • Rhoton.3 • Prasannatech. LDAP System Administration (http://oreilly. org/ internet-drafts/ draft-zeilenga-ldap-txn-15.500 series .Specification of Basic Notation". 1994 • RFC 4346 . 1109/ MIC. • Donley. light introductory tutorial for LDAP. A simple.ietf.ietf. ietf.uk/papers/ldap-schema-design-feb-2005/index. Canonical. • Skills-1st.1 • RFC 4422 . J (1999). LDAP schema design .The TLS Protocol Version 1.com (http://web.690. B (2003). Understanding LDAP. txt) Tools.com/donley/).txt (http:/ / www. T. which is licensed under the GFDL.com/c/a/Administration/Understanding-LDAP-part-1/). X.com (http://www. org/ portal/ web/ csdl/ doi/ 10. O'Reilly Media. C (2002).521 Tools. ISBN 1565924916. 44) The X. LDAP Directories Explained: An Introduction and Analysis (http://www. Elsevier.aspx?isbn=0672323168). • Carter. 1) Openldap.1) . ietf.org (http:/ / tools. Manning Publications.devshed. org/ html/ rfc4511#section-3. computer. 2004.html). and Integration (http://www. Auerbach Publications.com/ ldapdesign. G (2003). External links • Devshed.A Case Study . • Howes.html). 1994 • Basic encoding rules (BER) . ISBN 1930110405.680.co. openldap. G (2003).org (http:/ / tools. Programmer's Guide to Internet Mail: SMTP.org/web/20080713040421/http://www. ietf. Further reading • Arkills. informit.prasannatech. M. IMAP. org/ html/ rfc4511#section-5. 3) Tools.ietf. "Abstract Syntax Notation One (ASN. X. ISBN 1555582125.ITU-T Rec.ITU-T Rec.com (http://capitalhead.Simple Authentication and Security Layer (SASL) • SASL mechanisms (http://www.org (http:/ / tools.org (http:/ / tools. Smith. and Distinguished Encoding Rules".aspx). and Trends (http:/ / www2. org/ doc/ admin24/ backends. 3) Tools. rfc-editor. Understanding and Deploying LDAP Directory Services (http://www. R (2003).com/store/product.7. Addison-Wesley Professional. Troubleshooting LDAP SSL connection issues between Microsoft ILM/MIIS & Novell eDirectory 8. ISBN 0672323168.LDAP 8 References         LDAP: Framework. POP. org/ html/ rfc4511#section-4. • Voglmaier.com/store/ product. Practices.1 encoding rules: Basic. "Specification of ASN. html#SQL) • ITU-T Rec.archive. Run. ISBN 0849313465.aspx?isbn=020178792X). Management. ISBN 020178792X. ietf.com/catalog/9781565924918). The ABCs of LDAP: How to Install. Addison-Wesley Professional.
Server Side Sorting of Search Results RFC 3045 .LDAP Client Update Protocol • RFC 4370 . RFC 2256.LDAPv3: All Operational Attributes RFC 3687 .LDAP: Directory Information Models (Obsoletes RFC 2251.com/linux-ldap-configuration.Language Tags and Ranges in LDAP • RFC 3909 . RFC 4519 & RFC 4524) RFC 2830 . A comprehensive Linux LDAP Configuration Guide RFCs LDAP is specified in a series of Request for Comments documents: • RFC 4510 .The LDAP Data Interchange Format (LDIF) RFC 2891 .LDAP: Uniform Resource Locator (Obsoletes RFC 2255) • RFC 4517 . RFC 2829.LDAP: The Protocol (Obsoletes RFC 2251. RFC 2256 & RFC 3674) • RFC 4513 .LDAPv3 Operational Signatures RFC 2696 . RFC 2830 & RFC 3771) • RFC 4512 .LDAP Proxied Authorization Control . RFC 2830.LDAP Authorization Identity Controls RFC 3866 .Use of DNS domains in distinguished names (Updated by RFC 4519 & RFC 4524) RFC 2307 . RFC 2253.LDAP: Authentication Methods and Security Mechanisms (Obsoletes RFC 2251.LDAPv3: Dynamic Directory Services Extensions RFC 2649 .LDAP Cancel Operation • RFC 3928 .LDAP: Additional Matching Rules RFC 3829 . RFC 2254. RFC 3771) • RFC 4511 .Named Subordinate References in LDAP Directories RFC 3671 .Subentries in LDAP RFC 3673 .segetech.Using LDAP as a Network Information Service RFC 2589 .LDAP: Syntaxes and Matching Rules (Obsoletes RFC 2252 & RFC 2256.LDAP Simple Paged Result Control RFC 2798 .inetOrgPerson LDAP Object Class (Updated by RFC 3698. RFC 2255. RFC 2798 & RFC 2377) The following RFCs detail LDAP-specific Best Current Practices: • RFC 4520 (also BCP 64) . Updates RFC 3698) • RFC 4518 .com (http://oss. Updates RFC 2247. RFC 2252.Considerations for Lightweight Directory Access Protocol (LDAP) Extensions The following is a partial list of RFCs specifying LDAPv3 extensions: • • • • • • • • • • • • • • • • • • • RFC 2247 .LDAPv3: Extension for Transport Layer Security RFC 2849 .LDAP: Schema for User Applications (Obsoletes RFC 2256.LDAP Component Matching Rules RFC 3698 .LDAP: String Representation of Search Filters (Obsoletes RFC 2254) • RFC 4516 .LDAP: Technical Specification Road Map (Obsoletes: RFC 2251.Collective Attributes in LDAP RFC 3672 . RFC 2252. RFC 2829 & RFC 2830) • RFC 4514 .LDAP: String Representation of Distinguished Names (Obsoletes RFC 2253) • RFC 4515 .html).Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) (replaced RFC 3383) • RFC 4521 (also BCP 118) .LDAP Password Modify Extended Operation RFC 3296 . RFC 3377.Storing Vendor Information in the LDAP root DSE RFC 3062 .LDAP: Internationalized String Preparation • RFC 4519 .LDAP 9 Configuration • Segetech.
LDAP Schema for UDDI RFC 4522 .The String Representation of Standard Attribute Syntaxes (replaced RFC 1488) • RFC 1779 .LDAP: Assertion Control RFC 4529 .LDAP: Absolute True and False Filters RFC 4527 .LDAP entryDN Operational Attribute 10 LDAPv2 was specified in the following RFCs: • RFC 1777 .LDAP: entryUUID RFC 4531 .LDAP Content Sync Operation RFC 4876 .Configuration Profile Schema for LDAP-Based Agents RFC 5020 .LDAP: Read Entry Controls RFC 4528 .LDAP Turn Operation RFC 4532 .A String Representation of Distinguished Names (replaced RFC 1485) LDAPv2 was moved to historic status by the following RFC: • RFC 3494 .LDAP: Modify-Increment Extension RFC 4526 .LDAP: Binary Encoding Option RFC 4523 .LDAP • • • • • • • • • • • • • • • • RFC 4373 .Lightweight Directory Access Protocol (replaced RFC 1487) • RFC 1778 .509 Certificate Schema RFC 4524 .LBURP RFC 4403 .LDAP: Requesting Attributes by Object Class RFC 4530 .LDAP: COSINE Schema (replaces RFC 1274) RFC 4525 .LDAP Who am I? Operation RFC 4533 .LDAP: X.Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status .
S3000. Jwilleke.xxx. CKlunck.svg Source: http://en. Vanished user 39948282. Srpnor. Gamma. Wereon. Pnm. Thumperward. Vitund. Ff1959. Redjar. Pedant17. Scratchy. Fred Bradstadt. Deflective. Kdz. Lesterrivera. Taxman. Ahoerstemeier.253. Marc Esnouf. Kbrose. Nethac DIU. Anna Lincoln. Combatentropy. Treydrake. Tothwolf. Charles Brooking. Stephan Leeds. Isnow. Doczilla. Nabber00. Mrbill. Joe Jarvis. Pascal. Rick Block.0 Unported http:/ / creativecommons.php?title=File:Loudspeaker.117. Tero. Cometstyles. Wiki alf. Wsheward. Crkey. Piet Delport. 62.Tesson. Helon. StaticGull. PatrikR. Andrew Findlay. Lee Carre. Mindmatrix. 0/ . DGG. Dmsar.delanoy. The Evil IP address. Peterblaise. Rasmus Faber. Jxn. Dustimagic. Subversive. Amux. Poor Yorick. ZZyXx. Amillar. UncleBubba. 598 anonymous edits Image Sources. 62. EagleOne. Jaanis2010. DrRogla. MilkMiruku. Pit@0xff. Pxma. Avijit. Wojtekpia. Alexbatko. Jiddisch. Jdthood. DavidHallett. Great Cthulhu. Wbenton.offe. Thingg. Southen. Hu12. Lysdexia. GerardM. VictorAnyakin. IanManka. Exien. Husky. Wilsonhughes. Rocket000. Chealer. Dalesc.wikipedia. Cavrdg. 9 anonymous edits License Creative Commons Attribution-Share Alike 3. Nick. Timotab. Jay. Smaines. Christian75.202. Randy Johnston. MarkWahl. Stevage. Danpritts. BabsiSnoecks. Sams sun. Looxix. Augustan. Manster. Mr stupid. MMSequeira. Arcade.szabo. Neelkanthtriptathi. JTN. Abeld.org/w/index. Wk muriithi. Aragorn2. A8UDI. Tyler. Hhielscher. Premil. JoeHenzi. AJackl. Rwoodsmall. Monkbel. Tobias Bergemann. Pieffe. SebastianBreier. Pgan002. Polluks. Armando82. Renaissancee. Jarsyl. Rnapier. Remi0o. WRJ. Tedp.php?oldid=422729587 Contributors: 0. Iamunknown. Maximaximax.64. Ruakh. Jeffschuler. SmartIcon. Lukegm. Pabix. Woohookitty.wikipedia. Anon lynx. Matt Crypto. Mallamace. DoubleBlue. Equendil. IronJohnSr. Javawizard. Marek69. MooingLemur. Dewet. Brandon. Iridescence.at. Manavmohanty. Konman72. IWhisky. J. Emmanuel JARRI. J-stan. DerHexer. Grs1969. Emperorbma. Kuru. Dennette.xxx. Bevo. Ed Poor. Waddey. Taw. OlEnglish. Jordav.ghosal. Licenses and Contributors File:Loudspeaker. Oxymoron83. Ghettoblaster. Lotje. Tlesher. Kwamikagami. Giraffedata. Shadow1. Gman124. ShelfSkewed. Rageear. Jordan Brown. Benjamin Barenblat. Manishearth. The undertow.svg License: Public Domain Contributors: Bayo. TRS-80. Dogcow. Dolda2000. Oneiros. Nippoo. Ronabop. Juliank.org/w/index. Kozuch. Flewis. Grovejary. Arknascar44. Asciberras. Joonga. ESkog. Levin. Jonathan de Boyne Pollard. Beland. Snupha. Hotlorp. Marty. RossPatterson. Chris Q. Tide rolls. Tbird1965. EmirA. Bcwhite. Khendon. Shshme. Wouterhagens. Almightylinuxgod. Phatom87. Rhubbarb. Wageslave. Atstarr. Gpallis.Article Sources and Contributors 11 Article Sources and Contributors LDAP Source: http://en. RFightmaster. Saligron. Chuunen Baka. Mortein. Gmaxwell. Turnstep. Brevantes. JakobVoss. Yingyang. RedWolf. EZio. Highlandsun. Omniplex. Uselesswarrior. Andareed. Sadads. HFuruseth. Folajimi. Lost on belmont. Darrien. Stickee. Tobias Hoevekamp. Bahar101. BigSmoke. Lazki. Myself488. Gurch. Parpauta. Omegatron.sound. Anna Frodesiak. SJK. org/ licenses/ by-sa/ 3. Georgesawyer. Jbm212. RW Dutton.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.