From benson@bldell.bltest.cc Sun Apr 21 21:51:02 2002
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id VAA22520
for <bugs@RT-11.mit.edu>; Sun, 21 Apr 2002 21:51:01 -0400 (EDT)
Received: from bldell.bltest.cc (dsl092-086-013.bos1.dsl.speakeasy.net [66.92.86.13])
by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA13298
for <krb5-bugs@mit.edu>; Sun, 21 Apr 2002 21:50:59 -0400 (EDT)
Received: (from benson@localhost)
by bldell.bltest.cc (8.11.6/8.11.6) id g3M1oua06678;
Sun, 21 Apr 2002 21:50:56 -0400
Message-Id: <200204220150.g3M1oua06678@bldell.bltest.cc>
Date: Sun, 21 Apr 2002 21:50:56 -0400
From: bmargulies@yahoo.com
Reply-To: bmargulies@yahoo.com
To: krb5-bugs@mit.edu
Subject: request for multi-homed control feature
X-Send-Pr-Version: 3.99
System: Linux bldell.bltest.cc 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown
Architecture: i686
The KDC listens on all available local interfaces.
1) It would be handy to be able to limit the addresses that the KDC
listens on.
2) Microsoft KB entry Q266095 documents a problem with the w2k
kerberos client. If the KDC has two physical interfaces, somehow the
IP address of one interface can end up in the KRB_AS_REP going out
over the other replying. This causes Windows 2000 to fail to log in.
Set up a KDC with two interfaces, and watch the packets
(KRB_AS_REQ/KRB_AS_REP) in flight.
There are two possible approaches here. First, if the kdc.conf had an
'interfaces' configuration stanza, then instead of foreach_localhost
the kdc could limit itself to the specified interfaces.
Even without that, however, it would be a good thing if the KDC kept
the addresses straight. Just because the KDC is on two networks does
not mean that the clients on each can route to the other.
From: Sam Hartman <hartmans@MIT.EDU>
To: bmargulies@yahoo.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/1093: request for multi-homed control feature
Date: Mon, 22 Apr 2002 16:35:59 -0400
We're not aware of situations where the wrong IP address gets sent in
the outgoing packet from the KDC. Can you give more details on a
specific configuration that reproduces this problem? Also, if
interfaces are added to the machine, you probably want to restart the
KDC to avoid potential problems.
From: Benson Margulies <bmargulies@yahoo.com>
To: Sam Hartman <hartmans@mit.edu>
Cc: krb5-bugs@mit.edu
Subject: Re: krb5-kdc/1093: request for multi-homed control feature
Date: Mon, 22 Apr 2002 17:52:28 -0700 (PDT)
Here's what I know.
In my test environment, I originally had a single-interface machine
running a KDC and a Windows 2000 pro machine successfully logging in user
with it.
Then, I completely replaced the system running the KDC and recreated the
realm from scratch. The new machine has two ethernet cards with two
addresses.
I haven't been able to get the Windows box to log in a user in the new
environment.
Completely frustrated, I went trolling in the Microsoft KB, and came up
with the entry I sent you, in which MS claims that confusion results from
a multi-homed KDC. My configuration is dumb-as-a-stick. The error I get on
the Windows box, which is admittedly pretty generic, matches the MS report
exactly.
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id VAA22520
for <bugs@RT-11.mit.edu>; Sun, 21 Apr 2002 21:51:01 -0400 (EDT)
Received: from bldell.bltest.cc (dsl092-086-013.bos1.dsl.speakeasy.net [66.92.86.13])
by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA13298
for <krb5-bugs@mit.edu>; Sun, 21 Apr 2002 21:50:59 -0400 (EDT)
Received: (from benson@localhost)
by bldell.bltest.cc (8.11.6/8.11.6) id g3M1oua06678;
Sun, 21 Apr 2002 21:50:56 -0400
Message-Id: <200204220150.g3M1oua06678@bldell.bltest.cc>
Date: Sun, 21 Apr 2002 21:50:56 -0400
From: bmargulies@yahoo.com
Reply-To: bmargulies@yahoo.com
To: krb5-bugs@mit.edu
Subject: request for multi-homed control feature
X-Send-Pr-Version: 3.99
Show quoted text
>Number: 1093
>Category: krb5-kdc
>Synopsis: KDC could use feature to limit listening interfaces
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: raeburn
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Sun Apr 21 21:52:00 EDT 2002
>Last-Modified: Tue Apr 23 20:42:01 EDT 2002
>Originator: benson
>Organization:
Myself.>Category: krb5-kdc
>Synopsis: KDC could use feature to limit listening interfaces
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: raeburn
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Sun Apr 21 21:52:00 EDT 2002
>Last-Modified: Tue Apr 23 20:42:01 EDT 2002
>Originator: benson
>Organization:
Show quoted text
>Release: krb5-1.2.4
>Environment:
Linux RedHat 7.2.>Environment:
System: Linux bldell.bltest.cc 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown
Architecture: i686
Show quoted text
>Description:
The KDC listens on all available local interfaces.
1) It would be handy to be able to limit the addresses that the KDC
listens on.
2) Microsoft KB entry Q266095 documents a problem with the w2k
kerberos client. If the KDC has two physical interfaces, somehow the
IP address of one interface can end up in the KRB_AS_REP going out
over the other replying. This causes Windows 2000 to fail to log in.
Show quoted text
>How-To-Repeat:
Set up a KDC with two interfaces, and watch the packets
(KRB_AS_REQ/KRB_AS_REP) in flight.
Show quoted text
>Fix:
There are two possible approaches here. First, if the kdc.conf had an
'interfaces' configuration stanza, then instead of foreach_localhost
the kdc could limit itself to the specified interfaces.
Even without that, however, it would be a good thing if the KDC kept
the addresses straight. Just because the KDC is on two networks does
not mean that the clients on each can route to the other.
Show quoted text
>Audit-Trail:
From: Sam Hartman <hartmans@MIT.EDU>
To: bmargulies@yahoo.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/1093: request for multi-homed control feature
Date: Mon, 22 Apr 2002 16:35:59 -0400
We're not aware of situations where the wrong IP address gets sent in
the outgoing packet from the KDC. Can you give more details on a
specific configuration that reproduces this problem? Also, if
interfaces are added to the machine, you probably want to restart the
KDC to avoid potential problems.
From: Benson Margulies <bmargulies@yahoo.com>
To: Sam Hartman <hartmans@mit.edu>
Cc: krb5-bugs@mit.edu
Subject: Re: krb5-kdc/1093: request for multi-homed control feature
Date: Mon, 22 Apr 2002 17:52:28 -0700 (PDT)
Here's what I know.
In my test environment, I originally had a single-interface machine
running a KDC and a Windows 2000 pro machine successfully logging in user
with it.
Then, I completely replaced the system running the KDC and recreated the
realm from scratch. The new machine has two ethernet cards with two
addresses.
I haven't been able to get the Windows box to log in a user in the new
environment.
Completely frustrated, I went trolling in the Microsoft KB, and came up
with the entry I sent you, in which MS claims that confusion results from
a multi-homed KDC. My configuration is dumb-as-a-stick. The error I get on
the Windows box, which is admittedly pretty generic, matches the MS report
exactly.
Show quoted text
__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
From: Benson Margulies <bmargulies@yahoo.com>
To: Sam Hartman <hartmans@mit.edu>
Cc: krb5-bugs@mit.edu
Subject: Re: krb5-kdc/1093: request for multi-homed control feature
Date: Mon, 22 Apr 2002 18:58:08 -0700 (PDT)
I just went and set up a KDC slave on a single-interface box, and now W2K
is happy. So, SOMETHING is definitely going amiss in the multi-interface
case.
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
From: Benson Margulies <bmargulies@yahoo.com>
To: Sam Hartman <hartmans@mit.edu>
Cc: krb5-bugs@mit.edu
Subject: Re: krb5-kdc/1093: request for multi-homed control feature
Date: Mon, 22 Apr 2002 18:58:08 -0700 (PDT)
I just went and set up a KDC slave on a single-interface box, and now W2K
is happy. So, SOMETHING is definitely going amiss in the multi-interface
case.
__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
Responsible-Changed-From-To: krb5-unassigned->raeburn
Responsible-Changed-By: raeburn
Responsible-Changed-When: Tue Apr 23 15:54:03 2002
Responsible-Changed-Why:
I'll take it, part of the multi-homed support is my code.
From: Ken Raeburn <raeburn@MIT.EDU>
To: bmargulies@yahoo.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/1093: KDC could use feature to limit listening interfaces
Date: Tue, 23 Apr 2002 17:25:45 -0400
I've had another request for limiting the set of addresses used, and
am planning to implement that in the future. Regardless, the
multi-homed KDC support should be fixed if it's not working.
Set up a KDC with two interfaces, and watch the packets
(KRB_AS_REQ/KRB_AS_REP) in flight.
You didn't say what you're seeing. Packets with the wrong addresses,
or packets not on the interface you expect?
The KDC code should be sending back responses using the same file
descriptor that it got the request on. So the local address for
sending the response should be the same as the request was sent to.
If that's not happening (the problem described in the MS Knowledge
Base), I'd like some tcpdump, strace and lsof output from you
indicating what file descriptors are being used, what socket addresses
they're bound to, etc.
On some (most? all?) systems with multiple interfaces, the local
routing info may cause the packet to go out an interface that has a
different address assigned. If that's not the right address to use to
reach the destination from the KDC address that was chosen by the
client, I'd argue that that's a system configuration bug.
I don't have a Linux system with multiple physical interfaces on
different networks at the moment, but I may be able to try some tests
using tunnels.
Ken
From: Benson Margulies <bmargulies@yahoo.com>
To: Ken Raeburn <raeburn@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/1093: KDC could use feature to limit listening interfaces
Date: Tue, 23 Apr 2002 17:41:49 -0700 (PDT)
I'm not sure that I'm a representative of a multi-homing problem.
It turns out that Microsoft played a prank on me that led me to believe
that using a single-homed KDC made everything all better. In fact, what
was really happening was the Windows was logging in a user using cached
credentials, while failing to talk to the KDC. When I fixed the
communications problem, the login went back to failing. The KDC issues the
ticket, but Windows fails the login anyway. It doesn't log or audit any
clue to what the problem is.
So, perhaps there's a multi-homing problem. MS certainly seems/seemed to
think so. However, there's some other more basic issue in which following
MS's instructions for setting up a W2K standalone workstation to use an
MIT KDC for authentication don't work. Setting up trust relationships
between an MIT KDC and a Windows AD does work.
In general, the MS Kerberos interface has proved, in my experience, to be
a classic example of providing just enough doc to make it look like it
would be possible to use the thing, but not quite enough to be able to
reliably make it work.
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
Responsible-Changed-From-To: krb5-unassigned->raeburn
Responsible-Changed-By: raeburn
Responsible-Changed-When: Tue Apr 23 15:54:03 2002
Responsible-Changed-Why:
I'll take it, part of the multi-homed support is my code.
From: Ken Raeburn <raeburn@MIT.EDU>
To: bmargulies@yahoo.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/1093: KDC could use feature to limit listening interfaces
Date: Tue, 23 Apr 2002 17:25:45 -0400
I've had another request for limiting the set of addresses used, and
am planning to implement that in the future. Regardless, the
multi-homed KDC support should be fixed if it's not working.
>How-To-Repeat:
Set up a KDC with two interfaces, and watch the packets
(KRB_AS_REQ/KRB_AS_REP) in flight.
You didn't say what you're seeing. Packets with the wrong addresses,
or packets not on the interface you expect?
The KDC code should be sending back responses using the same file
descriptor that it got the request on. So the local address for
sending the response should be the same as the request was sent to.
If that's not happening (the problem described in the MS Knowledge
Base), I'd like some tcpdump, strace and lsof output from you
indicating what file descriptors are being used, what socket addresses
they're bound to, etc.
On some (most? all?) systems with multiple interfaces, the local
routing info may cause the packet to go out an interface that has a
different address assigned. If that's not the right address to use to
reach the destination from the KDC address that was chosen by the
client, I'd argue that that's a system configuration bug.
I don't have a Linux system with multiple physical interfaces on
different networks at the moment, but I may be able to try some tests
using tunnels.
Ken
From: Benson Margulies <bmargulies@yahoo.com>
To: Ken Raeburn <raeburn@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/1093: KDC could use feature to limit listening interfaces
Date: Tue, 23 Apr 2002 17:41:49 -0700 (PDT)
I'm not sure that I'm a representative of a multi-homing problem.
It turns out that Microsoft played a prank on me that led me to believe
that using a single-homed KDC made everything all better. In fact, what
was really happening was the Windows was logging in a user using cached
credentials, while failing to talk to the KDC. When I fixed the
communications problem, the login went back to failing. The KDC issues the
ticket, but Windows fails the login anyway. It doesn't log or audit any
clue to what the problem is.
So, perhaps there's a multi-homing problem. MS certainly seems/seemed to
think so. However, there's some other more basic issue in which following
MS's instructions for setting up a W2K standalone workstation to use an
MIT KDC for authentication don't work. Setting up trust relationships
between an MIT KDC and a Windows AD does work.
In general, the MS Kerberos interface has proved, in my experience, to be
a classic example of providing just enough doc to make it look like it
would be possible to use the thing, but not quite enough to be able to
reliably make it work.
__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
>Unformatted: