Strong Authentication with One-Time Passwords in Windows 7 and Windows Server 2008 R2

Updated: January 14, 2012

Applies To: Windows 7, Windows Server 2008 R2

This document describes a certificate-based approach to implement a one-time password (OTP) authentication solution for computers running the Windows 7 or Windows Server 2008 R2 operating systems. The approach can be used to require two-factor authentication with remote access technologies such as DirectAccess.

This document contains an architectural overview, component requirements, implementation guidelines, and a sample work flow for an OTP authentication solution.

Scenario examples

The scenario examples that follow involve using various methods for logging on to a Windows operating system.

Using a user name and password to log on remotely through DirectAccess

Joe is an employee of Contoso, Ltd. Contoso has procured OTP tokens from a reputable OTP vendor, and the company requires its employees to use these tokens for DirectAccess. When Joe is outside of the corporate network, he attempts to access corporate resources by using his corporate user name and password to log on to his computer.

The OTP server is accessible from outside the corporate network, and the token value is verified by the OTP token server before the user is logged on. After Joe is logged on, when he tries to access a corporate resource, the following error message informs him that he needs additional credentials:

When Joe locks his computer and unlocks it by using his OTP user name and password, the server validates the credentials and Joe is able to access the corporate resource.

Using an OTP to log on remotely through DirectAccess

David is an employee of Contoso, Ltd. Contoso has procured OTP tokens from a reputable vendor. Contoso has deployed DirectAccess, and the company requires its employees to use the OTP token for remote access by using DirectAccess. To access corporate resources while outside of the corporate network, David logs on to his corporate laptop by using his corporate user name and the OTP. After David is logged on, when he tries to access a corporate resource, he is able to do so without additional authentication prompts.

Using a OTP inside a corporate network to log on to a Windows operating system

Patricia is an employee of Woodgrove Bank. The bank has deployed OTP tokens for two-factor authentication for its employees. When Patricia begins her day at the office, she is prompted at the logon screen to enter her user name and the OTP. Upon successful validation, she is able to log on to the Windows operating system and do her work.

The solutions described in this document do not support the following scenarios.

Using OTP to log on offline

Lori is an employee of Woodgrove Bank. The bank has deployed OTP tokens for 2-factor authentication for its employees, but the OTP server is only accessible from inside the corporate network. When Lori is at home, she starts her laptop and enters her user name and the OTP value. She is able to log on and access files on her laptop. But because the OTP server is not available from outside corporate network, Lori has no corporate access.

Logging on remotely from unmanaged computers

An OTP authentication solution for remote access that uses technologies such as Remote Desktop Gateway from unmanaged computers (non-domain joined with no administrator privileges) could be supported. However, the client computer must have the necessary software components installed and be configured appropriately.

High-level architecture

The following components are used in a typical OTP solution:

• Client computer: Contains the DirectAccess components, a credential provider that is written by the OTP vendor, and a custom key storage provider (KSP).

• One-time password server: Consists of two services, an OTP agent that communicates with the validation server, and a component that communicates with the certification authority (CA).

• Certification authority: Provides a certificate that is trusted by the domain.

• One-time password validation server: Validates the OTP.

Figure 1   High-level architecture of for an OTP solution

When invoked, the OTP credential provider collects a user name and OTP value from the user and presents it to the OTP server. The server first verifies the OTP against the validation server. After the credentials are verified, the OTP server enrolls the user for a short-lived certificate from the CA that is trusted by domain.

After the certificate is returned to the OTP credential provider, the OTP server saves the certificate in the personal certificate store on the user’s computer and interacts with the logon components in Windows as if it is a smart card logon to the computer.

Benefits of this approach

• This approach does not involve special requirements for client computers if they support DirectAccess. An OTP vendor can write the required components to work with the Winlogon service and remote access by using DirectAccess.

• Only minimal public key infrastructure (PKI) deployment and management is required because short-lived certificates are used for this approach. For deployments with existing PKIs, this approach can be added to existing deployment and usage scenarios.

• This approach requires minimal changes to the logic that DirectAccess uses to request strong user credentials.

Components and requirements

At a minimum, the following components are required from an OTP vendor for the complete end-to-end solution:

• An OTP credential provider

• A key storage provider (KSP) that works with the OTP credential provider and the Kerberos protocol

• An OTP server that includes OTP token validation

OTP credential provider

For detailed information about credential providers and their uses, refer to the Credential Provider Technical Reference, which can be downloaded from the MSDN Code Gallery.

Conditional filtering of credential providers

To provide a better user experience, the OTP credential provider should be able to filter the inbox smart card credential provider based on a Group Policy setting. If no filtering is provided, the OTP credential provider, the inbox smart card credential provider, and the password credential provider will be shown during Logon and for post-logon scenarios that invoke credential providers.

Short-lived certificate enrollment

The OTP credential provider should be able to enroll the user for a short-lived certificate with the private key associated with the certificate that has access to the Windows logon processes (through the Kerberos protocol).

The private key specification must be set to AT_KEYEXCHANGE.

Communication with the OTP server

The OTP CP should communicate with the OTP server over a secured channel such as TLS/SSL or IPsec.

Behavior for credential provider usage scenarios

The OTP credential provider is required to enumerate successfully under the following credential provider usage scenarios:

• CPUS_LOGON

• CPUS_UNLOCK_WORKSTATION

• CPUS_CREDUI

Other usage scenarios do not need to be supported. To perform a smart card logon in Windows 7 or Windows Server 2008 R2, the OTP CP needs to support the KERB_CERTIFICATE_LOGON structure. For more information, see KERB_CERTIFICATE_LOGON Structure.

The OTP credential provider must enumerate successfully for the Nego auth package, the zero auth package, and TS/CredSSP.

Key storage provider

The KSP needs to implement support for NCRYPT_CERTIFICATE _PROPERTY and NCRYPT_PIN_PROPERTY because the Kerberos protocol expects the KSP to respond to these properties.

The KSP should process the PIN that is passed in by the Kerberos protocol. The PIN is passed to Kerberos by the OTP credential provider in the Authentication Information package.

For more information about how to write a KSP, see:

Microsoft Windows Cryptographic Next Generation Software Development Kit for Windows Vista, Windows Server 2008, and Windows 7.

The OTP password server

The OTP server validates the OTP tokens and user PIN.

One-time password value validation

The OTP value that is received from the client computer must be validated based on the specific policies set on the OTP validation server. The user name for which the OTP value is validated should map to a unique UPN name.

Short-lived certificate issuance policy

The CA must only issue short-lived certificates under a specified issuance policy. The following table outlines the requirements for short-lived certificate extensions.

Time synchronization between the OTP server and the domain controller

Because this proposed scheme relies on short-lived certificates, the OTP server (which issues the certificate) must use the same time reference as the domain controller. You should consider the time alignment between the OTP server and the domain controller when you set the Validity Period for the short-lived certificate. The time on the client computers also must synchronize with the domain controller and the OTP server.

Requests authentication

To prevent processing data from an unauthenticated source, the OTP server can require that requests come over an authenticated tunnel. In this situation, the OTP value is validated before any other data processing occurs.

Active Directory and OTP user data synchronization

The short-lived certificates that are issued by the OTP server should have the correct UPN value in the Subject Alternative Name extension. This value is used later in the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), when the UPN value is mapped to a user account.

To assure that the correct UPN is added to the certificate, the OTP server should have a one-to-one mapping between the user name that is used to validate the OTP value and the UPN that is added to the short-lived certificate.

Implementation and deployment notes

Notification through DirectAccess

This user notification appears when the user logs on with a user name and password. The notification can be set up through a well-known security identifier (SID) or by enabling authentication mechanism assurance in Active Directory Domain Services (AD DS).

Notification through a well-known security identifier

To implement the user notification through a SID, your system must meet the following requirements:

• Client computers are running Windows 7 or Windows Server 2008 R2

• DirectAccess server is running Windows Server 2008 R2

• OTP server has a CA that is trusted by the user domains

• Short-lived certificates include the following:

  • One or more issuance policy object identifiers (OIDs)

  • Key usage: Digital signature

  • EKU: Smart card logon

The DirectAccess server can use the local well-known security identifier (SID, “This Organization’s Certificate”). Authorization failure due to the absence of this well-known SID in the access token is returned to the client computer by IPsec. The following error message appears on the client computer, which asks the user to provide a smart card credential.

Although this error message indicates that the user is asked to enter smart card credentials, the OTP credential provider also supports KERB_CERTIFICATE_LOGON, because it also is enumerated.

