Everything You Need to Know About Azure Infrastructure – November 2020 Edition

Published: Dec 01, 2020

SHARE ARTICLE

It’s not even 4:30PM as I write this and it’s dark outside my office. Winter has come. The night is dark and full of … Azure VM and SAP HANA backup news … ok, it’s full of terrors.

Azure Bastion & VNet Peering

If you have virtual machines running in The Cloud, then you need to be able to log into them over a network connection via RDP or SSH. Those who are new to network security, The Cloud, or just don’t care about security, will likely just connect directly to those machines across the Internet, possibly without any firewall. Various innovations have appeared to secure SSH and RDP access to Azure virtual machines but some of us settled on the use of a Remote Desktop Gateway (RDGW) to “air gap” or bounce into IaaS in the cloud.

RDGW is far from perfect:

  • It requires more virtual machines.
  • Multi-factor authentication (MFA) with Azure AD is not a smooth experience, administration or operations-wise, using Network Policy Server with the Azure AD MFA extension.
  • There just isn’t a good story for third-party vendor support.

When Azure Bastion preview was announced, I hoped that it would end the need of RDGW. Alas, that was not the case. I work with enterprise clients that run hub & spoke architectures. Running a Bastion in every spoke would be too expensive. But now a preview release of inter-subscription VNet peering support has been launched for Bastion.
Things are not perfect! The Bastion resource must be deployed into the hub – thus ruling out Azure Virtual WAN hubs today. And the RBAC requirements are poorly documented. And yes, Bastion has other limitations such as:

  • Not supporting desktop clients
  • No support for RDP channels (file transfer for example)

But overall, Bastion is an imperfect but better experience than RDGW.

Encryption Over ExpressRoute

It seems that many people are not aware that ExpressRoute circuits:

  • Are not encrypted: The data transfers “in the clear”
  • Do not terminate at a Microsoft data center: Edge data centers are hosted in third-party locations, which means that even if your ISP could encrypt the circuit as far as Microsoft’s enterprise edge (MSEE) router, the data would return to the clean until it transited a circuit (not necessarily owned by Microsoft) to reach the Azure region.

This is a topic that has taken up a lot of my time lately. The original two options were:

  • Implement IPsec encryption, which is an operational nightmare and useless with PaaS.
  • Use ExpressRoute Direct, which will be 5x more expensive than ExpressRoute Standard – and that’s just the Azure charges.

In November, a new option was made generally available: VPN over ExpressRoute private peering. The concept is that you run a VPN Virtual Network Gateway alongside the ExpressRoute Virtual Network Gateway. The on-premises edge network creates a VPN tunnel to the VPN Virtual Network Gateway across the ExpressRoute circuit. Yes, there will be an overhead of encryption, but you can use a lower cost ExpressRoute tier. There is some additional BGP complexity where you need to ensure that on-premises routes are advertised only through the VPN tunnel to avoid ExpressRoute taking priority, which is automatically does if it propagates an identical set of on-premises prefixes.
The downside of the solution is that the VPN Virtual Network Gateway must be one of the AZ SKUs – that means that the solution is limited to regions that support zone redundancy. That’s where the core concept of this feature falls apart. Many of the organisations that will require encryption for compliance are the same organisations that have driven Microsoft to deploy Azure regions into more localities. Those local regions are smaller and mostly do not support zone redundancy. That leaves VPN over the Internet as the best option – you can still do VPN over ExpressRoute to a virtual appliance, but that leaves you with a single point of failure (the appliance) that cannot propagate BGP routes into your virtual network(s).

Other Announcements from Microsoft

Here are other Azure IaaS headlines from the past month:

Azure Storage

Networking

Azure Virtual Machines

Backup And Site Recovery

App Services

Databases

Management

Miscellaneous

And Now for Something Different

Do you know how to do a “DCPromo”? Can you create and troubleshoot GPOs? Are you able to engineer AD sites & site links?
I went to my first IT conference in 2004. It was WinConnections at Lake Las Vegas where IT luminaries such as Mark Minasi, Jeremy Moskowitz, and more spoke about the latest things in Windows Server. I was there mainly to advance my skills in Active Directory Domain Services (ADDS), because it was at the heart of the global IT system that I was responsible for.
Enterprise IT has not changed all that much since then. Sure, Azure AD has come along and we have stuff like MFA, Intune (or whatever it’s called this month), and all that jazz. But in an enterprise, where is identity created? Yup, ADDS. What is used as the authentication/authorization engine for the billions of legacy business systems? Yup, ADDS. And what skill is disappearing from our business? Yup, ADDS.
I’ve been involved in a few engagements over this year where I’ve been amazed at how this critical system, central to the organizations in question, is relatively unknown to those who own it. Even in my team, only a few of us grey-beards (hair on the top of the head is in short supply) know our way around a domain controller. Back in the Spring, I walked a 20-something colleague through his first forest creation for a client.
You could argue that AAD should be killing off ADDS. But that’s not possible. Too many legacy systems, including Citrix and Windows Virtual Desktop, rely on ADDS. Azure AD Domain Services doesn’t even offer the same single-scope experience.
And meanwhile, those of us who do know the tech are getting older, retiring, or … let’s not go there. Are any of you starting to feel old?

SHARE ARTICLE