In-Depth

Say Hello to Active Directory Authentication

Microsoft's new Passport for Work helps enroll Windows 10 devices using the new Windows Hello biometric authentication to Active Directory.

• By Brien Posey
• 04/26/2016

Windows Hello, the biometric authentication capability Microsoft introduced last year in Windows 10, one day will make the life of IT administrators much easier once users no longer have to remember their network passwords. It will also reduce the risk of unauthorized access by requiring users to log in with a PC facial recognition or fingerprint scanner. Enabling Windows Hello, user credentials in Windows 10 are enrolled in Microsoft Passport, the component in Windows 10 that lets users authenticate to a Microsoft account or into Active Directory, as well as any other service that supports the Fast ID Online (FIDO) standard.

Windows Hello is still evolving, but authenticating to Microsoft accounts over time will allow single sign-on access to Software-as-a-Service (SaaS) applications such as Office 365 or Web sites that support FIDO. Microsoft in late March at the Build 2016 conference announced that in addition to Windows 10, the new Edge browser will support Windows Hello authentication.

Microsoft Passport-based authentication is often used when users set up their Windows 10-based devices, whether they're personal devices or domain-joined systems owned by the organization. Enterprises and even small businesses looking to provide Windows Hello authentication to their networks can do so by connecting Microsoft Passport credentials to Active Directory. Microsoft now offers a tool called Passport for Work to handle the enrollment of user credentials with their Active Directory accounts. I'll explain how to connect Microsoft Passport with Active Directory, including some of the setup and configuration options.

Preparing Devices for Use
When a user sets up a new Windows 10 device, the Setup dialog asks who owns it. The user can either specify it belongs to the organization, or that it's a personal device. If the organization owns it, the user can specify the preferred method of connecting to enterprise resources. Setup offers two choices: Administrators can join using Azure Active Directory, or they can set up a local account and manually join a domain later. After making a selection, Setup asks the user to verify his identity. This may involve receiving a phone call or a text message and entering a code (an authentication app is also sometimes used). Once an identity is verified, the user is instructed to create a PIN. From that point on, the PIN can be used to unlock the device.

In some cases, the organization might decide to allow biometric authentication. Windows provides a Group Policy setting for this. When enabled, this policy setting allows Windows Hello to be added to a user's passport. Windows Hello supports the use of biometric authentication via finger­print, iris or facial recognition. Of course, biometric authentication can only be used if the device is equipped with the proper hardware.

Even if biometric authentication is enabled and the device includes supported hardware, Windows will still ask for a PIN. The PIN serves as a backup authentication mechanism designed to prevent the user from being accidentally locked out of his device. An accidental lockout could otherwise potentially occur as a result of a hardware malfunction or a severe injury to the body part used for authentication.

Enabling Microsoft Passport via Active Directory
Microsoft makes it relatively easy to implement Microsoft Passport in the workplace. The primary mechanism for doing so is Group Policy. It's worth noting Microsoft Passport integration is handled in different ways depending on whether the device in question is domain-joined or a user-owned device used as a part of a bring-your-own-device program.

Domain-joined Windows devices can be configured at the Group Policy level to use Microsoft Passport. The Group Policy settings used for Passport-related security are located within the Group Policy setting hierarchy at Computer Configuration | Policies | Administrative Templates | Windows Components | Microsoft Passport for Work (see the available policy settings in Figure 1).

The first Group Policy setting you need to be aware of is the Use Microsoft Passport for Work setting. As the name implies, this is the setting that allows users to use a passport for work. As you would probably expect, disabling this setting keeps Passport for Work from being provisioned, and enabling the setting enables key- or certificate-based provisioning for all users. By default, this setting isn't configured, and therefore users are allowed to provision Passport for Work, but aren't forced to use it. Incidentally, Microsoft has long provided a Group Policy setting called Turn On PIN Sign-In. However, this particular policy setting doesn't work for Windows 10 devices. PIN usage for Windows 10 devices is controlled via the Use Microsoft Passport for Work setting.

Another policy setting related to Passport for Work is Use a Hardware Security Device. This setting essentially controls whether Passport for Work will attempt to use a device's Trusted Platform Module (TPM). Enabling this setting is the same as requiring TPM usage. If the setting is disabled or if it isn't configured, Windows will make use of the device's TPM if it's available, but will revert to using software-based security in the absence of a TPM.

One of the more interesting settings provided by the Group Policy Object Editor is the Use Biometrics setting. This allows biometric devices, such as retina scanners and fingerprint readers, to be used in place of a PIN. Biometric device use is allowed by default (or by enabling this setting). Disabling Use Biometrics means Windows will only accept a PIN as a gesture.

