[37834] in Kerberos
Re: Cross-realm Trust Principals with LDAP
daemon@ATHENA.MIT.EDU (Kemper, Stephan)
Sun Jan 22 19:11:17 2017
From: "Kemper, Stephan" <stephan.kemper@viasat.com>
To: "kerberos@mit.edu" <kerberos@mit.edu>
Date: Mon, 23 Jan 2017 00:11:01 +0000
Message-ID: <A4F23F18-7B17-4A63-BEA3-473725A0B88F@viasat.com>
In-Reply-To: <73ACB86D-A40F-49F5-98CE-CB961063D3D3@viasat.com>
Content-Language: en-US
Content-ID: <E1D0286712470D458D0EF1A82A44B214@viasat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Sorry for the spam, but after continuing to investigate, it looks like this database shortcut only works for vertical trusts. A krbtgt/A.VIASAT.IO@B.VIASAT.IO principal only shows up in the realm it’s created in. That definitely pushes me toward the “unintended/bug” end of the spectrum, because otherwise the interface wouldn’t be uniform.
Stephan Kemper
ViaSat, Inc.
On 1/22/17, 12:42 PM, "Kemper, Stephan" <stephan.kemper@viasat.com> wrote:
Hello again!
Based on my previous question (“Cross-Realm Admins” from last month) we’re now using a model with separate admin principals per realm, and a large keyring of keytab files. This seems to be working *mostly* fine.
Where we run into issues is with creating the cross-realm trusts, specifically one-way trusts with a sub-realm trusting our master realm. When our automation tries to create the trust, it often fails with the following log messages:
KerberosService - Running [kadmin, -r, A.VIASAT.IO, -p, api/admin@A.VIASAT.IO, -kt, /path/to/keytab-A.VIASAT.IO, -q, add_principal -pw **random stuff** krbtgt/A.VIASAT.IO@VIASAT.IO]
WARNING: no policy specified for krbtgt/A.VIASAT.IO@VIASAT.IO; defaulting to no policy
Authenticating as principal api/admin@A.VIASAT.IO with keytab /path/to/keytab-A.VIASAT.IO.
Principal "krbtgt/A.VIASAT.IO@VIASAT.IO" created.
KerberosService - Running [kadmin, -r, VIASAT.IO, -p, api/admin@VIASAT.IO, -kt, /path/to/keytab-VIASAT.IO, -q, add_principal -pw **the same random stuff** krbtgt/A.VIASAT.IO@VIASAT.IO]
WARNING: no policy specified for krbtgt/A.VIASAT.IO@VIASAT.IO; defaulting to no policy
add_principal: Principal or policy already exists while creating "krbtgt/A.VIASAT.IO@VIASAT.IO".
Authenticating as principal api/admin@VIASAT.IO with keytab /path/to/keytab-VIASAT.IO.
The principals do not exist before this point, I am 100% certain. In our system, all realms are backed by the same LDAP database, under the container cn=Kerberos,dc=viasat,dc=io. So we have separate krbRealmContainer objects cn=VIASAT.IO, cn=A.VIASAT.IO, and so on. What’s happening, based on my manual duplication of these steps, is that the A.VIASAT.IO version of the principal is somehow “spilling over” into VIASAT.IO. After diving into the code, it appears this behavior is intentional: is_principal_in_realm() in ldap_misc.c explicitly allows these cross-realm TGS principals, no matter which krbRealmContainer they’re in.
So I have two questions: first, is this behavior truly expected, or is there some kind of bug here? It seems like a nice shortcut, but I want to make sure either way before we start depending on it in production. Second, if it is expected, it’d be really nice for this feature to be documented. Is it OK if I send in a pull request on GitHub, or some other patch for the docs to reflect this?
Thanks,
Stephan Kemper
ViaSat, Inc.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
