[38649] in Kerberos
Re: Kerberos / krb5.conf / CentOS7
daemon@ATHENA.MIT.EDU (Todd Grayson)
Wed Dec 11 22:44:15 2019
MIME-Version: 1.0
In-Reply-To: <CALNT6MWDqbXMh4-GpQSumx99GR4Zh2aoQeFNx=5FKTSLf_+UoA@mail.gmail.com>
From: Todd Grayson <tgrayson@cloudera.com>
Date: Wed, 11 Dec 2019 20:43:01 -0700
Message-ID: <CALNT6MXvfJ1VhXa70i4vVD8jZMNhX9nGpJauwB4obFtvRPsn0g@mail.gmail.com>
To: kerberos@gemneye.org
Cc: "kerberos@MIT.EDU" <kerberos@mit.edu>
Content-Type: multipart/mixed; boundary="===============8831890893639421339=="
Errors-To: kerberos-bounces@mit.edu
--===============8831890893639421339==
Content-Type: multipart/related; boundary="00000000000069a0510599798ba1"
--00000000000069a0510599798ba1
Content-Type: text/plain; charset="UTF-8"
oops mistyped on the CAPATH example, it SHOULD read:
(e.g. REALM A trusts REALM B, and REALM C trusts REALM B, but REALM A and
REALM C do not trust each other)
On Wed, Dec 11, 2019 at 7:16 PM Todd Grayson <tgrayson@cloudera.com> wrote:
> Cross realm trust would involve setting up specific krbtgt principals that
> represent the trusting realm and trusted realm, having proper realm entries
> present as well as proper domain_realm declarations in place. We cover the
> cross realm trust concept and command line steps between MIT realms as well
> as between and AD realm and MIT realm in our product documentation (google
> "kerberos cross realm trust cloudera" to find it) For AD to AD realm
> trust, the domains & trusts management tool is used to configure this via a
> GUI.
>
> If you have indirect trust scenarios (e.g. REALM A trusts REALM B, and
> REALM C trusts REALM B, but A and B do not trust each other) you will need
> to read up on using CAPATH maps as well.
>
> Glad to help.
>
> On Wed, Dec 11, 2019 at 7:05 PM GemNEye <kerberos@gemneye.org> wrote:
>
>> On 2019-12-11 18:52, Todd Grayson wrote:
>>
>> The domain_realm section of the krb5.conf is used to map DNS domain names
>> to kerberos realms. So lets say you had an active directory domain (dns
>> domain and AD domain) of ad.example.com, its kerberos realm would be
>> AD.EXAMPLE.COM, but lets say your environment had linux servers in
>> dev.example.com, but you still wanted them to be recognized as systems
>> that are have services that have kerberos principals in the
>> AD.EXAMPLE.COM kerberos realm. You would use the [domain_realms]
>> section of the krb5.conf to map this dns domain to the kerberos realm with
>> the entry
>>
>> [domain_realm]
>> dev.example.com = AD.EXAMPLE.COM
>>
>> The need for this kind of configuration comes up in hadoop as the
>> kerberos principals for the linux hosts will need to understand what realm
>> and KDC they need to resolve to, as the default behavior of kerberos to
>> resolve the lowercase dns name to the uppercase REALM name, but in the
>> scenario where dns names are host.dev.example.com, and there is no
>> kerberos realm of DEV.EXAMPLE.COM, for java applications things will
>> fail with a GSS error of "host not found in the kerberos database" type of
>> message, unless there is a [domain_realm] mapping like above in place.
>>
>> This is NOT cross realm trust when you use this kind of [domain_realm]
>> mapping, that is a completely different thing and would involve multiple
>> kerberos realms trusting each other for authenticating users and services
>> (just in case you were going to ask).
>>
>>
>> --
>> Todd Grayson
>> Principal Customer Operations Engineer
>> Security SME
>>
>> Yep, that is exactly what I was going to ask. Our current config has
>> entries for other AD DNS domains being mapped to the realm that is
>> configured in the [realms] stanza. I was trying to figure out why that was
>> being done and what purpose it was serving. I was not able to get an
>> answer from my co-workers which is why I posted here. From your
>> description is sounds like this configuration is probably erroneous.
>>
>> Thank you for your response.
>>
>
>
> --
> Todd Grayson
> Principal Customer Operations Engineer
> Security SME
>
>
--
Todd Grayson
Principal Customer Operations Engineer
Security SME
--00000000000069a0510599798ba1
Content-Type: image/gif; name="blocked.gif"
Content-Disposition: inline; filename="blocked.gif"
Content-Transfer-Encoding: base64
Content-ID: <16ef7de11f4527484c21>
X-Attachment-Id: 16ef7de11f4527484c21
R0lGODlhZAAyAIAAAPrOzgAAACH5BAAAAAAALAAAAABkADIAAAJNhI+py+0Po5y02ouz3rz7D4bi
SJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qt9yu9wsOi8fksvls
KwAAOw==
--00000000000069a0510599798ba1--
--===============8831890893639421339==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============8831890893639421339==--
