Part 2: Using Azure to remove to HQ dependency for AD

Part 1: The Sceanario

Part 2: The Azure Solution

Part 3: Virtual Networks (coming soon)

Proposed Solution

After sitting down and scoping the needs and requirements.  The below is the design that is now being built. In following posts I will discuss how to create those changes and why we used the options that we did.

In comparison to the initial image, you can see that we have moved key services (ADFS and ADFS Proxies (WAP) away from Azure Classic and into Azure Resource Manager. These are not rebuilds but instead we used MigAz to move the boxes from the old environment to ARM with minimal downtime.

A new subnet within our production vNet will host the Domain Controllers and the ADFS servers, the ADFS servers will sit behind a internal load balancer. WAP boxes will sit within the DMZ behind a External Load Balancer.

Both vNets are protected via Network Security Groups (NSG) and the VM’s themselves will also have individual NSG’s assigned to the network cards. This will limit the attack vector should someone breach another machine within the same Subnet.

vNet peering is enabled between the Azure Service Manager environment and Resource Manager. This keeps the traffic within the Azure data plane and means that we are not relaying through the HQ.

S2S VPN tunnels will be created from remote sites directly to Azure. Using Site costs within Active Directory Sites and Services, we will be able to force the majority of the traffic back to HQ, using Azure as the fall back for authentication traffic.

DNS servers currently point to HQ. This will remain the same, however tertiary and quaternary DNS servers will be added to DHCP scopes and statically assigned servers, meaning they will round robin between all 4.

 

 

 

Active Directory Sites – Powershell Site Links

My current client has asked me to look at tidying up their Active Directory, they have 3 environments that all should look identical but as with everything, time permits and changes can skip a environment.

Due to their sector, sites are constantly opening and closing, at any one time they can have over 70 sites. The previous fix to this was to push all the subnets into a single AD replication site and this connect back to the head office (where their domain controllers sit). After having Microsoft in for the day to go over a number of things, Microsoft advised that all sites should be separated as per best practice terms..

Our SCCM boundaries are also based off these Sites, so removing them is not a option.

I spoke to the networks team and got a list of all the subnets and their corresponding sites and started to build each site/subnet/AD site link. It wasn’t long before I wanted to pull my hair out! So i scrapped the manual creation and put together the script below. I have also included the part where I can pull out the information to a CSV that I can then take to the next environment and run to build. This way, i build the environment once in a offline area. and the import across the other environments.

# Run this on server to pull out records - then remove all quotations from CSV
# Get-ADReplicationSiteLink -filter * | Select Name | export-csv C:\source\ADsites.csv -notypeinformation

$Sites = get-content C:\source\Input\ADsites.csv
Foreach ($Site in $Sites) {
New-ADReplicationSite -Name $site -Description "Imported via Script"
}
$sitelinks = Get-ADReplicationSite -filter * 
ForEach ($sitelink in $sitelinks) {
New-ADReplicationSiteLink -Name $sitelink.Name -SitesIncluded $sitelink,10-Eaton-Court -Cost 100 -ReplicationFrequencyInMinutes 30 -InterSiteTransportProtocol IP
}

# Run this on server to pull out all Subnets and sites - then clean down CN= information either side of the site name
# Be careful of subnets specfic to Dev/UAT environment
# Get-ADReplicationSubnet -filter * | Select Name, Site | export-csv C:\source\ADSubnets.csv -notypeinformation

Import-csv C:\Source\Input\ADSubnets.csv | ForEach-Object{New-ADReplicationSubnet -Site $_.Site -Name $_.Subnet}