This post documents my first Proxmox VE host installation, configuration and the building of a Windows Domain Controller VM within my new home lab environment.

Pre-install configuration

As bought, my Lenovo M72e Tiny i3-3220T machines came with the virtualisation extensions disabled and the boot priority set to prefer BIOS over UEFI - I toggled both of these settings, enabling the virtualisation extensions and setting the boot priority to “UEFI First”.

Installing Proxmox

The Proxmox installation is quite straightforward:

  1. Agree to the EULA
  2. Installed to the only hard disk
  3. Type “United Kingdom” into the “Country”
  4. Set the password (I generated something random) and email address (for now, I set it to admin@lab.some.domain.tld where some.domain.tld is my actual domain - currently there is no mail router but that might come soon)
  5. Set networking hostname/IP/Gateway/DNS Server (setting Gateway to the default 192.168.100.1 address for now - there isn’t one yet, and DNS Server to 192.168.100.201 which will be setup later when I setup the Windows Domain Controller)
  6. I left “Automatically reboot after successful installation” ticked so I could move my monitor and keyboard to the next machine while it installed

Configuring Proxmox

Once installed, I made these changes to enable access to the isos and use the local software mirror which I setup previously:

  • At ‘Datacenter’ level, in storage, add the isos NFS share from NAS
  • To point repositories to local mirror:
    • In the UI (host, updates, repositories) add pve-no-subscription source
    • Manually edit /etc/apt/sources.list, /etc/apt/sources.list.d/ceph.list to point to the mirrors on the NAS
    • In the UI disable pve-enterprise source

I then created a PVE cluster - in Cluster (under Datacenter) click Create Cluster - I called it pve and left the rest as defaults.

Ceph has to be installed manually as the Proxmox tools always rewrite the apt source for Ceph back to the original (their repository URL), even if there’s a local mirror. To do this, run apt-get install ceph (you can access a console through Proxmox’s web interface or login to the machine’s terminal) before launching the Ceph install tool. Once Ceph is installed, go to Ceph in the UI (under Datacenter) and click ‘Configure Ceph’. Once complete, I could create a CephFS - in the host, choose ‘Ceph’, ‘CephFS’. Create a “Metadata Server” and then “Create CephFS”.

Creating the VM (Windows Domain Controller)

Created a VM (to be domain controller), from Windows Server 2019 trial ISO, and called it W2k19-DC1. I installed the “Desktop Experience” in order to have access to the graphical management tools (as this is to be the only Windows system on the network).

Once installed, I went into “Add roles and features” and selected both “Active Directory Domain Services” and “DNS Server” from the list. The Wizard alerted to the fact that the system does not have a static IP address configured but since the DHCP server (on the switch) is configured to give this machine the same IP each time, I ignored this warning. Windows had also set itself up with a nonsensical hostname so I changed that to be W2k19-DC1 too (which required a reboot to apply).

On reboot, and reloading “Server Manager” from the Start Menu, I went into “AD DS” anc clicked on the “More…” next to “Configuration required for Active Directory Domain Services at W2K19-DC1”. In the dialogue that opened, I clicked “Promote this server to a domain controller” under “Action”.

That opened the “Active Directory Domain Services Configuration Wizard” and I choose “Add a new forest” under “Select the deployment operation” (as this is the first domain controller being setup). In the “Root domain name” I specified a new subdomain called ad below my lab environment’s domain (e.g. ad.lab.some.domain.tld where lab.some.domain.tld is the lab’s domain).

In the “Domain Controller Options” I set the functional level down to “Windows Server 2012 R2” (from “Windows Server 2016”) and left “Domain Name System (DNS) server” and “Global Catalog (GC)” ticked. I set a randomly generated password for the “Directory Services Restore Mode (DSRM) password. On the next options page I left “Create DNS delegation” unticked (the domain controller will be authoritative for the AD domain).

The NetBIOS domain name I left as “AD” and the paths as their defaults before clicking through to the end of the wizard.

Assign the sticky IP

In order to ensure the domain controller receives the same IP address I found the MAC (on the switch this can be found from the binding for the IP it had been dynamically assigned) and added a static binding on the switch using the same process as I documented when setting up the switch. I assigned it 192.168.100.201.

Once the static binding was created, I cleared the dynamic binding so that it picked up the new binding next time it requested a DHCP address (N.B. this is done in enable mode, not configure):

Switch#clear ip dhcp binding 192.168.100.6

Post reboot Domain configuration

Once the Domain Controller had rebooted, I checked DNS was working by revolving the domain controller’s name at the domain controller with dig from a Linux box on the same network.

For the time being, I modified the DHCP configuration on the switch to hand out the new domain controller as DNS server and the lab’s domain name via DHCP. Once in configure mode (and don’t forget to copy to the start-up config once setup):

Switch(config)#ip dhcp pool default-pool
Switch(dhcp-config)#domain-name lab.some.domain.tld
Switch(dhcp-config)#dns-server 192.168.100.201

Testing authentication

After forcing a DHCP renewal on a Debian Linux system in the lab network, I installed krb5-user (apt-get install krb5-user) and then tested authentication using what used to be the local Administrator account that was automatically migrated to the Active Directory when the feature was added to the server:

kinit Administrator@AD.LAB.SOME.DOMAIN.TLD

I was able to do a kerberos authentication and get a ticket, so superficially everything is working.

Adding some users

Finally, I added some users and groups to the Active Directory to experiment with. In “Server Manager” I selected “AD DS” then right-clicked my domain controller and choose “Active Directory Users and Computers” from the menu.

In the “Active Directory Users and Computers” view I started by right-clicking on the domain and selecting “New” -> “Organizational Unit” to create an OU to hold them - I called it “Lab-Testing”. Within that OU, I created two sub OUs “Users” and “Groups”. For now I just created 5 dummy users called “User1” through “User5” with predictable passwords (since this will always be air-gapped, I am more concerned with ease of playing with the different accounts than security) by right-clicking the new “Users” OU in “Lab-Testing” and selecting “New” -> “User”. I deselected “User must change password at next logon” in the new user wizard.

I again tested authentication as these users using kinit from a Linux system within the lab environment.