On Fri, Feb 09, 2007 at 01:15:47AM -0800, Howard Chu wrote:

I wouldn't expect to find much documentation on this topic because in general it's the wrong thing to do. What distributed authentication system do you use that is supported by pam but is not supported directly by LDAP or SASL?

Radius. I'm aware that 2.4 fills that gap, but I don't want to use alpha software in production (In fact, I was not even able to build it)

These steps are only needed if you're going to use plaintext passwords in SASL Binds, and yet you only show the use of Simple Binds here.

Sure, that's just what I was looking for. I found no doc explaining how to do it, that's why I post it there, with the hope it could help someone else (or even myself in a few months).

I could not even find a place where it is said that userPassword should be {SASL} followed by the login.

...

NB2: slapd logs in /var/log/slapd.conf, the error messages are usually meaningless, especially for ACL and SASL troubles.

The log messages are meaningful, you just don't understand them. Your ignorance does not indicate a fault in the software.

I expected to be flammed for that one. I just tell you about my frustration working with some OpenLDAP areas. You can choose to call user feedbacks ignorance and ignore them, it's up to you.

Back on ACL logs: Point me to the document that explains how to parse that pack of nonsense, and I might consider them meaniningful. For now, my opinion is that the ACL log output is just useless for the average administrator. Where is the information such that what ACL matched, or for what value an ACL clause is evaluated?

Howard Chu hyc@symas.com wrote:

...

(In fact, I was not even able to build it)

But you should send feedback about what specific problems you encountered, otherwise things will never improve.

Sure, don't worry, when I'll have a useful feedback, I'll have sent it. I experienced obscure configure issues, and I need to investigate a bit more to tell you what is wrong.

...

I could not even find a place where it is said that userPassword should be {SASL} followed by the login.

The use of this mechanism is not recommended. We don't document deprecated mechanisms.

Then what is the recommended method? I did not find that information. What should go in that field?

[ACL log output is meaningless]

That was not a flame, just a statement of fact. The same as if the messages were written in Greek and you didn't know how to read Greek. If you don't know the language, you're in no position to judge if it is meaningful or not.

Except that I can go to the bookstore and buy a book to learn greek. I'm not aware of any document explaining how to understand what goes wrong in slapd ACL.

Show us your ACL configuration, a sample operation, and the logs that are produced.

Now it works, so there is no more problem to solve, but you'll jave the opportunity to show me I'm wrong and tell me where is the relevant information on the next ACL probem I'll encounter.

Howard Chu hyc@symas.com wrote:

Of course you could always have checked the FAQ. http://www.openldap.org/faq/data/cache/944.html

Of course I did check the FAQ. Where do you think I find the idea of using {SASL}? Note that this FAQ entry does not tell that {SASL} should be followed by the login. Other FAQ entries that deal with SASL and kerberos tell about using authz-regex or sasl-regex, it took me a while to find a setup that actually works.

By the way, you told me the {SASL} scheme in userPassword was deprecated. How this should be done, then? Or did I misunderstood your statement?

As other posters have already indicated, there's plenty of information out there, and a search on simple keywords like "SASL" and "userpassword" would have been all that was necessary to find the answers in this case.

In order to type that keywords in a search engine, one must already know that the answer is about having the right thing in userPassword.

My statement above was an offer to help explain anything you might want explained. Frankly I have better things to do with my time than try to teach people who are so unwilling to learn.

I'm not unwilling to learn, it's just that I already found the answer for the problem about which I was telling my ftrustration. I'm sure nobody want to loose time answering already resolved questions.

But yes, if you post "Here's how to do X" and I see that there's something wrong, I will say it's wrong.

Now I'd by thankful to you if you could tell me why it's wrong, and what is the right way of doing what I've done.

TechnoSophos wrote:

On 2/10/07, Howard Chu hyc@symas.com wrote:

...

Emmanuel Dreyfus wrote:

Howard, maybe you should look at this with a fresh set of eyes.

First, this link does not directly answer either of the questions that Emmanuel asked. Only if one is already familiar with SASL and Kerberos is this going to prove useful. And even so, it doesn't give enough guidance to answer the larger questions, like when using this method is good/justified, etc.

