Talk:Lightweight Directory Access Protocol/Archive 1

Archive 1

Active Directory?

Is it correct that Active Directory is Microsoft's implementation of the Lightweight Directory Access Protocol? — Preceding unsigned comment added by 62.202.117.xxx (talk) 16:41, 5 December 2001 (UTC)

I believe that's correct; at least in terms of Microsoft's "Embrace and Extend" (aka Steal and Bastardize) strategy. — Preceding unsigned comment added by Conversion script (talk • contribs) 15:51, 25 February 2002 (UTC)

Yes. No. LDAP is not a directory, it is an access protocol. Active Directory, surprisingly enough, is a directory. Yes, Active Directory is accessible by LDAP, as was Exchange Server before it. AD is also accessible by other methods, including ADSI, Kerberos, and NTLM. So AD isn't MS's implementation of LDAP, but it includes an MS implementation of LDAP. (For what it is worth, I'm not a fan of MS, but they do occaisionally implement something right without "extending" it. They didn't "extend" LDAP in AD like they did with Kerberos in AD.) — Amillar 03:28, 12 May 2003 (UTC)

Actually, Novell points out (1) that Active Directory doesn't actually follow the LDAP standard. JoeHenzi 12:31, 15 November 2004 (UTC)

Examples

Have you considered giving examples of coding LDAP using Perl or Javascript, for example. — Preceding unsigned comment added by Scanos (talk • contribs) 21:57, 11 May 2003 (UTC)

I don't think so. Wikipedia is not a how-to. Also, it would be important to illustrate correct error handling and that would make for a long example, preferably in a lower-level language like C which doesn't do it for you. Like the example in RFC 1823. HFuruseth 16:24, 20 January 2006 (UTC)

Separate article?

Does OpenLDAP really need a separate article? Any info is best gained from the external link. JohnCastle 12:44, 27 July 2003 (UTC)

Well, several other implementations have separate pages too: At least Active Directory, Fedora Directory Server, IBM Tivoli Directory Server (with 2 pages for its 2 names:-) and Novell eDirectory. If those are to stay, it makes sense to keep OpenLDAP as well. Maybe add a bit history to the page. And a page for the original Umich LDAP. HFuruseth 11:56, 28 December 2005 (UTC)

Recursive?

Can an LDAP attribute be an LDAP object recursively? Does the unique-name restriction apply only to items on the same leaf? Is there a master/template describing the structure or is it freeform? Roger.wernersson 16:54, 2 July 2004 (UTC)

The typical approach is to have an LDAP attribute be DN-valued: the values point to other entries. See the object class groupOfNames or groupOfUniqueNames. It is rare to contain an LDAP entry as an attribute value, see the changes attribute of the changelog object class. All entries in a single directory tree must have unique Distinguished Names. Any further restrictions, such as you can only have one person with a name of Joe Bloggs anywhere in the organization, even if you have more than one branch of the directory tree (e.g. having both uid=jbloggs,ou=Europe,o=mycompany and uid=jbloggs,ou=Asia,o=mycompany is legal in LDAP), is an implementation or deployment choice. The structure of the LDAP directory may be constrained by X.500 structure and DIT content rules, implementation restrictions (e.g. AD might only allow user entries in a particular part of the tree), or by deployment policy (e.g. entries for users are to be stored in a branch ou=People). — MarkWahl 16:03, 28 September 2004 (UTC)

If you like...

You can consider adding the external project that works on adding LDAP into squid! more info: http://group-ldap-auth.sourceforge.net (no I'm not affiliated with this site, it's just for completion) [edit] I went ahead and at least added the info of Apache supporting LDAP in his proxy functionality (mod_proxy), since this comes by default and doesn't require a third-party module like squid (still) does. 217.2.59.30 02:01, 20 June 2005 (UTC)

Confusing

I'm a non-technical person who clicked on a link to this page because I wanted to know what "LDAP" actually is. Maybe this should be mentioned somewhere here. ZacharyS 21:19, 14 August 2005 (UTC)

In short, it's a standard protocol for accessing a remote database -- with data organized as per the X.500 standard -- over a network (typically using TCP/IP). So, it does not prescribe what kind of data you'll be accessing, but merely how it's organized and how to access it.

(Also, what appears as a single remote database may in fact consist of many separate databases, physically isolated and run by different entities, but transparenty merged upon access. This is a feature of X.500.)

