Return-Path: Received: from haven.eyrie.org (haven.eyrie.org [166.84.7.159]) by krbdev.mit.edu (Postfix) with ESMTPS id 36FBF752A3 for ; Thu, 24 Dec 2015 01:21:06 -0500 (EST) Received: from lothlorien.eyrie.org (unknown [96.90.234.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 7E64B1183A1 for ; Wed, 23 Dec 2015 22:21:05 -0800 (PST) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id 0F30EB4156B; Wed, 23 Dec 2015 22:21:04 -0800 (PST) From: Russ Allbery To: rt@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #8332] gss_init_sec_context w/host@ fails with anonymous tickets In-Reply-To: (Greg Hudson via's message of "Thu, 24 Dec 2015 00:26:17 -0500 (EST)") Organization: The Eyrie References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Date: Wed, 23 Dec 2015 22:21:03 -0800 Message-ID: <87bn9g74fk.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain RT-Send-Cc: X-RT-Original-Encoding: iso-8859-1 Content-Length: 1762 "Greg Hudson via RT" writes: > This is a known problem, although I don't seem to have created a ticket > for it. It's a pretty serious impediment to using anonymous tickets, > which is unfortunate. For the record, anonymous tickets are pretty awesome, and I'm already using the new anonymous support in remctl to great effect to solve a system keytab bootstrapping problem I've been worrying at for years. Everything seems to work fine as long as one stays within the same realm and specifies the server to authenticate to using the Kerberos principal syntax. The limitation isn't too bad for me and is pretty easy to work around. > An outline of the solution is at > http://k5wiki.kerberos.org/wiki/Projects/StartRealmCCconfig, but we > haven't implemented it yet. Ah, yes, now the problem makes lots of sense. > A possible workaround for local-realm use is to configure a > [domain_realm] on the client so that it doesn't try to use the referral > realm for host-based service names. Oh, that explains why I didn't encounter this problem in my dev environment. Unfortunately, the environment I'm working in has no DNS domain structure that maps to Kerberos realms, so I literally have separate TXT records for each of a very large number of machines to map them to the appropriate realms. [domain_realm] doesn't work very well for that. :/ (I'd love some way to put wildcard matches into [domain_realm] rather than just domains; I can potentially fix the domain structure, but that's a rather invasive change.) Apparently you need an actual [domain_realm] section; DNS TXT records and enabling DNS domain-realm lookups isn't sufficient? -- Russ Allbery (eagle@eyrie.org)