That FAQ article states rather explicitly:

ALSO NOTE THAT ALL OF THIS IS IN GENERAL DISCOURAGED AND SHOULD BE USED ONLY WHEN THE CLIENT DOES NOT SUPPORT A MORE SECURE AUTHENTICATION CAPABILITY,

In my experience, this is the general issue with treating the FAQ like a manual: it's just a collection of questions and answers, and it is not particularly cohesive. In fact, as the admin guide gets older, it, too, is getting less cohesive.

None of this is news to anybody. This post http://www.openldap.org/lists/openldap-software/200701/msg00401.html is only the latest in a long history of calling for participation from the community, with essentially no results. If the community isn't willing to help itself, what else do you expect?

Emmanuel's point is worth noting: it is very difficult to learn the OpenLDAP jargon, and the official documentation (the admin guide plus the FAQ, plus the man pages) quite simply don't cut it. They are steeped through and through with LDAP technical jargon (often used inconsistently, like "slave","shadow," "replica," and "subordinate" all referring to the server receiving replication by SLURPD or SyncRepl).

My opinion may be in the minority here, but I don't think that a prerequisite to running OpenLDAP ought to be the thorough and careful reading of the whole bundle of LDAP RFCs. But that's the only method I've found of getting a good picture as to what is really (supposed to be) going on.

Disregarding your comments about the OpenLDAP documentation, which is already acknowledged multiple times over, I find your point ridiculous. You cannot run an Apache web server without knowing what "http" means and what URLs are, what CGI means, what MIME types are, etc. Any specialized software is necessarily accompanied by jargon and the use of that jargon is unavoidable.

In terms of pre-requisites, yes, I do believe that you must be familiar with LDAP fundamentals before attempting to use OpenLDAP. Whether you get those fundamentals from reading the RFCs or from reading something like Tim Howes' book, you do need to have that knowledge, and it is not something we currently provide. I recognize the fact that there's a gap here; Tim's book is very dated so the current RFCs are probably the only choice.

Just bear in mind - the Project moves in the directions that its most active members take it. Historically the Project has been about providing an LDAP suite for people who already knew LDAP and knew what they needed it to do for them. It has not been about teaching the basics of how LDAP works to people who have never heard of LDAP before. If you (the community) want the Project to spend energy moving in that direction, then someone has to step up and become an active member of the team to make it happen.

...

