SystoLOCK: A Real Passwordless MFA Platform for Windows Domains

Where is passwordless MFA for Windows?

Passwordless is a noisy buzzword in the modern world of authentication, with various approaches finding their place mostly in web-based products (think passkeys). Unfortunately, Windows domain environments haven't had native support for true MFA, if you don't count Azure-based MFA and Windows Hello for Business, so most third-party vendors offer MFA support for Windows in conjunction with a password-based approach.

There are only very few solutions on the market that provide real passwordless MFA for Microsoft Active Directory on premises, and SystoLOCK is the only one that is fully autonomous, self-hosted, does not rely on any cloud services, and supports all common usage scenarios, from system logon, through impersonation and network share access, to RDP and VPN access.

How is SystoLOCK different from traditional MFA?

SystoLOCK's approach to MFA is very different from that of most vendors: while it is a true MFA system, meaning that it uses 2 out of 3 factors to authenticate a user, it does not rely on the user's password to do so, nor does it manage any password rotation in the background. More specifically, it maintains separate sets of cryptographic credentials that are detached from the user object in Active Directory and verified at login. Upon successful verification of these credentials, SystoLOCK enrols a short-lived (valid only for that one login) certificate for the user and presents this certificate to the domain controller where final authentication takes place. Here is a diagram of the whole process:

SystoLOCK relies on hardened instances of AD CS, aimed to serve only its own requests.

Importantly, the approach does not stop at the login screen, but extends to all subsequent credential requests, including network access, user impersonation and privilege elevation:

And what happens to the password? Well, SystoLOCK is essentially a virtual smartcard and presents itself as such to the system. Therefore, we can apply a "smartcard required" account setting to the user object in AD, effectively preventing any password-based authentication and any brute-force attack or credential theft.

SystoLOCK for RDP: Sudden harmony

Logging into an RDP session has never been a trivial process when done correctly. When you try to add MFA to the process, even more issues become apparent and with an NLA requirement, you can get bogged down in troubleshooting. With traditional MFA vendors, you would normally use your password at the local RDP prompt, if configured to do so, and then complete the second step of the MFA process on the remote screen. There is simply no place in the RDP protocol architecture for the MFA credentials, hence the duality.

When we designed SystoLOCK, we wanted to streamline the user experience and eliminate this duality. The resulting flow is exactly that: you provide your credentials once and are then taken into the RDP session without the need for a second step - whether NLA is enforced or not, the experience is always close to single sign-on.

Another important aspect of RDP support is the prevention of credential theft. If you use a simple password-based or traditional MFA approach and your client or host is compromised, the password you enter in the RDP authentication prompt can be stolen unless Credential Guard is in place on the server side. Things are also dimm for password thefts on the client side. With SystoLOCK, because the passwords are effectively removed from the user objects and the certificates used are short-lived (with their private keys inaccessible), there is no way for an attacker to compromise the RDP session.

And, of course, it supports Devolution Remote Desktop Manager right out of the box!

Offline computers and remote workers

Since each logon results in a new certificate being issued and verified, a connection to the SystoLOCK server, a certificate server and a domain controller is required during logon. This can be a problem for those who travel or work from home and do not have a VPN in place. A different approach is used here to overcome this gap. While the previously described use cases could simply use an OTP, offline login requires the use of a smartphone to log in. Cached credentials, a Windows feature, also needs to be enabled for offline logins to work; however, it is usually enabled.

Once a user had previously successfully logged into a computer using SystoLOCK (and that computer has been configured by an administrator to allow offline logins), that computer will exchange some cryptographic information with the SystoLOCK server and store the smartphone's cryptographic keys for later use.

When the user attempts to log in while offline, the computer, which is unable to communicate with the server, instead communicates with the smartphone by displaying a QR code. When this QR is scanned, the smartphone initiates a credential check on the server, acting as the missing network link between the computer and the SystoLOCK server. If the server is unavailable, the smartphone will cryptographically verify the identity of the computer and the user, if configured to do so. If the verification is successful, the phone will present a numeric code to be entered on the computer. After the user enters this code at the offline login prompt, the login is complete. For the user, the offline login does not appear to be very different from the online login, making it a seemles experience:

