Talk:Lightweight Directory Access Protocol

message: 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)
thread_title:  TLS and LDAPs 

message: 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. 07:52, 28 July 2006 (UTC)
replies: text: 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)
thread_title:  LDAP Database Designer Tool 

message: 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)
replies: text: 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)
thread_title:  RFCs specifying LDAP 

message: 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)
replies: text: 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)

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

text: (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)
thread_title:  External Links 

message: 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)
replies: text: 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)
thread_title:  reason why Start TLS is an extended operation 

message: 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)
thread_title: Order of Operations? 

message: Is it correct that Active Directory is Microsoft's implementation of the Lightweight Directory Access Protocol? 
-I believe that's correct; at least in terms of Microsoft's "Embrace and Extend" (aka Steal and Bastardize) strategy.
: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 May 12, 2003 (UTC)
:: Actually, Novell points out (1) that Active Directory doesn't actually follow the LDAP standard. JoeHenzi 12:31, 15 Nov 2004 (UTC)
replies: text: 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)
thread_title: Active Directory?

message: Does OpenLDAP really need a separate article? Any info is best gained from the external link. JohnCastle 12:44 27 Jul 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)
thread_title: Separate article?

message: 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 Jul 2004 (UTC)
thread_title: Recursive?

message: 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 Jun 2005 (UTC)
thread_title:  If you like... 

message: 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!  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)
replies: text: LDBP, which stands for Lightweight Directory Browsing Protocol, is LDAP's original name.  Verification: .   This fact should be worked into the origins sections of the article.  Kdz 20:53, 30 January 2006 (UTC)
thread_title:  History and origins of LDAP 

message: 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)
replies: text: ...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)
thread_title:  Implementations/vendor lists need work 

message: 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)
thread_title:  Origin and influences section 

message: 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)
thread_title:  Connectionless Lightweight Directory Access Protocol 

message: 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)
thread_title:  Example attributes 

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

message: 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)
thread_title:  Anonymous &amp; Unauthenticated 

message: 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)
replies: text: 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)
thread_title:  uid 

message: 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)
replies: text: 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)
thread_title:  Used for authentication -- Security Problems? 

message: 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)
thread_title:  Diagram 

message: 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)
thread_title:  LDAP for the layman 

message: 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)
thread_title:  FQDNS 

message: 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)
thread_title:  Lacking examples 

message: 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)
thread_title:  The lack of citations threatens this article. 

message: "rather cumbersome" according to whom? The terminology section is poorly constructed and written. Terry J. Gardner 19:36, 3 June 2011 (UTC)
thread_title:  Terminology Section 

message: 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)
thread_title:  Add Section under Operations =

message: 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)
thread_title: Indefinite article

message: 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)
thread_title:  examples are too specific 

message: 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)
thread_title:  ldif syntax highlighting lost 

message: 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)
thread_title:  log4j vulnerability 

message: As of today, the article contains in the introduction "A common use of LDAP is to provide a central place to store usernames and passwords." That would be bad practice.
I assume that an LDAP server only stores salted hashes (current best practice). Am I correct?
Wrev (talk) 12:41, 23 May 2023 (UTC)
thread_title:  Does LDAP really store password - or only hashes???