This page describes the "Virtual UCC" (VUCC) setup by [FVP] end of 2018 to test changes to the Active Directory system.
Contents
> In a virtually perfect world, our servers will be named after what they do and not after species of fish.
For testing, a subdomain for the "Virtual" AD will be configured as ad.v.ucc.asn.au with NETBIOS domain name VUCC, on a separate virtual network using a virtualised Proxmox VE instance (yes, running VMs inside of VMs). The primary DNS server for domain is vucc0.v.ucc.asn.au, which is also the (virtual) Proxmox VE host. The "primary" DC for domain will also be dc0.v.ucc.asn.au, and a second DC will be dc1.v.ucc.asn.au. Note that whilst RODCs can be configured using Samba, replication makes things just so much cooler (and more prone to inexplicable breakage) so we might be stuck with that for the time being.
v.ucc.asn.au is delegated using separate zones in Mooneye's /etc/bind/named.conf.local.
zone "v.ucc.asn.au" { type forward; forward only; forwarders { 130.95.13.35; // vucc0 (proxmox VM on maltair, running dnsmasq) }; };
dnsmasq on the (virtualised) Proxmox VM host vucc0.ucc.asn.au then delegates the ad.v.ucc.asn.au domain to the domain controller(s).
Domain Controller Configuration
See NewActiveDirectory/DomainControllers
Client configuration
Windows systems
Just join them to the domain. It Just Works (TM) - thanks Microsoft / Red Hat / IBM?!!
TODO: roaming profiles (maybe WindowsProfiles will help?)
Linux systems
See NewActiveDirectory/LinuxClients
Mac OS
TODO; joining to the domain for authentication is pretty simple but the process has not been rigorously tested yet. Google is your friend for now.