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

[Sean Elble]

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.

> FWIW: We are running MIT Kerberos 1.13.x/1.15.x on FreeBSD, HP-UX and RHEL6.
> Wirshark pcaps are available privately.
> 
> Best regards,
> 
> Michael
> 
> [1] https://technet.microsoft.com/de-de/library/configure-kerberos-forest-search-order-kfso(v=ws.10).aspx
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>