At least, I think so. Someone correct me if I'm wrong. - Kwi | Talk 00:19, 19 August 2005 (UTC)

I found a really nice webpage that answers exactly "What is LDAP, anyway?" for the layman, or at least technically savvy layman. It also answers some other good questions like "Using 'LDAP' in a sentence" and "When you should use LDAP." Although I don't know enough about the topic to accordingly update the main page, you can find the link under external links. An Introduction to LDAP --Legaia 20:29, 5 July 2006 (UTC)

Some critical information that must be in the article for it to be remotely understandable to laymen is:

1. What the alternatives are.
2. What the practical advantages and disadvantages of LDAP are with respect to those alternatives, in terms of stuff like "in what general terms is it organized as far as I, a user attempting to access a file, am concerned" (e.g., folders vs. labels) and "does it have substantially longer or shorter access times".

Currently the article is simply gibberish to anyone who doesn't already know a lot about the topic. I'm moderately tech-inclined, but I can't make heads or tails of it. —Simetrical (talk) 00:51, 7 September 2005 (UTC)

I first heard of LDAP when looking into IMAP. I first assumed that LDAP was a protocol for accessing an address book located on a server. The only example I've seen shows it used as an address book for people showing their phone number email address etc but the definition makes it sound like it has much broader uses.

This article is still quite confusing. The oddly named "LDAP directories" section explains some elements of the protocol, but doesn't show how they fit together. An example showing how information is structured, stored, and access in this type of system would help a lot. -- Beland 07:11, 18 December 2005 (UTC)

Better now? I've reorganized and added a lot of text, maybe too much. Would have liked to get through a summary before getting down to the details, but there is so much to summarize... -- HFuruseth 02:36, 19 December 2005 (UTC)

I'd like to echo the concerns stated above. I'm missing a section citing (or describing) real-world applications. There's a section listing a large number of implementations, so there must be people out there using it for something, right? For example, do telephone companies use it to power their "Directory Information" (411) services? --Smithfarm 17:09, 1 December 2006 (UTC)

I've added a Usage section. With user/group info and address books, I don't know what phone companies do. HFuruseth 16:38, 14 December 2006 (UTC)

