Connecting the Dots: Domain Controller and Mixed-OS Networking

The goal was simple: one login that works everywhere. I log into my Windows desktop as user@example.internal, and that same identity should authenticate me on Linux servers, shared storage, and the Proxmox box I am starting to build.

The implementation was not simple. But it works now, and here's how.

Why a Domain Controller at All?

For a two-person operation, this looks like overkill. But we already have multiple machines, old servers, a workstation doing development work, and a larger Proxmox server plan turning into real hardware. Managing users per-machine doesn't scale past three boxes, and it scales to exactly zero when you want to revoke access across everything at once.

Active Directory handles this — the boring, battle-tested answer to centralized identity. And because it speaks standard protocols (LDAP, Kerberos, DNS), Linux machines can authenticate against it without joining the Windows world culturally.

The Server Box Starts Becoming Real

The GPU prices are still too high. That is the frustrating part. I can see the shape of the AI server I want, but seeing it and paying for it are two different things.

So I decided to start building the box anyway.

The CPU shows up as 32 x AMD Ryzen 9 9950X 16-Core Processor threads: cutting edge, fast enough to make the machine useful even before the GPU side is finished, and a good foundation for a Proxmox host. I paired it with 256GB of RAM because virtualization eats memory quickly, and I do not want every VM decision to turn into a memory-rationing exercise.

The motherboard choice was about the future. I picked one that can run two RTX 5090s at x16 rates. That does not mean two 5090s are in the budget yet. They are not. The prices are still too high. But when the GPU situation finally makes sense, I do not want the rest of the server to be the bottleneck.

For now, this gives me a real Proxmox server to work with: CPU, RAM, storage, networking, and the identity pieces that make the whole lab feel like one environment instead of a pile of machines.

The DC: Windows Server for the Lab

I set up Windows Server 2022 for the lab environment. The eventual home for this kind of service is virtualization, but the important part at this stage was getting identity and DNS working cleanly. The VM got 4 vCPUs, 8 GB RAM, and a 60 GB disk. Promoted it to a domain controller via Server Manager → "Add roles and features" → Active Directory Domain Services. The wizard creates the forest — I named it example.internal.

DNS is the critical piece. When you promote a server to DC, it installs DNS Server automatically. This DNS zone (example.internal) becomes the source of truth for every machine name on the network. I set the DC's IP as the primary DNS on every machine: Windows, Linux, and the new Proxmox host, either via DHCP or static config.

For external resolution, the DC forwards to 1.1.1.1 and 8.8.8.8. Internal names resolve locally; everything else goes upstream. Standard.

Joining Windows Machines

This part is easy. On each Windows dev machine: Settings → rename this PC (advanced) → change → Domain → enter example.internal → enter domain administrator credentials → reboot. The machine is now domain-joined. Users log in as DOMAIN\user instead of a local account.

File shares, printer management, Group Policy — it all becomes available. For now I'm mostly using it for identity and DNS, but the foundation is there.

Joining Linux Machines: SSSD

This is where it gets interesting. Linux doesn't "join" Active Directory the way Windows does — it authenticates against it. The tool for this is sssd (System Security Services Daemon), configured to talk LDAP and Kerberos to the DC.

I used realmd to do the heavy lifting, because it generates most of the SSSD config for you:

# Install prerequisites
sudo apt install realmd sssd sssd-tools adcli krb5-user \
  packagekit samba-common-bin oddjob oddjob-mkhomedir

# Discover the domain
realm discover example.internal

# Join
sudo realm join --user=<domain-user> example.internal

If that succeeds, sssd is configured and running. But I had to make a few manual tweaks to the config for things to feel right:

# /etc/sssd/sssd.conf
[domain/example.internal]
use_fully_qualified_names = False
fallback_homedir = /home/%u
default_shell = /bin/bash
krb5_store_password_if_offline = True

The use_fully_qualified_names = False line matters — without it, fully qualified logins are noisy and can break scripts that expect short local-style usernames.

Permissions on the config file are strict, because SSSD refuses to start otherwise:

sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl restart sssd

Now the same domain identity resolves on Linux servers, and SSH works with domain credentials instead of separate per-machine accounts.

The Kerberos Trap

The one error that ate an hour: KDC reply did not match expectations while getting initial credentials. Classic. The cause was DNS — the Linux box couldn't resolve the DC's Kerberos service record. The fix is making sure the DC is the DNS server and that the SRV records are present:

# Should return the DC's hostname
dig _ldap._tcp.example.internal SRV

If that comes back empty, DNS isn't set up correctly on the DC side. Once I pointed everything at the DC for DNS and confirmed the SRV records, Kerberos auth worked cleanly.

Network Shares

For shared storage between Windows and Linux, I set up a Samba share on one of the Linux VMs, joined to the domain so it authenticates via AD. Windows machines map it as a network drive; Linux machines mount it via cifs with sec=krb5:

//<fileserver>/<share>  /mnt/<mountpoint>  cifs  sec=krb5,uid=<local-uid>,gid=<local-gid>  0  0

No stored passwords in the article, no public share names, no real account names. Authentication flows through Kerberos. Clean.

What We Got

After all this:

• One identity across the machines I administer.
• Centralized DNS. Every machine name resolves.
• SSH to Linux boxes with domain credentials — no per-machine key management for humans.
• Shared file storage with consistent permissions.
• A foundation for adding new users or machines without touching each one.

Was it worth the Kerberos errors? Yes. Centralized identity is infrastructure you stop thinking about once it works, and that's the highest compliment I can give any system.

The next problem: models. We need to run inference experiments, and I'd rather not pay per-token forever. That means GPUs eventually, and in the short term it means seeing what the workstation can teach us.