Overview
GOAD (Game of Active Directory) is an open-source vulnerable Active Directory lab project maintained by Orange Cyberdefense. It gives you a real, multi-domain, multi-forest Active Directory environment with intentional misconfigurations that you can attack the way you would attack a real engagement. The lab is widely used in cybersecurity training because it is free, it is real (the misconfigurations are the kind you find in the wild, not contrived CTF puzzles), and it scales from a 2-VM beginner setup to a 5-VM multi-forest setup that mirrors a mid-size enterprise.
GOAD is shipped as code that drives Vagrant, VirtualBox, and Ansible. The official documentation at orange-cyberdefense.github.io/GOAD is comprehensive and accurate, but it assumes you already know how to use Vagrant. That assumption is the trap: a student who follows the docs literally will hit Vagrant error messages that the docs do not explain, will run `sudo vagrant` to make the errors go away, and will end up with a lab that requires `sudo` for every subsequent command. This walkthrough is the missing piece: the same install, in the same order as the official docs, with the Vagrant friction points called out and the right way to handle them.
What this walkthrough covers: the prerequisites you actually need (and what to do if your hardware is borderline), the install of VirtualBox and Vagrant on a Linux host (which is the most common path), the GOAD-specific Vagrant plugins and what each one does, the clone and the install, the verification step that tells you the install worked, the most common traps with the right fix for each, and the post-install steps (logging in, finding the FQDNs, knowing when to rebuild because the Windows eval expired). The walkthrough assumes GOAD-Light as the primary path because it fits in 20 GB of RAM and is the right starting point for most students; the full GOAD (5 VMs, 2 forests, 3 domains) is covered as a scaling-up note at the end.
How it works
GOAD is a Vagrant-driven lab. Vagrant is a tool from HashiCorp that takes a single configuration file (a Vagrantfile) and uses it to create, configure, and destroy virtual machines across a variety of providers (VirtualBox, VMware, Hyper-V, AWS, Azure, Proxmox, and others). For GOAD on a Linux host, the provider is VirtualBox. The flow is: you install Vagrant and VirtualBox on your host, you clone the GOAD repository, you run a small Python launcher (`goad.sh`) that creates a Python virtual environment, installs the Ansible dependencies, and writes a Vagrantfile into the chosen lab directory, and then Vagrant does the work of downloading the Windows ISO images, creating the VirtualBox VMs, booting them, and running Ansible against them to install Active Directory and seed the intentional misconfigurations.
The components, with the role of each: VirtualBox is the type-2 hypervisor that runs the lab VMs on your host. Vagrant is the orchestration tool that talks to VirtualBox. Ansible is the configuration-management tool that, once the VMs are booted, configures them into the lab (installs the Active Directory role, creates the users and groups, sets up the trusts between domains, configures the misconfigurations). The Python launcher (`goad.sh`) is the wrapper that ties the three together, creates the Python virtual environment, installs the right Ansible version for your Python, and generates the Vagrantfile that Vagrant actually uses. The five Vagrant plugins (`vagrant-reload`, `vagrant-vbguest`, `winrm`, `winrm-fs`, `winrm-elevated`) extend Vagrant with the specific behaviors that GOAD needs: the ability to reboot a Windows VM mid-provisioning, the ability to install VirtualBox Guest Additions, the ability to talk to Windows VMs over WinRM for the Ansible configuration step.
Why this stack is the way it is, and why the friction points exist. The reason Vagrant is involved at all is that GOAD has to deploy Windows VMs (which require a license-activation grace period, a sysprep pass, and a domain-join operation) and then configure Active Directory on top (which requires WinRM, PowerShell remoting, and a domain controller promotion). Doing all of that by hand-clicking through the Windows installer for every VM would take days. Vagrant plus Ansible automates the whole thing; the cost is the steep learning curve of getting Vagrant and Ansible installed and configured correctly. The friction points that this walkthrough is going to focus on are the places where that learning curve bites a newcomer: the sudo trap, the plugin install order, the Python version check, the IP range overlap with the rest of your network, the RAM and disk sizing, and the Windows evaluation license.
In practice
Step 1, hardware. Check that your host can run the lab. The minimums that the GOAD docs call out: GOAD-Light needs about 20 GB of RAM allocated to the VMs (the lab itself uses 3 VMs with 2-6 GB each), and GOAD-Light needs about 60 GB of free disk space for the Vagrant boxes (Windows Server 2019 ISOs are large, ~22 GB each before expansion). The full GOAD needs about 24 GB of RAM and about 115 GB of free disk. If your host is borderline, use GOAD-Light; it is the same vulnerable-by-design lab philosophy, smaller scale, and the same operational workflow. If your host is a laptop with 16 GB of RAM, run GOAD-Light with one VM at a time (you can halt a VM, work on it, halt another, work on that), not all three at once.
Step 2, install VirtualBox. On Debian/Ubuntu: `sudo apt update && sudo apt install -y virtualbox`. On Fedora: `sudo dnf install -y VirtualBox`. On Arch: `sudo pacman -S virtualbox`. The VirtualBox kernel modules have to be loaded on every boot, which is what the package handles for you; do not try to install VirtualBox from the upstream tarball unless you have a specific reason to, because the package integration with the kernel module loading is what you want. Verify with `vboxmanage --version` (or `/usr/lib/virtualbox/vboxmanage --version` on some systems) before continuing.
Step 3, install Vagrant. The Vagrant docs at developer.hashicorp.com/vagrant/install have the install steps for every platform. On Debian/Ubuntu the cleanest path is the upstream HashiCorp apt repo (the distro package is often too old); on Fedora the upstream HashiCorp dnf repo is the same. Verify with `vagrant --version`. The Vagrant version should be 2.3 or newer; older versions do not support all the plugins GOAD uses.
Step 4, install the GOAD Vagrant plugins. This is one of the steps where the official docs are terse and the consequences of getting it wrong are not obvious. The plugins and what each one does: `vagrant-reload` allows Vagrant to reboot a VM mid-provisioning (Windows VMs require several reboots during sysprep and domain join). `vagrant-vbguest` ensures the VirtualBox Guest Additions are at the version that matches VirtualBox (without this, the VMs have display and shared-folder issues). `winrm`, `winrm-fs`, and `winrm-elevated` are the plugins that let Vagrant (and Ansible, via Vagrant) talk to Windows VMs over WinRM for the configuration step. Install them all in one command: `vagrant plugin install vagrant-reload vagrant-vbguest winrm winrm-fs winrm-elevated`. Verify with `vagrant plugin list`; all five should be present.
Step 5, clone the GOAD repository. `git clone https://github.com/Orange-Cyberdefense/GOAD.git && cd GOAD`. The clone is large (the repo includes the VM box images referenced in the Vagrantfile, plus the Ansible playbooks, plus the documentation). The clone takes a few minutes on a typical connection.
Step 6, run the dependency check before installing. `./goad.sh -p virtualbox` enters the GOAD interactive shell. At the prompt, run `check`. The check tells you which mandatory dependencies are missing (red) and which are non-mandatory but recommended (yellow). The mandatory dependencies are: VirtualBox, Vagrant, the five Vagrant plugins, Python 3.8 or newer, the Python venv module, and the ability to run ansible-playbook (which the goad.sh launcher will set up for you in the venv). If the check passes, you are ready to install. If anything is red, fix it before continuing; installing on a host that fails the check leads to install errors that are hard to debug because the failure mode is in the Ansible configuration step rather than in the dependency itself.
Step 7, install. The cleanest path is the all-in-one command: `./goad.sh -t install -p virtualbox -l GOAD-Light -ip 192.168.56`. The `-l` flag chooses the lab (GOAD-Light for this walkthrough; other options are GOAD for the full lab, MINILAB for the 2-VM starter, SCCM for the System Center variant, NHA or DRACARYS for the challenge labs). The `-ip` flag chooses the IP range the lab VMs will use; 192.168.56 is the conventional choice and matches the default that VirtualBox's host-only network uses, which means you do not have to change anything in VirtualBox's network config. The install runs in three phases: the launcher creates the Python venv and installs Ansible, Vagrant downloads the Windows Server VM boxes and creates the VMs in VirtualBox, and Ansible configures each VM in turn (sysprep, domain join, AD configuration, user seeding, misconfiguration seeding). The first phase is fast (a few minutes). The second phase is the longest (download time for the VM boxes plus VM creation time, roughly 30-60 minutes depending on your connection and disk). The third phase is medium (10-30 minutes depending on the lab). The full install for GOAD-Light on a typical host takes 1-2 hours from start to finish.
Step 8, verify. After the install finishes, the launcher prints the lab status. To verify manually: from the GOAD directory, run `./goad.sh -p virtualbox`, then at the prompt run `status`. You should see all three GOAD-Light VMs listed with their IPs and their state (running, powered off, etc.). A clean install has all three VMs in the `running` state. If any VM is in a different state, the install did not complete cleanly; the most common cause is a plugin install order issue or a Python version mismatch. The check command (`check`) at the launcher prompt re-validates dependencies and is the right starting point for any post-install debugging.
Step 9, get into the lab. There are three ways to get into a GOAD VM: VirtualBox GUI (open VirtualBox Manager, double-click the VM, log in with the credentials in the docs), Guacamole (if you set it up at install time, the GOAD launcher can install a Guacamole container that gives you a browser-based RDP gateway), or direct RDP from your host (the VMs are on the host-only network 192.168.56.x, so you can RDP from your host to any VM at the listed IP, using the credentials in the docs). The credentials for the lab are in the GOAD docs for each lab variant; the GOAD-Light docs list the default admin credentials for the two domain controllers and the one member server. Change the passwords only after you have verified the lab is working; changing passwords before verification makes it harder to debug a broken install.
Common mistakes
The sudo trap. The single most common mistake newcomers make is running `sudo vagrant up` because VirtualBox complains about permissions. The right behavior is: VirtualBox needs root to load the kernel modules and to create the host-only network, but once VirtualBox is set up, Vagrant does not need to run as root. The fix is to add your user to the `vboxusers` group (`sudo usermod -aG vboxusers $USER`), log out, log back in, and run Vagrant as your normal user. Running `sudo vagrant` makes the install work, but then every subsequent Vagrant command (`vagrant status`, `vagrant ssh`, `vagrant halt`, `vagrant destroy`) has to be run as root because Vagrant stores its state in the user's home directory and the root-owned state is not visible to your normal user. The result is a lab you cannot operate without `sudo`, which is a security issue (you stop paying attention to what you are running as root because everything is run as root) and an operational issue (you cannot use the GOAD launcher as your normal user because the launcher shells out to Vagrant as your normal user, and the launcher will fail to find Vagrant's state). The fix is the group addition, not the `sudo` prefix.
The plugin install order trap. The five plugins have to be installed together; running `vagrant plugin install vagrant-reload` and then `vagrant plugin install vagrant-vbguest` separately is fine, but the typical newcomer mistake is to install only some of them (because the GOAD docs list all five on one line and the newcomer installs only the first one or two) and then hit a confusing error during the Ansible step. Verify with `vagrant plugin list` and make sure all five are present before continuing.
The Python version trap. GOAD requires Python 3.8 or newer. Python 3.10 is widely available on most distros; Python 3.11 is available but switches the Ansible version (the goad.sh launcher handles this automatically; just be aware that the requirements file changes). The trap is: an older distro with Python 3.6 or 3.7 will install but fail at the Ansible step with a confusing error. Fix is `python3 --version` before installing, and update Python if it is below 3.8. The other Python trap: missing python3-venv. On Debian/Ubuntu, `sudo apt install -y python3-venv python3-pip` is the fix; the goad.sh launcher will tell you it cannot find the venv module if it is missing.
The IP range trap. GOAD asks for an IP range for the lab VMs (the default is 192.168.56). If your host is already on a network that uses 192.168.56.x (which is a common home network default), the lab VMs will conflict with your existing network and the lab will not work correctly. Fix: pick an IP range that is not in use on your host. Safe choices: 192.168.57, 192.168.100, 10.10.10. The first octet does not have to be 192.168; anything RFC1918 works. The IP range is passed as the prefix only (192.168.57, not 192.168.57.0); Vagrant will assign the individual IPs.
The RAM trap. VirtualBox allocates the RAM you specify in the Vagrantfile to the VMs regardless of whether they are running. If your host has 16 GB of RAM and GOAD-Light wants 12 GB across three VMs, the host will start swapping the moment you boot all three. The fix is either to run GOAD-Light with one or two VMs at a time (halt the third while you work on the first two) or to use MINILAB (2 VMs) instead. If the host is 32 GB of RAM or more, GOAD-Light runs all three VMs without trouble.
The Windows evaluation trap. The Windows Server VMs that GOAD uses are evaluation copies (the free, 180-day trial). After 180 days, the VMs start shutting down every hour and eventually refuse to boot. The trap is: a student who builds the lab and does not use it for a few months comes back to a lab that is broken. The fix is to rebuild the lab (destroy and re-up) when the eval expires, which is what the GOAD docs recommend. The trap within the trap: rebuilding the lab takes 30-60 minutes (mostly the Vagrant download and the VM creation), so plan the rebuild for a time when you can spare the hour. The other trap: do not enter a real Windows license key into the GOAD VMs, even if you have one. GOAD is intentionally vulnerable; mixing real licenses with vulnerable VMs is a bad combination.
The networking assumption trap. A newcomer who runs GOAD on a laptop on a coffee-shop Wi-Fi will find that the lab VMs cannot reach each other, because the host-only network that VirtualBox creates for the lab is independent of the host's internet connection. This is by design (the lab is isolated from the rest of your network for safety), but it surprises newcomers who expect the lab VMs to be on the same network as the host. The lab VMs can talk to each other and to the host; they cannot reach the internet or any other network. If you want to give the lab VMs internet access (for example, to install additional tools during a practice session), you can add a second network interface to each VM in the Vagrantfile, but this should be done deliberately and only on a network you trust, because the lab is intentionally vulnerable.
The GOAD launcher shell trap. `./goad.sh -p virtualbox` opens an interactive shell. The trap is: the commands inside the shell (check, install, status, set_lab, set_ip_range) are shell commands in a Python REPL with readline, not bash commands. If you paste a bash command into the launcher, it will fail. The right behavior is to use the launcher's commands (which are documented) for the lab lifecycle, and to use bash commands in a separate terminal for everything else (Vagrant commands, file edits, git operations).
Defensive guidance
After the install, document the lab. The single most useful thing you can do for your future self is to write down the lab's IP addresses, the credentials for each VM, the domains and forests in the lab, and the procedure for rebuilding the lab from scratch. The documentation should live outside the lab (in a git repo on your main machine, or in a private GitHub repo, or in an Obsidian vault synced to the cloud), so that you can rebuild the lab from the documentation when the Windows evaluation expires or when something breaks. The procedure for rebuilding is in the GOAD docs, but copying the procedure into your own words is the part that makes it useful when you actually need it.
After the install, take a snapshot. Once the lab is verified working (`status` shows all VMs running, the credentials work, the domains are visible), take a snapshot of each VM in VirtualBox Manager. The snapshot is your known-good baseline; if something goes wrong during a practice session (you break a VM, you accidentally lock an account, the configuration drifts), you can revert to the snapshot and have a working lab again in minutes. Snapshots take disk space (count on roughly the same as the VM itself), so budget for it.
Treat the lab as a learning environment, not as a production system. The lab is intentionally vulnerable. Do not put real credentials into the lab, do not use the lab as a place to test things that matter, do not connect the lab to a network you care about. The GOAD docs explicitly call this out, and it is worth repeating: the lab is for practicing attack techniques on systems that are designed to be attacked. The defensive skill you build from the lab is the same skill you would build from any other vulnerable-by-design environment (HackTheBox, TryHackMe, VulnHub); the difference is that GOAD is local, free, and reproducible.
Build the muscle memory of the rebuild. The first time you rebuild GOAD, it takes 1-2 hours and you will hit at least one trap. The second time, it takes 1 hour and you will hit fewer traps. The third time, it takes 45 minutes and you will hit none. The rebuild is the most important practice you can do with GOAD, because the rebuild is what you will do every 180 days when the Windows evaluation expires, and the rebuild is the closest you will get to a real incident response scenario in a lab environment. Schedule the rebuilds on your calendar (every 5-6 months is a safe interval) and treat them as a deliberate practice.
Pick the lab size that matches your hardware, not the lab size that matches your ambition. GOAD-Light is the right starting point for most students, and the same vulnerable-by-design philosophy applies. Scaling up to full GOAD is a hardware decision (24 GB of RAM available, 115 GB of disk available) more than a learning decision. The skill you build on GOAD-Light is the same skill you would build on full GOAD; the difference is the breadth of the attack surface, not the depth of the practice. The right operational discipline is to run the lab size that fits comfortably on your hardware, to use the lab regularly, and to rebuild it cleanly when the evaluation expires.
Use the GOAD writeups as a starting point, not as a script. The GOAD creator (Mayfly) publishes detailed writeups of the GOAD attacks on his blog (mayfly277.github.io/categories/goad/). The writeups are a useful starting point for understanding what the lab is teaching, but the right operational discipline is to attempt the attacks yourself before reading the writeups, and to use the writeups as a check on your own thinking rather than as a recipe to follow. The lab is for building the muscle memory of the attack process, not for following a script.
Plan the GOAD install as a deliberate practice, not as a one-time setup. The first install is the hardest; every subsequent install is faster. The cost of the practice is the time to install and rebuild (a few hours per cycle); the benefit is the operational fluency that comes from having done the install several times. A cybersecurity student who has installed and rebuilt GOAD three times has a meaningfully different relationship with the lab than a student who has installed it once.