This page describes the "Virtual UCC" (VUCC) setup by [FVP] end of 2018 to test changes to the Active Directory system.

> 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.

Managing the Domain

See NewActiveDirectory/DomainManagement