[30444] in Kerberos
Re: kinit ignores kdc in config file on Mac 10.5
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Thu Nov 13 14:04:43 2008
From: Ken Raeburn <raeburn@mit.edu>
To: petesea@bigfoot.com
In-Reply-To: <alpine.OSX.1.10.0811130908140.11904@zippy-air>
Message-Id: <650C0D48-1337-4259-8AC5-F74FC53717CF@mit.edu>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 13 Nov 2008 14:04:01 -0500
Cc: Kerberos mailing list <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Nov 13, 2008, at 12:47, petesea@bigfoot.com wrote:
> Yes... A, not SRV. Oddly, the exact case of the realm it queries is
> mixed, eg: COMPANY.com, instead of COMPANY.COM. The config file only
> uses all uppercase for the realm name and all lowercase for the domain
> name in the [domain_realm] section, it never uses mixed case.
It's possible this is just an artifact of the local forwarding
resolver code. E.g., if it builds a tree with "com" below the root
(because someone looked up something.com in lower case), and then
someone looks up COMPANY.COM, it could add a node "COMPANY" below
"com", and use those strings in building the query...
As to why it would try to contact a host matching the name of the
realm, I don't know. Our basic library code shouldn't do that, but
Apple ships a couple of KDC-locating plugins in /System/Library/
KerberosPlugins/KerberosFrameworkPlugins which I haven't looked at.
Our library code does allow plugins to override the config file;
perhaps one of them is doing so. Is the Mac joined to a domain?
If not, one of the plugins might be triggering anyways. I'm not sure
if it's safe to move them to another directory or "chmod 0" them, to
try to see what's going on. But doing it only briefly while you've
got a command-line window open with a root shell would -- I would
*guess* -- not be too risky.
> - A query for an A record for the realm name by the client
> - A response from the DNS server with 4 IP addresses
> - An "AS-REQ" from the client to the 1st IP address
[...]
Curious, that's not quite the behavior I'd expect.
It shouldn't stop talking to the 3rd address after the first attempt,
unless it got back a TCP RST, UDP response, or ICMP error, and decided
it couldn't use that server. And the delays between the passes (7s,
then 5s) should start smaller than that, and increase. (See around
line 1160 in http://src.mit.edu/opengrok/xref/trunk/src/lib/krb5/os/sendto_kdc.c
, that describes the library behavior, and what you'll see for UDP
traffic; TCP connections are initiated in the first pass, but
retransmissions would be managed by the OS kernel.)
But that's probably not important right now...
Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
