One of the main strategies for securing privileged accounts in Active Directory Domain Services seems to enable the Smartcard is required for interactive logon option on members of the Domain Admins security group. Typically, that required deploying (virtual) smartcards, but there is a far easier way that is currently being wildly adopted: Windows Hello for Business (WHfB).
About Requiring smartcard for interactive logon
Mere password authentication is insufficient. It doesn’t suffice for people when they access organizational data from outside the organization’s perimeter and it doesn’t suffice for privileged accounts.
The Smartcard is required for interactive logon option has been a part of Active Directory Domain Services since its inception. This option on a user accounts Properties window, requires the use of (virtual) smartcards to be able to sign in interactively. This option is sometimes referred to as SCRIL.
For accounts that have the option enabled, the object’s useraccountcontrol attribute is increased by 262144.
The option can also be set using the Interactive logon: Require smart card Group Policy setting underneath the Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options node. This way, the option requires the use of smartcards for all people accessing devices in scope.
When signing in, a person using facing this requirement needs to present the smartcard certificate on the (virtual) smartcard to sign in. The smartcard is unlocked using a PIN. Effectively this makes sign-ins with smartcards multi-factor authenticated sign-ins, as the person proves they know something (the PIN) and proves they have physical possession of something (the smartcard or the device where the virtual smartcard is tied to).
About Windows Hello for Business
Windows Hello for Business (WHfB) also offers multi-factor authenticated sign-ins. It is available since Windows 10 and allows people to sign in using biometrics, like face recognition or using a finger print reader.
Under the hood, Windows Hello for Business uses certificates too. Just like a smartcard deployment, a WHfB requires Certification Authority (CA), the root CAs certificate to be trusted and a specific certificate enrolled to Domain Controllers. However, WHfB also requires device registration, either by Azure AD (and then written back to the on-premises Active Directory with Azure AD Connect) or by AD FS.
Whether a user certificate is needed within WHfB deployments depends on the trust model chosen; WHFB offers a key trust model and a certificate trust model. You’d have guessed right if you suspected the latter method to require a user certificate with, coincidently, the Smart Card Logon (1.3.6.1.4.1.311.20.2.2) enhanced Key usage enabled.
Satisfying the requirement using WHfB
The good news is that using Windows Hello for Business (WHfB) satisfies the Smartcard is required for interactive logon option for user objects and satisfies the Interactive logon: Require smart card Group Policy setting on devices to sign in interactively.
There is a gotcha: WHfB satisfies the requirement even on devices that aren’t equipped with TPM chips. Enable and deploy the Use a hardware security device Group Policy setting to force Windows WHfB to only work with hardware protected credentials.
Concluding
Checking the useraccountcontrol attribute on user accounts that are members of the Domain Admins security group is a popular activity by security firms. If it’s missing, it leads to a flag stating that privileged account sign-ins are insufficiently secured.
While Windows Hello for Business shares much of the same requirements as smart cards, it can be rolled out to all people in your organization to facilitate secure sign-ins. Unlike smart cards…
Further reading
Enabling smart card logon
Interactive logon Require smart card – security policy setting (Windows 10)
UserAccountControl property flags
Configure Windows Hello for Business Policy settings
Choosing the right Passwordless sign-in method for your colleagues
Requirements per Windows Hello for Business Deployment Type
HOWTO: Delete your Windows Hello for Business Registrations
This seems like a great option. One challenge is that if a user has not yet created a WHFB PIN on the system, that user will be unable to sign in. I suppose we could place the user or computer in a separate unenforced OU until they create PIN, then move them to the enforced OU, but this seems like a bit of a headache. Any other suggestions?