On pe, 20 maalis 2020, Todd Grayson wrote:
Oh, thank you this is our problem set exactly, we might have a dozen
of
lab.example.com hosts that are REALM1 another dozen lab hosts that are
lab.example.com domain but in REALM2 and trying to get cross realm trust
working between them.
We are using host specific mappings in [domain_realm] to do it. There
are even [CAPATH] scenarios that customers throw us where REALMA has trust
for REALMB and REALMC has trust for REALMB, and users from REALMB must be
trusted by REALMA cluster hosts. Imagine every insane heterogeneous
configuration troubleshooting possible. We setup and simulate issues
across all 3 using the same lab domains and explicit host mappings in
[domain_realm] to keep the kerberos stack straight...
But I have one observation, in your blog you state-
*Since Microsoft Active Directory implementation does not support per-host
Kerberos realm hint, unlike MIT Kerberos or Heimdal, such request from
Windows client will always fail. It will be not possible to obtain a
service ticket in such situation from Windows machines.However, when both
realms trusting each other are MIT Kerberos, their KDCs and clients can be
configured for a selective realm discovery.*
On Windows desktops/hosts that we are doing integration labs over with
mixed KDC implementations, the approach is to use the windows shell command
lines of ksetup /addkdc and ksetup /addhosttorealmmap to smooth things with
cross realm trust configurations ad-hoc between everything. I have not
researched if global policies will do this as well for windows hosts in a
domain... but on a host/desktop specific scenario it works and SPNEGO
authentication from browsers work to cluster web UI's (as does ODBC and
JDBC connections).
Yep. MIT and Heimdal implement discovery through querying DNS TXT records
automatically and allows you to do it per DNS zone or per host. Windows
doesn't have that, so your only method is to do it by creating the
registry configuration for Kerberos SSP, by forcing 'ksetup /addhosttorealmmap'
on each Windows machine.
I think you could use GPO to distribute the mappings since they are stored
in the registry.
What I'm not sure about is whether it is possible to apply the same on
Windows DCs for requests that are coming from the Windows clients so
that you can patch out subsets of AD domain and redirect requests for
services on those machines to IPA KDCs. The ksetup trick is clearly
client-side, only applies to Kerberos SSP on that machine.
https://docs.microsoft.com/en-us/windows-server/administration/windows-co...
https://docs.microsoft.com/en-us/windows-server/administration/windows-co...
What your blog is covering is a good thing to be aware of, I'm going to
share this with team mates and nominate referencing this into the "Kerberos
and Hadoop:The Madness Beyond The Gate" gitdocs we use to convey the
insanity of hadoop and kerberos integration for heterogeneous environments.
Thanks for sharing this!
You are welcome. I'll make sure to add the ksetup reference too.
On Fri, Mar 20, 2020 at 1:23 PM Alexander Bokovoy <abokovoy(a)redhat.com>
wrote:
> On pe, 20 maalis 2020, Todd Grayson via FreeIPA-users wrote:
> >Understood, thanks. Effectively the DNS based lookup of KDC is
> problematic
> >with clusters (delays, etc) in sprawling environments... so static
> mappings
> >are used in our labs... I understand thats counter intuitive from a
> >management/user perspective and we are talking about a severe edge case
> >here. Thanks again for the ongoing feedback.
>
> It is a bit more complex than "disable any DNS resolution",
> unfortunately. You can get a glimpse of the current problem domain in my
> blog post from a year ago:
>
https://vda.li/en/posts/2019/03/24/Kerberos-host-to-realm-translation/
>
> >
> >On Fri, Mar 20, 2020 at 11:27 AM Charles Hedrick <hedrick(a)rutgers.edu>
> >wrote:
> >
> >>
> >>
> >> > On Mar 6, 2020, at 5:31:36 PM, Todd Grayson via FreeIPA-users <
> >> freeipa-users(a)lists.fedorahosted.org> wrote:
> >> >
> >> > Thanks Rob, Thanks Angus,
> >> >
> >> > I am aware of how to point the client to the specific IPA server, what
> >> I'm struggling more with is freeIPA in an environment where its not
> using
> >> DNS for domain and realm resolution for kerberos, which does work today.
> >> > I should have limited my question to the following:
> >> >
> >> > Is it possible to use ipaClient but manage static mappings in the
> >> krb5.conf [realm] and [domain realm] and run with dns_lookup_kdc=false
> and
> >> dns_lookup_realm=false (including the krb5.conf on the ipa server
> itself so
> >> its aware of all). The question from Angus makes me believe that having
> >> the dns_lookup* = false is a unsupported context in an IPA environment.
> >> >
> >> I don’t see why not. We did that for a while. You need to configure
> >> servers in both krb5.conf and sssd.conf. But I’m not sure why you need
> >> this. The SRV records are for finding the server based on the Kerberos
> >> domain. As far as I know it has nothing to do with the hostname of the
> >> client. As long as krb5.conf and sssd.conf have the proper Kerberos
> domain,
> >> the client should be able to look up the servers in that domain.
> >>
> >>
> >> > Thanks for your feedback.
> >> > _______________________________________________
> >> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> >> > To unsubscribe send an email to
> >> freeipa-users-leave(a)lists.fedorahosted.org
> >> > Fedora Code of Conduct:
> >>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> > List Guidelines:
>
https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> > List Archives:
> >>
>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
> >>
> >>
> >
> >--
> >Todd Grayson
> >Principal Customer Operations Engineer
> >Security SME
>
>
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>
>
--
Todd Grayson
Principal Customer Operations Engineer
Security SME
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland