Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
I have now successfully tested sasl-sample-client sasl-sample-server (and imtest) with GSSAPI authentication. Once my kerberos config files were corrected, everything worked. The error messages could certainly have been more helpful, but I know of no reason why this bug should not be closed now. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
While constructing a reply to your message, I believe I have found the
error. I had the wrong hostname for the kdc in the [realms] section
of /etc/krb5.conf. I'm a bit confused about why I was able to get
tickets at all with kinit, but now both the kerberos clients and
sasl-sample-{client,server} authentication are working properly.
My thanks and apologies to all those who helped me with this. When I
get GSSAPI authentication fully functional with imapd on my system, I
will attempt to write it up as an example so that others might benefit
from these tribulations.
--Mike
My original reply, with the error messages that I saw before I
corrected the kdc's hostname in /etc/krb5.conf:
On Tue, Dec 19, 2006 at 10:52:13AM -0500, Sam Hartman wrote:
OK, so we basically know it is a client side problem.
* check the domain_realm mappings in krb5.conf
I don't have any that apply to my domain/realm. As I understand it,
the domain nutwerk.org should get mapped to the realm NUTWERK.ORG
without an entry there.
* confirm that you can get krb5-rsh-server and the rlogin -x hostname
fromkrb5-clients working. They tend to produce better error
reporting.
In fact, I cannot, though I can get it to work on another machine
(with a different domain realm, but very nearly identical config
files). The error messages in this case are less than enlightening,
however:
[EMAIL PROTECTED]:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1001
Default principal: [EMAIL PROTECTED]
Valid starting ExpiresService principal
12/23/06 16:25:21 12/24/06 02:25:21 krbtgt/[EMAIL PROTECTED]
renew until 12/30/06 16:25:17
Kerberos 4 ticket cache: /tmp/tkt1001
klist: You have no tickets cached
[EMAIL PROTECTED]:~$ rlogin -x geomancer.nutwerk.org
error getting credentials: Generic error (see e-text)
Trying krb4 rlogin...
krb_sendauth failed: You have no tickets cached
[EMAIL PROTECTED]:~$ krb5-rsh geomancer.nutwerk.org ls
error getting credentials: Generic error (see e-text)
Trying krb4 rsh...
krb_sendauth failed: You have no tickets cached
trying normal rsh (/usr/bin/netkit-rsh)
exec: No such file or directory
* Run kvno host/[EMAIL PROTECTED] after using kinit.
[EMAIL PROTECTED]:~$ kvno host/[EMAIL PROTECTED]
host/[EMAIL PROTECTED]: Generic error (see e-text) while getting credentials
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
On Mon, Dec 18, 2006 at 12:00:41AM -0500, Sam Hartman wrote:
Interesting. Do you end up getting tickets for the host service or
just a tgt?
After sasl-sample-client exits, I still only have a tgt.
Is any error logged on the Kerberos KDC?
None that I see, but I might be looking in the wrong place. The only
messages I see are in /var/log/auth.log when I call kinit:
Dec 18 16:04:11 geomancer krb5kdc[2359]: AS_REQ (7 etypes {18 17 16 23 1 3 2})
172.16.0.107: NE
Dec 18 16:04:17 geomancer krb5kdc[2359]: AS_REQ (7 etypes {18 17 16 23 1 3 2})
172.16.0.107: IS
--Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
Interesting. Do you end up getting tickets for the host service or just a tgt? Is any error logged on the Kerberos KDC? Does the sasl sample pass the hostname into the sasl library? Many mechanisms such as digest-md5 and cram-md5 will mostly work without a hostname passed in, but gssapi requires it. I rather assume the sample got that right because I'd actually expect that CMU often tests with gssapi. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
severity 402844 normal tags 402844 moreinfo thanks Sam: any chance you could send your configuration to this bug? Specifically, the following files: /etc/krb5.conf /etc/cyrus.conf /etc/imapd.conf /etc/default/saslauthd (unless you use an auxprop mechanism, of course) Michael: On Thu, 2006-12-14 at 11:44 -0500, Michael Richters wrote: That's what I did, and included in the original report, except that I specified the service name (host). The results are the same if I leave out the -s host: Right, of course. I didn't read carefully enough, sorry about that. Any idea what I might be doing wrong? I suspect some kind of configuration error, because Sam Hartman has a working GSSAPI + Cyrus IMAPd system running (see bug #400955). That's why I'm downgrading this bug -- which doesn't mean we're abandoning it. I think the fix will be better docs, as you've said. One thing which sticks out to me is that you have sasl_pwcheck_method: saslauthd in /etc/imapd.conf, but then you have MECHANISMS=pam in /etc/default/saslauthd. I'm not too familiar with GSSAPI, but it seems to me that something should be different here, as Kerberos will handle how authentication data is stored, and saslauthd should simply ask it to authenticate the user (or fail). Let's see if we can get Sam's config and find out if there is a deciding difference between his and yours. Cheers, -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
On Sat, Dec 16, 2006 at 10:34:53AM +0200, Fabian Fagerholm wrote: One thing which sticks out to me is that you have sasl_pwcheck_method: saslauthd in /etc/imapd.conf, but then you have MECHANISMS=pam in /etc/default/saslauthd. I'm not too familiar with GSSAPI, but it seems to me that something should be different here, as Kerberos will handle how authentication data is stored, and saslauthd should simply ask it to authenticate the user (or fail). I'd be surprised if saslauthd had anything to do with it, because GSSAPI is not a plaintext authentication mechanism (like CRAM-MD5 and DIGEST-MD5, which can succeed even when saslauthd isn't running). Could it be that GSSAPI authentication is failing because I have an entry for the user in /etc/sasldb? --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
Michael, Thanks for your report! On Tue, 2006-12-12 at 18:58 -0500, Michael Richters wrote: GSSAPI authentication does not appear to work for the SASL sample client and server. Of course, it is possible that I'm not doing something wrong, given the lack of examples in the documentation. The documentation is really lacking. That's one of the items on our todo list, which won't be in shape for etch, unfortunately. But we try to collect as much information as possible and hope to put together better documentation later. Could you please try the following: On the client: $ kinit $ sasl-sample-client -m gssapi -n geomancer.nutwerk.org On the server: $ sasl-sample-server Then manually copy and paste the server output (the whole line, starting with and including S: or C:) to stdin on the client and vice versa, until you either get success or failure. Thanks, -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
On Thu, Dec 14, 2006 at 08:23:58AM +0200, Fabian Fagerholm wrote: Could you please try the following: On the client: $ kinit $ sasl-sample-client -m gssapi -n geomancer.nutwerk.org On the server: $ sasl-sample-server Then manually copy and paste the server output (the whole line, starting with and including S: or C:) to stdin on the client and vice versa, until you either get success or failure. That's what I did, and included in the original report, except that I specified the service name (host). The results are the same if I leave out the -s host: [EMAIL PROTECTED]:~$ kinit Password for [EMAIL PROTECTED]: [EMAIL PROTECTED]:~$ /usr/sbin/sasl-sample-server Generating client mechanism list... Sending list of 7 mechanism(s) S: TE9HSU4gQ1JBTS1NRDUgR1NTQVBJIFBMQUlOIEFOT05ZTU9VUyBOVExNIERJR0VTVC1NRDU= Waiting for client mechanism... [EMAIL PROTECTED]:~$ sasl-sample-client -m gssapi -n geomancer.nutwerk.org Waiting for mechanism list from server... S: TE9HSU4gQ1JBTS1NRDUgR1NTQVBJIFBMQUlOIEFOT05ZTU9VUyBOVExNIERJR0VTVC1NRDU= recieved 53 byte message Forcing use of mechanism gssapi Choosing best mechanism from: gssapi sasl-sample-client: SASL Other: GSSAPI Error: Miscellaneous failure (Generic error (see e-text)) error was SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (Generic error (see e-text)) sasl-sample-client: Starting SASL negotiation: generic failure [EMAIL PROTECTED]:~$ echo $? 1 [EMAIL PROTECTED]:~$ Any idea what I might be doing wrong? --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
Package: libsasl2-modules-gssapi-mit Version: 2.1.22.dfsg1-7 Severity: important GSSAPI authentication does not appear to work for the SASL sample client and server. Of course, it is possible that I'm not doing something wrong, given the lack of examples in the documentation. Here's a transcript from the client: -- [EMAIL PROTECTED]:~$ kinit Password for [EMAIL PROTECTED]: [EMAIL PROTECTED]:~$ klist Ticket cache: FILE:/tmp/krb5cc_1001 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 12/12/06 18:41:57 12/13/06 04:41:57 krbtgt/[EMAIL PROTECTED] renew until 12/19/06 18:41:51 Kerberos 4 ticket cache: /tmp/tkt1001 klist: You have no tickets cached [EMAIL PROTECTED]:~$ sasl-sample-client -s host -m gssapi -n geomancer.nutwerk.org service=host Waiting for mechanism list from server... S: TE9HSU4gQ1JBTS1NRDUgR1NTQVBJIFBMQUlOIEFOT05ZTU9VUyBOVExNIERJR0VTVC1NRDU= recieved 53 byte message Forcing use of mechanism gssapi Choosing best mechanism from: gssapi sasl-sample-client: SASL Other: GSSAPI Error: Miscellaneous failure (Generic error (see e-text)) error was SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (Generic error (see e-text)) sasl-sample-client: Starting SASL negotiation: generic failure -- Here's the corresponding transcript from the server: -- geomancer:~# klist -k Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 3 host/[EMAIL PROTECTED] 3 host/[EMAIL PROTECTED] geomancer:~# sasl-sample-server -s host Generating client mechanism list... Sending list of 7 mechanism(s) S: TE9HSU4gQ1JBTS1NRDUgR1NTQVBJIFBMQUlOIEFOT05ZTU9VUyBOVExNIERJR0VTVC1NRDU= Waiting for client mechanism... -- The error message is too vague for me to guess the cause of the problem. --Mike -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
