Simple Automated Active Directory Deployments (Part 1)
A project detailing fast and simple AD server deployment in the cloud.
Active Directory is the backbone of the corporate world. With around 95% of the market share, the next company you enter is very likely to be using it (usually in combination with Azure) to manage their user and computer directories across the board. It’s also one of those things that get built once if you’re not the person that has done it then it might be a bit of a mystery as to how it all works.
As a contractor engaging a client, developing a product that communicates with their system, the fact that everyone uses Active Directory has its positives and negatives. There’s a lot of documentation out there, and a lot of software packages come with AD integrations out of the box. With that said, the sanctity of the directory is paramount, and a decent IT administration team is not going to let a contractor or platform engineer just have the keys to the castle and let you run rampant through their director trees.
As an IT administration team, you might be looking at changing that one tick box in your Azure Active Directory Connect settings from ADFS to ADDS. Still, you don’t want to accidentally destroy your server and leave your corporate network without a head.
So, time to spin up your AD server and test it out there first.
The goal of this series is to bring about a standard of installation for a process that can be frustrating to users not proficient in installing MS Active Directory and Federation Services. I’ll pull together a few useful links, hints, tips and code to bring about a standard, usable and secure code for installations of what should be standard code.
The massive assumption I’ll be making is that in the current climate, the average developer is going to be rolling out an instance of a server on the cloud (any cloud, they’re equivalent enough to not matter much). If you’re using a physical box, then the Powershell commands are the same but your mileage may vary on the rest of the information here.
1. Buy a Domain Name
Before you do anything else if you do not have one, purchase a domain name. <myname>.com or <adserver>.net — something cheap and easy to use. Most cloud providers provide a service for this, for example, Route53 in AWS or Google Domains in GCP.
You need to do this first because when you’re creating an AD server, you’ll need to specify your directory domain name. This is used when you’re syncing your Azure and your Federated Services, as well as certificates for LDAPS and whatever else you might be connecting to.
If you do not do set up a domain name now, it gets annoying to change later, so better to do things right the first time.
2. Create an Instance
The first thing you’ll want to do is create an instance of a base windows server. Whichever cloud you’re using (Windows 2012R2, 2016, 2019 are all fine):
From there, you’ll want to Remote Desktop Connect (RDP) into the instance.
3. Active Directory Initial Setup
Once you’re in, run Powershell (as an Administrator), and you can start entering code. I’m going to try and keep it all in Powershell, that way you won’t click the wrong button and screw it up, and things will remain consistent.
From now on, any code blocks you see, copy-paste it into Powershell. Edit the bold to make it match the domain name that you just purchased:
#For your domain "example.com", you'll want to split it up and enter the details below:$domain = “example”
$domainName = $domain + “.com”
$federationName = "fs."+$domainName# Now you have a nice domain, a domain name, and a federation name for your federation server.# Save these details to C:\ - we’re going to restart a few times${c:\Domain.txt} = $domain
${c:\DomainName.txt} = $domainName
${c:\Fed.txt} = $federationName
Pretty straight forward so far. We’re just going to save these details to C:\ for now, as we’re going to restart a few times, and it’s basically as a throwaway instance. You can clean it up later if you need to.
4. AD Installation
From there, you can start installing AD:
# Install Initial ADDS setup
Install-Windowsfeature -Name AD-Domain-Services -IncludeManagementTool# Admin Password Generation
[Reflection.Assembly]::LoadWithPartialName("System.Web")
$Password = [system.web.security.membership]::GeneratePassword(30,8)
$Password = ConvertTo-SecureString $Password -AsPlainText -Force# Create the AD forest
Install-ADDSForest -DomainName $domainName -SafeModeAdministratorPassword $Password -DomainMode "7" -DomainNetbiosName $DomainNetbiosName -ForestMode "7" -InstallDns -CreateDnsDelegation:$false -Force
You can check out Install-ADDSForest and Install-Windowsfeature for more details about what they do.
That’s it for a basic AD; it should now be installing. Once it is done, you’ll need to restart before you can make any more progress.
5. Federation Services, Certification Authorities and Network Policies
Once restarted the server certificate should have changed, so you might need to flush your certificates to log back in (on Mac). Once you’ve logged back in, run Powershell again (as Administrator) and pop in this code:
#Install the Network Policy Server (for VPN/RADIUS requirements)
Install-WindowsFeature NPAS -IncludeManagementTools#Install IIS (your Internet Management System)
Install-WindowsFeature -name Web-Server -IncludeManagementTools# Install the Certificate Manager
Import-Module ServerManager
Add-WindowsFeature Adcs-Cert-Authority
Install-AdcsCertificationAuthority -CAType StandaloneRootCa -Force:$true#Install the ADFS and Initial ADFS Farm
Install-WindowsFeature -IncludeManagementTools -Name ADFS-Federation
6. Federation Server Setup
This will install the foundations for ADFS, CA, and the NPS. While this is nice and good, there is still a final bit of setup to go:
# Retrieve the federation name
$federationName = ${c:\Fed.txt}# Generate another password for a new FS certificate
[Reflection.Assembly]::LoadWithPartialName("System.Web")
$Password = [system.web.security.membership]::GeneratePassword(30,8)
${c:\Cert_Pass.txt} = $Password
$Password = ConvertTo-SecureString $Password -AsPlainText -Force# Create & Export Self Signed Certificate (for ADFS)
$Certname = $federationName
$YearsToExpire = 1
$Cert = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname $Certname -NotAfter (Get-Date).AddYears($YearsToExpire)
$thumbprint = $Cert.Thumbprint
Export-PfxCertificate -cert cert:\localMachine\my\$thumbprint -FilePath C:\${Certname}.pfx -Password $Password#Create a Federation Service Admin Password
$Password = [system.web.security.membership]::GeneratePassword(30,8)
$Password = ConvertTo-SecureString $Password -AsPlainText -Force#Create Federation Service Admin Account
New-ADUser -Name "FedServer Admin" -GivenName "Fedserver" -Surname "Admin" -SamAccountName "fsadmin" -AccountPassword $Password -Enabled $true
Add-ADGroupMember -Identity "Domain Admins" -Members fsadmin$fullname = ${c:\Domain.txt}+"\fsadmin"
$fscred = New-Object System.Management.Automation.PSCredential ($fullname, $Password)#Configure the AD Federation Services
Install-AdfsFarm -CertificateThumbprint $thumbprint -FederationServiceName $federationName -ServiceAccountCredential $fscred -Credential $fscred -OverwriteConfiguration
There’s a lot that happened there. We create a self-signed certificate, a federated admin user (so we don’t have to modify the original administrator account / hardcode passwords), and a federated server farm. That’s it; everything is ready to go, you just have to link your federation service relying trusts to your other systems, create user accounts and groups, and a thousand other little things to make your installation yours.
With that all done, you might notice it’s not automated, just a lot of copy and paste. I’ll address automation in Part 2.
In future articles, I’ll demonstrate how to connect it up to Azure, link the FS server to AWS logins, how to Terraform it, and other networking issues around VPNs and RADIUS accounts.