Working offline does not always mean being completely disconnected from the office infrastructure. In some cases, it simply means establishing a VPN before launching an office application or RDP session. SystoLOCK offers different approaches to achieve the required connectivity.

One approach is to control the supported VPN clients. Microsoft's VPN client and Cisco's AnyConnect client are natively supported by SystoLOCK. The only requirement is that the VPN gateway accepts user certificates for authentication and is able to check them against Active Directory. The other approach is to use our generic RADIUS server plugin, which is designed to run under an NPS component on a Windows server.

If you are lucky enough to be using the natively supported VPN clients, you can take advantage of SystoLOCK's PLAP compatibility and dial into the VPN and log on to the computer in a single step:

What's wrong with traditional 2FA?

While "2FA" is an acronym for two-factor authentication, it is sometimes used to refer to so-called two-step authentication. This is where the main problem lies: authentication performed in this way is not primarily two-factor, but takes place in two steps: the first is the actual authentication, and the second is a form of confirmation that can even be turned on and off or configured.

Applied to a Windows or RDP logon, this means that the user would first provide their password, the actual authentication against a domain controller would take place and then, if this first step is successful, some form of additional verification would be performed. This verification, if we are talking about local or RDP logins, is usually done by "injecting" an extra screen just before the user shell is launched, and that screen is used to communicate the second factor. The trick is simple: if the verification fails here, the user shell never starts and the logon session is aborted.

Most traditional MFA vendors, including Duo, Thales, etc., use this trick to perform the second-step verification, thus relying on a successful password-based authentication in the first place.

The first problem with this approach is that it can only be applied to the login process. If you then need to access a file share or run a program as administrator, you are left without that second verification step. This can be a problem in itself (think compliance!), but it leads to other more important problems:

• Most other devices in your domain that are not MFA-aware can still be brute-force attacked, and they will be at some point if a device on your network "catches" a virus,
• Users will choose simplier passwords because they feel more secure using 2FA at login, making brute-force attacks easier,
• RDP sessions can be hijacked and password credentials stolen if the RDP client or server is compromised. These passwords could then be used against those MFA-unaware nodes.

These are just some of the issues associated with 2-step authentication, the other good example being "MFA fatigue", also known as an MFA bombing attack - the type of attack that was used in the Uber hack in September 2022. This and similar attacks led some researchers at Bleeping Computer, Sentinel One and PC Magazine to even questioning the effectiveness of MFA altogether.

Universal approach and future outlook

Windows user domain accounts are at the heart of the user experience. They are used in many different ways in many different scenarios, and these scenarios vary in complexity and approach. It's not just about login and RDP, SystoLOCK is able to talk to ADFS, for example, opening the way for passwordless login to Office 365 with locally managed users, it can instruct RD Gateway and RDWeb to perform SSO against a farm of published applications. And of course, SystoLOCK has its own mobile Authenticator App that can replace all other authenticators you have known so far. You can find here a variety of SystoLOCK modules available for different Windows components.

The main goal of SystoLOCK is to eliminate passwords while providing the best user experience and without any reliance on a cloud service. SystoLOCK does this by transforming one set of credentials into another. This transformation means that the initial set can vary and, although not yet supported, we are working on incorporating FIDO2 tokens and other means of authentication into the workflow.

It is becoming common sense that the future of authentication is passwordless. SystoLOCK is there to support this transition on the Windows side, where Microsoft has so far failed to provide a proper approach to modern MFA.

Further Information:

• Product site: SystoLOCK.com
• Schedule a SystoLOCK Demo
• Usage demonstrations as a YouTube playlist
• SystoLOCK broshure
• Penetration Test certificate
• Contacts: via web or LinkedIn