Use Active Directory for testing environments in DevOps shops
AD enables admins to create testing environments almost identical to production environments through duplicated trees, interconnected forests and authentication best practices.
Should IT organizations use Active Directory to test and stage labs?
Active Directory, sometimes abbreviated AD, is a ubiquitous service from Microsoft upon which many organizations rely for authentication, authorization and single sign-on capabilities. In addition to interactive user logins, Active Directory provides authentication for applications, services and computers. Traditionally, while organizations rely heavily on Active Directory, it has been relegated to systems administrators and IT operations teams.
DevOps is all about software development and delivery. Even if your organization doesn't develop applications on top of Active Directory, you aren't exempt from its necessity.
Active Directory and DevOps
One way or another, most -- if not all -- software applications make use of Active Directory. How do users authenticate to an application? What mechanism authenticates users when they access test environments? One major goal in DevOps is the ability to provision environments that look, act and feel like production.
One of the most visible Active Directory uses in DevOps involves provisioning test environments. To thoroughly vet how a live application will behave, QA teams need to test environments that are as similar to production as possible. Production not only means the VMs the application will run on, but also all of the various infrastructure dependencies, such as network, domain name system (DNS) and -- you guessed it -- Active Directory.
Build Active Directory in test environments
To build an environment that mirrors production as closely as possible, deploy an AD forest that is separate from production. To create an AD forest from scratch can appear daunting, but once the processes are in place, the build can take mere minutes. This is similar to a lab environment, and community projects such as PowerLab, AutomatedLab and Lability offer demonstrations.
The process is the same, regardless of the chosen tool and how the admin invokes the operation: Deploy a virtual machine or container, install Active Directory and a DNS server, then populate Active Directory with various objects like user accounts and computers -- though this final step is optional depending on the build requirements.
Consider AD design
As with production AD environments, determine the desired hierarchical design of Active Directory for testing. Active Directory is typically referred to as just a domain, but it can include multiple domains under a single forest. Additionally, trust can be established across different AD forests, which links them together.
To use Active Directory for testing, you can provision an entirely new AD forest for each test environment. This practice ensures complete separation from production. But when services deployed in those test environments are added to their respective AD domain, they require different user accounts -- and if there are dozens of test environments spread out across different teams, suddenly you have an accounts management nightmare.
Technically, to add additional objects -- such as the trust relationship between test and production AD forests -- does change the production environment, but that change is minimal.
For the one AD forest per environment approach, add trust creation as part of the deployment process. When a new forest deploys, establish a forest trust relationship between each test environment's forest and production's forest. This setup enables users to authenticate to every test environment with their production username and password -- and it eliminates the headache of multiple sets of accounts.
Technically, to add additional objects -- such as the trust relationship between test and production AD forests -- does change the production environment, but that change is minimal. And to run Active Directory for testing this way significantly reduces the burden of remembering a passel of passwords across environments.
Automate the full AD lifecycle
If appropriately automated, a new test environment can spin up with a single keystroke. Most of the work comes during deployment. It always feels most essential to create new environments as they're needed, but ongoing management and decommissioning are afterthoughts. Resist that urge!
It becomes altogether too easy to deploy dozens or even hundreds of AD forests with automation. Without careful management, admins can make changes in these AD forests during testing that cause them to diverge from production -- eventually, the environments become so different that testing results suffer. Monitoring and remediation are essential to maintain AD forests. Admins can also use configuration management tools to extend and enforce a single baseline configuration across all AD forests.
Be sure to automate the decommissioning process for each completed test environment. This includes any changes -- however small -- made in the production Active Directory forest for testing, as well as any DNS forwarders and the forest trust for membership. Track and maintain all these changes throughout the entire test environment's life to ensure that administrators eliminate unnecessary elements and dependencies upon its dissolution.
It's not a strict requirement to be an Active Directory expert, but it is vital for DevOps teams to know enough about Active Directory for testing to compose a deployment and management strategy that mimics production as closely as possible. Place AD on the list of infrastructure dependencies to automate in your organization's next build and release pipeline.
Dig Deeper on Systems automation and orchestration
