Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos
Osipov, Michael
michael.osipov at siemens.com
Wed Mar 15 08:15:11 EDT 2017
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?
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
More information about the Kerberos
mailing list