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?


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.

  • 1
    Note: Realm to KDC mapping can be configured with group policy. (Req: DC functional level >=Server2008; Client >=Vista or >=Server2008) – 84104 Nov 5 '12 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.