Dan White wrote:
On 09/09/10 21:25 -0700, Howard Chu wrote:
Dan White wrote:
On 09/09/10 20:05 -0700, Russ Allbery wrote:
Wouter van Marlewouter@squirrel-systems.com writes:
At this moment, I can connect to my ldap server from Evolution, authenticated. I have to enter a username and a password in my evo settings, which one way or another is communicated to openldap, which then checks this un/pw combo and considers it valid to give the information.
If you are using Kerberos, you should never have to enter your username and password into anything that isn't kinit or your initial authentication to your system. If you do, that something is broken and is not using Kerberos properly. Period.
So if the poster had stated that he wanted to perform PAM authentication for his simple binds, I don't think he'd be confronted with such a violent reaction. However, from the standpoint of slapd, that's exactly what he's wanting to do.
Performing simple binds have precisely the same negative security footprint regardless of where his passwords may be stored. I'm assuming Evolution
No, it makes a difference, and the fact that you're not aware of the difference demonstrates that you haven't thought it through enough to be qualified to render an opinion on it.
Do you really believe that's true?
My point is that in this scenario, slapd is ignorant of, and should be ignorant of, that fact that kerberos is involved. The fact that pass-through authentication is documented means that users are free to use slapd in this manner, and if a user chooses to use simple binds, there is no security difference with regards to which PAM module is ultimately used.
Or it could just be a doc bug. {KERBEROS} is in the docs too, but the code for that was deleted long ago (2004), since it was a security vulnerability.
Users don't really care to be preached to. If something is supported, it's supported.
If users don't like it that's tough. In this business "the customer is always wrong." If you (generic you) knew more about this than us you wouldn't be here asking questions. Certainly you're in no position to proclaim "I believe it ought to do X" when you lack any understanding of the issues. We discourage particular usage for solid reasons. If you're not going to listen and learn, that's your problem. If you want to go shoot yourself in the foot that's entirely your business too, just don't come back here blaming us when someone drives a tank through your compromised security.