Authentication with saslauthd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Thanks for the answer it's a little better....
Now i get the following in /var/log/maillog

Jan  3 21:17:34 localhost postfix/smtpd[3435]: warning: SASL authentication failure: Password verification failed
Jan  3 21:17:34 localhost postfix/smtpd[3435]: warning: localhost.localdomain[127.0.0.1]: SASL PLAIN authentication fa iled: authentication failure
Jan  3 21:17:34 localhost postfix/smtpd[3435]: > localhost.localdomain[127.0.0.1]: 535 5.7.0 Error: authentication fai led: authentication failure

I'm sure the user and pass is correct. It works when i use it with testsaslauthd. What else do you think it could be?
Thanks!



----- Original Message ----
From: "cyrus-sasl-request@xxxxxxxxxxxxxxxxxxxx" <cyrus-sasl-request@xxxxxxxxxxxxxxxxxxxx>
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Sent: Wednesday, January 3, 2007 7:00:15 PM
Subject: Cyrus-sasl Digest, Vol 18, Issue 2

Send Cyrus-sasl mailing list submissions to
    cyrus-sasl@xxxxxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.andrew.cmu.edu/mailman/listinfo/cyrus-sasl
or, via email, send a message with subject or body 'help' to
    cyrus-sasl-request@xxxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
    cyrus-sasl-owner@xxxxxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cyrus-sasl digest..."


Today's Topics:

   1. Re: Multiple-Mechanism Sample Code? (Henry B. Hotz)
   2. Re: Multiple-Mechanism Sample Code?  (Henry B. Hotz)
   3. Re: Multiple-Mechanism Sample Code?  (Ken Hornstein)
   4. (no subject) (Tiron Adrian)
   5. Re: (no subject) (Patrick Ben Koetter)


----------------------------------------------------------------------

Message: 1
Date: Tue, 2 Jan 2007 18:09:31 -0800
From: "Henry B. Hotz" <hotz@xxxxxxxxxxxx>
Subject: Re: Multiple-Mechanism Sample Code?
To: Dave Cridland <dave@xxxxxxxxxxxx>
Cc: Discussion list for the Cyrus SASL library
    <cyrus-sasl@xxxxxxxxxxxxxxxxxxxx>,    Alexey Melnikov
    <alexey.melnikov@xxxxxxxxx>
Message-ID: <AF580985-CC64-45B5-B859-34492B71F95D@xxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

The SASL API is already pretty complex for what it does IMO.  (Why  
isn't there a call that does both sasl_client_init() and  
sasl_client_new()?  Why does every app need 10++ lines in front of  
sasl_{client,server}_new() to do two getnameinfo()'s and two  
snprintf's, instead of just handing over the sockaddr's?  Why. . . ?  
Obviously, I'm still getting familiar with things.)

Unless you can tell me that there is a properly-documented API for an  
ACAP library that's deployed on as many platforms (including Java) as  
SASL already is, *AND* that it's no harder to write/modify an  
application to use ACAP than it is to use SASL, then I'm not  
interested.  Sorry.  You're welcome to try to convince me, but it  
sounds off-topic for this list.

In my current experiments Cyrus SASL doesn't appear to work when you  
call sasl_client_start() with the second mechanism to try.  There are  
a lot of variables here, and a better-than-even chance the problem is  
in my code, not the library.  Once I have something properly working  
I'll revisit this issue.  I gather you're claiming that ACAP solves  
this (and other) problems.  See above.

Hopefully I can provide a better SASL example than the one currently  
circulating.  The one in the current distribution is really an option  
test rig.  The older example is better for someone figuring out how  
to write a SASL-ized application.

On Dec 19, 2006, at 1:23 AM, Dave Cridland wrote:

> On Mon Dec 18 22:12:03 2006, Alexey Melnikov wrote:
>> Henry B. Hotz wrote:
>>> The published sample code seems to only try the first mechanism  
>>> and  then quit.  I'm told the "correct" way to do SASL is to try  
>>> all the  mechanisms (or at least all the ones supported) and  
>>> don't quit until  you've tried them all.  Is there any example  
>>> code that illustrates this?
>> (I wanted to point you to Cyrus imtest, but it doesn't do that).
>> In general, I think a well written SASL client should behave as  
>> follows:
>> It should sort SASL mechanisms that both client and server support  
>> by their "strength" or features recognized by the client. For SASL  
>> mechanisms with equal strength the order used by the server can be  
>> used.
>> The client starts iterating through the ordered list, starting  
>> from the strongest mechanism. It tries the mechanism. If  
>> authentication succeeds - success. If not, the client may retry  
>> the mechanism (e.g. if the server returned an indication that the  
>> password is incorrect) several times, say 3 times. After that the  
>> client should move on to the next strongest SASL mechanism and so on.
>> There are of course some complications. Some SASL mechanisms that  
>> can potentially be stronger can end up being weaker, because of  
>> the options that the server supports.
> There are more complications than that - some protocols give you a  
> fairly wide set of protocol-level data about why a SASL exchange  
> failed, others don't. For example, IMAP will give you a pretty  
> simple "NO" for any failure at all, whereas ACAP will tell you  
> rather more, such as AUTH-TOO-WEAK, ENCRYPT-NEEDED, TRANSITION-
> NEEDED, etc, which can be used by the client to figure out what the  
> next action should be.

Working examples?  I'm modifying the PostgreSQL protocol as needed.  
Adding SASL data to existing messages is easy.  Adding an  
AuthenticationContinue message isn't very hard either because they  
have a protocol manual that's quite nice.

I'm concerned that the Cyrus API is so complex that the resulting  
patches may be deemed too complex for acceptance.  From a practical  
standpoint what PostgreSQL stands to gain is 1) Kerberos support that  
works on Windows and in Java, not just Unix/C, and 2) a bunch of  
stuff that duplicates existing functionality.  If it works well  
enough 2) could be seen as an advantage in the long run since it  
could allow the removal of their custom password database, custom  
password verification algorithms, and PAM support.  "Works well  
enough" means "works, and takes no effort to link against on most  
platforms".