• Kerberos protocol implementation in Windows 7 and Windows Server 2008 R2 issues a ticket for a preconfigured time (10 hours is the default) even if the logon certificate is valid for a shorter time period.

• Windows 7 and Windows Server 2008 R2 support cached credentials so that users can log on to their workstation when a domain controller cannot be contacted. When the user logs on with the short-term certificate, the cached credentials are updated. Windows only supports cached smart card logon, so the user would need to know their personal password to log on offline.

Notification through authentication mechanism assurance

To implement the user notification by enabling authentication mechanism assurance, your system must meet the following requirements:

• Client computers are running Windows 7 or Windows Server 2008 R2

• DirectAccess server is running Windows Server 2008 R2

• The domain functional level in AD DS is set for Windows Server 2008 R2

• The OTP server has a CA that is trusted by the user domains

• Short-lived certificates include the following:

  • One or more issuance policy OIDs

  • Requirements for smart card logon certificates based on the domain functional level of the user domain

Authentication mechanism assurance can be enabled in the domain. The domain administrator maps the issuance policy OIDs, which are in the short-lived certificates that can be issued to a universal group of OTP users. The DirectAccess server can use this group to allow access to the network.

For more information, see the Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide.

If authorization fails because the required universal group does not appear in the access token, a message is returned to the client computer by IPsec. The following error message appears on the client computer, asking the user to lock and then unlock the computer with alternate credentials.

The users need to be told that they should select the OTP credential on the screen when they unlock the computer. For example, if the default logon procedure is to enter a User name and password, you need to educate users to select Other credentials.

To enable the error message to pop up as described in the previous example,the independent software vendor (ISV) application needs to set the following system registry key in Windows during installation: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley\ikeflags to the value of 0x00002000.

Managing OTP tokens

The OTP credential provider and the OTP server must be able to handle OTP-specific interactions, such as when the OTP credential is out-of-sync with the OTP validation server.

Lost or stolen OTP tokens must be handled by the OTP solution provider or the IT administrator.

Certificate management

Use the following guidelines when maintaining short-lived certificates:

• Keep short-lived certificates in a store that is created by the credential provider and that is different from the default user stores. This will prevent an undesirable interaction between credential roaming and autoenrollment. This can also be a file system-based store.

• Keep track of certificates. The OTP credential provider and the KSP may need to remove certificates and key pairs after successful calls.

• Set the domain so that it trusts the OTP server CA certificate.

• Publish the OTP server CA certificate in the NTAuth store for the user’s domain.

• Run KDC certificate revocation checks on client computers. This step requires a minimal domain PKI for the KDC certificate validation and computer certificates.

• Run short-lived certificate revocation check on the KDC. This step requires that the CA publish a certificate revocation list (CRL). The CRL should be long-lived because the CRL is cached on the KDC after first retrieval.

One-time password implementation

Use the following guidelines to implement OTP:

• Offline logon using OTPs can be implemented; however, there is no guidance from Microsoft on this scenario.

• The OTP authentication solution should work with different types of OTP technologies, such as time-based, counter-based, and challenge-response-based OTP algorithms.

• The OTP server must be reachable by the client computers, preferably over a secure channel such as SSL or IPsec.

• The DirectAccess server may be configured to allow access to the OTP server for client authentication purposes.

Appendix A: Workflow example for a DirectAccess scenario

Figure 2  One-time password integration with Windows for remote access by using DirectAccess

An OTP value can be represented by a non-constant value plus any other constant value, such as a user PIN or password. The OTP vendor and the integrator of the solution design and implement this aspect of the solution.

The OTP authentication solution works as follows:

1. User logs on by using a domain user name and password.

2. User requests a resource from corporate network.

3. IPsec attempts to establish a user-authenticated tunnel over a computer-authenticated tunnel.

4. IPsec receives notification from the DirectAccess server that the current Kerberos token is missing the well-known SID or the authentication mechanism assurance. It rejects the request for the user authenticated tunnel.

5. The IPsec (DirectAccess) client computer provides one of the following error messages:

   

6. The user locks the computer by using the Ctrl+Alt+Del keyboard shortcut or clicks the error message, and then selects the OTP credential provider.

The following table outlines the next processes that occur.