Welcome to part 2 of my NUC cluster; in the first part, I explained how to deploy a cluster using proxmox and walked through the hardware setup and the rest of the connectors. In this part, we'll dive into building your own Active Directory Lab environment and show you how to quickly deploy testing ranges when playing with Windows enterprise environments.

This post was written in collaboration with Chris P(Ghostie/BSky), who was kind enough to update the blog post with some of his recent steps to set up a Proxmox/Ludus lab.

Setting up Ludus

For those who may not have heard of Ludus, Ludus is a powerful lab automation tool that can deploy complex environments like Active Directory labs, penetration testing environments, and more with minimal effort. Setting up Ludus on Proxmox in the instructions by default involves creating a virtual machine, installing Ludus, and configuring it to deploy and manage your lab environments.

However, deploying Ludus directly on the Proxmox host works just as well. There’s an easy one-liner to install Ludus on the host but be warned: installing Ludus this way will effectively take over the host, so make sure it's what you want to do.

As for minimum requirements per the Ludus site, you'll need the following:

• x86_64 (aka amd64 aka 64-bit "Intel") CPU with a Passmark score > 6,000
• Debian 12 or Proxmox 8 (If Proxmox, see this page for details)
• Supports virtualization - vmx or svm in /proc/cpuinfo (nested virtualization is supported but has a performance penalty)
• Has at least 32 GB of RAM - the more the better, in all of my cases I've got 64GB of RAM.
• Has at least 200 GB of disk space (fast NVMe recommended) - again the more the better, I have 1TB of most of my rigs now(changed from default in my last post due to moving resources around hosts and repurposing NUCs).
• Root access - if you deploy it yourself, you'll have this already.
• Internet access (not via WiFi). Note: Bonded NICs or other advanced networking is not supported. If you use these, you will need to console in and fix the network after installation (edit /etc/network/interfaces), as Ludus assumes you have a single, standard interface.
  • In the case of networking, if you are rolling with the cluster described in part 1 you'll need to manually configure your interfaces, I'm not going to go through that in this post as it varies based on hardware as I found out.

If you decide to proceed, creating a dedicated user for Ludus is best, followed by running the one-liner:

curl -s https://ludus.cloud/install | bash

The install.sh the script will install the ludus client, optionally shell completions, and then prompt to install the server. Follow the interactive installer. If you are unsure of any option, just accept the default value. The installer will start and reboot the machine.

Once you select yes, the installer will auto-detect settings like so:

Each setting you hit return on will build the server settings config, and you will see it populate on the right-hand side:

Once you have gone through and built your config, Ludus will finally ask you if you are sure you want to install it with ready?

The installer then kicks off a lot of Ansible that automagically installs the Ludus client and server to the host:

After the reboot, the installation will continue automatically. To monitor its progress, ssh into the machine, elevate to root, and run ludus-install-status.

Ludus will not allow you to perform any actions without creating a standard Ludus user. Make a note of the LUDUS_API_KEY:

When you run the install status command, the screen above indicates the installation succeeded. The next step is to create a Ludus user to delegate the installation and prevent you from using the root account. The site suggests setting the API key in line with the command, but I found exporting it as an environmental variable to work better:

 export LUDUS_API_KEY='YOURKEYHERE'

Creating an admin user is as simple as the following command: Note that it may take up to a minute to generate, but once it is, you'll be presented with a new API key for your user.

ludus user add --name "Zephr Fish" --userid zero --admin --url https://127.0.0.1:8081

Note this API key is somewhere safe, as it will be used for all things Ludus. I opted to set this within my .bashrc/.zshrc so that it was constantly set:

Also because I'm lazy I saved the root one in there too for easy access so that I can comment one out and use the other for various commands.

Many Proxmox guides recommend running any commands from the PVE shell, not SSH. I've never had a problem using SSH, but many guides can't be wrong, right?

Another thing I suggest is adjust the default packer templates. I don't need the OS disks to be 250g, so I amended the the .prk.hcl file for each OS. They can be found in /opt/ludus/packer/"OS Name"/.

Once you have your key noted you can grab your credentials for proxmox for the newly created user with ludus user creds get

The next step in the chain is you'll want to build and add templates for the different lab environments you want to setup; this can be achieved with the templates command:

ludus templates list

