Josh Kelley wrote:
On 9/8/06, Howard Chu <hyc@xxxxxxxxx> wrote:Before you go any further with this, please tell us which version of OpenLDAP you're using. Current releases (since 2.3.6) return invalidCredentials for a SASL bind failure:2.2.13, as provided by RHEL 4. I had not thought to try a current release; thanks for the info.Probably we should also do something about not returning the SASL-specific error code in this case too, to adhere more to the intent of rfc4422. Logging it on the server side should be sufficient. I just checked, and releases 2.1 and 2.2 returned error code 80 here. So it seems Apple is relying on a broken behavior.I guess I really don't understand here. RFC 4422 says that "outcome message provided by the server can provide a way for the client to distinguish between errors" of various sorts, which I assumed could include errors resulting from attempting to use an unconfigured authentication mechanism. And although the RFC says that it is "important that the server can be configured such that the outcome message will not distinguish between a valid user with invalid credentials and an invalid user," it doesn't say that it's necessary that servers be so configured or that it's broken for servers to not be so configured. Furthermore, it seems to me that what Apple's trying to do - attempt a secure authentication method first, then fall back to a nonsecure authentication method if a secure method is not configured, without needlessly sending cleartext passwords if the secure authentication method is configured and rejects the user - is a good idea. Is Apple's default approach simply not permitted by the RFCs? I understand that for the server to unnecessarily give away security-related info is potentially bad, but it seems like a minor concern compared to the gains of permitting "secure by default, fall back to unsecured" behavior like Apple's default. (I guess MITM attacks are a risk with that kind of approach; are they enough of a risk to negate that approach's value?)
SASL is supposed to attempt to negotiate the strongest auth available.
I hope I'm not coming across as argumentative; I just would really like to understand the issues involved. If it is a bad idea for the server to distinguish between "invalid credentials" and "no secret in database," then what is the best way to get OS X logins to work? For now I've simply disabled CRAM-MD5 by moving those libraries out of my /usr/lib/sasl2 directory, but that seems like a hack. I guess a better solution would be to permit the SASL mech_list to be configured from within FDS; should I submit an RFE on Bugzilla for that?
Yes.
Thanks. Josh Kelley -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
