[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP authenticaton against PAM how-to

On 2/10/07, Howard Chu <hyc@symas.com> wrote: 
Emmanuel Dreyfus wrote:
>>> 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?

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


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. 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.


> [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.

You're clearly not aware of a lot. 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.


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).

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.


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.

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"). Shouldn't some sort of
alternative be outlined? (Granted, Tonni did give a positive
suggestion.)

>> 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.

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. 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. If you're
actually interested in learning how to use the software, you'll pay
attention. If you're just looking for a gold star and a pat on the head, go
back to kindergarten.


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.

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.

Matt


--
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   Chief Architect, OpenLDAP     http://www.openldap.org/project/