If an organization decides to allow biometric authentication, there's a separate collection of Group Policy settings specifically related to biometrics. These settings are located at Computer Configuration | Policies | Administrative Templates | Windows Components | Biometrics. You can see the available biometric settings in Figure 2.

Administrators tend to be somewhat apprehensive about PIN usage. In some cases, an administrator may not be allowed to enable device PINs because doing so would violate regulatory requirements. Even if you take the regulations out of the picture, however, PINs are typically considered far less secure than a password. After all, most organizations probably require the use of frequently changing, complex, alphanumeric passwords of at least eight characters in length. Conversely, PINs tend to be thought of as being similar to the four-digit numeric PINs that banks sometimes use for ATM cards.

Microsoft's rationale for PIN-based device security is it's theoretically more secure than passwords because a PIN is specific to a device. Unlike a password, a PIN does not get transmitted across the network.

Keeping PINs local to a specific device can certainly help to improve security, but Microsoft also allows the PIN require­ments to be established through the use of Group Policy settings. The PIN Complexity container offers a number of different PIN-related settings, which tend to be nearly identical to Windows password complexity settings (see Figure 3).

The first of these settings is the Require Digits setting. This setting forces users to include a numeric value (a digit) within their PIN. Such a digit is required as a default behavior, but the requirement can be overridden by disabling this policy setting. The second element of the PIN Complexity settings is the Require Lowercase Letters setting. The OS default behavior forbids users from including lowercase letters within their PIN. If an administrator wants to require the use of lowercase characters, they must explicitly enable this setting. Although this behavior is admittedly strange, it may have something to do with a lack of device-level support on some devices.

The third PIN Complexity setting is the Maximum PIN Length setting. By default, or when this setting is disabled, the maximum length of a user's PIN is 127 characters (of course, the PIN can always be shorter). Enabling this setting allows the administrator to choose the maximum PIN length.

Just as Windows lets the administrator specify a maximum PIN length of her choosing, she can also stipulate a minimum PIN length. Interestingly, with this setting you can't simply disable it to allow for PINs with no minimum length. When the setting is disabled or not configured, the minimum PIN length is four digits. The Microsoft documentation doesn't specify the minimum length that can be used when the setting is enabled.

Expiration Setting
Another PIN complexity setting is the Expiration setting. If this setting is disabled or if it isn't configured, the user's PIN will never expire. PIN expirations can only be achieved by enabling this policy setting, and specifying the number of days at which the PIN will expire. The minimum value is zero (which prevents a PIN from expiring), and the maximum value is 730.

The Windows Server OS also contains a History policy setting. This setting determines the number of previous PINs stored and prohibited for reuse. The default Windows behavior is to not store PIN histories. This is the same behavior that occurs if the History setting is disabled. If an administrator enables this setting, the administrator is able to specify the number of PINs to be stored in the history. It's worth noting the user's current PIN counts as one of the history items.

Yet another PIN Complexity configuration is the Require Special Characters setting. By default, Windows doesn't allow a user to include special characters in his PIN. Special characters are also forbidden if the policy setting is disabled. If, however, the policy setting is enabled, a user will be required to include at least one special character in her PIN.

The final PIN complexity setting is Require Uppercase Letters. Once again, uppercase letters are prohibited by default when the policy setting is disabled. Enabling this policy setting not only allows the use of uppercase characters, but requires at least one uppercase character to be used.

If an organization were to use the default PIN complexity settings, they'd be numeric only and employees could use short, four-digit PINs. The settings allow administrators to enforce the use of uppercase and lowercase letters, numbers and special characters. At that point, however, PINs become much more password-like. More important, it's possible some devices might not support alphanumeric PINs.

Use Remote Passport
One last setting related to Passport for Work, which isn't a PIN Complexity setting, is Use Remote Passport. This setting will let a user authenticate into a PC using a registered companion device (such as a phone) as an authentication mechanism. Although such a setting does pose some potential risks, it may very well prove to be a reliable means of authenticating users. After all, smartphones tend to be extremely personal devices. Each person's smartphone is unique in that everybody installs different apps and configures their device in a different way. Because smartphones are such personal devices, it's rare to see someone walking around with someone else's phone. Most people have their phone in their direct possession at all times. As such, a case could be made for smartphone-based authentication.

Whither the Password
Although passwords are still the primary authentication mech­anism for most organizations, it's becoming feasible to use biometrics as an alternative with Windows 10. Microsoft Passport for Work gives organizations the option of allowing authentication to Active Directory accounts through the use of a PIN or biometrics.