some windows user fail

[Roland C. Dowdeswell]

On Thu, Jan 24, 2013 at 07:59:29AM +0000, Gsandtner Michael wrote:
>

> >>> KrbKdcReq send: kdc=master.magwien.gv.at UDP:88, timeout=30000, number of retries =3, #bytes=1596
> >>> KDCCommunication: kdc=master.magwien.gv.at UDP:88, timeout=30000,Attempt =1, #bytes=1596
> >>> KrbKdcReq send: #bytes read=111
> >>> KrbKdcReq send: #bytes read=111
> >>> KdcAccessibility: remove master.magwien.gv.at
> >>> KDCRep: init() encoding tag is 126 req type is 13
> >>>KRBError:
>          sTime is Thu Jan 24 08:49:01 CET 2013 1359013741000
>          suSec is 217950
>          error code is 52
>          error Message is Response too big for UDP, retry with TCP
>          realm is MAGWIEN.GV.AT
>          sname is ldap/vmlxentw3.host.magwien.gv.at
>          msgType is 30
> >>> KrbKdcReq send: kdc=master.magwien.gv.at TCP:88, timeout=30000, number of retries =3, #bytes=1596
> >>> KDCCommunication: kdc=master.magwien.gv.at TCP:88, #bytes=1596
> >>>DEBUG: TCPClient reading 1538 bytes
> >>> KrbKdcReq send: #bytes read=1538
> >>> KrbKdcReq send: #bytes read=1538
> >>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
> >>> KrbApReq: APOptions are 00000000 00000000 00000000 00000000
> >>> EType: sun.security.krb5.internal.crypto.DesCbcMd5EType

> I hope you can find a difference, I cannot.

Well, there's at least one difference which is that in your successful
example, the client is failing over to TCP rather than using UDP.
It might be worth experimenting with udp_preference_limit = 500 in
your krb5.conf or some lower number to see if that makes a difference
and if it does that would suggest a path to debugging the issue.

Also, I note that your timeouts are 30 seconds.  If you are seriously
using the Java JGSS libraries, then it's a good idea to set the
timeouts rather lower than that.  I can't remember what the setting
is but many JGSS implementations have absurdly high defaults for
this which can result in applications experiencing 90 second delays
during KDC maintenance windows.  The 90s comes from the fact that
the JGSS implemenations that I've played with will try the same
KDC three times in a row before failing over to the next one (a
behaviour that one might argue is suboptimal and if said argument
were made I would have to not quite reluctantly agree.)

Many JGSS implementations will also not try TCP with packets of
any size until either the udp_preference_limit is exceeded or the
KDC replies with ``Message is Response too big for UDP''.  All of
the implementations that I have seen will always use UDP unless
you specify a udp_prefence_limit---the default is no limit rather
than 1491 as with the MIT krb5 libs.  It's a good idea to set one
even if it is the MIT default if you are using JGSS.  If your
network is in a habit of dropping UDP for any reason, you'll likely
do better to try to convince the Java libraries to go straight to
TCP as they'll never try TCP just because the UDP packets are lost.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/