Transition Guide - Passwords or OTP to Smart Cards for On-Prem Windows Authentication

By far the most common starting point when migrating to passwordless authentication in an On-Premises environment is a Windows Active Directory domain that primarily uses passwords, with some OTP support configured for more sensitive or externally available resources.

For end users that are dealing with both long passwords and OTP codes, smart cards and their relatively short PIN , that need not change periodically, can significantly cut down on issues caused by forgotten (or mis-typed) passwords, misplaced OTP generators, poor cell coverage areas and other headaches associated with the management of this legacy authentication mechanism.

One of the most crucial parts of a successful transition of an on-premises Active Directory infrastructure to phishing-resistant authentication, is understanding the desired goal. It may not be possible to completely transition to phishing resistant authentication for everything in an on-premises Active Directory environment, especially for organizations which have legacy hardware or applications.

This transition guide will outline the steps and highlight decision points that are critical to a successful rollout of smart card authentication.

The high level steps to transition to smart cards from passwords and/or OTP codes are:

  1. Enable optional smart card authentication
  2. (Optional) Remove or reconfigure OTP providers so that they do not require an OTP in addition to a smart card.
  3. Provision smart card certificates for users
  4. Enforce smart card authentication for specific users or services until all compatible use cases require smart card authentication

Enable Optional Smart Card Authentication

For Windows Active Directory, once all of the prerequisites have been met for smart card authentication, there’s nothing else that needs to be done to allow individual users to authenticate with a properly provisioned smart card.

For this step, organizations may use the Windows Active Directory Certificate Services server, which not only deploys the core PKI infrastructure, but configures the domain controllers and clients to trust the appropriate root certificates.

Other organizations may elect to use a 3rd party certificate or credential management system (CMS). In that case the CMS vendor will have resources for how to configure the domain, and certificate templates to allow for smart card authentication to Windows Active Directory.
In any case, at the end of this step, a newly provisioned smart card should work for initial sign-on to the Windows desktop.

Web Application Proxies

Web application proxies may provide additional flexibility to make applications work with AD FS, which has built-in support for smart card authentication. There are a variety of web application proxies that are compatible with Active Directory and AD FS, including Microsoft’s own AD FS Web Application Proxy server. These proxy servers can be used to bridge the gap between mobile devices that support smart cards like iPhones or iPads and on-premises applications that only support Integrated Windows Authentication.

While not ideal, web application proxies can also be configured to support pre-authentication - which is when the web application proxy separately authenticates the user before showing them the web application. This can unfortunately result in users authenticating twice, once to the proxy, and once to the application itself, but may be the only way to ensure that some applications are phishing resistant.

(Optional) Remove or Reconfigure OTP Providers to not Require an OTP in Addition to a Smart Card

Organizations that are building a new platform from the ground up may skip this step, but many organizations may have an existing approach to Multi Factor Authentication (MFA). This legacy MFA can take many forms, either at network boundaries like VPN systems or bastion hosts, or to log on to workstations, servers or web applications that contain sensitive information.

When planning your deployment keep in mind the User eXperience (UX.) Make sure you give adequate attention to which users and systems you will be migrating to smart cards at what point in the project. Some organizations will prefer moving discrete groups of users or related systems over to smart cards in groups, communication can be focused in certain areas, others will prefer to roll out smart card compatibility gradually over the whole organization and user population to minimize the risk of an unexpected outage that will affect business functions. The goal should be to segment your migrations in such a way as to avoid situations where users will need to authenticate with smart card & PIN and OTP. Entering an OTP code in addition to a smart card during authentication will make the process more complex for the end user without adding any additional security benefit, and should be avoided if at all possible.

While transitioning to smart card authentication, depending on the size (and location) of the organization and its users, it may be desirable to keep the legacy authentication methods enabled for some time in order to ensure that all users have correctly provisioned YubiKeys before smart card authentication is required.

The most important output from this step is a list of devices or applications that require a password and OTP code, and of those, which applications can be configured to support smart card authentication in a way that will not require the OTP code in addition to a smart card..

While it may be tempting to also leave less secure authentication methods in place as available fallback mechanisms for users that have a lost or damaged YubiKey, it’s important to consider that attackers are likely to target the weakest form of authentication available, and that additional controls may be necessary to prevent the misuse of the weaker authentication. Remember, “Any authentication system is only as strong as its weakest link.”


Provision Smart Card Certificates for Users

Once smart card authentication has been enabled to the extent possible, and situations where it is (and isn’t) expected to work are documented, you can then start getting smart card logon certificates into the hands of end users.

There are a number of different strategies for provisioning smart card logon certificates to users, depending on whether the organization is using Active Directory Certificate Services (AD CS) or a 3rd party CMS vendor. If the organization is using AD CS, the two main ways to provision certificates are via Self-Enrollment or having an enrollment agent “enroll on behalf of” another user.