Your failure to find answers doesn't prove that they don't exist. (Obviously

• it's impossible to prove nonexistence of a thing.) If you had asked

first, someone might have pointed you in the right direction and saved you a lot of effort.

I would wager, based on a few years of time on this list, that what one WOULD get should one ask such a question is "RTFM," perhaps sprinkled with comments about "newbie mistakes" and how people have the mistaken impression that skim reading documentation will answer all their questions.

You would have already lost that bet. http://www.openldap.org/lists/openldap-software/200702/msg00127.html The first response to the original thread is a request for clarification, to find out why the poster was trying to go down this route:

What distributed authentication system do you use that is supported by pam but is not supported directly by LDAP or SASL?

Whenever I see a post that is asking for something that doesn't make sense, I ask for more context and more clarification.

Yes, some people on this list have a tendency to post answers without taking the time to understand the original question. There's not much we can do about that; the fact that they're even willing to try to help is already sometimes more than can be expected.

And yes, people *do* have a tendency to skim the documentation, thus missing the answer that was already staring them in the face. http://www.openldap.org/lists/openldap-software/200702/msg00121.html Your criticism of that point is completely baseless.

Besides, Emmanuel did his best in attempting to actually remedy the situation by providing some information in an organized form. He didn't get it all right, but instead of getting helpful feedback, he is getting flamed! Most of his questions go unanswered, though he's getting "RTFM" comments and the like.

I think characterizing the responses as flames is unwarranted.

Starting with the first response, little positive information was given (aside from "that's deprecated"). Shouldn't some sort of alternative be outlined? (Granted, Tonni did give a positive suggestion.)

Little positive information was provided in the first response because the initial post didn't provide enough context from which to formulate an answer.

Look, the bottom line is that the documentation could get better. When people who are willing to *try* to improve it do so, it would be nice if we could actually facilitate that improvement instead of thwarting it.

As you've already noted, there's plenty of documentation all over the web written by people "trying to improve things" that is clearly wrong. If you're going to try to document something, the right way is not to sit in a vacuum tinkering and coming out to the world and saying "after zillions of hours banging my head against the wall, this is what I came up with."

The right way is starting a dialogue, asking questions where you're uncertain about a point, until you arrive at a correct answer. The channels for that dialogue are wide open.

The solution, I would assert, doesn't require much more than a change of attitude (or at least a change of mode of expression). OpenLDAP has a steep learning curve, and people who document it as they learn it may indeed be the best contributors to documentation because they still know what sort of thing trips up the newcomer.

Keeping a log of the steps you took to get where you are is of course a good practice. But asking for help before you take a series of questionable steps, instead of after you've already taken them, is a better practice.

OpenLDAP does not have a steep learning curve. Just for example, a few people came up to me after my SCALE talk to say how brain-dead easy it was to get OpenLDAP up and running after struggling unsuccessfully with other servers.

Using OpenLDAP requires that you know LDAP, and if you don't have that knowledge, then yes, there's a steep learning curve. But that curve is there no matter whose LDAP software you use.

But we know there are problems with this approach. First, using the google hunt-and-peck method does very little to give one a coherent picture of the workings of OpenLDAP. Second, we all know that there is an abundance of BAD information about OpenLDAP out there (owing, in part, to the fact that the vast majority of OpenLDAP installations are still on version 2.2, thanks to the reluctance of several mainstream Linux distributions). Emmanuel's point is worth noting: it is very difficult to learn the OpenLDAP jargon, and the official documentation (the admin guide plus the FAQ, plus the man pages) quite simply don't cut it. They are steeped through and through with LDAP technical jargon (often used inconsistently, like "slave","shadow," "replica," and "subordinate" all referring to the server receiving replication by SLURPD or SyncRepl).

Sorry, but this is rubbish. Is the Samba documentation expected to explain how Windows works or serve as an introduction to SMB/CIFS networking? Half the terms above are generic LDAP terms; is someone wants to use LDAP then start with reading up on *LDAP*. Seems reasonable to become familiar with a technology before moving on to a specific implementation. If you think this applies only to OpenLDAP pop over to the Samba, Sendmail, Cyrus, etc... lists for people asking questions that are really about CIFS, SMTP, IMAP, etc...

My opinion may be in the minority here, but I don't think that a prerequisite to running OpenLDAP ought to be the thorough and careful reading of the whole bundle of LDAP RFCs.

It isn't. There is *LOTS* and *LOTS* and *LOTS* of well cooked LDAP documentation - see Amazon. http://www.amazon.com/gp/reader/0672323168/ref=sib_dp_pt/105-2231389-9349228...

Asking the OpenLDAP project to re-document LDAP is unreasonable. Or SASL for that matter.

Now, I'll agree 100% that SASL documentation is seriously wanting, but that doesn't have much to do with OpenLDAP. I've been using OpenLDAP + SASL and SASL with other services for years and I still find SASL frustrating.

Besides, Emmanuel did his best in attempting to actually remedy the situation by providing some information in an organized form. He didn't get it all right, but instead of getting helpful feedback, he is getting flamed! Most of his questions go unanswered, though he's getting "RTFM" comments and the like. Starting with the first response, little positive information was given (aside from "that's deprecated").

"deprecated" seems pretty clear to me - don't use it.

TechnoSophos wrote:

But clarity in the documentation is certainly a desired feature, and as it stands now, it seems (based on responses to the list, as well as my own personal experience) that going from a small LDAP server following basically the default configuration to a more complex directory environment requires a pretty steep learning curve. Good documentation could improve that situation.

Yes, jump on in.

IMHO the OpenLDAP docs are not less detailed than that of other good software packages.

*. I don't find the argument that other products have bad documentation to be justification for not creating good documentation.

Yes, jump on in.

I would even go so far as to suggest that much of the growth in postfix, exim, and the like is due to the poor documentation in sendmail and cyrus.

You think postfix has better docs? It has a simpler configuration syntax which makes docs almost unnecessary for the experienced admin.

*. I don't actually think the problem with OpenLDAP is a *lack* of documentation (which is certainly a problem with Cyrus). Again, the man pages are very thorough and very complete. And if one reads the RFCs (which are also exceptionally good) and some of the code, then one can get along pretty well with OpenLDAP. But that seems to be a high barrier of entry. I'd like to see it get lower.

Yes, everything should be easier at no cost. Who's going to take that task? You?

Tim Howes' book is excellent. I would certainly not dispute that. But at nearly 1000 pages, it's not exactly a breeze compared to the RFCs.

So reading such a book is too much effort for getting a good OpenLDAP admin?

[..] is that this list is on the tough side. And this generally negative attitude impedes improvement because it turns people away.

Some list members are simply tired by people asking for more docs without really contributing to it. You have to change your own role from a consumer to a producer when using open source software. Everything else is a really lame attitude.

And I am using Emmanuel's attempt to contribute to the documentation as a case in point.

???

Ciao, Michael.

Emmanuel Dreyfus wrote:

If you go to the root of this thread, you'll find a post where I give the various information I did not find in the doc to use PAM authentication against LDAP. I also told my frustration about the documentation state.

With no doublt my contribution could have been more comprehensive. You can tell it's obsolete or incomplete (I'd appreciate you tell me how exactly), but you can't say I complained without contributing.

