On 9/8/06, Richard Megginson <[EMAIL PROTECTED]> wrote:
Josh Kelley wrote:
> 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 th
Josh Kelley wrote:
On 9/8/06, Howard Chu <[EMAIL PROTECTED]> 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
On 9/8/06, Howard Chu <[EMAIL PROTECTED]> 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
relea
Date: Fri, 08 Sep 2006 09:01:41 -0600
From: Richard Megginson <[EMAIL PROTECTED]>
Josh Kelley wrote:
> On 9/7/06, Richard Megginson <[EMAIL PROTECTED]> wrote:
>> I checked RFC 4513 - http://www.ietf.org/rfc/rfc4513.txt - it doesn't
>> say anything about the correct result code to return in t
I skimmed RFC 4513 (sans coffee) and didn't find the section you're
referring to. I did see that RFC 4422 (last paragraph of section 3.6)
seems to suggest that OS X's and OpenLDAP's behavior is legitimate and
useful.
I'm not sure I read that there. I see this :
It is also important that the
Josh Kelley wrote:
On 9/7/06, Richard Megginson <[EMAIL PROTECTED]> wrote:
I checked RFC 4513 - http://www.ietf.org/rfc/rfc4513.txt - it doesn't
say anything about the correct result code to return in this case, other
than it is an error if anything other than success or bindinprogress is
retur
On 9/7/06, Richard Megginson <[EMAIL PROTECTED]> wrote:
I checked RFC 4513 - http://www.ietf.org/rfc/rfc4513.txt - it doesn't
say anything about the correct result code to return in this case, other
than it is an error if anything other than success or bindinprogress is
returned. You might want
One thing to observe here is that _generally_ one does not
want to reveal more information to a potential attacker than is
necessary. In this case it may be useful for a bad guy to know
that there is no plaintext password vs. only knowing that
authentication failed. Put another way : attempts to a
Josh Kelley wrote:
On 9/7/06, Richard Megginson <[EMAIL PROTECTED]> wrote:
Josh Kelley wrote:
> Is this a bug in FDS? Or did I misconfigure something? Is there an
> easy workaround?
I'm not sure. Is it the LDAP resultCode that causes the OS X clients to
fail, or is it the SASL return code?
On 9/7/06, Richard Megginson <[EMAIL PROTECTED]> wrote:
Josh Kelley wrote:
> Is this a bug in FDS? Or did I misconfigure something? Is there an
> easy workaround?
I'm not sure. Is it the LDAP resultCode that causes the OS X clients to
fail, or is it the SASL return code?
I assume it's the LD
Josh Kelley wrote:
SASL authentication appears to be operating incorrectly on my install
of FDS. We do not use SASL; our passwords are stored in FDS using
CRYPT-MD5, SMD5, and SSHA256, depending on when and how the account's
password was last changed. As I understand it, SASL authentication
usi
SASL authentication appears to be operating incorrectly on my install
of FDS. We do not use SASL; our passwords are stored in FDS using
CRYPT-MD5, SMD5, and SSHA256, depending on when and how the account's
password was last changed. As I understand it, SASL authentication
using DIGEST-MD5 and CR
12 matches
Mail list logo