When dealing with both solutions, make sure to include peer organizations, especially HR, when building this documentation. In most organizations HR or payroll will need to be engaged to provide some identity verification or proofing steps, and the new hire/exit processes will likely be impacted as well.

Smart Card User Self-Enrollment

In the self-service enrollment model, the end user’s AD-Joined workstation prompts them to provision certificates if no valid certificate has been issued. Further information about configuring AD CS for self-service enrollment can be found in “Setting up Smart Card Login for User Self-Enrollment


Smart Card Enroll on Behalf Of

In the “enroll on behalf of” model, an authorized enrollment agent logs on to a secure workstation, preferably one that already requires smart card authentication, and a specifically configured AD CS certificate template to create certificates for another user on a YubiKey. This model may be used when there is a requirement for another person to supervise the creation of smart card credentials, or when credentials need to be made for a person who has no other way of logging in to their computer. Additional information about configuring AD CS to support enrolling smart card certificates on behalf of another user, see “Setting up Smart Card Login for Enroll on Behalf of


Enforce Smart Card Authentication for Specific Users or Services

By the time the end users start receiving smart card credentials, as many services as possible should be capable of smart card authentication. The next step for organizations as they drive the adoption of smart cards is to track which users have enrolled for smart card certificates on their YubiKey, and can start evaluating approaches for enforcing smart card authentication.

It’s important to note that it’s extremely challenging (if not impossible) to fully eliminate passwords from every user account on a Windows domain. Windows only supports enforcing smart cards for interactive authentication - situations where a user is initiating the authentication. The Microsoft article “Administrative tools and logon types” outlines the different types of authentication, and what methods are supported for each one. In organizations that are already OTP for MFA, administrators will likely be aware of this distinction already, because 3rd party OTP providers tend to be restricted to protecting interactive logons as well.

It’s likely there will be a small number of applications that still require weaker authentication methods like username and password, so it’s important to enforce smart card authentication gradually. Windows Active Directory provides two ways to enforce smart cards for interactive logon, per-user and per-machine, each with its own benefits and drawbacks.

Per-machine Smart Card Enforcement

Per-machine smart card enforcement controls whether a specific workstation or server will require smart cards for interactive logon sessions. While this setting alone is not very effective in completely eliminating the use of passwords or legacy MFA providers, it’s an important first step to reduce the number of times that users have to enter their password or use a one time password. Once a user’s interactive logon session is authenticated with a smart card, any resources that can be accessed via Integrated Windows Authentication (IWA) will be accessible, including file shares, databases and web sites hosted on-premises, as well as single sign-on via AD FS. This setting is effective when combined with firewall rules and other network controls, to limit the ability of anyone to sign on to the machine non-interactively.

Per-machine smart card enforcement is controlled by the “Interactive logon: Require smart card” group policy setting. Because this is a setting on the local machine, care should be taken to ensure it can’t be tampered with by users with local administrative access.

Per-User Smart Card Enforcement

Per-user smart card enforcement controls whether the Windows Domain will require smart card authentication for all interactive logon attempts across the domain. This is controlled via the “User Account Control” flags on a specific user account. When this setting is set on the user account, Windows will automatically set the user’s password hash based on a 120-character random string, effectively disabling the use of passwords for that account. This approach, while more thorough, should only be applied to accounts when the user will never need to use a password with the account.

It is still possible to manually reset a user account’s password after setting the “Smart card is required for interactive logon”, allowing a user to continue to use a username and password for non-interactive logon methods, while still requiring smart cards everywhere that uses interactive logons. This makes it possible to continue to use an account’s username and password with legacy applications over the network.

For an in-depth analysis of the different methods of enforcing smart card authentication, and more information about the security implications of each approach, please refer to the Microsoft article “Smart Card Logon Enforcement - Long Edition”.


Completing the Transition

As stated in the introduction to this document it may be that the end goal isn’t the complete elimination of passwords on-premises in a single project or effort. One of the final tasks that needs to be done in any successful transition to a phishing resistant authentication method is to ensure that the organization continually re-evaluates the applications and services that it uses to understand if those applications and services have been made compatible with smart card authentication. Even though smart cards are often seen as a very stable authentication technology, because they’ve existed and been well supported in on-premises Active directory deployments for over twenty years, there’s been a renewed interest in supporting smart cards for more devices and services now that regulators are becoming serious about requiring phishing resistant authentication. Yubico professional services can help your organization get the most out of a YubiKey based smart card implementation, ensure that as many applications as possible are using phishing resistant authentication, and utilize the other functions of the YubiKey to strengthen authentication in scenarios that don’t support smart cards.