Josh Kelley wrote: > On 9/8/06, Howard Chu <hyc at symas.com> 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 at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20060908/bdae49e7/attachment.bin
