Adding MFA on standalone Windows servers with UserLock

In an era when Active Directory (AD) is seen as the default, it’s easy to forget that many organizations still run standalone or "workgroup" servers for specific use cases. The motivation is usually security, simplicity, or a combination of both.

Common use cases include:

• Supporting small networks (typically fewer than 50 users) that don’t require the complexity and expense of managing a full AD domain. In some cases, the standalone server is the organization’s only server.

• Operating within an isolated or air-gapped network, such as in industrial control systems or software development. The organization uses AD, but the standalone server is kept separate.

• Hosting a dedicated application, such as an RDS (Remote Desktop Services, formerly Terminal Services) server to support a specific function. A standalone setup keeps the often-targeted RDS interface separate from the rest of the network.

The common thread across these examples is isolation. Hosting an application on a dedicated server and network helps protect the rest of the environment if the standalone server is compromised, and vice versa.

Securing a standalone server works differently than securing conventional "connected" AD servers. In an AD setup, authentication and policy enforcement are the job of a domain controller (DC). On a standalone server, the same job is handled locally through settings applied in the Security Accounts Manager (SAM) or Windows Server Registry. For example, to store password hashes and manage local accounts and group memberships.

Inevitably, managing security on a standalone server is more labor-intensive, since administrators must configure each isolated server individually. Despite this, the advantages of isolation are sometimes significant enough to warrant the extra overhead.

As with AD servers, user accounts on standalone servers need Active Directory multi-factor authentication (MFA) on access to meet the highest security standards. But since Windows lacks built-in MFA, organizations can only implement MFA using a separate product.

Depending on the type of standalone server, it’s not always straightforward to implement MFA. There are three key challenges:

1. Cost: Most MFA solutions rely on an Internet connection to a third-party cloud service, which can be expensive to implement.

2. Independence: In the case of on-premise networks, organizations might be reluctant to rely on an external provider or an Internet connection at all.

3. Complexity: Some MFA solutions require a second server for authentication. This is a big compromise on a network where the Windows server is meant to operate in standalone mode.

Typically, we see clients deploy UserLock for identity and access management (IAM) in on-prem AD environments. But UserLock’s various security layers, including MFA, SSO and user access control, also support standalone servers.

This includes protecting fully standalone servers operating unconnected to an AD domain, for example a server running RDS /Terminal Services in its own workgroup.

In terms of security, this is normally tricky. RDS servers need the same MFA security as any other server, but Windows Server doesn’t offer it natively. Fortunately, UserLock can run in standalone mode without the need for agents through a local account and Windows SAM. It installs directly on the same server as the RDS service.

During installation, the UserLock setup wizard offers three options:

• Primary server

• Backup server

• Standalone terminal

The standalone terminal option supports any version of Windows Server from 2012 onwards. Select this option to deploy UserLock in standalone mode.

You can read a full breakdown of server roles on the UserLock Server types page.