Auror Project — Challenge 1 (Automated Active Directory Lab Deployment)
Dear reader, before hopping on to the technical aspect, let me introduce you to the Auror Project. Its an initiative by Mr. Sudarshan Pisupati to build a challenge driven Infosec community.
Registration link: https://forms.gle/Nuu3DyskCPbeYLGj6
“3 Machine Labs” is a course under the Auror Project initiative. It comprises of weekly informative sessions followed by challenges designed to cement understanding of the discussed concepts. For this week, to be precise the challenge was to automate the following tasks. More on it here
1. Spin up a Window 2016 server VM (Machine A)
2. Create an Active Directory Domain
3. Promote the server VM to DC
4. Add another server machine to the AD domain (Machine B)
5. Create a domain user
6. Configure the newly created user to be local admin on Machine B
7. Install Chrome on Machine B
Tools of the Trade
My preferred choice of cloud provider is Azure. Additionally, Terraform will be used to scale up the Infrastructure and using Ansible modules we will provision our virtual machines (Windows & Linux hosts) and apply configurational changes.
Before we start building the infra its very important to have a mental model or at least a rough sketch of what our end product should look like. In our case we plan to do it this way
Link to entire source code on GitHub: https://github.com/sbasu7241/Auror-Project-Challenge-1
Terraform in action!
Azure CLI Setup
First and foremost we need to setup the Azure CLI according to docs. Once Azure CLI is installed we need to run az login to connect to our Azure account.
Var.tf
We will define all variables that we intend to use while writing various terraform scripts in this file. We will be adding more variables as we proceed
Provider.tf
We will be using the azurerm provider from hashicorp to configure infrastructure in Microsoft Azure
Network.tf
Next we will cover some network components — virtual networks, subnets etc so that when creating the virtual machines we can properly set their network configuration.
We will create a resource group that will contain all our resources, a virtual network and a subnet.
Next we will create a network security group with proper security rules — allow inbound SSH, HTTP and RDP from whitelisted IP and allow all inbound traffic originating from inside the subnet so that hosts can talk to each other.
Next we will associate our network security group to the created subnet.
Next we will add 2 Public IP addresses
- One for a Load balancer which will provide ssh access to Linux host (we will need to SSH into the jump box and use the same to provision and configure the AD domain and its hosts via Ansible)
- Another, for a NAT gateway that will be used to provide outbound internet access to hosts in the subnet
Our next step will be to create a Load balancer, assign the previously created public IP to it and create load balancer NAT rules.
Finally we will create a NAT gateway, associate it with the previously allocated public IP address as well as with our subnet ensuring outbound Internet connectivity for all hosts in the subnet.
Local.tf
Before provisioning the hosts we will declare some local values intended to be used later while configuring our domain joined hosts.
- FirstLogonCommands.xml consists of command(s) that will run once for the first user that logs into the system in XML format.
- Autologon.xml specifies the account to use to log on to a computer automatically in XML format
Dc.tf
We will first configure the network interface for the domain controller — assign it a static IP.
Next, let’s create the Windows Server machine (DC) and associate the newly created network interface with the same
To conclude, we need a Virtual Machine Extension to perform automated post deployment configuration and run scripts as soon as the VM boots up . In our case we will be running — ConfigureRemotingForAnsible.ps1 i.e. a powershell script that configures WinRM settings on domain joined hosts for Ansible connectivity.
Server1.tf
Similar to the domain controller machine, we will first configure the network interface first and assign it a static IP.
Next we will spin up the machine and attach the newly created network interface to it.
And finally using a Virtual Machine Extension to run ConfigureRemotingForAnsible.ps1 similar to the domain controller machine.
Jumpbox.tf
In case of the jumpbox host we will again go through the regular process — creating a network interface → provisioning the linux virtual machine.
However unlike other hosts we don’t need a virtual machine extension for this host. However in order to be able to SSH into the jumpbox from our whitelisted host through the internet we need to associate the network interface of the jumpbox to the load balancer NAT rule (allow inbound SSH from whitelisted IP)
Ansible.tf
We will create a null_resource that will help us to provision the AD lab from the jumpbox using Ansible. This resource is expected to be triggered i.e. recreated every time the script is run
This resource connects to our jumpbox via ssh and copies ansible script present locally onto the remote host and finally utilizes a remote-exec provisioner to install ansible along with the modules we wish to use and run the ansible playbooks from the jumpbox.
Outputs.tf
This last script contains multiple output values that would display information regarding the newly provisioned infra like —public IP of VM, domain name, admin user and pass etc.
Finally we have everything setup to setup the infra on Azure. We can run the following commands from the project directory to verify the same
terraform init → used to initialize a working directory containing Terraform configuration files
terraform plan → creates an execution plan which lets you preview the addition/changes that Terraform plans to make to your infrastructure
terraform apply → executes the actions proposed in the current Terraform plan
This will create the resources as specified in the code on Azure.
Ansible FTW!
Now that we have our server machines and the other Linux host up and running, we will use Ansible to configure the windows hosts and perform configurational changes via WinRM.
ansible.cfg
Let’s specify the Ansible configuration settings
inventory.yml
This file contains a list/group of hosts present in your infra. Since the challenge requires static IP’s we will hardcode those in our inventory file.
group_vars\windows.yml
We will define some group variables in this file so that we can apply them to multiple hosts at once.
roles\domain\tasks\main.yml
We will define a domain role and define a list of its tasks using this file. It will be used to set DNS config on the DC → install Active Directory and reboot so that the necessary changes can take place
roles\dc\tasks\main.yml
We will define a dc role and define a list of its tasks using this file. This will be used to create a domain user acc. to the challenge
roles\server1\tasks\main.yml
We will define a server1 role and define a list of its tasks using this file. First we will configure its DNS and point preferred DNS server to IP address of the DC , then we will add the machine to the aurora.local domain. After a reboot, according to the challenge we will disable domain firewall → add the previously created Adam user to local admin group on this machine and finally install Google Chrome.
Ansible playbook — ad-cloudlab.yml
Finally we will create our ansible playbook that will orchestrate all of these tasks onto their respective hosts in a defined order.
Result
After adding the Ansible scripts, we can run terraform apply again to put them into effect. So finally, we have successfully setup our Active Directory environment compromising of a domain controller and a domain joined server.
After you are done with the lab we can destroy everything that we did using terraform by simply running,
terraform destroy
PS: This is my first attempt at infra automation and I would highly appreciate any correction/suggestions, please feel free to reach out to me. And finally thank you very much for taking your time to read this post hope you enjoyed it 😊