> Also, you need to add TLS into the mix, too - which is in itself  
> negotiated, of course, and will probably change the advertised  
> mechanisms.
>
> As a for-example, a ACAP client might initially try DIGEST-MD5,  
> cancel it partway through because no encryption was supported, use  
> STARTTLS, try DIGEST-MD5, fail due to a TRANSITION-NEEDED code, and  
> use PLAIN.
>
> An IMAP client in more or less tha same situation has longer to go,  
> because it doesn't get the TRANSITION-NEEDED code, and therefore  
> has no idea if it should retry DIGEST-MD5 a few times, or try a  
> different mechanism.
>
> As if anyone needed *more* reasons to use ACAP. :-)
>
> Dave.
> --
> Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@xxxxxxxxxxxx, or hbhotz@xxxxxxx




------------------------------

Message: 2
Date: Tue, 2 Jan 2007 18:50:49 -0800
From: "Henry B. Hotz" <hotz@xxxxxxxxxxxx>
Subject: Re: Multiple-Mechanism Sample Code?
To: Ken Hornstein <kenh@xxxxxxxxxxxxxxxx>
Cc: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <0754C074-7229-4DBD-9E74-6B9651C6C8A8@xxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed


On Dec 31, 2006, at 9:41 PM, Ken Hornstein wrote:

> Now, my suggestions?  I think a SASL client should do the following:
>
> - Allow (and perhaps even enforce) the selection of a specific SASL
>   mechanism.

Do you disagree with Simon's recommendation that a client should try  
all mutually supported mechanisms before giving up?

> - If a mechanism is not specifically selected, pick the "best" one
>   (I'm sure we could get into massive arguments about what the "best"
>   mechanism is).  You could use some intelligence here; if you don't
>   have a Kerberos credential cache, for example, don't try GSSAPI.

Around here all users are in the central repository, but the  
administrative accounts for services are local to the service.  I was  
envisioning "GSSAPI CRAM-MD5" as a back-door way of supporting two  
different repositories.

> - If authentication fails with the chosen mechanism, error out and
>   return the error text to the user.

Absolutely necessary.  Of course the error you want is for the  
mechanism that was supposed to work, and not for the ones that were  
supposed to fail.  ;-)

------

My own prejudices:

I think Cyrus SASL should take care of trying all the mutually  
supported mechanisms.  The client app programmer should never have to  
tell the server what mechanism it's trying; that ought to be in the  
"clientout" data returned by sasl_client_{start,step}().  The client  
app programmer should never have to call sasl_client_start() a second  
time to make the library try all of the mechanisms.  SASL_INTERACT  
should only be returned by sasl_client_start(), and never by  
sasl_client_step().  The client app should not require any mechanism  
selection configuration at all (except to exclude insecure mechanisms).

What I see in practice is that most (everything except MacOS X  
ldapsearch?) applications make you select the specific, actual  
mechanism on the client side.  Nobody actually uses the mechanism  
negotiation that the protocol provides.  I think we're both touching  
on reasons why:  the library doesn't properly support it.  Maybe the  
protocol is inadequate to make it work reliably, but I would think  
that trying all the possibilities SHOULD make it more reliable rather  
than less.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@xxxxxxxxxxxx, or hbhotz@xxxxxxx




------------------------------

