For those small business DoD contractors managing non-domain connected workstations and who have been struggling with how to apply multifactor authentication to protect access — especially local administrator access — to those workstations, Microsoft has a game changer: MFA Unlock. This is a feature of “Windows Hello for Business”, which notionally requires a Microsoft account to use, but we’ve found it can be used on standalone local accounts. Combined with a few other IT configurations, this feature can help those small business DoD contractors comply with the DFARS 252.240-7012, NIST 800-171, and CMMC requirements for multifactor authentication for networked and privileged access to CUI. (Well, we sure have started this post off with a lot of acronyms, haven’t we!) In this post we’ll elaborate on how Microsoft’s MFA Unlock may help us meet these requirements..
Why is multifactor authentication important, and how can it be a challenge for small businesses pursuing CMMC?
Aside from being one of the single best cybersecurity safeguards any organization in any industry can implement to secure its sensitive systems and data, multifactor authentication (MFA) is required to be implemented by some of us in regulated environments.
At Totem, our focus is on small businesses that work on US Department of Defense (DoD) programs. If we have access to Controlled Unclassified Information (CUI) as part of that work (and about 80,000 small businesses do), we are required to abide the DoD Federal Acquisition Regulation Supplement rule 252.204-7012 (“DFARS 7012” for short). DFARS 7012 requires us to implement the National Institutes of Standards and Technology (NIST) 800-171 standard for the protection of CUI.
MFA for local administrator (privileged) access to any IT system that handles or protects CUI is required by NIST 800-171 control (and its associated assessment objective listed in the 800-171A companion document) 3.5.3[b]: “Multifactor authentication is implemented for local access to privileged accounts.”
Furthermore, all networked access to CUI systems requires MFA, per NIST control/objective 3.5.3[c/d]. This means MFA is required not only for remote access, such as:
- accessing CUI on webservers (e.g., Microsoft 365 OneDrive),
- Remote Desktop Protocols (RDP), and
- Virtual Private Networks (VPN),
but also for local network access, e.g., fileshares on a LAN. If your organization includes workstations that are not managed by a Windows Active Directory domain — a common situation for businesses that employ 1099 contractors or permanently remote employees — meeting these MFA requirements can be a challenge.
To meet these requirements, many organizations have had to figure out ways to manage all workstations on a domain (such as enroll the organization in M365), implement enterprise MFA solutions such as DUO or Authlite, and perhaps even purchase hardware tokens such as YubiKey. Re-architecting an existing network is not fun, and it is expensive and time consuming (we suffered through this ourselves; we had to re-architect after spinning up our IT system rapidly upon winning our first DoD contract). And while typically not terribly expensive, costs of the MFA services and products add up. There is also the additional headache of having to replace lost MFA tokens.
But Windows MFA Unlock can help your organization meet its NIST/CMMC MFA obligations, especially for non-domain-managed Windows workstations, at effectively zero cost.
What is MFA Unlock, and how is it configured?
MFA Unlock is an aspect of Microsoft’s “Windows Hello for Business”. You may be familiar with Windows Hello, which allows you to replace your workstation’s password credential with a PIN or biometric such as fingerprint or facial recognition. The drawback with Windows Hello is that you are simply replacing your password, not adding a second factor to it. So, Hello is not multifactor authentication. Aside from a PIN being better than a password, Hello is kind of worthless in my opinion.
However, Microsoft touts Windows Hello for Business (let’s just call this “WHFB” going forward, shall we? My fingers are old and tired…) as true MFA, meaning you can require users to provide several authentication factors during login or screen unlock, i.e., to log back in when your screensaver kicks on or after you manually lock your screen when you leave your computer unattended. (You do lock your screen when you leave your computer unattended, right? RIGHT?)
Now, the kicker here is that ostensibly Microsoft wants your organization to have a Microsoft 365 account and pay for user licenses to access the WHFB features. However, we discovered (well, Lamar discovered) that you can take advantage of the MFA Unlock feature of WHFB without a M365 account or user license, from a non-domain-managed machine. This means you can use the MFA features for local user accounts on a Windows workstation, including administrator accounts, for free! As a result those users that need local administrator accounts on their CUI workstations — like those of us engineers that need to frequently install or upgrade software — can meet the MFA requirements in the 800-171 control 3.5.3[b].
To top things off, in a section further below in this post, we’ll explain some additional Windows and network configurations you can put in place to meet the multifactor authentication requirements for network access to CUI (and/or the “covered” systems that handle or protect CUI, per 800-171 controls 3.5.3[c/d]) and comply with CMMC. The tactics we describe in that section could also be applied for control 3.5.3[b], say, to provide MFA on privileged access from dedicated workstations into network switches or WiFi router consoles.
For now we’ll give a short primer on how MFA Unlock works and how to configure it. (We should reiterate here the Microsoft webpage on this feature, as it contains much more detailed information than we’ll present in this post.)
To use MFA Unlock, you’ll first have the workstation user setup several “unlock” factors via the “Sign-in options” settings in Windows 10 (v1709+) or 11 (click on Start and type “Sign-in options”):
The first unlock factor credential could be one or more of:
- PIN
- Fingerprint
- Facial Recognition
The second unlock factor credential could be either:
- Trusted Signal
- PIN
So by default the user will use a PIN or biometric for the first factor, and a PIN or “Trusted Signal” for the second factor. By the way, the user can configure all three first factors — PIN, fingerprint, and facial recognition — if they want to have options.
One of the really cool aspects of MFA Unlock is the Trusted Signal, especially for those workstations that don’t have a camera or fingerprint reader. The Trusted Signal can be a phone (paired with the workstation via bluetooth), or a WiFi SSID, a LAN IP, or several other options. So the second factor of authentication can be something you already own or have configured, negating the need for a third-party token like Yubikey. So, for the second part of the factor setup, have the user type “bluetooth” at the Start menu and pair their phone with the workstation.
Then we just need to turn MFA Unlock on. MFA Unlock for standalone workstations is configured with the Windows Local Group Policy Object (LGPO), accessed through the gpedit.msc snap in — at the Start menu type “gpedit.msc” and run as an administrator and navigate to Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business “Configure device unlock factors”.
Just change the “Configure device unlock factors” from Not configured to Enabled, leaving all the default settings, and click OK. Then have the user log out and try to log back in. They’ll be forced to provide two factors to get back into their machine: Voila!
NOTE: once you enable the device unlock factors setting on the Sign-in options page you may see some pop ups that you’ll need a Microsoft account. Just ignore these. You can also ignore the messages that some of the sign-in factors are “currently unavailable”.
Using just the default setup of the Windows 10 LGPO we’ve tested this with phone pairing and it works like a champ, both at initial log in and when the machine is locked, for both regular and administrative users.
So for our machines that require local administration, we’ve setup PIN or fingerprint as the first factor (we prefer to use the PIN, as most fingerprint readers are on the laptop, and touching your laptop repeatedly in the dry, static-heavy desert environment in Utah is just asking for trouble :). For the second factor we use a bluetooth-paired cellphone. After you’ve punched in the PIN (or swiped your finger), the workstation automatically checks to see if the paired phone is in range, and if it is, completes the login or unlocks the machine (see the screenshots just below). And if you walk away with your phone (exceeding the range of the bluetooth connection), the machine automatically locks. Very cool!
We don’t need to use the phone as the second factor, however. We could use the fingerprint as the first factor, and the PIN as the second factor. Or we could use PIN and re-configure the second factor to be the fact that the workstation is connected to a specific VLAN in our environment. There are several options (with examples) you can explore on the Microsoft page; however, Microsoft does recommend you go with the default options as described above.
However it’s configured, this Windows multifactor authentication just may be the thing that allows your organization to comply with the often tricky NIST/CMMC requirements for MFA into privileged local accounts.
How will this help with network-connected but non-domain-joined components?
Many of our clients, especially in the manufacturing sector, have Windows workstations that are not managed by the domain, i.e., the user accounts on those workstations are local-only. However, for various reasons, including automation, the machines are network-connected. Since the workstation may access the CUI “covered” network, it is subject to NIST controls 3.5.3[c/d]: “Multifactor authentication is implemented for network access to privileged/non-privileged accounts.”
Additionally, non-domain-controlled workstations may need remote access to the covered system, through WiFi, VPN, or RDP. The same control objectives apply here. We have several clients that desire to allow 1099 contractors remote access to their networks. The question is how to implement MFA in a meaningful way for those connections, to meet the NIST requirements and prepare for CMMC.
Combined with one other control, MFA Unlock can be used to meet those objectives. First you’d have the workstation user(s) establish the MFA Unlock, as outlined above. Then you’d ensure the workstation itself is verified (or authenticated) by the network prior to allowing the connection. Workstation verification can be done by MAC filtering/whitelisting, and the 802.1x protocol allows for workstation authentication, if you’d rather go that route. And there are other combinatorial methods for device verification/authentication, such as Network Access Control (NAC). The point is ensure only verified or authenticated devices are allowed access to your network (BTW, this is required by several other 800-171 controls, including 3.1.1 and 3.5.2).
Of course, if your organization is allowing, say, 1099 contractors’ workstations access to your CUI network, then you’ll have to make sure those workstations meet the rest of the applicable 800-171 controls, aside from just MFA. Controls such as:
- implementing endpoint protection (antivirus)
- applying security baseline configuration (hardening)
- the users have partaken your security training
- you include those workstations on your asset inventory list and network diagrams
- etc., etc.
However, by allowing only verified devices access to the network (e.g., MAC filtering), and by forcing users of those verified devices to provide multiple factors of authentication to access the workstation (MFA Unlock), you are essentially limiting access to the network to users that have MFA. We use the word “compensation” when we combine various types of safeguards like this to meet a cybersecurity control objective that otherwise might be a challenge to meet in a straightforward manner. By combining device verification with MFA, your organization has put compensating controls in place to meet the NIST control 3.5.3 objectives, and should be well prepared to pass a CMMC assessment of that control. And all it cost you was some time!
Wrapping up how Windows' native multifactor authentication can help your organization meet NIST/CMMC compliance.
In this post we described the Windows MFA Unlock feature of the Hello for Business toolset, and how its multifactor authentication options can support your organization’s objectives to secure the CUI it handles, so it can eventually pass a CMMC assessment. If you have any thoughts on the MFA Unlock, or would like to share your organizations’ successes for failures with MFA of any sort, we encourage you to drop us a line, post in our Knowledge Base, or participate in one of our monthly Totem Town Hall events. We’d love to hear from you!
If you’d like to know more about DoD contractor cybersecurity compliance, join us in one of our DFARS/NIST/CMMC Workshops, where we cover the requirements “soup-to-nuts” and do deep dives into various challenging aspects of CMMC compliance such as multifactor authentication. These Workshops run quarterly, and we actually have fun talking about these topics! We’d love to have you with us!
Before I go, I want to give a huge shout-out to our friend Lamar Clapham at 227Infosec for turning us on to MFA Unlock!
Good Hunting!
–Adam