Off course answering questions on the list is contributing to the project. But contributing to docs would mean you identify the place in the docs where your information should be added, you improve your information according to the list's feedback, you either provide a patch or file an ITS with sufficient information.

Regarding pam_ldap you should better contribute to PADL's docs.

You could also add something to the FAQ-O-MATIC. It's not read-only. And there is already plenty valuable information in there.

Ciao, Michael.

Emmanuel Dreyfus wrote:

Sure, I'm very interested by feedback on the actual content on the document. Here are the feedbacks I gathered so far:

1. I used deprecated features, but I was not told which was the

deprecated features

The use of plaintext passwords to authenticate to "strong" authentication systems is discouraged. Browsing through the mailing list archives will turn up this point in discussions time and time again. The use of Simple Bind to authenticate against SASL, instead of using actual SASL Binds, is deprecated. The use of Simple Bind to authenticate against Kerberos is deprecated. etc. etc...

2. I document only a small part of SASL capacities. I'm aware of that.

The scope of the document was just to explain how to validate a login/password against a random PAM authentication source. It's better than nothing.

Are you so sure it's better than nothing? With "nothing" the integrity of your site's security policy remains intact. (Granted, no work gets done right away.) With "something" your site's security policy may crumble to nothing (and then down the road, no work may get done, but for worse reasons).

3. Doing authentication that way is The Wrong Way, I should

authentitcate against LDAP or Kerberos. Well, it would certainly be better to do that, but is it completely unreasonnable to start using OpenLDAP without refactoring the world around it? Migration paths can go through harsh flag days or through softer incremental steps. I'm convinced that setting up an LDAP authentication against PAM can help people that try to make a small incremental step.

You are trading off security for expedience. That's almost always a poor trade. If you have convinced yourself that you've weighed all of the pros and cons, go ahead, but we will never encourage such a thing.

You have to step back and consider - what is authentication for? What is being secured? What are the consequences of insecure access to the data? What are the consequences of giving away a "secure" password? Can you actually enumerate all of them?

Taking very simple examples - the directory either contains highly sensitive information, or it contains completely public information. In the public case, there is no need for enforcement of authentication at all. If the system is public anyway, then you should use no passwords, or you should use low-value passwords - e.g., passwords that are only valid in the context of the directory server itself.

If you use a password to a "strong" security system, and the directory service is breached, you have very likely given away the keys to a lot of much more important systems, that were all protected by that same "strong" key. Can you afford such a possibility?

