Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos

[Osipov, Michael]

> On Mar 15, 2017, at 8:15 AM, Osipov, Michael <michael.osipov at siemens.com>
> wrote:
> >
> > Hi folks,
> >
> > we are experiencing a problem with an insufficient Kerberos setup on
> Active Directory
> > side which can be solved on Windows-side with Kerberos Forest Search
> Order [1].
> > What Windows basically does is to traverse a list of Kerberos realms to
> obtain a
> > service ticket for a specific SPN where a forest (realm) feels
> responsible for.
> >
> > Let me go in detail with a realworld example:
> >
> > Two forests (realms): AD001.COMPANY.NET and COMPANY.NET whereas the
> latter has 20
> > subrealms, e.g., OLD4.COMPANY.NET.
> > Client account: michael-o at OLD4.COMPANY.NET
> > Target server is hostabc.ad001.company.net, but also has the A record
> > app.workspace.company.com, and of course the SPN
> HTTP/app.workspace.company.com.
> >
> > Now both forest are set to be responsible for DNS namespace company.com.
> > So when michael-o at OLD4.COMPANY.NET issues a TGS-REQ to OLD4.COMPANY.NET
> for
> > HTTP/app.workspace.company.com it receives "Server not found in Kerberos
> database"
> > which makes sense here. Using a client principal from AD001.COMPANY.NET
> works
> > flawlessly. So KFSO would traverse AD001.COMPANY.NET too for the
> OLD1.COMPANY.NET
> > client principal on Windows with SSPI.
> >
> > MIT Kerberos isn't capable to make use of such a logic because there is
> none. What
> > I have done is to define "app.workspace.company.com = AD001.COMPANY.NET"
> in the
> > [domain_realm], but I don't like this because to do this for every
> single target I
> > want to access and on every single server we have in our server room.
> >
> > Is there a better way to solve this issue?
> >
> 
> The documentation (https://web.mit.edu/kerberos/krb5-
> latest/doc/admin/realm_config.html) suggests two possibilities for this
> issue, if I'm understanding your problem correctly:
> 
> * Add "_kerberos.<FQDN>" DNS records mapping a given system to its
> corresponding realm.  It's a bit painful, but I've had success with it,
> provided you have "dns_lookup_realm" set to true (yes, it's technically
> insecure, but is probably acceptable in most environments).
> * The host-based service referrals mechanism also seems promising, and
> you're certainly running a new enough version of Kerberos to accommodate
> it.  I have not personally used it (yet), but it maintains security
> whereas the DNS lookup mechanism does not.

Both aren't an option:

1. TXT records are unknown to Windows are all host to realm maping is
performed by the domain controller by querying the global catalog
2. This applies only if your KDC is MIT Kerberos. All of our KDCs
are Active Directory servers. We use MIT Kerberos for only for clients.

Michael