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.

 

 

 

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

Scenario

Currently HQ is a single point of failure, this is the only site within the network to host Domain Controllers. These are responsible for authentication to Office 365, external applications that are served via Azure AD, and all of the Users and Computers within the company. This has been highlighted twice in the past few months, during which time HQ experience an internet outage, and a separate incident where the ASM VPN went down.

During these times, users are unable to authenticate with cloud apps, including Outlook, Onedrive and Sharepoint. Users in the remote offices also connect back across Site to Site VPNs for authentication to file shares and applications. The network grounded to an halt.

Current Setup

From the diagram below, the red line indicates the way end points connect back to HQ to authenticate. As you can see from the image, all traffic heads back to HQ from both Azure VPN environments. ADFS servers currently site in ASM and are dependent on the ASM VPN tunnel remaining up.

The network sits in a Hub/Spoke topology where all traffic between remote sites will traverse through the HQ. MPLS and ultimately ExpressRoute was deemed too expensive.

To Note: The Azure portal also uses ADFS for authentication so could lose our login ability to Azure aswell.

Find when VM was created in Azure Resource Manager

Recently I was asked how to confirm when a particular ARM Virtual machine was created. I thought this would be a relatively easy thing to accomplish. However searching through powershell I could not find any Datecreated on either the VM or the VHD.

in the end I resorted to going into the Windows VM (this will not work on Linux). And checking the location: C:\Windows\panther\

In here you should find a number of files but the ones we are interested in are: WaSetup.log and WaSetup.xml – The dates modified of these files will be from during the provisioning of the Image / VHD.

This was the closest I could find to given a true Date and time.

 

Migrate from Azure Classic to Azure RM

For reference in the below post:

Azure Service Manager = ASM

Azure Resource Manager = ARM

My current client have over 75 VMs that sit within Azure Service Manager (Azure Classic). The majority of these production VMs do not warrant a project to spin up new VMs and move across the services.

After some investigation into possible ways to migrate a VM from ASM > ARM. I found MigAz (https://github.com/Azure/migAz) – This tool can migrate from Classic to ARM, ARM to ARM and currently being developed work with AWS.

This free to use tool will export scripts to JSON files and a powershell scripts to migrate your selected VM from one environment to the next. It also works across Subscription so if your like my current client and each environment is separated by subscription this tool can be very useful.

The tool is self explanatory, the only thing that I would point out is I was caught out when moving ARM > ARM that the managed disks by default only have a 60 minute token. So when copying large amounts of data (I copied around 600gb and it was taking about 6-7 hours).

You will need to go into the options of the program and increase the metric for: Managed Disk Access SAS Duration.

I’ve now used this tool to migrate around 40% of the VM’s, of all different sizes and I could not recommend this tool enough.

Azure Classic Portal (ASM Portal) to be decommisioned

Microsoft have announced that the Azure Classic portal (https://manage.windowsazure.com/) Will be retired starting the 8th of Janurary 2018. Therefore you will need to use the new ARM portal (https://portal.azure.com) for future administration.

The full story can be found here: https://azure.microsoft.com/en-us/updates/azure-portal-updates-for-classic-portal-users/

I would expect this will be the beginning of pushing companies away from the old environment and moving them to the new Azure Resource Manager instead.

 

Azure 70-533 Exam Experience

On Saturday I passed the 70-533 – Implementing Microsoft Azure Infrastructure Solutions.

The exam itself I found challenging but no where near as difficult as I had primed for. I have been working with Azure on and off for around 2 years now and thought it was about time I stamped my Linkedin page with the 70-533 exam. For clarification and refinement, i used Videos on udemy followed by a ton of reading on the Microsoft pages.

But my main stress came from before the exam with the At home proctored exam that Pearson Vue are now offering. It started fine with me needing to look directly at the webcam, then provide my driving license as identification. Then comes the room sweep. You have to move your webcam slowly around the room so that the agent can see what is in the room. I was using my Laptop, but was forced to unplug screens (that were not connected to anything the other end). Have my phone in the room but not in arms reach. Move Credit Cards and other paperwork that I had deliberatly stored underneeth my printer behind my screens, out of arms reach. And put that on the floor.

The doors had to be closed, and I had to keep my face in view at all times of the exam. Problem being, my Dell XPS 13 web cam sits in the bottom left of the screen. The screen has to be tilted back massively for me to fit in the screen (poor design on Dells part). In all. The experience took me about 25 minutes of constantly going over areas to prove that it was clear and that no one else was in the room. I wish I had braved the Christmas Shopper rush to my nearest Test Center which is in the heart of my nearest city right next to the shopping center.

WSUS Tidy – Powershell

I normally set the below script on a weekly schedule. If you haven’t run this for a long period of time. It may crash out, but you’ll find that the cleanups are going through and eventually it will complete.
The stats write to a log file.

#Variables
$DateFormat = Get-Date -format yyyymmdd
$Logfile = "C:\Source\wsuslogs\$Dateformat.log"

# WSUS Cleanup
Invoke-WsusServerCleanup -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates | Out-File $Logfile

Find Stale AD Computers

Active directory can often be neglected and orphaned computer objects can get out of control. The below script will query your domain (remember to provide your FQDN in the variable at the top) for computers that have not spoken on the domain for 90 days.

By default, Active directory looks to change computer object passwords every 30 days. If you have a large mobile workforce that may not be connecting into the network for a long period of time, you may way to extend this. I find that 90 days works well for us.

NOTE: Be careful when using this on environments that have clusters. SQL Clusters for example, have a AD joined computer object for the name of the cluster. This does not update its lastlogonstamp and therefore gets caught by this script.

import-module activedirectory  
$domain = "domain.local"  
$DaysInactive = 90  
$time = (Get-Date).Adddays(-($DaysInactive)) 
  
# Get all AD computers with lastLogonTimestamp less than our time 
Get-ADComputer -Filter {LastLogonTimeStamp -lt $time} -Properties LastLogonTimeStamp | 
  
# Output hostname and lastLogonTimestamp into CSV 
select-object Name,@{Name="Stamp"; Expression={[DateTime]::FromFileTime($_.lastLogonTimestamp)}} | export-csv c:\source\OLD_Computer.csv -notypeinformation

 

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}