[Dovecot] GSSAPI Authentication in v1.2.1
In the release notes for v1.2.2, Timo said:
Found and fixes several v1.2-specific bugs. Hopefully it's now stable for most people's usage.
- GSSAPI: More changes to authentication. Hopefully good now.
What were the GSSAPI changes? I am having problems with _some_ of my users using GSSAPI auth. I am using version 1.2.1. The client (thunderbird) reports that the server does not support 'secure authentication'. When I switch on auth_debug in dovecot, I see errors such as these in the logs:
Aug 3 16:45:57 fury dovecot: auth(default): client in: AUTH 1 GSSAPI service=imap lip=10.1.0.20 rip=10.8.5.72 lport=143 rport=4027 Aug 3 16:45:57 fury dovecot: auth(default): gssapi(?,10.8.5.72): Using all keytab entries Aug 3 16:45:57 fury dovecot: auth(default): client out: CONT 1 Aug 3 16:45:57 fury dovecot: imap-login: Disconnected: Input buffer full (auth failed, 1 attempts): method=GSSAPI, rip=10.8.5.72, lip=10.1.0.20
Other users work perfectly (eg. all of the user accounts I tested
against). Would this have been a bug that was fixed in 1.2.2 or is it
something else? If it is most likely something else, I will post
dovecot -n.
-- Thanks, Phill Macey
On Tue, 2009-08-04 at 11:31 +1000, Phillip Macey wrote:
In the release notes for v1.2.2, Timo said:
Found and fixes several v1.2-specific bugs. Hopefully it's now stable for most people's usage.
- GSSAPI: More changes to authentication. Hopefully good now.
What were the GSSAPI changes? I am having problems with _some_ of my users using GSSAPI auth. I am using version 1.2.1. The client (thunderbird) reports that the server does not support 'secure authentication'.
I think "secure authentication" usually means CRAM-MD5 in Thunderbird. But maybe they use it for GSSAPI too, no idea.
Aug 3 16:45:57 fury dovecot: imap-login: Disconnected: Input buffer full (auth failed, 1 attempts): method=GSSAPI, rip=10.8.5.72, lip=10.1.0.20
Does it help if you increase
#define LOGIN_MAX_INBUF_SIZE 4096
to e.g. 8192 in src/login-common/client-common.h?
On 8/08/2009 2:50 AM, Timo Sirainen wrote:
Does it help if you increase
#define LOGIN_MAX_INBUF_SIZE 4096
to e.g. 8192 in src/login-common/client-common.h? I also needed to change src/master/master-login-interface.h #define MASTER_LOGIN_MAX_DATA_SIZE (8192*2)
After making those changes and recompiling, users who were previously unable to authenticate are now able to - at least on my test box anyway. I will test with a couple of other accounts later this week - so far I have only tested on two. All going well I should be able to apply the changes to our live server sometime soon.
Out of interest, what sort of stuff gets stored in this buffer? Would it be where dovecot stores a users kerberos tickets?
-- Thanks, Phill Macey (CiSRA IT Services)
On Thu, 2009-08-13 at 17:55 +1000, Phillip Macey wrote:
On 8/08/2009 2:50 AM, Timo Sirainen wrote:
Does it help if you increase
#define LOGIN_MAX_INBUF_SIZE 4096
to e.g. 8192 in src/login-common/client-common.h? I also needed to change src/master/master-login-interface.h #define MASTER_LOGIN_MAX_DATA_SIZE (8192*2)
What do you mean by "needed to"? Was the auth still failing without that change? I don't think it should..
Out of interest, what sort of stuff gets stored in this buffer? Would it be where dovecot stores a users kerberos tickets?
LOGIN_MAX_INBUF_SIZE is just the max. size of data that can be kept in memory that comes from client. The limit you were probably reaching was in AUTHENTICATE command when your client was sending Kerberos response.
MASTER_LOGIN_MAX_DATA_SIZE is only about sending data to imap process that was already read from client by imap-login process. There are no Kerberos tickets or anything stored there. Usually it needs only a couple of bytes to transfer the IMAP login command tag. So I've no idea why it would need to be that large with you.
On 14/08/2009 3:34 AM, Timo Sirainen wrote:
On Thu, 2009-08-13 at 17:55 +1000, Phillip Macey wrote:
On 8/08/2009 2:50 AM, Timo Sirainen wrote:
Does it help if you increase
#define LOGIN_MAX_INBUF_SIZE 4096
to e.g. 8192 in src/login-common/client-common.h?
I also needed to change src/master/master-login-interface.h #define MASTER_LOGIN_MAX_DATA_SIZE (8192*2)
What do you mean by "needed to"? Was the auth still failing without that change? I don't think it should..
I got a warning message during the build if I did not. I dont think it built successfully if I did not change it as well. The comment immediately preceding that line of code also talks about keeping the two values in sync. From src/master/master-login-interface.h: /* This should be kept in sync with LOGIN_MAX_INBUF_SIZE. Multiply it by two to make sure there's space to transfer the command tag */ #define MASTER_LOGIN_MAX_DATA_SIZE (8192*2)
Out of interest, what sort of stuff gets stored in this buffer? Would it be where dovecot stores a users kerberos tickets?
LOGIN_MAX_INBUF_SIZE is just the max. size of data that can be kept in memory that comes from client. The limit you were probably reaching was in AUTHENTICATE command when your client was sending Kerberos response.
MASTER_LOGIN_MAX_DATA_SIZE is only about sending data to imap process that was already read from client by imap-login process. There are no Kerberos tickets or anything stored there. Usually it needs only a couple of bytes to transfer the IMAP login command tag. So I've no idea why it would need to be that large with you. Win2k8/Active Directory KDC - maybe they do something wacky?
-- Thanks, Phill Macey (CiSRA IT Services)
On Fri, 2009-08-14 at 16:46 +1000, Phillip Macey wrote:
I also needed to change src/master/master-login-interface.h #define MASTER_LOGIN_MAX_DATA_SIZE (8192*2)
What do you mean by "needed to"? Was the auth still failing without that change? I don't think it should..
I got a warning message during the build if I did not.
Oh. That's good then. I tried to look for those warnings but didn't notice where I had put one so I thought you had some runtime failure.
On Fri, 2009-08-14 at 16:46 +1000, Phillip Macey wrote:
I also needed to change src/master/master-login-interface.h #define MASTER_LOGIN_MAX_DATA_SIZE (8192*2) Will these changes be included in the next release or is this something
On 15/08/2009 2:08 AM, Timo Sirainen wrote: that we will need to maintain for ourselves?
-- Thanks, Phill Macey (CiSRA IT Services)
On Mon, 2009-08-17 at 18:18 +1000, Phillip Macey wrote:
On Fri, 2009-08-14 at 16:46 +1000, Phillip Macey wrote:
I also needed to change src/master/master-login-interface.h #define MASTER_LOGIN_MAX_DATA_SIZE (8192*2) Will these changes be included in the next release or is this something
On 15/08/2009 2:08 AM, Timo Sirainen wrote: that we will need to maintain for ourselves?
I increased them now: http://hg.dovecot.org/dovecot-1.2/rev/05eec45994d9
v2.0 does this better. There the limit is only in dovecot-auth, login process just forwards the data no matter how large it is.
On 15/08/2009 2:08 AM, Timo Sirainen wrote:
On Fri, 2009-08-14 at 16:46 +1000, Phillip Macey wrote:
I also needed to change src/master/master-login-interface.h #define MASTER_LOGIN_MAX_DATA_SIZE (8192*2) Will these changes be included future releases or is this something that we will need to maintain for ourselves?
-- Thanks, Phill Macey (CiSRA IT Services)
On 8/08/2009 2:50 AM, Timo Sirainen wrote:
Does it help if you increase
#define LOGIN_MAX_INBUF_SIZE 4096
to e.g. 8192 in src/login-common/client-common.h? I also needed to change src/master/master-login-interface.h #define MASTER_LOGIN_MAX_DATA_SIZE (8192*2)
After making those changes and recompiling, users who were previously unable to authenticate are now able to - at least on my test box anyway. I will test with a couple of other accounts later this week - so far I have only tested on two. FYI: I got a few more of the 'Input buffer full (auth failed' logs while I was doing some testing for the 'Crash in v1.2.3: istream.c: assertion failed on line 99' thread (http://www.dovecot.org/list/dovecot/2009-August/042109.html). I didnt notice it actually break anything so Im not sure if its worth worrying about - but I thought it worth a mention. Perhaps it is just something
On 13/08/2009 5:55 PM, Phillip Macey wrote: peculiar about our setup or what I was doing that caused something (kerberos tickets?) to be excessively large?
-- Thanks, Phill Macey (CiSRA IT Services)
Phillip Macey wrote:
In the release notes for v1.2.2, Timo said:
Found and fixes several v1.2-specific bugs. Hopefully it's now stable for most people's usage.
* GSSAPI: More changes to authentication. Hopefully good now.What were the GSSAPI changes? I am having problems with _some_ of my users using GSSAPI auth. I am using version 1.2.1. The client (thunderbird) reports that the server does not support 'secure authentication'. When I switch on auth_debug in dovecot, I see errors such as these in the logs:
Aug 3 16:45:57 fury dovecot: auth(default): client in: AUTH 1 GSSAPI service=imap lip=10.1.0.20 rip=10.8.5.72 lport=143 rport=4027 Aug 3 16:45:57 fury dovecot: auth(default): gssapi(?,10.8.5.72): Using all keytab entries Aug 3 16:45:57 fury dovecot: auth(default): client out: CONT 1 Aug 3 16:45:57 fury dovecot: imap-login: Disconnected: Input buffer full (auth failed, 1 attempts): method=GSSAPI, rip=10.8.5.72, lip=10.1.0.20
Other users work perfectly (eg. all of the user accounts I tested against). Would this have been a bug that was fixed in 1.2.2 or is it something else? If it is most likely something else, I will post
dovecot -n.
Same here (1.2.3), it's been working fine adding all possible principals to the keytab and setting:
auth_gssapi_hostname = $ALL
There are all sorts of resolvers out there that seem to mess with principal name selection on the clients all the time. Weird thing is this particular one didn't happen with 1.1.x
-- Angel Marin http://anmar.eu.org/
participants (4)
-
Angel Marin
-
Jason Gunthorpe
-
Phillip Macey
-
Timo Sirainen