Message: 3
Date: Wed, 03 Jan 2007 00:44:27 -0500
From: Ken Hornstein <kenh@xxxxxxxxxxxxxxxx>
Subject: Re: Multiple-Mechanism Sample Code?
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <200701030544.l035iSUX026092@xxxxxxxxxxxxxxxxxxxxxxx>

>> Now, my suggestions?  I think a SASL client should do the following:
>>
>> - Allow (and perhaps even enforce) the selection of a specific SASL
>>   mechanism.
>
>Do you disagree with Simon's recommendation that a client should try  
>all mutually supported mechanisms before giving up?

In a perfect world ... no.  In this world ... yes, I disagree.

#1 - You need mechanism-specific knowledge to do this right.
Otherwise you end up with things like prompting for a new password
when you get a GSSAPI failure.  I'll give you a related example: I
had cases where the MacOS X-suppled ssh would "hang" for a long
time when someone would kinit and then ssh to a system that didn't
support GSSAPI.  I wasn't able to debug it completely because the
user ended up being a flaming asshole, but my theory was that when
a credential cache appeared, the MacOS X ssh would always try GSSAPI
...  and that was behaving badly in domains that didn't have Kerberos
support.  Now, people are going to point out that ssh doesn't use
SASL, and that's certainly true ... I only bring it up to illustrate
that I can easily envision cases where you shouldn't attempt to use
GSSAPI, even if the server supports it.

#2 - If you try all of the mechanisms and they all fail ... what kind
of error message should you return to the user?

>Absolutely necessary.  Of course the error you want is for the  
>mechanism that was supposed to work, and not for the ones that were  
>supposed to fail.  ;-)

Right, and if you figure out how to determine _that_, let me know :-)

>What I see in practice is that most (everything except MacOS X  
>ldapsearch?) applications make you select the specific, actual  
>mechanism on the client side.  Nobody actually uses the mechanism  
>negotiation that the protocol provides.

Actually, in the code I've written I let mechanism negotiation happen by
default, but I let the user configure a specific mechanism if they want.
This seems to work reasonably well.  But there's only one shot at
authentication.

>I think we're both touching  
>on reasons why:  the library doesn't properly support it.  Maybe the  
>protocol is inadequate to make it work reliably, but I would think  
>that trying all the possibilities SHOULD make it more reliable rather  
>than less.

The problem I see is that this would require the library to be able
to say, "Okay, now restart authentication with this mechanism".  Perhaps
that wouldn't be hard.  But ... and I hate harp on it, but it's very
important to me ... error reporting would be a real bitch if you
did that.

--Ken


------------------------------

Message: 4
Date: Wed, 3 Jan 2007 02:55:40 -0800 (PST)
From: Tiron Adrian <tiron_adrian@xxxxxxxxx>
Subject: (no subject)
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <20070103105540.92237.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"

Hello,
First of all i hope i've sent this mail where it should be. I have had some problems understanding the website.

Anyway i have installed postfix 2.3.5 compiled with cyrus-sasl 2.1.21 and i want to it to perform authentication with the unix database of users, however it tries using the /etc/sasldb2 file  and i don't know why.
I'm running Fedora Core 4 and this is how my /usr/local/lib/sasl2/smtpd.conf looks like.

cat /usr/local/lib/sasl2/smtpd.conf

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

Any ideas?
Sorry for my english,i'm not a native speaker.

Thanks,
Adrian









__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.andrew.cmu.edu/mailman/private/cyrus-sasl/attachments/20070103/33522f4c/attachment-0001.html

------------------------------

Message: 5
Date: Wed, 3 Jan 2007 13:13:54 +0100
From: Patrick Ben Koetter <p@xxxxxxxxxxxxxxxx>
Subject: Re: (no subject)
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <20070103121354.GD15381@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8

* Tiron Adrian <tiron_adrian@xxxxxxxxx>:
> Hello,
> First of all i hope i've sent this mail where it should be. I have had some problems understanding the website.
>
> Anyway i have installed postfix 2.3.5 compiled with cyrus-sasl 2.1.21 and i
> want to it to perform authentication with the unix database of users,
> however it tries using the /etc/sasldb2 file  and i don't know why.  I'm
> running Fedora Core 4 and this is how my /usr/local/lib/sasl2/smtpd.conf
> looks like.
>
>  cat /usr/local/lib/sasl2/smtpd.conf

ln -s /usr/local/lib/sasl2 /usr/lib/sasl2

--
The Book of Postfix
<http://www.postfix-book.com>
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>


------------------------------

_______________________________________________
Cyrus-sasl mailing list
Cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
https://lists.andrew.cmu.edu/mailman/listinfo/cyrus-sasl


End of Cyrus-sasl Digest, Vol 18, Issue 2
*****************************************


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Index of Archives]     [Info Cyrus]     [Squirrel Mail]     [Linux Media]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux