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 CRAM-MD5 only works if passwords are stored in cleartext in FDS. Is this correct?
The problem is that our OS X clients, when configured for LDAP authentication, try a SASL bind (CRAM-MD5) first then fall back to a simple bind if that fails. When OS X checks a login against an OpenLDAP server, the server returns resultCode 80 (other), error message "SASL(-13): user not found: no secret in database", and so the client falls back to a simple bind. However, when OS X tries a SASL bind against FDS, the server returns resultCode 49 (invalidCredentials), error message "SASL(-13): authentication failure: incorrect digest response", and so the client assumes that the login failed.
Is this a bug in FDS? Or did I misconfigure something? Is there an easy workaround? Our Macs are mostly unusable until I can get this fixed.
Thanks.
Josh Kelley
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 using DIGEST-MD5 and CRAM-MD5 only works if passwords are stored in cleartext in FDS. Is this correct?
Yes.
The problem is that our OS X clients, when configured for LDAP authentication, try a SASL bind (CRAM-MD5) first then fall back to a simple bind if that fails. When OS X checks a login against an OpenLDAP server, the server returns resultCode 80 (other), error message "SASL(-13): user not found: no secret in database", and so the client falls back to a simple bind. However, when OS X tries a SASL bind against FDS, the server returns resultCode 49 (invalidCredentials), error message "SASL(-13): authentication failure: incorrect digest response", and so the client assumes that the login failed.
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?
Our Macs are mostly unusable until I can get this fixed.
Thanks.
Josh Kelley
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
On 9/7/06, Richard Megginson rmeggins@redhat.com 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 LDAP resultCode - the only SASL results that the client sees appears to be a text error message, and I doubt OS X bothers to parse that - but I don't know of an easy way to check.
Josh Kelley
Josh Kelley wrote:
On 9/7/06, Richard Megginson rmeggins@redhat.com 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 LDAP resultCode - the only SASL results that the client sees appears to be a text error message, and I doubt OS X bothers to parse that - but I don't know of an easy way to check.
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 to ask on ldap@umich.edu or on IRC.freenode.net #ldap if there is a standard that covers this case.
Josh Kelley
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
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 authenticate generally result in a binary succeed/fail result (excepting perhaps cases like 'your password has expired, which is only returned when an old but valid password is presented).
On 9/7/06, Richard Megginson rmeggins@redhat.com 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 to ask on ldap@umich.edu or on IRC.freenode.net #ldap if there is a standard that covers this case.
Thanks for the suggestion. I'll ask.
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.
Even if the standards permit either behavior (and even if it's slightly more secure to not reveal additional information, as David Boreham pointed out), wouldn't it be worth having FDS compatible with OpenLDAP and OS X?
Josh Kelley
Josh Kelley wrote:
On 9/7/06, Richard Megginson rmeggins@redhat.com 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 to ask on ldap@umich.edu or on IRC.freenode.net #ldap if there is a standard that covers this case.
Thanks for the suggestion. I'll ask.
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.
Yes. But it seems to differ from the behavior of a simple bind (rfc4513 5.1.3). In a simple bind, the server resultCode differentiates these cases: 1) Invalid bind DN results in a noSuchObject (well, not exactly specified, but this is the usual behavior) 2) Valid bind DN but invalid password results in invalidCredentials
However, the rfc (and also rfc 4511 Appendix A LDAP Result Codes) says that other codes may be substituted for the above "to prevent unauthorized disclosures (such as substitution of noSuchObject for insufficientAccessRights, or invalidCredentials for insufficientAccessRights)."
The SASL doc (rfc4422) says:
"It is also 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."
So it seems that SASL wants the server not to differentiate these cases, probably for security reasons. But this makes sasl binds have different semantics than simple binds.
Even if the standards permit either behavior (and even if it's slightly more secure to not reveal additional information, as David Boreham pointed out), wouldn't it be worth having FDS compatible with OpenLDAP and OS X?
Yes. And please file a bug about this at http://bugzilla.redhat.com/
Josh Kelley
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
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 server can be configured such that the outcome message will not distinguish between a valid user with invalid credentials and an invalid user.
This is eactly what I was saying and would appear to be the opposite of what OpenLDAP have implemented.
Back and bit in that same paragraph it says :
The outcome is not successful if ... - the client's credentials could not be verified,
which again seems to be in line with the FDS implementation because it tells the client that the authentication attempt was unsuccessful.
389-users@lists.fedoraproject.org
-
David Boreham -
Josh Kelley -
Rich Megginson