For IT admins, installing Windows Server is often a balancing act. The larger the operating system footprint, the more features it has. At the same time, a larger installation consumes more resources, is more time-consuming to manage, and offers a larger attack surface for hackers to target. Windows Server Core offers a minimalist Windows server installation, but it needs the same protection as any other Windows server: strong passwords, access controls, and MFA for servers. UserLock offers a simple way to implement Server Core MFA.

Ever since Windows Server Core appeared in 2008, admins have had the option to install this stripped-back version of Windows, which removes components that are not necessary for the operating system to do its basic job. 

Lacking a GUI management interface, admins interact with a Windows Server Core server using the PowerShell command line scripting language or Remote Server Administration Tools (RSAT) controlled from a separate PC. 

When managed remotely, PowerShell sessions are an obvious security risk, not least because Server Core is more common in virtualized and on-premise environments where security is critical.

Installing Windows Server traditionally means installing a version that includes the full Desktop Experience GUI plus a range of Server “roles” that add different capabilities.

Admins choose the roles or services the server will need. However, an important calculation is that each one of these roles takes up space and consumes resources when it is active. 

That’s why today the idea of a single Windows installation is no longer an automatic choice, and admins pick and choose the components they need to keep the Windows footprint to a minimum.

Windows Server Core is the embodiment of this idea. Designed for an era of virtualized and headless servers, Windows Server Core cuts the operating system’s installation down from a standard image of 11.2GB to around 4.8GB.

This reflects the changing nature of Windows itself from the single monolithic operating system of the past to today’s modular architecture designed to serve multiple needs.

The main caveat to this is that admins need to be comfortable using PowerShell without the visual aid of a GUI, and this can be challenging.

Server Core’s smaller footprint makes it ideal for on-premise servers where reducing the attack surface is important. Examples of this are servers that perform specific roles within the network such as domain controllers, print and file servers, web servers, servers hosting Remote Desktop Services (RDS), and virtualized Hyper-V hosts.

The main argument for doing this is security: the fewer Windows components there are, the fewer security vulnerabilities of misconfigurations it will suffer over time, affording attackers less opportunity for compromise.

If you're like many organizations, you have good reason to continue investing in on-premise infrastructure.

In some cases, organizations operate in a regulated sector in which data must be kept onsite for security reasons or find themselves supporting legacy systems that they can’t easily replace or upgrade.

However, while on-premise infrastructure gives organizations more control, it comes with the downside of greater management effort.

Unlike the cloud, all infrastructure including servers is their sole responsibility. Windows Server Core offers a way to keep this general overhead to a minimum. 

However, security in on-premise environments is always a concern. Every access to a server creates the opportunity for compromise. That is as true for Windows Server Core servers as any other Windows image.

If something goes wrong, the organization is on its own. In an on-premise environment, responsibility for securing a Windows Server Core is solely a problem for the organization it belongs to.

Every admin today understands the risk of password compromise. It's now so high that this type of credential is no longer enough security protection on its own. The solution is to implement MFA for servers — across all servers — but doing this is not always simple.

For one, Windows Servers don’t have an integrated MFA mechanism. This often means that organizations must construct their own solution using third-party tools.

UserLock is a perfect fit for organizations looking to address this issue. Designed to integrate with your existing Active Directory (AD), UserLock makes MFA deployment seamless across a wide range of connection types, including Server Core.

You can apply Server Core MFA to privileged users accessing Server Core servers based on the same access parameters — location, time of day, user, group and organizational unit (OU) — defined by existing Active Directory security policies.

When you install UserLock on a Windows Server Core, a special agent is deployed to your Server Core (to the user, you don’t see that it’s a special agent since installation stays the same as for other servers).

The interface of UserLock’s desktop agent uses an MFC library, which is always available in Server Core. So, even if your server has no interface, this is how UserLock can apply a dialog box for entering the MFA code.

Depending on how your admins access Server Core, the password prompt on a Server Core server is normally via the command line.

With UserLock in place, once the admin enters this credential, the UserLock server immediately intercepts the call from a desktop agent on the accessing computer, displaying an MFA prompt in a small dialog box.

Read more about how to install UserLock in a Windows Server Core.