Quick question… For some reason, unless you use KSETUP /addkdc REALMNAME (or place the associated registry key in the Windows OS), windows clients won’t try to look up KDCs for non MS realms. Once this key is added to the clients, it appears to work fine. But without defining it, Windows makes no attempt to lookup KDCs for other realms. Note: I’m not actually specifying any KDCs in the /addKDC option. Quite literally just creating the entry lets Windows know that the realm exists and it needs to do something. Is this expected behavior? Why doesn’t it just follow the trust that’s created in the AD Domain? -Mike Sent from Mail for Windows 10
Non MS-based Kerberos Ralm Lookup?
- 360 Views
- Last Post 23 August 2017
I'd have to look back at the RFC's for the exact, but I wouldn't expect clients of any kind to follow a trust to a non-Windows based KDC. The reason is that the RFC strict version doesn't really understand trusts in that way. KDC realms are something that Microsoft enhanced beyond the RFC to enable the trusts and the behavior you're talking about. I haven't checked before, but the behavior you're mentioning sounds like the client is told to look for non-Windows realms if it has that key. That's a client behavior and I don't recall if that's RFC or not.
What scenario are you trying that you want a non-Windows realm to be trusted?
In general, the Kerberos KDC locator process is client-based. The client must know how to find the KDCs for a given Kerberos realm. For purely Microsoft/Windows
KDCs & clients, this is done via the DC locator process. The DC locator process primarily depends on SRV records. Non-Microsoft/Windows KDCs have not adopted this Microsoft/proprietary locator mechanism. So to be cross-platform compliant which does not rely
on this Microsoft-centric one, another mechanism was needed for Windows clients.
Most non-Microsoft Kerberos clients have a configuration file for this purpose. That wasn’t what was chosen for Windows clients—likely because the thinking at
the time of Windows 2000 was to get away from configuration files and move those settings into the registry.
The primary folks using the cross-platform Kerberos back in the Windows 2000 days were the higher education sector. At the time, we found lots of bugs, design
seams, developed our own set of best practices, and lists of required bug fixes across the two sets of platforms. In the summer of 2000, we had a nice conference in Redmond where we had an extended chat with John Brezak, who at the time was the feature PM
for Kerberos. Then a few years later, my understanding is that MIT’s Kerberos team was contracted to help rewrite the relevant Microsoft code (but that could have just been rumor). The quality certainly improved after Windows Server 2003. The authoritative
Microsoft document on this topic is still the one written for Windows 2000. Interest in the feature waned around 2004, and the best practice lists I’m aware of essentially died. Anyhow, there are significantly fewer folks in the higher education sector using
cross-platform Kerberos. This is mostly because of the design issue around NTLM. With NTLM waning, maybe this feature will have a resurgence, but I doubt it. I stopped supporting it here at the UW 4-5 years ago, mostly because it is 10x more complicated to
figure out when things go wrong. I could say more on that topic, but this is becoming long, so I’ll stop.