On Mar 15, 2017, at 8:15 AM, Osipov, Michael <michael.osi...@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: michae...@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 michae...@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@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