Although, I think this article is very good and informative in technical ways, I think it's still lacking in clear applications/examples of what LDAP can actually be used for beyond an address book. For people who don't know what it can even be used for, I think some examples of useful applications of LDAP should be mentioned very early in the article. I came to this article because it was mentioned as a good solution for a home server for centralized user data/logins (http://linuxexchange.org/questions/1121/same-login-different-computers), however, I couldn't find any mention of such or any specific uses besides for address books (although I was just skimming). Reading the link given above by Legaia was useful for me, though. Also, it seems that most of the Usage section added by HFuruseth has been deleted as of this edit: https://secure.wikimedia.org/wikipedia/en/w/index.php?title=LDAP&oldid=276694571 Besides that, the rest of the article looks very good! :) —Preceding unsigned comment added by ZeniffMartineau (talk • contribs) 06:16, 22 August 2010 (UTC)

History and origins of LDAP

If you dig around, you'll find that LDAP was originally called LDBP, and quite different in scope; for instance, it didn't have authentication or BER encoding! [1] If my fuzzy recollection is correct, it was also not initiated at the behest of the IETF, but as a DARPA contract to provide for better x.500 interoperation. There was some unctuous stuff happening with umich/merit's x.400 contract as well, but that was before my time there. --moof 12:24, 11 November 2005 (UTC)

LDBP, which stands for Lightweight Directory Browsing Protocol, is LDAP's original name. Verification: [2]. This fact should be worked into the origins sections of the article. Kdz 20:53, 30 January 2006 (UTC)

Implementations/vendor lists need work

Can people who know the implementations and vendors fill in a few keywords about them - or collect it here in Talk so we can fill it in all at once later? Currently someone who don't know them can't always tell which ones he is interested in. (I can check the various sites' claims, but someone who has used the software would be better.)

E.g. is it a general LDAP suite or for a more specific purpose? Free or commercial? Or delivered as part of some other product? Portable or just for one platform? Open source? HFuruseth 12:44, 28 December 2005 (UTC)ff Cursieve tekst

...at least for the implementation lists. As I say above, I think we should delete the vendor list. HFuruseth 17:09, 14 December 2006 (UTC)

External Links

I would like to reorganize how RFC and various external links are presented. In particular, I would like to move the list of LDAP RFCs up into a section titled "The LDAP Technical Specification". Comments? Kurt 22:02, 28 January 2006 (UTC)

I also think the "supporting vendor" section needs some rework. For instance, it lists "Fedora Directory Server" as a vendor where as "Fedora Directory Server" is an implementation. Likewise for the "Redhat Directory Server". I would suggest that the list of vendors be deleted as it seems kind of subjective as to which vendors offer "wide support" for LDAP. I suggest we list available LDAP server implementations and LDAP development libraries. Where the same code was provided under multiple names (like Mozilla and Netscape Directory SDKs, OpenLDAP and CDS, etc.), the code would be listed under the primary name and any secondary names presented as comments in that listing. I suggest we avoid attempting to list LDAP clients as that list is far too long. Comments? Kurt 22:02, 28 January 2006 (UTC)

I think the vendor should go, but lists of full implementations and some clients and libraries are still useful. HFuruseth 17:07, 14 December 2006 (UTC)

I note that I have yet to really attack the meat of the article... but first I intend to work on some of the side dishs, like DIXIE, DAS, and X.500. But soon... Kurt 22:02, 28 January 2006 (UTC)

I've added basic articles on DIXIE and DAS. Kdz 20:38, 30 January 2006 (UTC)

I've taken the liberty of adding a link to my LDAP Wiki. There are many subjects which are nice to have in Wiki but which don't belong in an encyclopedia. Please feel free to add anything related to LDAP there. Also feel absolutely free to add nothing; www.paldap.org will be around for some time to come and the beauty of Wiki is that you can relax while the garden continues to grow. After all, PALDAP stands for "PALDAP, A Lazy Directory Administrator's Pal." --BigSmoke 02:04, 17 February 2006 (UTC)

(The link given as reference [1]'LDAP: Framework, Practices, and Trends' is a non-freely downloadable article (it now costs $29 from the 'ieee computer society' website)... just the abstract and the article's references are given (Is there a standard way to highlight this in the wiki page?)). R.traverso 19:29, 17 October 2007 (UTC)

reason why Start TLS is an extended operation

The Extended Operation text use to include a statement:

"...The Extended Operation is a generic LDAP operation which can be used to define new operations. Examples include the Cancel, Password Modify and Start TLS operations - the latter is defined that way because it was originally introduced as an LDAP extension..."

This implies that if Start TLS would have been included in RFC 2251, it would not have been specified as an Extended Operation. While I believe this conjecture is likely false, I am confident that the statement above is conjecture. Hence, I have removed it. Kurt 07:55, 28 January 2006 (UTC)

Good. I don't remember just what I meant with it, but I don't think that was it anyway. HFuruseth 15:05, 14 December 2006 (UTC)

Order of Operations?

The list of operations claims to be "in order" but it quite unclear what that order is. Certainly its not order of typical or recommended use. Of course, "recommended use" requires statement of an opinion and "typical" is not verifable. I suggest instead the operations be listed in alphabetical order, or grouped by category. After all, wikipedia is neither a how-to (to steal a line from Hallvard) or a technical specification. Kurt 19:31, 27 January 2006 (UTC) This issue has been addressed by recent changes. Kurt 07:55, 28 January 2006 (UTC)

Authentication comparison

What are the advantages of using LDAP for authentication versus DNS, NIS, and AD? Can someone point me to a comparison table or add one to this article? Thanks. — Preceding unsigned comment added by Sandboul (talk • contribs) 02:24, 8 June 2006 (UTC)

RFCs specifying LDAP

Instead of the lists of RFCs in External Links, I suggest adding a few of new sections. One, titled "The LDAP Technical Specification", would details the current LDAPv3 TS (RFC 4510). Another, titled "History of LDAP Standardization" would discuss the evolution of LDAP in the IETF. Another, titled "LDAP Extensions" would enumerate various LDAPv3 Extensions. As my time is limited presently, I've only updated references to the current revision of the LDAP TS (RFC 4510). There are many new LDAP Extensions which likely should be added as well. Kdz 05:36, 10 June 2006 (UTC)

I just made a suggestion on List of RFCs about revising how the topical RFCs there are listed. My suggestion is to use transcluded pages specific to each protocol or topic. The transcluded content could then be included on the protocol specific article (such as this one). It doesn't quite meet your suggestion for individual sections, but I think is somewhat related. Your suggested sections could then focus on the explanation and discourse of the RFCs as a whole. My prior suggestion is here Talk:List of RFCs#Transclusion to other pages.3F. Crkey (talk) 19:31, 16 May 2008 (UTC)

LDAP Database Designer Tool

If you want to create own structure of data in ldap, or if you want to prepare file for import own user data to ldap, it can be a little bit problem. If you don't understand the schema file structure, or ldif file structure, you can have a little problem. But for the users which don't have deeper knowledge about ldap schemas and ldifs can be very helpful tool from Simplica. I found it yesterday and I think that it is very powerful tool. With it is possible to manage schemas and ldifs. You can simply manage all by user friendly GUI and after that generate the final schema or ldif file. I don't know any other tool for manage schema and ldif files in this simply way. For me was very important that I was able to prepare whole database in a few moments. From create ldap schema to create ldif file to import my data to designed database without any special knowledges about Ldap. If someone have the similar problem try to check Simplica page and try to download Ldap Database Designer Tool. — Preceding unsigned comment added by 192.108.125.11 (talk) 07:52, 28 July 2006 (UTC)

Peter Blaise says: As of 2007-01-15, http://www.simplica.eu/ seems to be gone, with no tool download, only last referenced in Google cache as of 2007-12. If someone else has references to tools that build, analyze, repair, and report on LDPA databases, please report on them and add them to a new section on the article page, perhaps called "Tools and Utilities" -- Peter Blaise peterblaise (talk) 11:00, 15 January 2008 (UTC)

PHP & LDAP

There's a part on this page about perl and LDAP, so i think php and LDAP should receive a note too: http://www.php.net/manual/en/ref.ldap.php — Preceding unsigned comment added by Joopmans (talk • contribs) 13:24, 21 September 2006 (UTC)

Origin and influences section

This section has grown quite large. I suggest it is moved to near the end of the article (before Supporting Vendors), I expect it is more of interest to people who reach the end.

I've moved 2 paragraphs which did not seem to belong there, to the intro section.

Does something there need to be kept early in the article for newcomers to LDAP? I don't see anything at the moment. Replies from LDAP newcomers especially welcome:-) HFuruseth 16:48, 14 December 2006 (UTC)

Connectionless Lightweight Directory Access Protocol

Hi!

I was patrolling the Articles-for-Creation page and this text was suggested as the basis of a new article:

From 193.36.230.96:

The Connectionless Lightweight Directory Access Protocol (CLDAP)is a computer networking protocol designed for providing access, for querying and modifying stored data, to X.500 directory systems.

Origianlly, the Directory Access Protocol (DAP) was designed for accessing the directory service, but if the only requirement for an application was to, for example, have read access to data, then most of DAP's features would be unused. The Lightweight Directory Access Protocol (LDAP) was created as a scaled down version of DAP, which does not require deployment of an OSI network. CLDAP is built upon the Lightweight Directory Access Protocol (LDAP). It inherits a restricted set of LDAP's features, requires less resources than LDAP and is a connectionless-oriented protocol, so it uses UDP rather than TCP.

The CLDAP offers very high performance, which is an important feature for routing.

Sources

• http://www.rfc-archive.org/getrfc.php?rfc=1798
• http://www.rfc-archive.org/getrfc.php?rfc=3352
• http://www.circ.ca/cldap.html

I rejected the proposed article saying that it might be better as a part of the LDAP article (ie, here!) - perhaps you folks could make a better determination as to where it belongs and either start it as a new article or merge it here.

Thanks in advance. SteveBaker 15:49, 27 December 2006 (UTC)

Example attributes

I'm removing the recently added "uniqueMember" and "memberOf" attributes as examples of DN-valued attributes. The standard attribute "member" is already there and we only need one example of a DN-valued attribute.

"uniqueMember" is not DN-valued, it has the weird syntax "Name and Optional UID" - see RFC 4519 section 2.40. "memberOf" is not in the standard, I don't know where it is defined.

Maybe jpegPhoto is an unfortunate example too since it's not in the standard. However, it seems useful to have an example binary attribute. It's from RFC 2798 (the inetOrgPerson object class).

HFuruseth 04:22, 28 December 2006 (UTC)

Telephone directory example in first paragraph

It's not a great example: there's nothing hierarchical about a telephone directory 139.133.7.37 15:27, 2 July 2007 (UTC)

Anonymous & Unauthenticated

The section with the heading "Terminology" currently contains the following grammatically incomplete sentence:

An "anonymous" and an "unauthenticated" Bind are different Bind methods that both produce anonymous authentication state, so both terms are being used for both variants.

I'm guessing that there should be an "an" or a "the" between "produce" and "anonymous". Can someone with more LDAP knowledge fix this? -Jarsyl 11:37, 30 August 2007 (UTC)

uid

In the "Terminology" section a statement is made indicating that "uid" should not contain numeric IDs. Where is the authority for this statement? -- Terry J. Gardner (talk) 00:18, 25 April 2008 (UTC)

I know this is an old question, and the text no longer appears in the article, but here's what I can find about the answer: The IANA list says that it's defined by RFC 4519. RFC 4519 says that it supersedes "uid" from RFC 2798 and "userid" from RFC 1274. RFC 2798 defines uid as a string and gives as an example "bjensen". Unfortunately, it does not give a prose description of the intended meaning. It too equates uid with userid from RFC 1274. RFC 1274 says that userid specifies a computer system login name. RFC 2307 is consistent with this definition, and in addition defines uidNumber to contain a UNIX-style numeric user ID. Jordan Brown (talk) 20:18, 9 August 2010 (UTC)

Used for authentication -- Security Problems?

The first paragraph has: ", despite the security problems this causes". There are a couple things wrong with this: A) there is no reference to back up this claim -so it should be referenced or removed. B) Every authentication system needs some root authority on whether credentials are correct or not, and no matter what system is used for this there will be one system that is requesting for authorization, and another replying. At the most basic level this will always be: is this user/pass correct or not. LDAP or any other software being used to answer that question will have equivalent "security problems" so to suggest LDAP is the cause to additional problems, is just wrong. Such a system would have equivalent problems if it were an SQL statement and a database. In other words the security problems can only be blamed on the designer, who just might equally write code to send plain-text user/pass from a Java applet to a Servlet for some SQL yes/no return. —Preceding unsigned comment added by 76.102.152.160 (talk) 18:52, 3 May 2008 (UTC)

I can see a security issue from the point that the directory becomes a single point for attacks, once compromised it potentially provides the keys to every application using it as an authentication source. I think this is generally accepted as out-weighing the risks imposed by multiple disconnected sources of identity. Given the number of articles and industry trends towards consolidating identity stores (or at least virtualizing into a common view for authentication), I think the security problem mentioned in this part of the article is not justified. It may be better to simply note that as a result of the use of LDAP to centralize authentication, more care should be taken in securing the service Crkey (talk) 01:41, 13 May 2008 (UTC)

Diagram

I don't understand LDAP, but I think that a diagram might help. Requesting someone who knows LDAP come up with a good diagram RyanTMulligan (talk) 17:18, 27 May 2008 (UTC)

LDAP for the layman

I came to this site to find out about LDAP as an email address database system. I believe that this is what most layman (and thus most people) will be looking for, yet the article does not mention this application whatsoever.

I understand that this may simply be one application, but it seems to the major one that most people interact with and seems like it ought to be covered.

Thanks, Sligocki (talk) 03:26, 10 December 2008 (UTC)

FQDNS

The section regarding LDAP URLs defines the 'host' portion of the URL as the FQDNS of the LDAP server. As far as I'm aware, this would translate to fully-qualified domain name system. If that's an accurate translation, I'd recommend changing it to FQDN, fully-qualified domain name. Thoughts? —Preceding unsigned comment added by 207.127.128.2 (talk) 16:42, 20 April 2009 (UTC)

Lacking examples

This article is conspicuously lacking any examples of current application. This would greatly assist a newcomer to LDAP in understanding its significance. pencilneck (talk) 07:19, 20 December 2009 (UTC)

The lack of citations threatens this article.

There simply are NOT enough interspersed citations in this thing. There are just too many places where statement after statement goes unattributed or uncited.

I would supply some of the citations myself by simply googling around, but I feel it inappropriate because it is not directly within my particular spheres of software engineering. More importantly, this is *NOT* the way an article should be done:

1. Look at unsupported statements and 2. Go hunting for places that might support it

I'm almost begging the originating contributors, because where wikipedia really excels IMO is as a technical reference. Can we please fix this? — Tgm1024 (talk) 23:01, 4 January 2010 (UTC)

3. That was a joke about wikipedia being a technical reference, since it isn't, and never will be. — Preceding unsigned comment added by 155.8.89.2 (talk) 16:49, 27 March 2013 (UTC)

Terminology Section

"rather cumbersome" according to whom? The terminology section is poorly constructed and written. — Preceding unsigned comment added by Ff1959 (talk • contribs) 19:36, 3 June 2011 (UTC)

Add Section under Operations

It says this: In the above example, uid=user,ou=people,dc=example,dc=com must not exist, and ou=people,dc=example,dc=com must exist. I think it might be more precise to say In the above example, ou=people,dc=example,dc=com must exist, and uid=user must not exist in the ou=people,dc=example,dc=com subtree. I am not an LDAP expert, but it sounds ambiguous as currently stated. — Preceding unsigned comment added by Techgrrl (talk • contribs) 18:29, 13 August 2012 (UTC)

In addition, within the actual example the DN is given as "uid=user,ou=,dc=example,dc=com". Note that the word "people" is missing. — Preceding unsigned comment added by 98.240.220.85 (talk) 00:07, 13 August 2014 (UTC)

TLS and LDAPs

StartTls is not an LDAP operation. Extended Operation is the operation and StartTLS is one of many extended operations.

Although LDAPS may be deprecated within the RFCs, there are MANY more active LDAPS operations and servers implementations than there are StartTLS operations.

The line "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."; This is Equally true of StartTLS operations as LDAPs operations or any operation which involves certificates. It is always the client's job to perform certificate verification. — Preceding unsigned comment added by Jwilleke (talk • contribs) 11:50, 25 September 2012 (UTC)

Indefinite article

See Wikipedia:Administrators' noticeboard/Incidents#User: 109.77.xx.xx and the indefinite article and Talk:XMPP#Please discuss changes to the indefinite article. Andrewa (talk) 15:11, 24 May 2013 (UTC)

examples are too specific

In sections "Operations -> Add" and "Creating a new object class and adding attributes"

The examples are bad because they are showing vendor/OS specific details:

• They use openldap specific programs (ldapadd, ldapsearch, slaptest) with specific command line switches.
• They use "sudo" which is specific to unix like operating systems.
• They use debian (a GNU/Linux distribution) configuration files '/etc/ldap/schema/inetorgperson.schema'

I think we rewrite them to be vendor and OS agnostic ? Or direct to examples from the openldap page ? Or at least make the specific parts explicit (adding a note saying: "For example, on debian with openldap:") — Preceding unsigned comment added by Jonenst (talk • contribs) 15:20, 10 February 2015 (UTC)

ldif syntax highlighting lost

Since the switch from Geshi to Pygments for syntax highlighting (phab:T85794), support for 'ldif' was unfortunately dropped, as can be seen with the plain text formatting on this page and possibly others. If you want specialised 'ldif' syntax highlight support again, it will need to be added to Pygments. Alternatively, if there is another language which has similar syntax, we can add that as a fallback. John Vandenberg ^(chat) 15:50, 14 July 2015 (UTC)

Active Directory?

Can we get something more in here about Active Directory? There's nothing at present, not even a See also.

AD is "based on LDAP" (I know nothing about Microsoft) or at least "presents itself as being like LDAP". Today I want to know how true this is. If I build an LDAP-based client solution, will it roll out to Microsoft and an AD context, or is it just too far different? Surely there is some linking and context we can give here that's still framed in terms of LDAP, without only belonging at that article. Viam Ferream (talk) 13:49, 22 January 2016 (UTC)

Sorry, about two years' late. Regarding AD: I refer you to the comment by User:HFuruseth above. I think he gave a very clear and succinct explanation of the relationship between LDAP and AD.

Might I observe that LDAP is very abstract; you could use it to represent really any kind of information structure. Perhaps this is why people are reluctant to trot out obvious examples - it makes it seem as if that's what LDAP is limited to. Anyway, it seems unsurprising to me that people have trouble explaining it. Oh yeah - say I'm a layman. What is this 'protocol' thing? I thought that was about diplomats being polite.

Could be improved; but I don't think I'm the man to do it. Well, I may be able to fix some small things. MrDemeanour (talk) 18:27, 22 June 2018 (UTC)

log4j vulnerability

Noting we may get increased traffic here as people lookup the recent Log4j ldap vulnerability https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/ Mathiastck (talk) 20:40, 13 December 2021 (UTC)