The default list is shown below but if you want more you can clone them from (https://gitlab.com/badsectorlabs/ludus).

+------------------------------------+-------+
|              TEMPLATE              | BUILT |
+------------------------------------+-------+
| debian-11-x64-server-template      | FALSE |
| debian-12-x64-server-template      | FALSE |
| kali-x64-desktop-template          | FALSE |
| win11-22h2-x64-enterprise-template | FALSE |
| win2022-server-x64-template        | FALSE |
+------------------------------------+-------+

If you go down the route of adding more, it is as simple as:

git clone https://gitlab.com/badsectorlabs/ludus
cd ludus/templates
ludus templates add -d <template name>

Or, if you just want to add them all, you can use this for loop:

for x in $(ls); do ludus templates add -d $x; done

Before deploying, a few prereqs are worth considering for your templates(Fix needed below at the time of writing Dec 2024). In my case, I had to comment out the provisioner section of /opt/ludus/packer/kali/kali.pkr.hcl due to the bug referenced in the Ludus documentation (https://docs.ludus.cloud/docs/troubleshooting/kali):

build {
  sources = ["source.proxmox-iso.kali"]

//  provisioner "ansible" {
//    user               = "${var.ssh_username}"
//    use_proxy          = false
//    extra_arguments    = ["--extra-vars", "{ansible_python_interpreter: /usr/bin/python3, ansible_password: ${var.ssh_password}, ansible_sudo_pass: ${var.ssh_password}}"]
//    playbook_file      = "./kali.yml"
//    ansible_env_vars   = ["ANSIBLE_HOME=${var.ansible_home}", "ANSIBLE_LOCAL_TEMP=${var.ansible_home}/tmp", "ANSIBLE_PERSISTENT_CONTROL_PATH_DIR=${var.ansible_home}/pc", "ANSIBLE_SSH_CONTROL_PATH_DIR=${var.ansible_home}/cp"]
//    skip_version_check = true
//  }

}

What this does is prevents ansible from trying to configure the kali host, what this does is gives us a baseline kali image and means that it will be fresh out the box when configuring new VMs based off of the template.

Once you opt to build the templates, Ludus will go away in the background and do this for you:

You can watch the progress either via the logs using the ludus templates logs -f command"

Or via your ProxMox UI:

It'll first create a VM and then configure it before converting it to a template.

The deployment log will look similar to the above. Note that the red line is where I had to manually enter the console to tweak some things with one of my templates.

If it fails just rerun it, it took me several attempts to build the templates as kali kept failing on me for a mirad of reasons.

Once all the templates are built, you'll get a message in the logs similar to this:

Deploying SCCM Lab on Ludus

After setting up Ludus on my Proxmox host, I wanted to deploy a few lab environments, including:

• SCCM (System Center Configuration Manager)
• Basic Active Directory environment
• Active Directory Certificate Services (AD CS)

For example, here’s a step-by-step guide on deploying SCCM using Ludus and what I did next to optimise my setup.

Step 1: Deploying SCCM with Ludus

To deploy SCCM, I followed these steps:

1. Create a New Lab: From the Proxmox CLI, making sure you've exported your user API key, run this cmd "ludus ansible collection add synzack.ludus_sccm"
2. Configure the Lab: Create a new config.yml "nano config.yml", paste the example config from https://docs.ludus.cloud/docs/environment-guides/sccm If you have more resources available to assign in terms of CPU and RAM, then up those settings. Save the config.
3. Set that config file to be the template for the range "ludus range config set -f config.yml"
4. Deploy the Lab: Deploy the range with "ludus range deploy"
5. Check the logs Check the logs for errors "ludus range logs" or "ludus range logs -f"
6. Wait.....Depending on your specs, this could take a while(so best to leave it doing its thing and trust it). If one host fails to build, I found running the range deploy again fixed the issue without needing to change anything. Your mileage may vary.
7. If it fails If your hardware is slightly older, failure to complete is common. If so, amend the timeouts in the folder "/opt/ludus/ansible/range-management/tasks/windows". I found sysprep.yml took a long time and in some cases, 60 seconds might not be enough. Up the values and build again.

Once complete, if you run ludus range status you'll see an output with Deployment Status as SUCCESS hopefully! If you get errors, you can run ludus range errors and it'll print out what it failed on. My suggestion would be to Google the errors, as sometimes they're simple things like the image not playing nicely, or other times ansible timeouts have failed, and it skips a step.

Additionally, for the SCCM lab specifically, you can log on to the "sccm-sitesrv" server, and launch the Configuration Manager to double-check everything works as expected. All going well, your ProxMox should look similar to the list below:

Post install I went in and tagged all the resources tied to the specific labs which gives the green dot in the screenshot above, click on the pencil and give the tags a name, this is more for quality of life than anything.

Best Next Steps for Setting Up Ludus

With SCCM running, here’s what I did next to make the most out of Ludus:

1. Explore More Labs: Ludus offers more than just SCCM; I explored other labs like GOAD for Active Directory simulations to expand my learning.
2. Automate Tasks: I have looked into using scripts in Ludus to automate repetitive tasks, like resetting labs or making quick changes across multiple VMs. I've also been exploring writing custom config files for ludus to deploy.
3. Monitor Resources: Keeping an eye on CPU, memory, and disk usage in Proxmox helped me balance the load and keep everything running smoothly.
4. Back Up Configurations: I set up regular backups of Ludus configurations and lab states to ensure I can recover quickly if something goes wrong.
5. Keep Everything Updated: I regularly checked for updates to both Ludus and Proxmox to make sure I had the latest features and security patches.
   By following these steps, I was able to set up a functional SCCM lab and optimise Ludus for my needs. It’s a great tool for building and managing lab environments, and I recommend giving it a try if you’re setting up similar labs.

Finally, Part 3 is up next

For my third part of this series, I'm going to dive into building an automated media stack using Docker and how to connect it all up initially, I was going to use proxmox for this but have since re-architected my cluster; I only have 3 NUCs connected in a lab configuration with Ludus on all three and a fourth used for media consumption and automation.