Securing Windows server VMs: MFA without the overhead

Virtualization is one of the foundations of modern IT, but it is not without its security challenges. The first problem is the sheer volume of virtualized servers (virtual machines, or VMs) admins must now defend, which creates a constantly expanding attack surface for criminals to aim at.

A second issue is that today’s servers are almost always physically remote. In on-premises deployments, this means the servers are in another building. In the case of cloud services, they can be thousands of miles away. While this isn’t necessarily less secure, it does increase the chance that a server will be overlooked at some point.

To stay secure, organizations need strong access controls. Multi-factor authentication (MFA) and contextual access control policies are a must.

But in a Microsoft environment, implementing this quickly gets tricky.

How IT teams implement strong access controls depends on whether the organization is predominantly on-prem, has migrated to Entra ID, or has adopted some hybrid combination of the two.

And when it comes to putting MFA on access to Windows server VMs, the options narrow even more.

The problem: MFA isn’t baked into virtual server infrastructure. It’s always an extra layer.

The authentication system must support MFA across multiple types of Windows VMs, including those in the cloud as well as on-premises.

Unfortunately, this often means teams spend big money on time-absorbing, extra infrastructure that makes their job harder.

Originally, a server was a physical machine running a single OS on dedicated hardware. Today, for reasons of scale and efficiency, almost all servers run on VMs in which multiple copies of the OS are run on the same hardware. Clustering allows multiple VMs to be run together as single logical units, with workload distributed using load balancing.

This idea helped to make the cloud possible because it allows large numbers of servers to be run in datacenters operated by service providers. This in turn has allowed organizations to purchase server resources without having to think about their physical provisioning, the basic concept of platform-as-a-service (PaaS).

The downside is that organizations now have two or more environments to manage:

• Traditional VM servers with their applications running on-premises, and

• Remote ones in the cloud.

Inevitably, this has a huge bearing on security. It means that organizations must choose whether authentication is managed from their own network using AD or via a third-party service provider.

Securing VMs requires well-designed monitoring. MFA is not a set and forget technology and requires constant oversight. This is true for any user login, but is doubly so for server logins protecting a core asset.

This is why one of its most important features of an MFA platform is how information on events is fed back to the admins managing them.

If something suspicious or unusual occurs, admins should always be the first to know. The MFA system should be able to give them the full context around an alert.

There's no right or wrong answer here.

One option is to go for Microsoft’s native tools and services.

1. For cloud-oriented customers: Entra ID identity and access management (IAM) with Entra MFA and Role-Based Access Control (RBAC).

2. For on-premise and hybrid (mixed on-premise with Microsoft cloud) customers: the above option with a mix of additional tools which, depending on the balance of on-premise and cloud, might include Active Directory Federated Services (AD FS), Entra Connect Sync, and Entra Cloud Sync.

Many organizations find that the downside of using these tools is that they add complexity and, in many cases, extra cost.

The question, then, is how organizations with an on-prem or hybrid setup should best secure their VM infrastructure. They want to add a layer of MFA and access control to secure these vital servers, but without increasing management overhead.

UserLock was designed to solve these MFA implementation challenges through one smart, simple platform.

For on-prem use, UserLock allows admins to apply MFA and access control policies for VM connections according to existing AD policies.

In other words, you can simply add security layers on top of the infrastructure already in place.

UserLock also makes it easy to extend secure on-prem authentication of AD identities to the cloud. UserLock SSO makes it easy to bring SaaS access under IT's control. Again, with UserLock, the on-premise AD identity can be used to authenticate access to VMs running in Microsoft’s cloud. 

That means that organizations oriented towards on-premise control can have the best of both worlds, deploying MFA controls to VMs, regardless of where those servers are located.

AD already defines how users and admins access VMs. UserLock simply builds on this with granular MFA and access control policies that teams can customize completely.

UserLock applies MFA when admins or users authenticate from any connection type (RDP, VPN, IIS) using a range of factors, including push notifications, authenticator apps, and YubiKey or Token2 hardware tokens.

However, MFA itself is only half the story. Monitoring is also critical. Through UserLock, admins are given comprehensive oversight of authentication events, for example unsuccessful/successful logins.

Importantly, this applies even when those VMs are managed through Entra ID. Any policy violations are immediately flagged for admin attention while the platform’s access controls allow organizations to set restrictions based on location or time of day.

Diligent VM monitoring is part of effective admin. Remember, while low-level VM management is for admins only, the applications running on those servers can be accessed by anyone. Criminals don’t only target admin accounts. Humble user accounts are a popular target too.