Using SSL/TLS to encrypt the sessions isn't a fool-proof solution. If you still have a cleartext LDAP port enabled on the server, anybody can perform a plaintext Simple Bind. Even though the server security policy may reject such a Bind, the damage is already done because the plaintext password has already been sent across the network. Do you really want to risk that?

In short - don't use Simple Binds unless both the passwords and the directory content are of low importance. Once you connect Simple Bind to a "strong" security system (like Kerberos, RADIUS, whatever) you jeopardize every other service on the network that also uses those systems.

Sean O'Malley omalleys@msu.edu wrote:

I found his documentation -extremely- useful. In fact it was the only one I found that laid out almost the entire process. It should be in the FAQ with some of the BSD stuff taken out. :)

"File an ITS" :-)

On Tuesday 13 February 2007, Emmanuel Dreyfus wrote:

Michael Ströder michael@stroeder.com wrote:

...

Some list members are simply tired by people asking for more docs without really contributing to it.

(snip)

...

...

And I am using Emmanuel's attempt to contribute to the documentation as a case in point.

???

If you go to the root of this thread, you'll find a post where I give the various information I did not find in the doc to use PAM authentication against LDAP. I also told my frustration about the documentation state.

With no doublt my contribution could have been more comprehensive. You can tell it's obsolete or incomplete (I'd appreciate you tell me how exactly), but you can't say I complained without contributing.

However, only a few points of your (4) were specific to OpenLDAP, and about the only one which is not covered in the documentation is the {SASL} scheme for userPassword. There rest of the HOWTO was NetBSD specific, covered some Cyrus-SASL stuff (with NetBSD specifics) and PAM (also with NetBSD specifics).

Regards, Buchan

On Friday 09 February 2007, Emmanuel Dreyfus wrote:

On Fri, Feb 09, 2007 at 01:15:47AM -0800, Howard Chu wrote:

...

I wouldn't expect to find much documentation on this topic because in general it's the wrong thing to do. What distributed authentication system do you use that is supported by pam but is not supported directly by LDAP or SASL?

Radius.

Since all the RADIUS servers I've used (FreeRadius, Radiator, Cisco Access Registrar) support authenticating against a number of different identity storage backends (LDAP, RDBMSs, etc.) ... it would be interesting to know what RADIUS server this is, and why you can't instead authenticate against the same backend store that it uses ...

To me it really seems like you are doing one thing the wrong way around because you have something else doing things the wrong way around.

Regards, Buchan

Emmanuel Dreyfus wrote, on 12. feb 2007 10:54:

...

Since all the RADIUS servers I've used (FreeRadius, Radiator, Cisco Access Registrar) support authenticating against a number of different identity storage backends (LDAP, RDBMSs, etc.) ... it would be interesting to know what RADIUS server this is, and why you can't instead authenticate against the same backend store that it uses ...

To me it really seems like you are doing one thing the wrong way around because you have something else doing things the wrong way around.

The backend against which RADIUS authenticatate could be used, and it will prbbaly be in the future, but that require major refactoring of some IT mess, which is not in the short terms gaols.

Of course that RADIUS story is not The Right Way, but it is what I need right now. This is the real world, you know...

There is a (limited) number of documented masters of "the real world" subscribing to this list on a regular basis and Buchan Milne is one of them; indeed I personally am (and my sites are) indebted to him for his work. Nuff said.

You could, at least, answer his question and tell him why you need to proceed in the obtuse manner you demonstrate instead of waving his question airily away with the argument: that your needs "require major refactoring of some IT mess, which is not in the short terms gaols".

--Tonni

Howard Chu wrote:

Emmanuel Dreyfus wrote:

...

Hi

I banged my head on OpenLDAP -> SASL -> PAM for two days. The status of the documentation is really horrible. Until someone eventually fix that, here is for future reference what I had to do (the NetBSD system parts are out of topic, but I added them for the sake of completeness)

I wouldn't expect to find much documentation on this topic because in general it's the wrong thing to do. What distributed authentication system do you use that is supported by pam but is not supported directly by LDAP or SASL?

Also, postgresql comes to my mind. It supports pam, but not ldap directly.

Even more importantl<, OS Authentication on Linux (and other unices) supports PAM, but not openldap...

Tim