1

I am currently in the process of extending my development environment, which used to only run Linux servers so far, by adding machines running Windows Server 2016. The authentication process is handled by MIT Kerberos. For the new Windows machines, I am planning on using Active Directory. Since I don't want to manage users in two systems, I am setting up a cross-realm trust between the Windows AD and the already existing MIT Kerberos installation.

To do that, I have followed this guide: https://bluedata.zendesk.com/hc/en-us/articles/115007484067-How-To-Establish-Cross-Realm-Trust-from-MIT-KDC-to-AD.

Now, I have noticed that I can obtain a ticket from the Windows AD for a User from the AD on a linux machine just fine: Running kinit Administrator@AD.DOMAIN.LOCAL completes without any errors and gives me a ticket as expected.

On the other hand, I cannot login to any of the Windows machines using an account from the MIT Kerberos setup. Trying to log in using my test account (test@DOMAIN.LOCAL from the MIT realm DOMAIN.LOCAL) throws the following error:

"The security database on the server does not have a computer account for this workstation trust relationship".

Another thing I am noticing is that when I try to verify the trust relationship using the command netdom trust DOMAIN.LOCAL /Domain:AD.DOMAIN.LOCAL /Kerberos /verbose /verify, I am getting the following error message:

"Unable to contact the domain DOMAIN.LOCAL. The command failed to complete successfully."

Seems like the Windows AD is unable to communicate with the MIT Kerberos installation, which seems weird though, because it apparently does work the other way around. I have already double-checked that all the DNS records (domain.local, ad.domain.local and the FQDNs for the KDCs) resolve to the correct IP addresses. While researching the problem, I stumbled across this post https://stackoverflow.com/questions/45236577/using-mit-kerberos-as-account-domain-for-windows-ad-domain, which seemed promising at first, but couldn't help me fix my problem. Any help is greatly appreciated!

Alexander Richter
  • 11
  • 3

1 Answers1

1

Fair warning, my knowledge in this area is extremely dated at this point. Like early 2000's, Windows 2003 era Active Directory. So things may work differently now.

The main problem is that Windows doesn't know how to find the KDC for your MIT realm by default (ironically, it won't just use DNS to look it up like it does for AD). There's a utility called ksetup.exe that will let you map a realm name to one or more KDC servers. Ultimately, this utility is just setting some registry values. So you can automate this with Group Policy if necessary.

Update: @grawity mentioned that Windows may actually be able to find the KDCs via DNS as long as the proper SRV records exist and ksetup has been used to at least define the realm.

We also had what were essentially "shadow" accounts in AD that matched the users defined in the MIT realm. The passwords on those accounts didn't matter, they just had to exist. We may have also set some additional attributes like UPN or SPN that were related to the MIT realm in some way. Memory is hazy though.

Another thing to be aware of is the supported encryption types between AD and your MIT realm. If both are pretty recent, you'll probably be fine. But when we were doing this, our MIT realm was old and we had to add Group Policy in AD to add some legacy encryption types that the MIT realm supported.

Hopefully this should get you going in the right direction.

Ryan Bolger
  • 16,472
  • 3
  • 40
  • 59
  • Hey Ryan, thank you for your answer. I already figured out the part with the `ksetup.exe`, it is showing that the MIT realm DOMAIN.LOCAL has one KDC associated with it (FQDN of the KDC, "kdc.domain.local"), that should be all it needs, right? The encryption types should be fine I guess because I am running Kerberos 5 on both ends. I think I'm going to give the shadow accounts a try next! – Alexander Richter Oct 05 '18 at 16:00
  • Hmm, back in Windows XP, if you used `ksetup` to add the realm with some flags but _not_ its KDCs, then Windows _would_ use DNS SRV records to find the correct KDC. – user1686 Oct 05 '18 at 18:20
  • @grawity It's quite possible our MIT realm admins never added the necessary SRV records which is why we ended up needing to add the explicit mappings. – Ryan Bolger Oct 05 '18 at 22:21