Can a Windows machine authenticate against Samba with Kerberos when users are stored in AD?

I understand the title is probably less clear that it should be, but I couldn't think of anything better.

We have two domains, let's call them example.com and subnet.example.com. The former is managed by an Active Directory server, and houses some servers as well as all the Windows clients. The latter houses a number of Unix machines (mostly Solaris). There is a one-way trust from the realm SUBNET.EXAMPLE.COM to EXAMPLE.COM.

With this setup, the usual stuff works fine, like ssh login, NFSv4, etc.

Now, what I want to be able to do is to run Samba servers on the Unix machines in subnet.example.com. Windows users should be able to access the files on these servers.

I set up Kerberos authentication in Samba, and it works perfectly from any Linux client. I can access the machines via smbclient when I have a Kerberos TGT, and it stops working if I drop it. User mapping works exactly as expected. The machines have cifs/hostname entries in the MIT Kerberos server.

However, Windows clients are unable to do the same. When looking at the Samba logs I can see that the Samba server attempts to talk to the AD server, but is not allowed to do this since the Samba server has not joined the AD domain.

So, I hear you ask: "Why don't you just join the AD domain?". The answer is that I'm not able to do that since the systems on the subnet are test systems that are being installed and reinstalled, often many times per day, and we do not wish to have an AD admin configuring this (and removing them as well) every time a test system is installed or taken offline.

Besides, everything works perfectly for the Linux clients, which leads me to believe that it should be possible to get this to work somehow.

So, my question is: Is this even possible? Is there some limitation in Windows that prevents them from being clients in a normal Kerberos realm? If so, what would be the best workaround for this problem?

Solution 1:

I solved the problem. The issue was that the Windows client did not know that subnet.example.com belongs to a different realm. The solution is to inform the client of this. It can be done with the following two commands that, I believe, i similar to adding domain information in krb5.conf on a Unix system:

ksetup /addkdc SUBNET.EXAMPLE.COM hostname.of.kerberos.server
ksetup /addhosttorealmmap .subnet.example.com SUBNET.EXAMPLE.COM

After I did this, client authentication worked as expected.