[19921] in Kerberos_V5_Development
Re: Logic behind lib/krb5/os/k5_sendto()
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Apr 19 10:35:42 2019
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=
<dilyan.palauzov@aegee.org>,
<krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <0fc4a599-f612-63fd-e378-19c5e4528a74@mit.edu>
Date: Fri, 19 Apr 2019 10:35:17 -0400
MIME-Version: 1.0
In-Reply-To: <a65b5a2715f9cfcd6d1a715227cc6df0015bbac9.camel@aegee.org>
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On 4/19/19 4:49 AM, Дилян Палаузов wrote:
> thank for your answers. On Monday I asked, if k5_sendto receives an answer from a KDC, that the realm is non-local,
> does it retry to the other KDCs, here asking the same process over a different transport protocol.
Your question was about a specific function in the client code and you
didn't specify the KDC implementation. I took "the realm is non-local"
to mean that the KDC had some knowledge of the correct realm as a
foreign realm. Sorry for the miscommunication.
In the scenario where the client uses the wrong realm case (so the realm
lookup succeeds in DNS due to case-insensitivity there), with all MIT
krb5 components, a typical result is the following:
$ kinit ghudson@athena.mit.edu
kinit: Client 'ghudson@athena.mit.edu' not found in Kerberos database
while getting initial credentials
Here the KDC issues a KDC_ERR_C_PRINCIPAL_UNKNOWN error (because it
looks up ghudson@athena.mit.edu in its database and does not find it)
and the client does not retry.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
