Merge remote-tracking branch 'refs/remotes/origin/master' into vs-9329193

windows/keep-secure/TOC.md

@@ -682,6 +682,18 @@
 ###### [Shut down the system](shut-down-the-system.md)
 ###### [Synchronize directory service data](synchronize-directory-service-data.md)
 ###### [Take ownership of files or other objects](take-ownership-of-files-or-other-objects.md)
+### [Smart Cards](smart-card-windows-smart-card-technical-reference.md)
+#### [How Smart Card Sign-in Works in Windows](smart-card-how-smart-card-sign-in-works-in-windows.md)
+##### [Smart Card Architecture](smart-card-architecture.md)
+##### [Certificate Requirements and Enumeration](smart-card-certificate-requirements-and-enumeration.md)
+##### [Smart Card and Remote Desktop Services](smart-card-and-remote-desktop-services.md)
+##### [Smart Cards for Windows Service](smart-card-smart-cards-for-windows-service.md)
+##### [Certificate Propagation Service](smart-card-certificate-propagation-service.md)
+##### [Smart Card Removal Policy Service](smart-card-removal-policy-service.md)
+#### [Smart Card Tools and Settings](smart-card-tools-and-settings.md)
+##### [Smart Cards Debugging Information](smart-card-debugging-information.md)
+##### [Smart Card Group Policy and Registry Settings](smart-card-group-policy-and-registry-settings.md)
+##### [Smart Card Events](smart-card-events.md)
 ### [Trusted Platform Module](trusted-platform-module-overview.md)
 #### [TPM fundamentals](tpm-fundamentals.md)
 #### [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md)
@@ -697,6 +709,13 @@
 #### [How User Account Control works](how-user-account-control-works.md)
 #### [User Account Control security policy settings](user-account-control-security-policy-settings.md)
 #### [User Account Control Group Policy and registry key settings](user-account-control-group-policy-and-registry-key-settings.md)
+### [Virtual Smart Cards](virtual-smart-card-overview.md)
+#### [Understanding and Evaluating Virtual Smart Cards](virtual-smart-card-understanding-and-evaluating.md)
+##### [Get Started with Virtual Smart Cards: Walkthrough Guide](virtual-smart-card-get-started.md)
+##### [Use Virtual Smart Cards](virtual-smart-card-use-virtual-smart-cards.md)
+##### [Deploy Virtual Smart Cards](virtual-smart-card-deploy-virtual-smart-cards.md)
+##### [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md)
+#### [Tpmvscmgr](virtual-smart-card-tpmvscmgr.md)
 ### [Windows Defender Advanced Threat Protection](windows-defender-advanced-threat-protection.md)
 #### [Minimum requirements](minimum-requirements-windows-defender-advanced-threat-protection.md)
 #### [Data storage and privacy](data-storage-privacy-windows-defender-advanced-threat-protection.md)

windows/keep-secure/credential-guard.md

@@ -48,7 +48,8 @@ The following tables provide more information about the hardware, firmware, and
 
 > [!NOTE]  
 > For new computers running Windows 10, Trusted Platform Module (TPM 2.0) must be enabled by default. This requirement is not restated in the tables that follow.<br>
-> If you are an OEM, see the requirements information at [PC OEM requirements for Device Guard and Credential Guard](https://msdn.microsoft.com/library/windows/hardware/mt767514(v=vs.85).aspx).
+> If you are an OEM, see the requirements information at [PC OEM requirements for Device Guard and Credential Guard](https://msdn.microsoft.com/library/windows/hardware/mt767514(v=vs.85).aspx).<br>
+> Starting in Widows 10, 1607, TPM 2.0 is required.
 
 
 ## Credential Guard requirements for baseline protections

windows/keep-secure/smart-card-and-remote-desktop-services.md

@@ -0,0 +1,99 @@
+---
+title: Smart Card and Remote Desktop Services (Windows 10)
+description: This topic for the IT professional describes the behavior of Remote Desktop Services when you implement smart card sign-in.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Smart Card and Remote Desktop Services
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional describes the behavior of Remote Desktop Services when you implement smart card sign-in.
+
+The content in this topic applies to the versions of Windows that are designated in the **Applies To** list at the beginning of this topic. In these versions, smart card redirection logic and **WinSCard** API are combined to support multiple redirected sessions into a single process.
+
+Smart card support is required to enable many Remote Desktop Services scenarios. These include:
+
+-   Using Fast User Switching or Remote Desktop Services. A user is not able to establish a redirected smart card-based remote desktop connection. That is, the connect attempt is not successful in Fast User Switching or from a Remote Desktop Services session.
+
+-   Enabling Encrypting File System (EFS) to locate the user's smart card reader from the Local Security Authority (LSA) process in Fast User Switching or in a Remote Desktop Services session. If EFS is not able to locate the smart card reader or certificate, EFS cannot decrypt user files.
+
+## Remote Desktop Services redirection
+
+In a Remote Desktop scenario, a user is using a remote server for running services, and the smart card is local to the computer that the user is using. In a smart card sign-in scenario, the smart card service on the remote server redirects to the smart card reader that is connected to the local computer where the user is trying to sign in.
+
+![Smart card service redirects to smart card reader](images/sc-image101.png)
+
+**Remote Desktop redirection**
+
+Notes about the redirection model:
+
+1.  This scenario is a remote sign-in session on a computer with Remote Desktop Services. In the remote session (labeled as "Client session"), the user runs **net use /smartcard**.
+
+2.  Arrows represent the flow of the PIN after the user types the PIN at the command prompt until it reaches the user's smart card in a smart card reader that is connected to the Remote Desktop Connection (RDC) client computer.
+
+3.  The authentication is performed by the LSA in session 0.
+
+4.  The CryptoAPI processing is performed in the LSA (Lsass.exe). This is possible because RDP redirector (rdpdr.sys) allows per-session, rather than per-process, context.
+
+5.  The WinScard and SCRedir components, which were separate modules in operating systems earlier than Windows Vista, are now included in one module. The ScHelper library is a CryptoAPI wrapper that is specific to the Kerberos protocol.
+
+6.  The redirection decision is made on a per smart card context basis, based on the session of the thread that performs the SCardEstablishContext call.
+
+7.  Changes to WinSCard.dll implementation were made in Windows Vista to improve smart card redirection.
+
+## RD Session Host server single sign-in experience
+
+As a part of the Common Criteria compliance, the RDC client must be configurable to use Credential Manager to acquire and save the user's password or smart card PIN. Common Criteria compliance requires that applications not have direct access to the user's password or PIN.
+
+Common Criteria compliance requires specifically that the password or PIN never leave the LSA unencrypted. A distributed scenario should allow the password or PIN to travel between one trusted LSA and another, and it cannot be unencrypted during transit.
+
+When smart card-enabled single sign-in (SSO) is used for Remote Desktop Services sessions, users still need to sign in for every new Remote Desktop Services session. However, the user is not prompted for a PIN more than once to establish a Remote Desktop Services session. For example, after the user double-clicks a Microsoft Word document icon that resides on a remote computer, the user is prompted to enter a PIN. This PIN is sent by using a secure channel that the credential SSP has established. The PIN is routed back to the RDC client over the secure channel and sent to Winlogon. The user does not receive any additional prompts for the PIN, unless the PIN is incorrect or there are smart card-related failures.
+
+### Remote Desktop Services and smart card sign-in
+
+Remote Desktop Services enable users to sign in with a smart card by entering a PIN on the RDC client computer and sending it to the RD Session Host server in a manner similar to authentication that is based on user name and password.
+
+In addition, Group Policy settings that are specific to Remote Desktop Services need to be enabled for smart card-based sign-in.
+
+To enable smart card sign-in to a Remote Desktop Session Host (RD Session Host) server, the Key Distribution Center (KDC) certificate must be present on the RDC client computer. If the computer is not in the same domain or workgroup, the following command can be used to deploy the certificate:
+
+**certutil -dspublish NTAuthCA** "*DSCDPContainer*"
+
+The *DSCDPContainer* Common Name (CN) is usually the name of the certification authority.
+
+Example:
+
+**certutil -dspublish NTAuthCA** <*CertFile*> **"CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=engineering,DC=contoso,DC=com"**
+
+For information about this option for the command-line tool, see [-dsPublish](https://technet.microsoft.com/en-us/library/cc732443(v=ws.11).aspx#BKMK_dsPublish).
+
+### Remote Desktop Services and smart card sign-in across domains
+
+To enable remote access to resources in an enterprise, the root certificate for the domain must be provisioned on the smart card. From a computer that is joined to a domain, run the following command at the command line:
+
+**certutil -scroots update**
+
+For information about this option for the command-line tool, see [-SCRoots](https://technet.microsoft.com/en-us/library/cc732443(v=ws.11).aspx#BKMK_SCRoots).
+
+For Remote Desktop Services across domains, the KDC certificate of the RD Session Host server must also be present in the client computer's NTAUTH store. To add the store, run the following command at the command line:
+
+**certutil -addstore -enterprise NTAUTH** <*CertFile*>
+
+Where <*CertFile*> is the root certificate of the KDC certificate issuer.
+
+For information about this option for the command-line tool, see [-addstore](https://technet.microsoft.com/en-us/library/cc732443(v=ws.11).aspx#BKMK_addstore).
+
+> **Note**  If you use the credential SSP on computers running the supported versions of the operating system that are designated in the **Applies To** list at the beginning of this topic: To sign in with a smart card from a computer that is not joined to a domain, the smart card must contain the root certification of the domain controller. A public key infrastructure (PKI) secure channel cannot be established without the root certification of the domain controller.
+
+Sign-in to Remote Desktop Services across a domain works only if the UPN in the certificate uses the following form: <*ClientName*>@<*DomainDNSName*>
+
+The UPN in the certificate must include a domain that can be resolved. Otherwise, the Kerberos protocol cannot determine which domain to contact. You can resolve this issue by enabling GPO X509 domain hints. For more information about this setting, see [Smart Card Group Policy and Registry Settings](smart-card-group-policy-and-registry-settings.md).
+
+## See also
+
+[How Smart Card Sign-in Works in Windows](smart-card-how-smart-card-sign-in-works-in-windows.md)

windows/keep-secure/smart-card-architecture.md

@@ -0,0 +1,337 @@
+---
+title: Smart Card Architecture (Windows 10)
+description: This topic for the IT professional describes the system architecture that supports smart cards in the Windows operating system.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Smart Card Architecture
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional describes the system architecture that supports smart cards in the Windows operating system, including credential provider architecture and the smart card subsystem architecture.
+
+Authentication is a process for verifying the identity of an object or person. When you authenticate an object, such as a smart card, the goal is to verify that the object is genuine. When you authenticate a person, the goal is to verify that you are not dealing with an imposter.
+
+In a networking context, authentication is the act of proving identity to a network application or resource. Typically, identity is proven by a cryptographic operation that uses a key only the user knows (such as with public key cryptography), or a shared key. The server side of the authentication exchange compares the signed data with a known cryptographic key to validate the authentication attempt. Storing the cryptographic keys in a secure central location makes the authentication process scalable and maintainable.
+
+For smart cards, Windows supports a provider architecture that meets the secure authentication requirements and is extensible so that you can include custom credential providers. This topic includes information about:
+
+-   [Credential provider architecture](#credential-provider-architecture)
+
+-   [Smart card subsystem architecture](#smart-card-subsystem-architecture)
+
+<!-- This link probably won't stay current. If it seems useful, it could be un-commented.
+For more information, see [Windows Authentication Architecture](https://technet.microsoft.com/en-us/library/dn751044(v=ws.11).aspx). This topic in the Windows Authentication Technical Overview explains the basic architectural scheme for Windows authentication for past and current versions of Windows.
+-->
+
+## Credential provider architecture
+
+The following table lists the components that are included in the interactive sign-in architecture of the Windows Server and Windows operating systems.
+
+| **Component**               | **Description**   |
+|------------------------------------------------|-----|
+| Winlogon | Provides an interactive sign-in infrastructure.         |
+| Logon UI | Provides interactive UI rendering.   |
+| Credential providers (password and smart card) | Describes credential information and serializing credentials.              |
+| Local Security Authority (LSA)                 | Processes sign-in credentials.       |
+| Authentication packages     | Includes NTLM and the Kerberos protocol. Communicates with server authentication packages to authenticate users. |
+
+Interactive sign-in in Windows begins when the user presses CTRL+ALT+DEL. The CTRL+ALT+DEL key combination is called a secure attention sequence (SAS). To keep other programs and processes from using it, Winlogon registers this sequence during the boot process.
+
+After receiving the SAS, the UI then generates the sign-in tile from the information received from the registered credential providers. The following graphic shows the architecture for credential providers in the Windows operating system.
+
+![Credential provider architecture](images/sc-image201.gif)
+
+**Figure 1**&nbsp;&nbsp;**Credential provider architecture**
+
+Typically, a user who signs in to a computer by using a local account or a domain account must enter a user name and password. These credentials are used to verify the user's identity. For smart card sign-in, a user's credentials are contained on the smart card's security chip. A smart card reader lets the computer interact with the security chip on the smart card. When users sign in with a smart card, they enter a personal identification number (PIN) instead of a user name and password.
+
+Credential providers are in-process COM objects that run on the local system and are used to collect credentials. The Logon UI provides interactive UI rendering, Winlogon provides interactive sign-in infrastructure, and credential providers work with both of these components to help gather and process credentials.
+
+Winlogon instructs the Logon UI to display credential provider tiles after it receives an SAS event. The Logon UI queries each credential provider for the number of credentials it wants to enumerate. Credential providers have the option of specifying one of these tiles as the default. After all providers have enumerated their tiles, the Logon UI displays them to the user. The user interacts with a tile to supply the proper credentials. The Logon UI submits these credentials for authentication.
+
+Combined with supporting hardware, credential providers can extend the Windows operating system to enable users to sign in by using biometrics (for example, fingerprint, retinal, or voice recognition), password, PIN, smart card certificate, or any custom authentication package. Enterprises and IT professionals can develop and deploy custom authentication mechanisms for all domain users, and they may explicitly require users to use this custom sign-in mechanism.
+
+> **Note**&nbsp;&nbsp;Credential providers are not enforcement mechanisms. They are used to gather and serialize credentials. The LSA and authentication packages enforce security.
+
+Credential providers can be designed to support single sign-in (SSO). In this process, they authenticate users to a secure network access point (by using RADIUS and other technologies) for signing in to the computer. Credential providers are also designed to support application-specific credential gathering, and they can be used for authentication to network resources, joining computers to a domain, or to provide administrator consent for User Account Control (UAC).
+
+Multiple credential providers can coexist on a computer.
+
+Credential providers must be registered on a computer running Windows, and they are responsible for:
+
+-   Describing the credential information that is required for authentication.
+
+-   Handling communication and logic with external authentication authorities.
+
+-   Packaging credentials for interactive and network sign-in.
+
+> **Note**&nbsp;&nbsp;The Credential Provider API does not render the UI. It describes what needs to be rendered. <br>Only the password credential provider is available in safe mode.<br>The smart card credential provider is available in safe mode during networking.
+
+## Smart card subsystem architecture
+
+Vendors provide smart cards and smart card readers, and in many cases the vendors are different for the smart card and the smart card reader. Drivers for smart card readers are written to the [Personal Computer/Smart Card (PC/SC) standard](http://www.pcscworkgroup.com/specifications/overview.php). Each smart card must have a Credential Service Provider (CSP) that uses the CryptoAPI interfaces to enable cryptographic operations, and the WinSCard APIs to enable communications with smart card hardware.
+
+### Base CSP and smart card minidriver architecture
+
+Figure 2 illustrates the relationship between the CryptoAPI, CSPs, the Smart Card Base Cryptographic Service Provider (Base CSP), and smart card minidrivers.
+
+![Base CSP and smart card minidriver architecture](images/sc-image203.gif)
+
+**Figure 2**&nbsp;&nbsp;**Base CSP and smart card minidriver architecture**
+
+### Caching with Base CSP and smart card KSP
+
+Smart card architecture uses caching mechanisms to assist in streamlining operations and to improve a user’s access to a PIN.
+
+-   [Data caching](#data-caching): The data cache provides for a single process to minimize smart card I/O operations.
+
+-   [PIN caching](#pin-caching): The PIN cache helps the user from having to reenter a PIN each time the smart card is unauthenticated.
+
+#### Data caching
+
+Each CSP implements the current smart card data cache separately. The Base CSP implements a robust caching mechanism that allows a single process to minimize smart card I/O operations.
+
+The existing global cache works as follows:
+
+1.  The application requests a cryptographic operation. For example, a user certificate is to be read from the smart card.
+
+2.  The CSP checks its cache for the item.
+
+3.  If the item is not found in the cache, or if the item is cached but is not up-to-date, the item is read from the smart card.
+
+4.  After any item has been read from the smart card, it is added to the cache. Any existing out-of-date copy of that item is replaced.
+
+Three types of objects or data are cached by the CSP: pins (for more information, see [PIN caching](#pin-caching)), certificates, and files. If any of the cached data changes, the corresponding object is read from the smart card in successive operations. For example, if a file is written to the smart card, the CSP cache becomes out-of-date for the files, and other processes read the smart card at least once to refresh their CSP cache.
+
+The global data cache is hosted in the Smart Cards for Windows service. Windows includes two public smart card API calls, SCardWriteCache and SCardReadCache. These API calls make global data caching functionality available to applications. Every smart card that conforms to the smart card minidriver specification has a 16-byte card identifier. This value is used to uniquely identify cached data that pertains to a given smart card. The standard Windows GUID type is used. These APIs allow an application to add data to and read data from the global cache.
+
+#### PIN caching
+
+The PIN cache protects the user from entering a PIN every time the smart card is unauthenticated. After a smart card is authenticated, it will not differentiate among host-side applications—any application can access private data on the smart card.
+
+To mitigate this, the smart card enters an exclusive state when an application authenticates to the smart card. However, this means that other applications cannot communicate with the smart card and will be blocked. Therefore, such exclusive connections are minimized. The issue is that a protocol (such as the Kerberos protocol) requires multiple signing operations. Therefore, the protocol requires exclusive access to the smart card over an extended period, or it require multiple authentication operations. This is where the PIN cache is used to minimize exclusive use of the smart card without forcing the user to enter a PIN multiple times.
+
+The following example illustrates how this works. In this scenario, there are two applications: Outlook and Internet Explorer. The applications use smart cards for different purposes.
+
+1.  The user starts Outlook and tries to send a signed e-mail. The private key is on the smart card.
+
+2.  Outlook prompts the user for the smart card PIN. The user enters the correct PIN.
+
+3.  E-mail data is sent to the smart card for the signature operation. The Outlook client formats the response and sends the e-mail.
+
+4.  The user opens Internet Explorer and tries to access a protected site that requires Transport Layer Security (TLS) authentication for the client.
+
+5.  Internet Explorer prompts the user for the smart card PIN. The user enters the correct PIN.
+
+6.  The TLS-related private key operation occurs on the smart card, and the user is authenticated and signed in.
+
+7.  The user returns to Outlook to send another signed e-mail. This time, the user is not prompted for a PIN because the PIN is cached from the previous operation. Similarly, if the user uses Internet Explorer again for another operation, Internet Explorer will not prompt the user for a PIN.
+
+The Base CSP internally maintains a per-process cache of the PIN. The PIN is encrypted and stored in memory. The functions that are used to secure the PIN are RtlEncryptMemory, RtlDecryptMemory, and RtlSecureZeroMemory, which will empty buffers that contained the PIN.
+
+### Smart card selection
+
+The following sections in this topic describe how Windows leverages the smart card architecture to select the correct smart card reader software, provider, and credentials for a successful smart card sign-in:
+
+-   [Container specification levels](#container-specification-levels)
+
+-   [Container operations](#container-operations)
+
+-   [Context flags](#context-flags)
+
+-   [Create a new container in silent context](#create-a-new-container-in-silent-context)
+
+-   [Smart card selection behavior](#smart-card-selection-behavior)
+
+-   [Make a smart card reader match](#make-a-smart-card-reader-match)
+
+-   [Make a smart card match](#make-a-smart-card-match)
+
+-   [Open an existing default container (no reader specified)](#open-an-existing-default-container-no-reader-specified)
+
+-   [Open an existing GUID-named container (no reader specified)](#open-an-existing-guid-named-container-no-reader-specified)
+
+-   [Create a new container (no reader specified)](#create-a-new-container-no-reader-specified)
+
+-   [Delete a container](#delete-a-container)
+
+#### Container specification levels
+
+In response to a CryptAcquireContext call in CryptoAPI, the Base CSP tries to match the container that the caller specifies to a specific smart card and reader. The caller can provide a container name with varying levels of specificity, as shown in the following table, and sorted from most-specific to least-specific requests.
+
+Similarly, in response to a NCryptOpenKey call in CNG, the smart card KSP tries to match the container the same way, and it takes the same container format, as shown in the following table.
+
+> **Note**&nbsp;&nbsp;Before opening a key by using the smart card KSP, a call to NCryptOpenStorageProvider (MS\_SMART\_CARD\_KEY\_STORAGE\_PROVIDER) must be made.
+
+| **Type** | **Name** | **Format** |
+|----------|----------|------------|
+| I | Reader Name and Container Name | \\\\.\\&lt;Reader Name&gt;\\&lt;Container Name&gt; |
+| II | Reader Name and Container Name (NULL) | \\\\.\\&lt;Reader Name&gt; |
+| III | Container Name Only | &lt;Container Name&gt; |
+| IV | Default Container (NULL) Only | NULL |
+
+The Base CSP and smart card KSP cache smart card handle information about the calling process and about the smart cards the process has accessed. When searching for a smart card container, the Base CSP or smart card KSP first checks its cache for the process. If the cached handle is invalid or no match is found, the SCardUIDlg API is called to get the card handle.
+
+#### Container operations
+
+The following three container operations can be requested by using CryptAcquireContext:
+
+1.  Create a new container. (The CNG equivalent of CryptAcquireContext with dwFlags set to CRYPT\_NEWKEYSET is NCryptCreatePersistedKey.)
+
+2.  Open an existing container. (The CNG equivalent of CryptAcquireContext to open the container is NCryptOpenKey.)
+
+3.  Delete a container. (The CNG equivalent of CryptAcquireContext with dwFlags set to CRYPT\_DELETEKEYSET is NCryptDeleteKey.)
+
+The heuristics that are used to associate a cryptographic handle with a particular smart card and reader are based on the container operation requested and the level of container specification used.
+
+The following table shows the restrictions for the container creation operation.
+
+| **Specification**                  | **Restriction**         |
+|------------------------------------|-----------|
+| No silent context                  | Key container creation must always be able to show UI, such as the PIN prompt.   |
+| No overwriting existing containers | If the specified container already exists on the chosen smart card, choose another smart card or cancel the operation. |
+
+#### Context flags
+
+The following table shows the context flags used as restrictions for the container creation operation.
+
+| **Flag**               | **Description**                   |
+|------------------------|------------------------------------------------------|
+| CRYPT\_SILENT          | No UI can be displayed during this operation.        |
+| CRYPT\_MACHINE\_KEYSET | No cached data should be used during this operation. |
+| CRYPT\_VERIFYCONTEXT   | Only public data can be accessed on the smart card.  |
+
+In addition to container operations and container specifications, you must consider other user options, such as the CryptAcquireContext flags, during smart card selection.
+
+> **Important**&nbsp;&nbsp;The CRYPT\_SILENT flag cannot be used to create a new container.
+
+#### Create a new container in silent context
+
+Applications can call the Base CSP with CRYPT\_DEFAULT\_CONTAINER\_OPTIONAL, set the PIN in silent context, and then create a new container in silent context. This operation occurs as follows:
+
+1.  Call CryptAcquireContext by passing the smart card reader name in as a type II container specification level, and specifying the CRYPT\_DEFAULT\_CONTAINER\_OPTIONAL flag.
+
+2.  Call CryptSetProvParam by specifying PP\_KEYEXCHANGE\_PIN or PP\_SIGNATURE\_PIN and a null-terminated ASCII PIN.
+
+3.  Release the context acquired in Step 1.
+
+4.  Call CryptAcquireContext with CRYPT\_NEWKEYSET, and specify the type I container specification level.
+
+5.  Call CryptGenKey to create the key.
+
+#### Smart card selection behavior
+
+In some of the following scenarios, the user can be prompted to insert a smart card. If the user context is silent, this operation fails and no UI is displayed. Otherwise, in response to the UI, the user can insert a smart card or click **Cancel**. If the user cancels the operation, the operation fails. The flow chart in Figure 3 shows the selection steps performed by the Windows operating system.
+
+![Smart card selection process](images/sc-image205.png)
+
+**Figure 3**&nbsp;&nbsp;**Smart card selection behavior**
+
+In general, smart card selection behavior is handled by the SCardUIDlgSelectCard API. The Base CSP interacts with this API by calling it directly. The Base CSP also sends callback functions that have the purpose of filtering and matching candidate smart cards. Callers of CryptAcquireContext provide smart card matching information. Internally, the Base CSP uses a combination of smart card serial numbers, reader names, and container names to find specific smart cards.
+
+Each call to SCardUI \* may result in additional information read from a candidate smart card. The Base CSP smart card selection callbacks cache this information.
+
+#### Make a smart card reader match
+
+For type I and type II container specification levels, the smart card selection process is less complex because only the smart card in the named reader can be considered a match. The process for matching a smart card with a smart card reader is:
+
+1.  Find the requested smart card reader. If it cannot be found, the process fails. (This requires a cache search by reader name.)
+
+2.  If no smart card is in the reader, the user is prompted to insert a smart card. (This is only in non-silent mode; if the call is made in silent mode, it will fail.)
+
+3.  For container specification level II only, the name of the default container on the chosen smart card is determined.
+
+4.  To open an existing container or delete an existing container, find the specified container. If the specified container cannot be found on this smart card, the user is prompted to insert a smart card.
+
+5.  If the system attempts to create a new container, if the specified container already exists on this smart card, the process fails.
+
+#### Make a smart card match
+
+For container specification levels III and IV, a broader method is used to match an appropriate smart card with a user context, because multiple cached smart cards might meet the criteria provided.
+
+#### Open an existing default container (no reader specified)
+
+> **Note**&nbsp;&nbsp;This operation requires that you use the smart card with the Base CSP.
+
+1.  For each smart card that has been accessed by the Base CSP and the handle and container information are cached, the Base CSP looks for a valid default container. An operation is attempted on the cached SCARDHANDLE to verify its validity. If the smart card handle is not valid, the Base CSP continues to search for a new smart card.
+
+2.  If a matching smart card is not found in the Base CSP cache, the Base CSP calls to the smart card subsystem. SCardUIDlgSelectCard() is used with an appropriate callback filter to find a matching smart card with a valid default container.
+
+#### Open an existing GUID-named container (no reader specified)
+
+> **Note**&nbsp;&nbsp;This operation requires that you use the smart card with the Base CSP.
+
+1.  For each smart card that is already registered with the Base CSP, search for the requested container. Attempt an operation on the cached SCARDHANDLE to verify its validity. If the smart card handle is not valid, the smart card's serial number is passed to the SCardUI \* API to continue searching for this specific smart card (rather than only a general match for the container name).
+
+2.  If a matching smart card is not found in the Base CSP cache, a call is made to the smart card subsystem. SCardUIDlgSelectCard() is used with an appropriate callback filter to find a matching smart card with the requested container. Or, if a smart card serial number resulted from the search in Step 1, the callback filter attempts to match the serial number, not the container name.
+
+#### Create a new container (no reader specified)
+
+> **Note**&nbsp;&nbsp;This operation requires that you use the smart card with the Base CSP.
+
+If the PIN is not cached, no CRYPT\_SILENT is allowed for the container creation because the user must be prompted for a PIN, at a minimum.
+
+For other operations, the caller may be able to acquire a "verify" context against the default container (CRYPT\_DEFAULT\_CONTAINER\_OPTIONAL) and then make a call with CryptSetProvParam to cache the user PIN for subsequent operations.
+
+1.  For each smart card already known by the CSP, refresh the stored SCARDHANDLE and make the following checks:
+
+    1.  If the smart card has been removed, continue the search.
+
+    2.  If the smart card is present, but it already has the named container, continue the search.
+
+    3.  If the smart card is available, but a call to CardQueryFreeSpace indicates that the smart card has insufficient storage for an additional key container, continue the search.
+
+    4.  Otherwise, use the first available smart card that meets the above criteria for the container creation.
+
+2.  If a matching smart card is not found in the CSP cache, make a call to the smart card subsystem. The callback that is used to filter enumerated smart cards verifies that a candidate smart card does not already have the named container, and that CardQueryFreeSpace indicates the smart card has sufficient space for an additional container. If no suitable smart card is found, the user is prompted to insert a smart card.
+
+#### Delete a container
+
+1.  If the specified container name is NULL, the default container is deleted. Deleting the default container causes a new default container to be selected arbitrarily. For this reason, this operation is not recommended.
+
+2.  For each smart card already known by the CSP, refresh the stored SCARDHANDLE and make the following checks:
+
+    1.  If the smart card does not have the named container, continue the search.
+
+    2.  If the smart card has the named container, but the smart card handle is no longer valid, store the serial number of the matching smart card and pass it to SCardUI \*.
+
+3.  If a matching smart card is not found in the CSP cache, make a call to the smart card subsystem. The callback that is used to filter enumerated smart cards should verify that a candidate smart card has the named container. If a serial number was provided as a result of the previous cache search, the callback should filter enumerated smart cards on serial number rather than on container matches. If the context is non-silent and no suitable smart card is found, display UI that prompts the user to insert a smart card.
+
+### Base CSP and KSP-based architecture in Windows
+
+Figure 4 shows the Cryptography architecture that is used by the Windows operating system.
+
+![Cryptography architecture](images/sc-image206.gif)
+
+**Figure 4**&nbsp;&nbsp;**Cryptography architecture**
+
+### Base CSP and smart card KSP properties in Windows
+
+The following properties are supported in versions of Windows designated in the **Applies To** list at the beginning of this topic.
+
+> **Note**&nbsp;&nbsp;The API definitions are located in WinCrypt.h and WinSCard.h.
+
+| **Property**          | **Description**  |
+|-----------------------|------------------|
+| PP\_USER\_CERTSTORE   | -   Used to return an HCERTSTORE that contains all user certificates on the smart card<br>- Read-only (used only by CryptGetProvParam)<br>- Caller responsible for closing the certificate store<br>- Certificate encoded using PKCS\_7\_ASN\_ENCODING or X509\_ASN\_ENCODING<br>- CSP should set KEY\_PROV\_INFO on certificates<br>- Certificate store should be assumed to be an in-memory store<br>- Certificates should have a valid CRYPT\_KEY\_PROV\_INFO as a property |
+| PP\_ROOT\_CERTSTORE   | -   Read and Write (used by CryptGetProvParam and CryptSetProvParam)<br>- Used to write a collection of root certificates to the smart card or return HCERTSTORE, which contains root certificates from the smart card<br>- Used primarily for joining a domain by using a smart card<br>- Caller responsible for closing the certificate store |
+| PP\_SMARTCARD\_READER | -   Read-only (used only by CryptGetProvParam)<br>- Returns the smart card reader name as an ANSI string that is used to construct a fully qualified container name (that is, a smart card reader plus a container)    |
+| PP\_SMARTCARD\_GUID   | -   Return smart card GUID (also known as a serial number), which should be unique for each smart card<br>- Used by the certificate propagation service to track the source of a root certificate|
+| PP\_UI\_PROMPT        | -   Used to set the search string for the SCardUIDlgSelectCard card insertion dialog box<br>- Persistent for the entire process when it is set<br>- Write-only (used only by CryptSetProvParam) |
+
+### Implications for CSPs in Windows
+
+Credential Service Providers (CSPs), including custom smart card CSPs, continue to be supported but this approach is not recommended. Using the existing Base CSP and smart card KSP with the smart card minidriver model for smart cards provides significant benefits in terms of performance, and PIN and data caching. One minidriver can be configured to work under CryptoAPI and CNG layers. This provides benefits from enhanced cryptographic support, including elliptic curve cryptography and AES.
+
+If a smart card is registered by a CSP and a smart card minidriver, the one that was installed most recently will be used to communicate with the smart card.
+
+### Write a smart card minidriver, CSP, or KSP
+
+CSPs and KSPs are meant to be written only if specific functionality is not available in the current smart card minidriver architecture. For example, the smart card minidriver architecture supports hardware security modules, so a minidriver could be written for a hardware security module, and a CSP or KSP may not be required unless it is needed to support algorithms that are not implemented in the Base CSP or smart card KSP.
+
+For more information about how to write a smart card minidriver, CSP, or KSP, see [Smart Card Minidrivers](https://msdn.microsoft.com/windows/hardware/drivers/smartcard/smart-card-minidrivers).

windows/keep-secure/smart-card-certificate-propagation-service.md

@@ -0,0 +1,75 @@
+---
+title: Certificate Propagation Service (Windows 10)
+description: This topic for the IT professional describes the certificate propagation service (CertPropSvc), which is used in smart card implementation.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Certificate Propagation Service
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional describes the certificate propagation service (CertPropSvc), which is used in smart card implementation.
+
+The certificate propagation service activates when a signed-in user inserts a smart card in a reader that is attached to the computer. This action causes the certificate to be read from the smart card. The certificates are then added to the user's Personal store. Certificate propagation service actions are controlled by using Group Policy. For more information, see [Smart Card Group Policy and Registry Settings](smart-card-group-policy-and-registry-settings.md).
+
+> **Note**  The certificate propagation service must be running for smart card Plug and Play to work.
+
+The following figure shows the flow of the certificate propagation service. The action begins when a signed-in user inserts a smart card.
+
+1.  The arrow labeled **1** indicates that the Service Control Manager (SCM) notifies the certificate propagation service (CertPropSvc) when a user signs in, and CertPropSvc begins to monitor the smart cards in the user session.
+
+2.  The arrow labeled **R** represents the possibility of a remote session and the use of smart card redirection.
+
+3.  The arrow labeled **2** indicates the certification to the reader.
+
+4.  The arrow labeled **3** indicates the access to the certificate store during the client session.
+
+**Certificate propagation service**
+
+![Certificate propagation service](images/sc-image302.gif)
+
+1.  A signed-in user inserts a smart card.
+
+2.  CertPropSvc is notified that a smart card was inserted.
+
+3.  CertPropSvc reads all certificates from all inserted smart cards. The certificates are written to the user's personal certificate store.
+
+> **Note**  The certificate propagation service is started as a Remote Desktop Services dependency.
+
+Properties of the certificate propagation service include:
+
+-   CERT\_STORE\_ADD\_REPLACE\_EXISTING\_INHERIT\_PROPERTIES adds certificates to a user's Personal store.
+
+-   If the certificate has the CERT\_ENROLLMENT\_PROP\_ID property (as defined by wincrypt.h), it filters empty requests and places them in the current user's request store, but it does not propagate them to the user's Personal store.
+
+-   The service does not propagate any computer certificates to a user's Personal store or propagate user certificates to a computer store.
+
+-   The service propagates certificates according to Group Policy options that are set, which may include:
+
+    -   **Turn on certificate propagation from the smart card** specifies whether a user's certificate should be propagated.
+
+    -   **Turn on root certificate propagation from smart card** specifies whether root certificates should be propagated.
+
+    -   **Configure root certificate cleanup** specifies how root certificates are removed.
+
+## Root certificate propagation service
+
+Root certificate propagation is responsible for the following smart card deployment scenarios when public key infrastructure (PKI) trust has not yet been established:
+
+-   Joining the domain
+
+-   Accessing a network remotely
+
+In both cases, the computer is not joined to a domain, and therefore, trust is not being managed by Group Policy. However, the objective is to authenticate to a remote server, such as the domain controller. Root certificate propagation provides the ability to use the smart card to include the missing trust chain.
+
+When the smart card is inserted, the certificate propagation service propagates any root certificates on the card to the trusted smart card root computer certificate stores. This process establishes a trust relationship with the enterprise resources. You may also use a subsequent cleanup action when the user's smart card is removed from the reader, or when the user signs out. This is configurable with Group Policy. For more information, see [Smart Card Group Policy and Registry Settings](smart-card-group-policy-and-registry-settings.md).
+
+For more information about root certificate requirements, see [Smart card root certificate requirements for use with domain sign-in](smart-card-certificate-requirements-and-enumeration.md#smart-card-root-certificate-requirements-for-use-with-domain-sign-in).
+
+## See also
+
+[How Smart Card Sign-in Works in Windows](smart-card-how-smart-card-sign-in-works-in-windows.md)

windows/keep-secure/smart-card-certificate-requirements-and-enumeration.md

@@ -0,0 +1,317 @@
+---
+title: Certificate Requirements and Enumeration (Windows 10)
+description: This topic for the IT professional and smart card developers describes how certificates are managed and used for smart card sign-in.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Certificate Requirements and Enumeration
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional and smart card developers describes how certificates are managed and used for smart card sign-in.
+
+When a smart card is inserted, the following steps are performed.
+
+> **Note**  Unless otherwise mentioned, all operations are performed silently (CRYPT\_SILENT is passed to CryptAcquireContext).
+
+1.  The smart card resource manager database searches for the smart card's cryptographic service provider (CSP).
+
+2.  A qualified container name is constructed by using the smart card reader name, and it is passed to the CSP. The format is *\\\\.\\<Reader name>*\\
+
+3.  CryptAcquireContext is called to retrieve a context to the default container. If a failure occurs, the smart card will be unusable for smart card sign-in.
+
+4.  The name of the container is retrieved by using the PP\_CONTAINER parameter with CryptGetProvParam.
+
+5.  Using the context acquired in Step 3, the CSP is queried for the PP\_USER\_CERTSTORE parameter (added in Windows Vista). For more information, see [Smart Card Architecture](smart-card-architecture.md). If the operation is successful, the name of a certificate store is returned, and the program flow skips to Step 8.
+
+6.  If the operation in Step 5 fails, the default container context from Step 3 is queried for the AT\_KEYEXCHANGE key.
+
+7.  The certificate is then queried from the key context by using KP\_CERTIFICATE. The certificate is added to an in-memory certificate store.
+
+8.  For each certificate in the certificate store from Step 5 or Step 7, the following checks are performed:
+
+    1.  The certificate must be valid, based on the computer system clock (not expired or valid with a future date).
+
+    2.  The certificate must not be in the AT\_SIGNATURE part of a container.
+
+    3.  The certificate must have a valid user principal name (UPN).
+
+    4.  The certificate must have the digital signature key usage.
+
+    5.  The certificate must have the smart card logon EKU.
+
+    Any certificate that meets these requirements is displayed to the user with the certificate's UPN (or e-mail address or subject, depending on the presence of the certificate extensions).
+
+    > **Note**  These requirements are the same as those in Windows Server 2003, but they are performed before the user enters the PIN. You can override many of them by using Group Policy settings.
+
+9.  The process then chooses a certificate, and the PIN is entered.
+
+10.  LogonUI.exe packages the information and sends it to Lsass.exe to process the sign-in attempt.
+
+11.  If successful, LogonUI.exe closes. This causes the context acquired in Step 3 to be released.
+
+## About Certificate support for compatibility
+
+Although versions of Windows earlier than Windows Vista include support for smart cards, the types of certificates that smart cards can contain are limited. The limitations are:
+
+-   Each certificate must have a user principal name (UPN) and the smart card sign-in object identifier (also known as OID) in the enhanced key usage (EKU) attribute field. There is a Group Policy setting, Allow ECC certificates to be used for logon and authentication, to make the EKU optional.
+
+-   Each certificate must be stored in the AT\_KEYEXCHANGE portion of the default CryptoAPI container, and non-default CryptoAPI containers are not supported.
+
+The following table lists the certificate support in older Windows operating system versions.
+
+| **Operating system**                  | **Certificate support**     |
+|---------------------------------------|----------------------------------------------------------------------------------------------------------|
+| Windows Server 2008 R2 and Windows 7  | Support for smart card sign-in with ECC-based certificates. ECC smart card sign-in is enabled through Group Policy.<br><br>ECDH\_P256<br>ECDH<br>Curve P-256 from FIPS 186-2<br><br>ECDSA\_P256<br>ECDSA<br>Curve P-256 from FIPS 186-2<br><br>ECDH\_P384<br>ECDH<br>Curve P-384 from FIPS 186-2<br><br>ECDH\_P521<br>ECDH<br>Curve P-521 from FIPS 186-2<br><br>ECDSA\_P256<br>ECDH<br>Curve P-256 from FIPS 186-2<br><br>ECDSA\_P384<br>ECDSA<br>Curve P-384 from FIPS 186-2<br><br>ECDSA\_P521<br>ECDSA<br>Curve P-384 from FIPS 186-2 |
+| Windows Server 2008 and Windows Vista | Valid certificates are enumerated and displayed from all smart cards and presented to the user.<br>Keys are no longer restricted to the default container, and certificates in different containers can be chosen.<br>Elliptic curve cryptography (ECC)-based certificates are not supported for smart card sign-in                 |
+
+## Smart card sign-in flow in Windows
+
+Most issues during authentication occur because of session behavior changes. When changes occur, the Local Security Authority (LSA) does not reacquire the session context; it relies instead on the Cryptographic Service Provider to handle the session change.
+
+In the supported versions of Windows designated in the **Applies To** list at the beginning of this topic, client certificates that do not contain a UPN in the **subjectAltName** (SAN) field of the certificate can be enabled for sign-in, which supports a wider variety of certificates and supports multiple sign-in certificates on the same card.
+
+Support for multiple certificates on the same card is enabled by default. New certificate types must be enabled through Group Policy.
+
+If you enable the **Allow signature keys valid for Logon** credential provider policy, any certificates that are available on the smart card with a signature-only key are listed on the sign-in screen. This allows users to select their sign-in experience. If the policy is disabled or not configured, smart card signature-key-based certificates are not listed on the sign-in screen.
+
+The following diagram illustrates how smart card sign-in works in the supported versions of Windows.
+
+![Smart card sign-in flow](images/sc-image402.png)
+
+**Smart card sign-in flow**
+
+Following are the steps that are performed during a smart card sign-in:
+
+1.  Winlogon requests the sign-in UI credential information.
+
+2.  Asynchronously, smart card resource manager starts, and the smart card credential provider does the following:
+
+    1.  Gets credential information (a list of known credentials, or if no credentials exist, the smart card reader information that Windows detected).
+
+    2.  Gets a list of smart card readers (by using the WinSCard API) and the list of smart cards inserted in each of them.
+
+    3.  Enumerates each card to verify that a sign-in certificate that is controlled by Group Policy is present. If the certificate is present, the smart card credential provider copies it into a temporary, secure cache on the computer or terminal.
+
+    > **Note**&nbsp;&nbsp;Smartcard cache entries are created for certificates with a subject name or with a subject key identifier. If the certificate has a subject name, it is stored with an index that is based on the subject name and certificate issuer. If another certificate with the same subject name and certificate issuer is used, it will replace the existing cached entry. A change in this behavior after Windows Vista, allows for the condition when the certificate does not have a subject name, the cache is created with an index that is based on the subject key identifier and certificate issuer. If another certificate has the same the subject key identifier and certificate issuer, the cache entry is replaced. When certificates have neither a subject name nor subject key identifier, a cached entry is not created.
+
+    4.  Notifies the sign-in UI that it has new credentials.
+
+3.  The sign-in UI requests the new credentials from the smart card credential provider. As a response, the smart card credential provider provides each sign-in certificate to the sign-in UI, and corresponding sign-in tiles are displayed. The user selects a smart card-based sign-in certificate tile, and Windows displays a PIN dialog box.
+
+4.  The user enters the PIN, and then presses ENTER. The smart card credential provider encrypts the PIN.
+
+5.  The credential provider that resides in the LogonUI system collects the PIN. As part of packaging credentials in the smart card credential provider, the data is packaged in a KERB\_CERTIFICATE\_LOGON structure. The main contents of the KERB\_CERTIFICATE\_LOGON structure are the smart card PIN, CSP data (such as reader name and container name), user name, and domain name. User name is required if the sign-in domain is not in the same forest because it enables a certificate to be mapped to multiple user accounts.
+
+6.  The credential provider wraps the data (such as the encrypted PIN, container name, reader name, and card key specification) and sends it back to LogonUI.
+
+7.  Winlogon presents the data from LogonUI to the LSA with the user information in LSALogonUser.
+
+8.  LSA calls the Kerberos authentication package (Kerberos SSP) to create a Kerberos authentication service request (KRB\_AS\_REQ), which containing a preauthenticator (as specified in RFC 4556: [Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)](http://www.ietf.org/rfc/rfc4556.txt)).
+
+    If the authentication is performed by using a certificate that uses a digital signature, the preauthentication data consists of the user's public certificate and the certificate that is digitally signed with the corresponding private key.<br>If the authentication is performed by using a certificate that uses key encipherment, the preauthentication data consists of the user's public certificate and the certificate that is encrypted with the corresponding private key.
+
+9.  To sign the request digitally (as per RFC 4556), a call is made to the corresponding CSP for a private key operation. Because the private key in this case is stored in a smart card, the smart card subsystem is called, and the necessary operation is completed. The result is sent back to the Kerberos security support provider (SSP).
+
+10.  The Kerberos SSP sends an authentication request for a ticket-granting-ticket (TGT) (per RFC 4556) to the Key Distribution Center (KDC) service that runs on a domain controller.
+
+11.  The KDC finds the user's account object in Active Directory Domain Services (AD DS), as detailed in [Client certificate requirements and mappings](#client-certificate-requirements-and-mappings), and uses the user's certificate to verify the signature.
+
+12.  The KDC validates the user's certificate (time, path, and revocation status) to ensure that the certificate is from a trusted source. The KDC uses CryptoAPI to build a certification path from the user's certificate to a root certification authority (CA) certificate that resides in the root store on the domain controller. The KDC then uses CryptoAPI to verify the digital signature on the signed authenticator that was included in the preauthentication data fields. The domain controller verifies the signature and uses the public key from the user's certificate to prove that the request originated from the owner of the private key that corresponds to the public key. The KDC also verifies that the issuer is trusted and appears in the NTAUTH certificate store.
+
+13.  The KDC service retrieves user account information from AD DS. The KDC constructs a TGT, which is based on the user account information that it retrieves from AD DS. The TGT’s authorization data fields include the user's security identifier (SID), the SIDs for universal and global domain groups to which the user belongs, and (in a multidomain environment) the SIDs for any universal groups of which the user is a member.
+
+14.  The domain controller returns the TGT to the client as part of the KRB\_AS\_REP response.
+
+    > **Note**&nbsp;&nbsp;The KRB\_AS\_REP packet consists of:
+    >- Privilege attribute certificate (PAC)
+    >- User's SID
+    >- SIDs of any groups of which the user is a member
+    >- A request for ticket-granting service (TGS)
+    >- Preauthentication data
+
+    TGT is encrypted with the master key of the KDC, and the session key is encrypted with a temporary key. This temporary key is derived based on RFC 4556. Using CryptoAPI, the temporary key is decrypted. As part of the decryption process, if the private key is on a smart card, a call is made to the smart card subsystem by using the specified CSP to extract the certificate corresponding to the user's public key. (Programmatic calls for the certificate include CryptAcquireContext, CryptSetProvParam with the PIN, CryptgetUserKey, and CryptGetKeyParam.) After the temporary key is obtained, the Kerberos SSP decrypts the session key.
+
+15.  The client validates the reply from the KDC (time, path, and revocation status). It first verifies the KDC's signature by the construction of a certification path from the KDC's certificate to a trusted root CA, and then it uses the KDC's public key to verify the reply signature.
+
+16.  Now that a TGT has been obtained, the client obtains a service ticket, which is used to sign in to the local computer.
+
+17.  With success, LSA stores the tickets and returns a success message to LSALogonUser. After this success message is issued, user profile for the device is selected and set, Group Policy refresh is instantiated, and other actions are performed.
+
+18.  After the user profile is loaded, the Certification Propagation Service (CertPropSvc) detects this event, reads the certificates from the smart card (including the root certificates), and then populates them into the user's certificate store (MYSTORE).
+
+19.  CSP to smart card resource manager communication happens on the LRPC Channel.
+
+20.  On successful authentication, certificates are propagated to the user's store asynchronously by the Certificate Propagation Service (CertPropSvc).
+
+21.  When the card is removed, certificates in the temporary secure cache store are removed. The Certificates are no longer available for sign-in, but they remain in the user's certificate store.
+
+> **Note**&nbsp;&nbsp;A SID is created for each user or group at the time a user account or a group account is created within the local security accounts database or within AD DS. The SID never changes, even if the user or group account is renamed.
+
+For more information about the Kerberos protocol, see [Microsoft Kerberos](https://msdn.microsoft.com/library/windows/desktop/aa378747(v=vs.85).aspx).
+
+By default, the KDC verifies that the client's certificate contains the smart card client authentication EKU szOID\_KP\_SMARTCARD\_LOGON. However, if enabled, the **Allow certificates with no extended key usage certificate attribute** Group Policy setting allows the KDC to not require the SC-LOGON EKU. SC-LOGON EKU is not required for account mappings that are based on the public key.
+
+## KDC certificate
+
+Active Directory Certificate Services provides three kinds of certificate templates:
+
+-   Domain controller
+
+-   Domain controller authentication
+
+-   Kerberos authentication
+
+Depending on the configuration of the domain controller, one of these types of certificates is sent as a part of the AS\_REP packet.
+
+## Client certificate requirements and mappings
+
+Certificate requirements are listed by versions of the Windows operating system. Certificate mapping describes how information from the certificate is mapped to the user account.
+
+### Certificate requirements
+
+The smart card certificate has specific format requirements when it is used with Windows XP and earlier operating systems. You can enable any certificate to be visible for the smart card credential provider.
+
+| **Component**     | **Requirements for Windows 8.1, Windows 8, Windows 7, and Windows Vista**          | **Requirements for Windows XP**  |
+|--------------------------------------|--------------------------------|------|
+| CRL distribution point location      | Not required              | The location must be specified, online, and available, for example:<br>\[1\]CRL Distribution Point<br>Distribution Point Name:<br>Full Name:<br>URL=http://server1.contoso.com/CertEnroll/caname.crl                   |
+| Key usage         | Digital signature         | Digital signature                |
+| Basic constraints | Not required              | \[Subject Type=End Entity, Path Length Constraint=None\] (Optional)    |
+| Enhanced key usage (EKU)             | The smart card sign-in object identifier is not required.<br><br>**Note**&nbsp;&nbsp;If an EKU is present, it must contain the smart card sign-in EKU. Certificates with no EKU can be used for sign-in. | -   Client Authentication (1.3.6.1.5.5.7.3.2)<br>The client authentication object identifier is required only if a certificate is used for SSL authentication.<br><br>- Smart Card Sign-in (1.3.6.1.4.1.311.20.2.2)   |
+| Subject alternative name             | E-mail ID is not required for smart card sign-in.               | Other Name: Principal Name=(UPN), for example:<br>UPN=user1@contoso.com<br>The UPN OtherName object identifier is 1.3.6.1.4.1.311.20.2.3.<br>The UPN OtherName value must be an ASN1-encoded UTF8 string.                |
+| Subject           | Not required              | Distinguished name of user. This field is a mandatory extension, but the population of this field is optional.                  |
+| Key exchange (AT\_KEYEXCHANGE field) | Not required for smart card sign-in certificates if a Group Policy setting is enabled. (By default, Group Policy settings are not enabled.) | Not required  |
+| CRL               | Not required              | Not required  |
+| UPN               | Not required              | Not required  |
+| Notes             | You can enable any certificate to be visible for the smart card credential provider.                  | There are two predefined types of private keys. These keys are Signature Only (AT\_SIGNATURE) and Key Exchange (AT\_KEYEXCHANGE). Smart card sign-in certificates must have a Key Exchange (AT\_KEYEXCHANGE) private key type. |
+
+### Client certificate mappings
+
+Certificate mapping is based on the UPN that is contained in the subjectAltName (SAN) field of the certificate. Client certificates that do not contain information in the SAN field are also supported.
+
+SSL/TLS can map certificates that do not have SAN, and the mapping is done by using the AltSecID attributes on client accounts. The X509 AltSecID, which is used by SSL/TLS client authentication is of the form "X509: &lt;I&gt;"*&lt;Issuer Name&gt;*"&lt;S&gt;"*&lt;Subject Name&gt;*. The *&lt;Issuer Name&gt;* and *&lt;Subject Name&gt;* are taken from the client certificate, with '\\r' and '\\n' replaced with ','.
+
+**Certificate revocation list distribution points**
+
+![Certificate revocation list distribution points](images/sc-image403.png)
+
+**UPN in Subject Alternative Name field**
+
+![UPN in Subject Alternative Name field](images/sc-image404.png)
+
+**Subject and Issuer fields**
+
+![Subject and Issuer fields](images/sc-image405.png)
+
+This account mapping is supported by the KDC in addition to six other mapping methods. The following figure demonstrates a flow of user account mapping logic that is used by the KDC.
+
+**High-level flow of certificate processing for sign-in**
+
+![High-level flow of certificate processing for sign-in](images/sc-image406.png)
+
+The certificate object is parsed to look for content to perform user account mapping.
+
+-   When a user name is provided with the certificate, the user name is used to locate the account object. This operation is the fastest, because string matching occurs.
+
+-   When only the certificate object is provided, a series of operations are performed to locate the user name to map the user name to an account object.
+
+-   When no domain information is available for authentication, the local domain is used by default. If any other domain is to be used for lookup, a domain name hint should be provided to perform the mapping and binding.
+
+Mapping based on generic attributes is not possible because there is no generic API to retrieve attributes from a certificate. Currently, the first method that locates an account successfully stops the search. But a configuration error occurs if two methods map the same certificate to different user accounts when the client does not supply the client name through the mapping hints.
+
+The following figure illustrates the process of mapping user accounts for sign-in in the directory by viewing various entries in the certificate.
+
+**Certificate processing logic**
+
+![Certificate processing logic](images/sc-image407.png)
+
+NT\_AUTH policy is best described in the CERT\_CHAIN\_POLICY\_NT\_AUTH parameter section of the CertVerifyCertificateChainPolicy function. For more information, see [CertVerifyCertificateChainPolicy](https://msdn.microsoft.com/library/aa377163.aspx).
+
+## Smart card sign-in for a single user with one certificate into multiple accounts
+
+A single user certificate can be mapped to multiple accounts. For example, a user might be able to sign in to a user account and also to sign in as a domain administrator. The mapping is done by using the constructed AltSecID based on attributes from client accounts. For information about how this mapping is evaluated, see [Client certificate requirements and mappings](#client-certificate-requirements-and-mappings).
+
+> **Note**&nbsp;&nbsp;Because each account has a different user name, we recommend that you enable the **Allow user name hint** Group Policy setting (**X509HintsNeeded** registry key) to provide the optional fields that allow users to enter their user names and domain information to sign in.
+
+Based on the information that is available in the certificate, the sign-in conditions are:
+
+1.  If no UPN is present in the certificate:
+
+    1.  Sign-in can occur in the local forest or in another forest if a single user with one certificate needs to sign in to different accounts.
+
+    2.  A hint must be supplied if mapping is not unique (for example, if multiple users are mapped to the same certificate).
+
+2.  If a UPN is present in the certificate:
+
+    1.  The certificate cannot be mapped to multiple users in the same forest.
+
+    2.  The certificate can be mapped to multiple users in different forests. For a user to sign in to other forests, an X509 hint must be supplied to the user.
+
+## Smart card sign-in for multiple users into a single account
+
+A group of users might sign in to a single account (for example, an administrator account). For that account, user certificates are mapped so that they are enabled for sign-in.
+
+Several distinct certificates can be mapped to a single account. For this to work properly, the certificate cannot have UPNs.
+
+For example, if Certificate1 has CN=CNName1, Certificate2 has CN=User1, and Certificate3 has CN=User2, the AltSecID of these certificates can be mapped to a single account by using the Active Directory Users and Computers name mapping.
+
+## Smart card sign-in across forests
+
+For account mapping to work across forests, particularly in cases where there is not enough information available on the certificate, the user might enter a hint in the form of a user name, such as *domain\\user*, or a fully qualified UPN such as *user@contoso.com*.
+
+> **Note**&nbsp;&nbsp;For the hint field to appear during smart card sign-in, the **Allow user name hint** Group Policy setting (**X509HintsNeeded** registry key) must be enabled on the client.
+
+## OCSP support for PKINIT
+
+Online Certificate Status Protocol (OCSP), which is defined in RFC 2560, enables applications to obtain timely information about the revocation status of a certificate. Because OCSP responses are small and well bound, constrained clients might want to use OCSP to check the validity of the certificates for Kerberos on the KDC, to avoid transmission of large CRLs, and to save bandwidth on constrained networks. For information about CRL registry keys, see [Smart Card Group Policy and Registry Settings](smart-card-group-policy-and-registry-settings.md).
+
+The KDCs in Windows attempt to get OCSP responses and use them when available. This behavior cannot be disabled. CryptoAPI for OCSP caches OCSP responses and the status of the responses. The KDC supports only OCSP responses for the signer certificate.
+
+Windows client computers attempt to request the OCSP responses and use them in the reply when they are available. This behavior cannot be disabled.
+
+## Smart card root certificate requirements for use with domain sign-in
+
+For sign-in to work in a smart card-based domain, the smart card certificate must meet the following conditions:
+
+-   The KDC root certificate on the smart card must have an HTTP CRL distribution point listed in its certificate.
+
+-   The smart card sign-in certificate must have the HTTP CRL distribution point listed in its certificate.
+
+-   The CRL distribution point must have a valid CRL published and a delta CRL, if applicable, even if the CRL distribution point is empty.
+
+-   The smart card certificate must contain one of the following:
+
+    -   A subject field that contains the DNS domain name in the distinguished name. If it does not, resolution to an appropriate domain fails, so Remote Desktop Services and the domain sign-in with the smart card fail.
+
+    -   A UPN where the domain name resolves to the actual domain. For example, if the domain name is Engineering.Corp.Contoso, the UPN is username@engineering.corp.contoso.com. If any part of the domain name is omitted, the Kerberos client cannot find the appropriate domain.
+
+Although the HTTP CRL distribution points are on by default in Windows Server 2008, subsequent versions of the Windows Server operating system do not include HTTP CRL distribution points. To allow smart card sign-in to a domain in these versions, do the following:
+
+1.  Enable HTTP CRL distribution points on the CA.
+
+2.  Restart the CA.
+
+3.  Reissue the KDC certificate.
+
+4.  Issue or reissue the smart card sign-in certificate.
+
+5.  Propagate the updated root certificate to the smart card that you want to use for the domain sign-in.
+
+The workaround is to enable the **Allow user name hint** Group Policy setting (**X509HintsNeeded** registry key), which allows the user to supply a hint in the credentials user interface for domain sign-in.
+
+If the client computer is not joined to the domain or if it is joined to a different domain, the client computer can resolve the server domain only by looking at the distinguished name on the certificate, not the UPN. For this scenario to work, the certificate requires a full subject, including DC=*&lt;DomainControllerName&gt;*, for domain name resolution.
+
+To deploy root certificates on a smart card for the currently joined domain, you can use the following command:
+
+**certutil -scroots update**
+
+For more information about this option for the command-line tool, see [-SCRoots](https://technet.microsoft.com/en-us/library/cc732443(v=ws.11).aspx#BKMK_SCRoots).
+
+## See also
+
+[How Smart Card Sign-in Works in Windows](smart-card-how-smart-card-sign-in-works-in-windows.md)
+

windows/keep-secure/smart-card-debugging-information.md

@@ -0,0 +1,239 @@
+---
+title: Smart Cards Debugging Information (Windows 10)
+description: This topic explains tools and services that smart card developers can use to help identify certificate issues with the smart card deployment.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Smart Cards Debugging Information
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic explains tools and services that smart card developers can use to help identify certificate issues with the smart card deployment.
+
+Debugging and tracing smart card issues requires a variety of tools and approaches. The following sections provide guidance about tools and approaches you can use.
+
+-   [Certutil](#certutil)
+
+-   [Debugging and tracing using WPP](#debugging-and-tracing-using-wpp)
+
+-   [Kerberos protocol, KDC and NTLM debugging and tracing](#kerberos-protocol-kdc-and-ntlm-debugging-and-tracing)
+
+-   [Smart Card service](#smart-card-service)
+
+-   [Smart card readers](#smart-card-readers)
+
+-   [CryptoAPI 2.0 Diagnostics](#cryptoapi-20-diagnostics)
+
+## Certutil
+
+For a complete description of Certutil including examples that show how to use it, see [Certutil \[W2012\]](https://technet.microsoft.com/en-us/library/cc732443(v=ws.11).aspx).
+
+### List certificates available on the smart card
+
+To list certificates that are available on the smart card, type certutil -scinfo.
+
+> **Note**  Entering a PIN is not required for this operation. You can press ESC if you are prompted for a PIN.
+
+### Delete certificates on the smart card
+
+Each certificate is enclosed in a container. When you delete a certificate on the smart card, you are deleting the container for the certificate.
+
+To find the container value, type certutil -scinfo.
+
+To delete a container, type **certutil -delkey -csp "Microsoft Base Smart Card Crypto Provider"** "<*ContainerValue*>".
+
+## Debugging and tracing using WPP
+
+Windows software trace preprocessor (WPP) simplifies tracing the operation of the trace provider, and it provides a mechanism for the trace provider to log real-time binary messages. Logged messages can subsequently be converted to a human-readable trace of the operation of the trace provider. For more information about WPP, see [Diagnostics with WPP - The NDIS blog](http://blogs.msdn.com/b/ndis/archive/2011/04/06/diagnostics-with-wpp.aspx).
+
+### Enable the trace
+
+Using WPP, use one of the following commands to enable tracing:
+
+-   **tracelog.exe -kd -rt -start** <*FriendlyName*> **-guid \#**<*GUID*> **-f .\\**<*LogFileName*>**.etl -flags** <*flags*> **-ft 1**
+
+-   **logman start** <*FriendlyName*> **-ets -p {**<*GUID*>**} -**<*Flags*> **-ft 1 -rt -o .\\**<*LogFileName*>***.etl -mode 0x00080000**
+
+You can use the parameters in the following table.
+
+| **Friendly name** | **GUID**          | **Flags** |
+|-------------------|--------------------------------------|-----------|
+| scardsvr          | 13038e47-ffec-425d-bc69-5707708075fe | 0xffff    |
+| winscard          | 3fce7c5f-fb3b-4bce-a9d8-55cc0ce1cf01 | 0xffff    |
+| basecsp           | 133a980d-035d-4e2d-b250-94577ad8fced | 0x7       |
+| scksp             | 133a980d-035d-4e2d-b250-94577ad8fced | 0x7       |
+| msclmd            | fb36caf4-582b-4604-8841-9263574c4f2c | 0x7       |
+| credprov          | dba0e0e0-505a-4ab6-aa3f-22f6f743b480 | 0xffff    |
+| certprop          | 30eae751-411f-414c-988b-a8bfa8913f49 | 0xffff    |
+| scfilter          | eed7f3c9-62ba-400e-a001-658869df9a91 | 0xffff    |
+| wudfusbccid       | a3c09ba3-2f62-4be5-a50f-8278a646ac9d | 0xffff    |
+
+Examples
+
+To enable tracing for the SCardSvr service:
+
+-   tracelog.exe -kd -rt -start scardsvr -guid \#13038e47-ffec-425d-bc69-5707708075fe -f .\\scardsvr.etl -flags 0xffff -ft 1
+
+-   logman start scardsvr -ets -p {13038e47-ffec-425d-bc69-5707708075fe} 0xffff -ft 1 -rt -o .\\scardsvr.etl -mode 0x00080000
+
+To enable tracing for scfilter.sys:
+
+tracelog.exe -kd -rt -start scfilter -guid \#eed7f3c9-62ba-400e-a001-658869df9a91 -f .\\scfilter.etl -flags 0xffff -ft 1
+
+### Stop the trace
+
+Using WPP, use one of the following commands to stop the tracing:
+
+-   **tracelog.exe -stop** <*FriendlyName*>
+
+-   **logman -stop** <*FriendlyName*> **-ets**
+
+Examples
+
+To stop a trace:
+
+-   tracelog.exe -stop scardsvr
+
+-   logman -stop scardsvr -ets
+
+## Kerberos protocol, KDC and NTLM debugging and tracing
+
+<!-- It's difficult to find any Kerberos content any more. If they reinstate some content that's more relevant and detailed than what's below, link to it instead. -->
+
+You can use the following resources to begin troubleshooting these protocols and the KDC:
+
+-   [Kerberos and LDAP Troubleshooting Tips](https://technet.microsoft.com/library/bb463167.aspx)
+
+-   [Windows Driver Kit (WDK) and Debugging Tools for Windows (WinDbg)](https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit)  You can use the trace log tool in this SDK to debug Kerberos authentication failures.
+
+To begin tracing, you can use Tracelog. Different components use different control GUIDs as explained in the following examples. For more information, see [Tracelog](https://msdn.microsoft.com/library/windows/hardware/ff552994.aspx).
+
+### NTLM
+
+To enable tracing for NTLM authentication, run the following at the command line:
+
+tracelog.exe -kd -rt -start ntlm -guid \#5BBB6C18-AA45-49b1-A15F-085F7ED0AA90 -f .\\ntlm.etl -flags 0x15003 -ft 1
+
+To stop tracing for NTLM authentication, run the following at the command line:
+
+tracelog -stop ntlm
+
+### Kerberos authentication
+
+To enable tracing for Kerberos authentication, run the following at the command line:
+
+tracelog.exe -kd -rt -start kerb -guid \#6B510852-3583-4e2d-AFFE-A67F9F223438 -f .\\kerb.etl -flags 0x43 -ft 1
+
+To stop tracing for Kerberos authentication, run the following at the command line:
+
+tracelog.exe -stop kerb
+
+### KDC
+
+To enable tracing for the Key Distribution Center (KDC), run the following at the command line:
+
+tracelog.exe -kd -rt -start kdc -guid \#1BBA8B19-7F31-43c0-9643-6E911F79A06B -f .\\kdc.etl -flags 0x803 -ft 1
+
+To stop tracing for the KDC, run the following at the command line:
+
+tracelog.exe -stop kdc
+
+To stop tracing from a remote computer, run the following at the command line: logman.exe -s *&lt;ComputerName&gt;*.
+
+> **Note**&nbsp;&nbsp;The default location for logman.exe is %systemroot%system32\\. Use the **-s** option to supply a computer name.
+
+### Configure tracing with the registry
+
+You can also configure tracing by editing the Kerberos registry values shown in the following table.
+
+| **Element** | **Registry Key Setting**       |
+|-------------|----------------------------------------------------|
+| NTLM        | HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\MSV1\_0<br>Value name: NtLmInfoLevel<br>Value type: DWORD<br>Value data: c0015003          |
+| Kerberos    | HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Kerberos<br>Value name: LogToFile<br>Value type: DWORD<br>Value data: 00000001<br><br>HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Kerberos\\Parameters<br>Value name: KerbDebugLevel<br>Value type: DWORD<br>Value data: c0000043<br><br>HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Kerberos\\Parameters<br>Value name: LogToFile<br>Value type: DWORD<br>Value data: 00000001 |
+| KDC         | HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Kdc<br>Value name: KdcDebugLevel<br>Value type: DWORD<br>Value data: c0000803                  |
+
+If you used Tracelog, look for the following log file in your current directory: kerb.etl/kdc.etl/ntlm.etl.
+
+Otherwise, if you used the registry key settings shown in the previous table, look for the generated trace log files in the following locations:
+
+-   NTLM: %systemroot%\\tracing\\msv1\_0
+
+-   Kerberos: %systemroot%\\tracing\\kerberos 
+
+-   KDC: %systemroot%\\tracing\\kdcsvc 
+
+To decode event trace files, you can use Tracefmt (tracefmt.exe). Tracefmt is a command-line tool that formats and displays trace messages from an event trace log file (.etl) or a real-time trace session. Tracefmt can display the messages in the Command Prompt window or save them in a text file. It is located in the \\tools\\tracing subdirectory of the Windows Driver Kit (WDK). For more information, see [Tracefmt](https://msdn.microsoft.com/library/ff552974.aspx).
+
+## Smart Card service
+
+The smart card resource manager service runs in the context of a local service, and it is implemented as a shared service of the services host (svchost) process.
+
+**To check if Smart Card service is running**
+
+1.  Press CTRL+ALT+DEL, and then click **Start Task Manager**.
+
+2.  In the **Windows Task Manager** dialog box, click the **Services** tab.
+
+3.  Click the **Name** column to sort the list alphabetically, and then type **s**.
+
+4.  In the **Name** column, look for **SCardSvr**, and then look under the **Status** column to see if the service is running or stopped.
+
+**To restart Smart Card service**
+
+1.  Run as administrator at the command prompt.
+
+2.  If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
+
+3.  At the command prompt, type **net stop SCardSvr**.
+
+4.  At the command prompt, type **net start SCardSvr**.
+
+You can use the following command at the command prompt to check whether the service is running: **sc queryex scardsvr**.
+
+The following is example output from running this command:
+
+```
+SERVICE_NAME: scardsvr
+    TYPE        : 20 WIN32_SHARE_PROCESS
+    STATE       : 4 RUNNING
+                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
+    WIN32_EXIT_CODE  : 0 (0x0)
+    SERVICE_EXIT_CODE : 0 (0x0)
+    CHECKPOINT     : 0x0
+    WAIT_HINT     : 0x0
+    PID        : 1320
+    FLAGS       :
+C:\>
+```
+
+## Smart card readers
+
+As with any device connected to a computer, Device Manager can be used to view properties and begin the debug process.
+
+**To check if smart card reader is working**
+
+1.  Navigate to **Computer**.
+
+2.  Right-click **Computer**, and then click **Properties**.
+
+3.  Under **Tasks**, click **Device Manager**.
+
+4.  In Device Manager, expand **Smart card readers**, select the name of the smart card reader you want to check, and then click **Properties**.
+
+> **Note**&nbsp;&nbsp;If the smart card reader is not listed in Device Manager, in the **Action** menu, click **Scan for hardware changes**.
+
+## CryptoAPI 2.0 Diagnostics
+
+CryptoAPI 2.0 Diagnostics is a feature that is available in Windows operating systems that supports CryptoAPI 2.0. This feature can help you troubleshoot public key infrastructure (PKI) issues.
+
+CryptoAPI 2.0 Diagnostics logs events in the Windows event log, which contain detailed information about certificate chain validation, certificate store operations, and signature verification. This information makes it easier to identify the causes of issues and reduces the time required for diagnosis.
+
+For more information about CryptoAPI 2.0 Diagnostics, see [Troubleshooting an Enterprise PKI](https://technet.microsoft.com/library/cc771463.aspx).
+
+## See also
+
+[Smart Card Technical Reference](smart-card-windows-smart-card-technical-reference.md)

windows/keep-secure/smart-card-events.md

@@ -0,0 +1,111 @@
+---
+title: Smart Card Events (Windows 10)
+description: This topic for the IT professional and smart card developer describes events that are related to smart card deployment and development.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Smart Card Events
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional and smart card developer describes events that are related to smart card deployment and development.
+
+A number of events can be used to monitor smart card activities on a computer, including installation, use, and errors. The following sections describe the events and information that can be used to manage smart cards in an organization.
+
+-   [Smart card reader name](#smart-card-reader-name)
+
+-   [Smart card warning events](#smart-card-warning-events)
+
+-   [Smart card error events](#smart-card-error-events)
+
+-   [Smart card Plug and Play events](#smart-card-plug-and-play-events)
+
+## Smart card reader name
+
+The Smart Card resource manager does not use the device name from Device Manager to describe a smart card reader. Instead, the name is constructed from three device attributes that are queried directly from the smart card reader driver.
+
+The following three attributes are used to construct the smart card reader name:
+
+-   Vendor name
+
+-   Interface device type
+
+-   Device unit
+
+The smart card reader device name is constructed in the form <*VendorName*> <*Type*> <*DeviceUnit*>. For example 'Contoso Smart Card Reader 0' is constructed from the following information:
+
+-   Vendor name: Contoso
+
+-   Interface device type: Smart Card Reader
+
+-   Device unit: 0
+
+## Smart card warning events
+
+> **Note**  IOCTL in the following table refers to input and output control.
+
+| **Event ID** | **Warning Message**                 | **Description**                  |
+|--------------|---------|--------------------------------------------------------------------------------------------|
+| 620          | Smart Card Resource Manager was unable to cancel IOCTL %3 for reader '%2': %1. The reader may no longer be responding. If this error persists, your smart card or reader may not be functioning correctly. %n%nCommand Header: %4 | This occurs if the resource manager attempts to cancel a command to the smart card reader when the smart card service is shutting down or after a smart card is removed from the smart card reader and the command could not to be canceled. This can leave the smart card reader in an unusable state until it is removed from the computer or the computer is restarted.<br><br>%1 = Windows error code<br>%2 = Smart card reader name<br>%3 = IOCTL being canceled<br>%4 = First 4 bytes of the command that was sent to the smart card |
+| 619          | Smart Card Reader '%2' has not responded to IOCTL %3 in %1 seconds. If this error persists, your smart card or reader may not be functioning correctly. %n%nCommand Header: %4              | This occurs when a reader has not responded to an IOCTL after an unusually long period of time. Currently, this error is sent after a reader does not respond for 150 seconds. This can leave the smart card reader in an unusable state until it is removed from the computer or the computer is restarted.<br><br>%1 = Number of seconds the IOCTL has been waiting<br>%2 = Smart card reader name<br>%3 = IOCTL sent<br>%4 = First 4 bytes of the command that was sent to the smart card         |
+
+## Smart card error events
+
+| **Event ID** | **Error Message**  | **Description**          |
+|--------------|--------------------------------------------|-------------------------------------------------------------------------------|
+| 202          | Failed to initialize Server Application                  | An error occurred, and the service cannot initialize properly. Restarting the computer may resolve the issue.           |
+| 203          | Server Control has no memory for reader reference object.                   | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.    |
+| 204          | Server Control failed to create shutdown event: %1       | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code             |
+| 205          | Reader object has duplicate name: %1  | There are two smart card readers that have the same name. Remove the smart card reader that is causing this error message.<br>%1 = Name of the smart card reader that is duplicated               |
+| 206          | Failed to create global reader change event.             | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.    |
+| 401          | Reader shutdown exception from eject smart card command  | A smart card reader could not eject a smart card while the smart card reader was shutting down.      |
+| 406          | Reader object cannot Identify Device  | A smart card reader did not properly respond to a request for information about the device, which is required for constructing the smart card reader name. The smart card reader will not be recognized by the service until it is removed from the computer and reinserted or until the computer is restarted.       |
+| 502          | Initialization of Service Status Critical Section failed | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.    |
+| 504          | Resource Manager cannot create shutdown event flag:  %1  | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code             |
+| 506          | Smart Card Resource Manager failed to register service:  %1                 | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code             |
+| 506          | Smart Card Resource Manager received unexpected exception from PnP event %1 | An attempt to add a Plug and Play reader failed. The device may already be in use or may be defective. To resolve this error message, try to add the device again or restart the computer.<br>%1 = The affected handle name             |
+| 507          | No memory available for Service Status Critical Section  | There is not enough system memory available. This prevents the service from managing the status. Restarting the computer may resolve the issue.               |
+| 508          | Smart Card Resource Manager received unexpected exception from PnP event %1 | An attempt to add a Plug and Play reader failed. The device may already be in use or may be defective. To resolve this error message, try to add the device again or restart the computer.<br>%1 = The affected handle name             |
+| 509          | Smart Card Resource Manager received unexpected exception from PnP event %1 | An attempt to add a Plug and Play reader failed. The device may already be in use or may be defective. To resolve this error message, try to add the device again or restart the computer.<br>%1 = The affected handle name             |
+| 510          | Smart Card Resource Manager received NULL handle from PnP event %1          | An attempt to add a Plug and Play smart card reader failed. The device may already be in use or may be defective. To resolve this error message, try to add the device again or restart the computer.<br>%1 = The affected handle name  |
+| 511          | Smart Card Resource Manager received unexpected exception from PnP event %1 | An attempt to add a Plug and Play reader failed. The device may already be in use or may be defective. To resolve this error message, try to add the device again or restart the computer.<br>%1 = The affected handle name             |
+| 512          | Smart Card Resource Manager received NULL handle from PnP event %1          | An attempt to add a Plug and Play smart card reader failed. The device may already be in use or may be defective. To resolve this error message, try to add the device again or restart the computer.<br>%1 = The affected handle name  |
+| 513          | Smart Card Resource Manager received unexpected exception from PnP event %1 | An attempt to add a Plug and Play reader failed. The device may already be in use or may be defective. To resolve this error message, try to add the device again or restart the computer.<br>%1 = The affected handle name             |
+| 514          | Smart Card Resource Manager failed to add reader %2: %1  | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code<br>%2 = Smart card reader name                  |
+| 515          | Smart Card Resource Manager failed to declare state:  %1 | This is an internal unrecoverable error that indicates a failure in the smart card service. The smart card service may not operate properly. Restarting the service or computer may resolve this issue.<br>%1 = Windows error code      |
+| 516          | Smart Card Resource Manager Failed to declare shutdown:  %1                 | This is an internal, unrecoverable error that indicates a failure in the smart card service. The smart card service may not be able to stop. Restarting the computer may resolve this issue.<br>%1 = Windows error code                 |
+| 517          | Smart Card Resource Manager received unexpected exception attempting to add reader %1          | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Smart card reader name         |
+| 521          | Smart Card Resource Manager received NULL handle from PnP event %1          | An attempt to add a Plug and Play smart card reader failed. The device may already be in use or may be defective. To resolve this error message, try to add the device again or restart the computer.<br>%1 = The affected handle name  |
+| 523          | Smart Card Resource Manager received NULL handle from PnP event %1          | An attempt to add a Plug and Play smart card reader failed. The device may already be in use or may be defective. To resolve this error message, try to add the device again or restart the computer.<br>%1 = The affected handle name  |
+| 602          | WDM Reader driver initialization cannot open reader device:  %1             | The service cannot open a communication channel with the smart card reader. You cannot use the smart card reader until the issue is resolved.<br>%1 = Windows error code       |
+| 603          | WDM Reader driver initialization has no memory available to control device %1                  | There is not enough system memory available. This prevents the service from managing the smart card reader that was added. Restarting the computer may resolve the issue.<br>%1 = Name of affected reader            |
+| 604          | Server control cannot set reader removal event:  %1      | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code             |
+| 605          | Reader object failed to create overlapped event:  %1     | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code             |
+| 606          | Reader object failed to create removal event:  %1        | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code             |
+| 607          | Reader object failed to start monitor thread:  %1        | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code             |
+| 608          | Reader monitor failed to create power down timer: %1     | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code             |
+| 609          | Reader monitor failed to create overlapped event:  %1    | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code             |
+| 610          | Smart Card Reader '%2' rejected IOCTL %3: %1  If this error persists, your smart card or reader may not be functioning correctly.%n%nCommand Header: %4 | The reader cannot successfully transmit the indicated IOCTL to the smart card. This can indicate hardware failure, but this error can also occur if a smart card or smart card reader is removed from the system while an operation is in progress.<br>%1 = Windows error code<br>%2 = Name of the smart card reader<br>%3 = IOCTL that was sent<br>%4 = First 4 bytes of the command sent to the smart card |
+| 611          | Smart Card Reader initialization failed                  | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve this issue.   |
+| 612          | Reader insertion monitor error retry threshold reached:  %1                 | This occurs when a smart card reader fails several times to respond properly to the IOCTL, which indicates whether a smart card is present in the reader. The smart card reader is marked as defective, and it is not recognized by the service until it is removed from the computer and reinserted or until the computer is restarted.<br>%1 = Windows error code          |
+| 615          | Reader removal monitor error retry threshold reached:  %1                   | This occurs when a smart card reader fails several times to respond properly to the IOCTL, which indicates whether a smart card is present in the reader. The smart card reader is marked as defective, and it is not recognized by the service until it is removed from the computer and reinserted or until the computer is restarted.<br>%1 = Windows error code          |
+| 616          | Reader monitor '%2' received uncaught error code:  %1    | This occurs when a smart card reader fails several times to respond properly to the IOCTL, which indicates whether a smart card is present in the reader. The smart card reader is marked as defective, and it is not recognized by the service until it is removed from the computer and reinserted or until the computer is restarted.<br>%1 = Windows error code<br>%2 = Reader name       |
+| 617          | Reader monitor '%1' exception -- exiting thread          | An unknown error occurred while monitoring a smart card reader for smart card insertions and removals. The smart card reader is marked as defective, and it is not recognized by the service until it is removed from the computer and reinserted or until the computer is restarted.<br>%1 = Smart card reader name                   |
+| 618          | Smart Card Resource Manager encountered an unrecoverable internal error.    | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.    |
+| 621          | Server Control failed to access start event: %1          | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code             |
+| 622          | Server Control failed to access stop event: %1           | This is an internal, unrecoverable error that indicates a failure in the smart card service. The most common cause is limited computer resources. Restarting the computer may resolve the issue.<br>%1 = Windows error code             |
+
+## Smart card Plug and Play events
+
+| **Event ID** | **Event type** | **Event Message**              | **Description**         |
+|--------------|----------------|-----------------------------------------------------------------------------------------|----------------|
+| 1000         | Error          | Could not get device ID for smart card in reader %1. The return code is %2.             | Smart card Plug and Play could not obtain the device ID for the smart card. This information is required to determine the correct driver. The smart card may be defective.<br>%1 = Smart card reader name<br>%2 = Windows error code |
+| 1001         | Information    | Software successfully installed for smart card in reader %1. The smart card name is %2. | Smart card Plug and Play successfully installed a minidriver for the inserted card.<br>%1 = Smart card reader name<br>%2 = Name of new smart card device |
+
+## See also
+
+[Smart Card Technical Reference](smart-card-windows-smart-card-technical-reference.md)

windows/keep-secure/smart-card-group-policy-and-registry-settings.md

@@ -0,0 +1,378 @@
+---
+title: Smart Card Group Policy and Registry Settings (Windows 10)
+description: This topic for the IT professional and smart card developer describes the Group Policy settings, registry key settings, local security policy settings, and credential delegation policy settings that are available for configuring smart cards.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Smart Card Group Policy and Registry Settings
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional and smart card developer describes the Group Policy settings, registry key settings, local security policy settings, and credential delegation policy settings that are available for configuring smart cards.
+
+The following sections and tables list the smart card-related Group Policy settings and registry keys that can be set on a per-computer basis. If you use domain Group Policy Objects (GPOs), you can edit and apply Group Policy settings to local or domain computers.
+
+-   [Primary Group Policy settings for smart cards](#primary-group-policy-settings-for-smart-cards)
+
+    -   [Allow certificates with no extended key usage certificate attribute](#allow-certificates-with-no-extended-key-usage-certificate-attribute)
+
+    -   [Allow ECC certificates to be used for logon and authentication](#allow-ecc-certificates-to-be-used-for-logon-and-authentication)
+
+    -   [Allow Integrated Unblock screen to be displayed at the time of logon](#allow-integrated-unblock-screen-to-be-displayed-at-the-time-of-logon)
+
+    -   [Allow signature keys valid for Logon](#allow-signature-keys-valid-for-logon)
+
+    -   [Allow time invalid certificates](#allow-time-invalid-certificates)
+
+    -   [Allow user name hint](#allow-user-name-hint)
+
+    -   [Configure root certificate clean up](#configure-root-certificate-clean-up)
+
+    -   [Display string when smart card is blocked](#display-string-when-smart-card-is-blocked)
+
+    -   [Filter duplicate logon certificates](#filter-duplicate-logon-certificates)
+
+    -   [Force the reading of all certificates from the smart card](#force-the-reading-of-all-certificates-from-the-smart-card)
+
+    -   [Notify user of successful smart card driver installation](#notify-user-of-successful-smart-card-driver-installation)
+
+    -   [Prevent plaintext PINs from being returned by Credential Manager](#prevent-plaintext-pins-from-being-returned-by-credential-manager)
+
+    -   [Reverse the subject name stored in a certificate when displaying](#reverse-the-subject-name-stored-in-a-certificate-when-displaying)
+
+    -   [Turn on certificate propagation from smart card](#turn-on-certificate-propagation-from-smart-card)
+
+    -   [Turn on root certificate propagation from smart card](#turn-on-root-certificate-propagation-from-smart-card)
+
+    -   [Turn on Smart Card Plug and Play service](#turn-on-smart-card-plug-and-play-service)
+
+-   [Base CSP and Smart Card KSP registry keys](#base-csp-and-smart-card-ksp-registry-keys)
+
+-   [CRL checking registry keys](#crl-checking-registry-keys)
+
+-   [Additional smart card Group Policy settings and registry keys](#additional-smart-card-group-policy-settings-and-registry-keys)
+
+## Primary Group Policy settings for smart cards
+
+The following smart card Group Policy settings are located in Computer Configuration\\Administrative Templates\\Windows Components\\Smart Card.
+
+The registry keys are in the following locations:
+
+-   HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\SmartCardCredentialProvider
+
+-   HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\CertProp
+
+> **Note**&nbsp;&nbsp;Smart card reader registry information is located in HKEY\_LOCAL\_MACHINE\\Software\\Microsoft\\Cryptography\\Calais\\Readers.<br>Smart card registry information is located in HKEY\_LOCAL\_MACHINE\\Software\\Microsoft\\Cryptography\\Calais\\SmartCards.
+
+The following table lists the default values for these GPO settings. Variations are documented under the policy descriptions in this topic.
+
+| **Server Type or GPO**    | **Default Value** |
+|----------------------------------------------|-------------------|
+| Default Domain Policy     | Not configured    |
+| Default Domain Controller Policy             | Not configured    |
+| Stand-Alone Server Default Settings          | Not configured    |
+| Domain Controller Effective Default Settings | Disabled          |
+| Member Server Effective Default Settings     | Disabled          |
+| Client Computer Effective Default Settings   | Disabled          |
+
+### Allow certificates with no extended key usage certificate attribute
+
+This policy setting allows certificates without an enhanced key usage (EKU) set to be used for sign in.
+
+> **Note**&nbsp;&nbsp;Enhanced key usage certificate attribute is also known as extended key usage.
+
+In versions of Windows prior to Windows Vista, smart card certificates that are used to sign in require an EKU extension with a smart card logon object identifier. This policy setting can be used to modify that restriction.
+
+When this policy setting is enabled, certificates with the following attributes can also be used to sign in with a smart card:
+
+-   Certificates with no EKU
+
+-   Certificates with an All Purpose EKU
+
+-   Certificates with a Client Authentication EKU
+
+When this policy setting is disabled or not configured, only certificates that contain the smart card logon object identifier can be used to sign in with a smart card.
+
+| **Item**          | **Description**                 |
+|--------------------------------------|-------------------------------------------------------------------------------------------------------------|
+| Registry key      | AllowCertificatesWithNoEKU      |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None    |
+| Notes and resources                  |              |
+
+### Allow ECC certificates to be used for logon and authentication
+
+This policy setting allows you to control whether elliptic curve cryptography (ECC) certificates on a smart card can be used to sign in to a domain. When this setting is enabled, ECC certificates on a smart card can be used to sign in to a domain. When this setting is disabled or not configured, ECC certificates on a smart card cannot be used to sign in to a domain.
+
+| **Item**          | **Description**                   |
+|--------------------------------------|-------------------------------|
+| Registry key      | EnumerateECCCerts                 |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent   |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None      |
+| Notes and resources                  | This policy setting only affects a user's ability to sign in to a domain. ECC certificates on a smart card that are used for other applications, such as document signing, are not affected by this policy setting. <br>If you use an ECDSA key to sign in, you must also have an associated ECDH key to permit sign-in when you are not connected to the network. |
+
+### Allow Integrated Unblock screen to be displayed at the time of logon
+
+This policy setting lets you determine whether the integrated unblock feature is available in the sign-in user interface (UI). The feature was introduced as a standard feature in the Credential Security Support Provider in Windows Vista.
+
+When this setting is enabled, the integrated unblock feature is available. When this setting is disabled or not configured, the feature is not available.
+
+| **Item**          | **Description**    |
+|--------------------------------------|---------------------------------------------------------------------------------------------------------------|
+| Registry key      | AllowIntegratedUnblock                |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent       |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None          |
+| Notes and resources                  | To use the integrated unblock feature, the smart card must support it. Check with the hardware manufacturer to verify that the smart card supports this feature.<br>You can create a custom message that is displayed when the smart card is blocked by configuring the policy setting [Display string when smart card is blocked](#display-string-when-smart-card-is-blocked). |
+
+### Allow signature keys valid for Logon
+
+This policy setting lets you allow signature key-based certificates to be enumerated and available for sign in. When this setting is enabled, any certificates available on the smart card with a signature-only key are listed on the sign-in screen. When this setting is disabled or not configured, certificates available on the smart card with a signature-only key are not listed on the sign-in screen.
+
+| **Item**          | **Description**                 |
+|--------------------------------------|-------------------------------------------------------------------------------------------------------------|
+| Registry key      | AllowSignatureOnlyKeys          |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None    |
+| Notes and resources                  |              |
+
+### Allow time invalid certificates
+
+This policy setting permits those certificates that are expired or not yet valid to be displayed for sign-in.
+
+Prior to Windows Vista, certificates were required to contain a valid time and to not expire. To be used, the certificate must be accepted by the domain controller. This policy setting only controls which certificates are displayed on the client computer.
+
+When this setting is enabled, certificates are listed on the sign-in screen whether they have an invalid time or their time validity has expired. When this setting is disabled or not configured, certificates that are expired or not yet valid are not listed on the sign-in screen.
+
+| **Item**          | **Description**                 |
+|--------------------------------------|-------------------------------------------------------------------------------------------------------------|
+| Registry key      | AllowTimeInvalidCertificates    |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None    |
+| Notes and resources                  |              |
+
+### Allow user name hint
+
+This policy setting lets you determine whether an optional field is displayed during sign-in and provides a subsequent elevation process that allows users to enter their user name or user name and domain, which associates a certificate with the user. If this setting is enabled, an optional field is displayed that allows users to enter their user name or user name and domain. If this setting is disabled or not configured, the field is not displayed.
+
+| **Item**          | **Description**                 |
+|--------------------------------------|-------------------------------------------------------------------------------------------------------------|
+| Registry key      | X509HintsNeeded                 |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None    |
+| Notes and resources                  |              |
+
+### Configure root certificate clean up
+
+This policy setting allows you to manage the cleanup behavior of root certificates. Certificates are verified by using a trust chain, and the trust anchor for the digital certificate is the Root Certification Authority (CA). A CA can issue multiple certificates with the root certificate as the top certificate of the tree structure. A private key is used to sign other certificates. This creates an inherited trustworthiness for all certificates immediately under the root certificate. When this setting is enabled, you can set the following cleanup options:
+
+-   **No cleanup**. When the user signs out or removes the smart card, the root certificates used during their session persist on the computer.
+
+-   **Clean up certificates on smart card removal**. When the smart card is removed, the root certificates are removed.
+
+-   **Clean up certificates on log off**. When the user signs out of Windows, the root certificates are removed.
+
+When this policy setting is disabled or not configured, root certificates are automatically removed when the user signs out of Windows.
+
+| **Item**          | **Description**                 |
+|--------------------------------------|-------------------------------------------------------------------------------------------------------------|
+| Registry key      | RootCertificateCleanupOption    |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None    |
+| Notes and resources                  |              |
+
+### Display string when smart card is blocked
+
+When this policy setting is enabled, you can create and manage the displayed message that the user sees when a smart card is blocked. When this setting is disabled or not configured (and the integrated unblock feature is also enabled), the system’s default message is displayed to the user when the smart card is blocked.
+
+| **Item**          | **Description**             |
+|--------------------------------------|-------------------------|
+| Registry key      | IntegratedUnblockPromptString                  |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent                |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: This policy setting is only effective when the [Allow Integrated Unblock screen to be displayed at the time of logon](#allow-integrated-unblock-screen-to-be-displayed-at-the-time-of-logon) policy is enabled. |
+| Notes and resources                  |          |
+
+### Filter duplicate logon certificates
+
+This policy setting lets you use a filtering process to configure which valid sign-in certificates are displayed. During the certificate renewal period, a user’s smart card can have multiple valid sign-in certificates issued from the same certificate template, which can cause confusion about which certificate to select. This behavior can occur when a certificate is renewed and the old certificate has not expired yet.
+
+Two certificates are determined to be the same if they are issued from the same template with the same major version and they are for the same user (this is determined by their UPN). When this policy setting is enabled, filtering occurs so that the user will only see the most current valid certificates from which to select. If this setting is disabled or not configured, all the certificates are displayed to the user.
+
+This policy setting is applied to the computer after the [Allow time invalid certificates](#allow-time-invalid-certificates) policy setting is applied.
+
+| **Item**          | **Description**               |
+|--------------------------------------|--------------------------------------------------------------------------------------------------|
+| Registry key      | FilterDuplicateCerts          |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent                  |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None  |
+| Notes and resources                  | If there are two or more of the same certificates on a smart card and this policy setting is enabled, the certificate that is used to sign in to computers running Windows 2000, Windows XP, or Windows Server 2003 will be displayed. Otherwise, the certificate with the most distant expiration time will be displayed. |
+
+### Force the reading of all certificates from the smart card
+
+This policy setting allows you to manage how Windows reads all certificates from the smart card for sign-in. During sign in, Windows reads only the default certificate from the smart card unless it supports retrieval of all certificates in a single call. This policy setting forces Windows to read all the certificates from the smart card.
+
+When this policy setting is enabled, Windows attempts to read all certificates from the smart card regardless of the CSP feature set. When disabled or not configured, Windows attempts to read only the default certificate from smart cards that do not support retrieval of all certificates in a single call. Certificates other than the default are not available for sign in.
+
+| **Item**          | **Description**                 |
+|--------------------------------------|----------------------------------------------------------------------------|
+| Registry key      | ForceReadingAllCertificates     |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None<br><br>**Important**&nbsp;&nbsp;Enabling this policy setting can adversely impact performance during the sign in process in certain situations.  |
+| Notes and resources                  | Contact the smart card vendor to determine if your smart card and associated CSP support the required behavior.                |
+
+### Notify user of successful smart card driver installation
+
+This policy setting allows you to control whether a confirmation message is displayed to the user when a smart card device driver is installed. When this policy setting is enabled, a confirmation message is displayed when a smart card device driver is installed. When this setting is disabled or not configured, a smart card device driver installation message is not displayed.
+
+| **Item**          | **Description**        |
+|--------------------------------------|------------------------------------------------|
+| Registry key      | ScPnPNotification      |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent           |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None              |
+| Notes and resources                  | This policy setting applies only to smart card drivers that have passed the Windows Hardware Quality Labs (WHQL) testing process.        |
+
+### Prevent plaintext PINs from being returned by Credential Manager
+
+This policy setting prevents Credential Manager from returning plaintext PINs. Credential Manager is controlled by the user on the local computer, and it stores credentials from supported browsers and Windows applications. Credentials are saved in special encrypted folders on the computer under the user’s profile. When this policy setting is enabled, Credential Manager does not return a plaintext PIN. When this setting is disabled or not configured, plaintext PINs can be returned by Credential Manager.
+
+| **Item**          | **Description**     |
+|--------------------------------------|-----------------------------------------------------------------------------------|
+| Registry key      | DisallowPlaintextPin                   |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent        |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None           |
+| Notes and resources                  | If this policy setting is enabled, some smart cards may not work in computers running Windows. Consult the smart card manufacturer to determine whether this policy setting should be enabled. |
+
+### Reverse the subject name stored in a certificate when displaying
+
+When this policy setting is enabled, it causes the display of the subject name to be reversed from the way it is stored in the certificate during the sign-in process.
+
+To help users distinguish one certificate from another, the user principal name (UPN) and the common name are displayed by default. For example, when this setting is enabled, if the certificate subject is CN=User1, OU=Users, DN=example, DN=com and the UPN is user1@example.com, "User1" is displayed with "user1@example.com." If the UPN is not present, the entire subject name is displayed. This setting controls the appearance of that subject name, and it might need to be adjusted for your organization.
+
+| **Item**          | **Description**                 |
+|--------------------------------------|-------------------------------------------------------------------------------------------------------------|
+| Registry key      | ReverseSubject                  |
+| Default values    | No changes per operating system versions<br>Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None    |
+| Notes and resources                  |              |
+
+### Turn on certificate propagation from smart card
+
+This policy setting allows you to manage the certificate propagation that occurs when a smart card is inserted. The certificate propagation service applies when a signed-in user inserts a smart card in a reader that is attached to the computer. This action causes the certificate to be read from the smart card. The certificates are then added to the user's Personal store.
+
+If you enable or do not configure this policy setting, certificate propagation occurs when the user inserts the smart card. When this setting is disabled, certificate propagation does not occur and the certificates will not be made available to applications such as Outlook.
+
+| **Item**          | **Description**    |
+|--------------------------------------|----------------|
+| Registry key      | CertPropEnabled    |
+| Default values    | No changes per operating system versions<br>Enabled and not configured are equivalent        |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: This policy setting must be enabled to allow the [Turn on root certificate propagation from smart card](#turn-on-root-certificate-propagation-from-smart-card) setting to work when it is enabled. |
+| Notes and resources                  | |
+
+### Turn on root certificate propagation from smart card
+
+This policy setting allows you to manage the root certificate propagation that occurs when a smart card is inserted. The certificate propagation service applies when a signed-in user inserts a smart card in a reader that is attached to the computer. This action causes the certificate to be read from the smart card. The certificates are then added to the user's Personal store. When this policy setting is enabled or not configured, root certificate propagation occurs when the user inserts the smart card.
+
+| **Item**          | **Description**   |
+|--------------------------------------|---------------------------------------------------------------------------------------------------------|
+| Registry key      | EnableRootCertificate Propagation    |
+| Default values    | No changes per operating system versions<br>Enabled and not configured are equivalent       |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: For this policy setting to work, the [Turn on certificate propagation from smart card](#turn-on-certificate-propagation-from-smart-card) policy setting must also be enabled. |
+| Notes and resources                  |                   |
+
+### Turn on Smart Card Plug and Play service
+
+This policy setting allows you to control whether Smart Card Plug and Play is enabled. This means that your users can use smart cards from vendors who have published their drivers through Windows Update without needing special middleware. These drivers will be downloaded in the same way as drivers for other devices in Windows. If an appropriate driver is not available from Windows Update, a PIV-compliant minidriver that is included with any of the supported versions of Windows is used for these cards.
+
+When the Smart Card Plug and Play policy setting is enabled or not configured, and the system attempts to install a smart card device driver the first time a smart card is inserted in a smart card reader. If this policy setting is disabled a device driver is not installed when a smart card is inserted in a smart card reader.
+
+| **Item**          | **Description**        |
+|--------------------------------------|------------------------------------------------|
+| Registry key      | EnableScPnP            |
+| Default values    | No changes per operating system versions<br>Enabled and not configured are equivalent            |
+| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None              |
+| Notes and resources                  | This policy setting applies only to smart card drivers that have passed the Windows Hardware Quality Labs (WHQL) testing process.        |
+
+## Base CSP and Smart Card KSP registry keys
+
+The following registry keys can be configured for the base cryptography service provider (CSP) and the smart card key storage provider (KSP). The following tables list the keys. All keys use the DWORD type.
+
+The registry keys for the Base CSP are located in the registry in HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Cryptography\\Defaults\\Provider\\Microsoft Base Smart Card Crypto Provider.
+
+The registry keys for the smart card KSP are located in HKEY\_LOCAL\_MACHINE\\SYSTEM\\ControlSet001\\Control\\Cryptography\\Providers\\Microsoft Smart Card Key Storage Provider.
+
+**Registry keys for the base CSP and smart card KSP**
+
+| **Registry Key**                   | **Description**                 |
+|------------------------------------|---------------------------------------------------------------------------------|
+| **AllowPrivateExchangeKeyImport**  | A non-zero value allows RSA exchange (for example, encryption) private keys to be imported for use in key archival scenarios.<br>Default value: 00000000           |
+| **AllowPrivateSignatureKeyImport** | A non-zero value allows RSA signature private keys to be imported for use in key archival scenarios.<br>Default value: 00000000                 |
+| **DefaultPrivateKeyLenBits**       | Defines the default length for private keys, if desired.<br>Default value: 00000400<br>Default key generation parameter: 1024-bit keys        |
+| **RequireOnCardPrivateKeyGen**     | This key sets the flag that requires on-card private key generation (default). If this value is set, a key generated on a host can be imported into the smart card. This is used for smart cards that do not support on-card key generation or where key escrow is required.<br>Default value: 00000000 |
+| **TransactionTimeoutMilliseconds** | Default timeout values allow you to specify whether transactions that take an excessive amount of time will fail.<br>Default value: 000005dc1500<br>The default timeout for holding transactions to the smart card is 1.5 seconds.           |
+
+**Additional registry keys for the smart card KSP**
+
+| **Registry Key**               | **Description**             |
+|--------------------------------|-----------------------------------------------------|
+| **AllowPrivateECDHEKeyImport** | This value allows Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) private keys to be imported for use in key archival scenarios.<br>Default value: 00000000    |
+| **AllowPrivateECDSAKeyImport** | This value allows Elliptic Curve Digital Signature Algorithm (ECDSA) private keys to be imported for use in key archival scenarios.<br>Default value: 00000000 |
+
+## CRL checking registry keys
+
+The following table lists the keys and the corresponding values to turn off certificate revocation list (CRL) checking at the Key Distribution Center (KDC) or client. To manage CRL checking, you need to configure settings for both the KDC and the client.
+
+**CRL checking registry keys**
+
+| **Registry Key**         | **Details**                 |
+|------------|-----------------------------|
+| HKEY\_LOCAL\_MACHINE\\SYSTEM\\CCS\\Services\\Kdc\\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors   | Type = DWORD<br>Value = 1 |
+| HKEY\_LOCAL\_MACHINE\\SYSTEM\\CCS\\Control\\LSA\\Kerberos\\Parameters\\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors | Type = DWORD<br>Value = 1 |
+
+## Additional smart card Group Policy settings and registry keys
+
+In a smart card deployment, additional Group Policy settings can be used to enhance ease-of-use or security. Two of these policy settings that can complement a smart card deployment are:
+
+-   Turning off delegation for computers
+
+-   Interactive logon: Do not require CTRL+ALT+DEL (not recommended)
+
+The following smart card-related Group Policy settings are located in Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options.
+
+**Local security policy settings**
+
+| Group Policy Setting and Registry Key    |  Default   | Description   |
+|------------------------------------------|------------|---------------|
+| Interactive logon: Require smart card<br><br>scforceoption          |  Disabled        | This security policy setting requires users to sign in to a computer by using a smart card.<br><br>**Enabled**  Users can only sign in to the computer by using a smart card.<br>**Disabled**  Users can sign in to the computer by using any method.         |
+| Interactive logon: Smart card removal behavior<br><br>scremoveoption | This policy setting is not defined, which means that the system treats it as **No Action**. | This setting determines what happens when the smart card for a signed-in user is removed from the smart card reader. The options are:<br>**No Action**<br>**Lock Workstation**: The workstation is locked when the smart card is removed, allowing users to leave the area, take their smart card with them, and still maintain a protected session.<br>**Force Logoff**: The user is automatically signed out when the smart card is removed.<br>**Disconnect if a Remote Desktop Services session**: Removal of the smart card disconnects the session without signing out the user. This allows the user to reinsert the smart card and resume the session later, or at another computer that is equipped with a smart card reader, without having to sign in again. If the session is local, this policy setting functions identically to the **Lock Workstation** option.<br><br>**Note**&nbsp;&nbsp;Remote Desktop Services was called Terminal Services in previous versions of Windows Server.  |
+
+From the Local Security Policy Editor (secpol.msc), you can edit and apply system policies to manage credential delegation for local or domain computers.
+
+The following smart card-related Group Policy settings are located in Computer Configuration\\Administrative Templates\\System\\Credentials Delegation.
+
+Registry keys are located in HKEY\_LOCAL\_MACHINE\\SYSTEM\\ControlSet001\\Control\\Lsa\\Credssp\\PolicyDefaults.
+
+> **Note**&nbsp;&nbsp;In the following table, fresh credentials are those that you are prompted for when running an application.
+
+**Credential delegation policy settings**
+
+| Group Policy Setting and Registry Key  | Default   | Description |
+|----------------------------------------|-----------|-------------|
+| **Allow Delegating Fresh Credentials**<br><br>AllowFreshCredentials     | Not Configured | This policy setting applies: <br>When server authentication was achieved through a trusted X509 certificate or Kerberos protocol.<br>To applications that use the CredSSP component (for example, Remote Desktop Services).<br><br>**Enabled**: You can specify the servers where the user's fresh credentials can be delegated. <br>**Not Configured**: After proper mutual authentication, delegation of fresh credentials is permitted to Remote Desktop Services running on any computer.<br>**Disabled**: Delegation of fresh credentials to any computer is not permitted.<br><br>**Note**&nbsp;&nbsp;This policy setting can be set to one or more service principal names (SPNs). The SPN represents the target server where the user credentials can be delegated. A single wildcard character is permitted when specifying the SPN, for example:<br>Use *TERMSRV/\** for Remote Desktop Session Host (RD Session Host) running on any computer. <br>Use *TERMSRV/host.humanresources.fabrikam.com* for RD Session Host running on the host.humanresources.fabrikam.com computer.<br>Use *TERMSRV/\*.humanresources.fabrikam.com* for RD Session Host running on all computers in .humanresources.fabrikam.com  |
+| **Allow Delegating Fresh Credentials with NTLM-only Server Authentication**<br><br>AllowFreshCredentialsWhenNTLMOnly | Not Configured | This policy setting applies:<br>When server authentication was achieved by using NTLM.<br>To applications that use the CredSSP component (for example, Remote Desktop).<br><br>**Enabled**: You can specify the servers where the user's fresh credentials can be delegated.<br>**Not Configured**: After proper mutual authentication, delegation of fresh credentials is permitted to RD Session Host running on any computer (TERMSRV/\*).<br>**Disabled**: Delegation of fresh credentials is not permitted to any computer.<br><br>**Note**&nbsp;&nbsp;This policy setting can be set to one or more SPNs. The SPN represents the target server where the user credentials can be delegated. A single wildcard character (\*) is permitted when specifying the SPN.<br>See the **Allow Delegating Fresh Credentials** policy setting description for examples.             |
+| **Deny Delegating Fresh Credentials**<br><br>DenyFreshCredentials | Not Configured | This policy setting applies to applications that use the CredSSP component (for example, Remote Desktop).<br><br>**Enabled**: You can specify the servers where the user's fresh credentials cannot be delegated.<br>**Disabled** or **Not Configured**: A server is not specified.<br><br>**Note**&nbsp;&nbsp;This policy setting can be set to one or more SPNs. The SPN represents the target server where the user credentials cannot be delegated. A single wildcard character (\*) is permitted when specifying the SPN.<br>See the **Allow Delegating Fresh Credentials** policy setting description for examples.          |
+
+If you are using Remote Desktop Services with smart card logon, you cannot delegate default and saved credentials. The registry keys in the following table, which are located at HKEY\_LOCAL\_MACHINE\\SYSTEM\\ControlSet001\\Control\\Lsa\\Credssp\\PolicyDefaults, and the corresponding Group Policy settings are ignored.
+
+| **Registry key** | **Corresponding Group Policy setting**                 |
+|-------------------------------------|---------------------------------------------------------------------------|
+| AllowDefaultCredentials             | Allow Delegating Default Credentials                   |
+| AllowDefaultCredentialsWhenNTLMOnly | Allow Delegating Default Credentials with NTLM-only Server Authentication |
+| AllowSavedCredentials               | Allow Delegating Saved Credentials  |
+| AllowSavedCredentialsWhenNTLMOnly   | Allow Delegating Saved Credentials with NTLM-only Server Authentication   |
+
+## See also
+
+[Smart Card Technical Reference](smart-card-windows-smart-card-technical-reference.md)

windows/keep-secure/smart-card-how-smart-card-sign-in-works-in-windows.md

@@ -0,0 +1,27 @@
+---
+title: How Smart Card Sign-in Works in Windows (Windows 10)
+description: This topic for IT professional provides links to resources about the implementation of smart card technologies in the Windows operating system.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# How Smart Card Sign-in Works in Windows
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for IT professional provides links to resources about the implementation of smart card technologies in the Windows operating system. It includes the following resources about the architecture, certificate management, and services that are related to smart card use:
+
+-   [Smart Card Architecture](smart-card-architecture.md): Learn about enabling communications with smart cards and smart card readers, which can be different according to the vendor that supplies them.
+
+-   [Certificate Requirements and Enumeration](smart-card-certificate-requirements-and-enumeration.md): Learn about requirements for smart card certificates based on the operating system, and about the operations that are performed by the operating system when a smart card is inserted into the computer.
+
+-   [Smart Card and Remote Desktop Services](smart-card-and-remote-desktop-services.md): Learn about using smart cards for remote desktop connections.
+
+-   [Smart Cards for Windows Service](smart-card-smart-cards-for-windows-service.md): Learn about how the Smart Cards for Windows service is implemented.
+
+-   [Certificate Propagation Service](smart-card-certificate-propagation-service.md): Learn about how the certificate propagation service works when a smart card is inserted into a computer.
+
+-   [Smart Card Removal Policy Service](smart-card-removal-policy-service.md): Learn about using Group Policy to control what happens when a user removes a smart card.

windows/keep-secure/smart-card-removal-policy-service.md

@@ -0,0 +1,35 @@
+---
+title: Smart Card Removal Policy Service (Windows 10)
+description: This topic for the IT professional describes the role of the removal policy service (ScPolicySvc) in smart card implementation.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Smart Card Removal Policy Service
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional describes the role of the removal policy service (ScPolicySvc) in smart card implementation.
+
+The smart card removal policy service is applicable when a user has signed in with a smart card and subsequently removes that smart card from the reader. The action that is performed when the smart card is removed is controlled by Group Policy settings. For more information, see [Smart Card Group Policy and Registry Settings](smart-card-group-policy-and-registry-settings.md).
+
+**Smart card removal policy service**
+
+![Smart card removal policy service](images/sc-image501.gif)
+
+The numbers in the previous figure represent the following actions:
+
+1.  Winlogon is not directly involved in monitoring for smart card removal events. The sequence of steps that are involved when a smart card is removed begins with the smart card credential provider in the sign-in UI process. When a user successfully signs in with a smart card, the smart card credential provider captures the reader name. This information is then stored in the registry with the session identifier where the sign in was initiated.
+
+2.  The smart card resource manager service notifies the smart card removal policy service that a sign-in has occurred.
+
+3.  ScPolicySvc retrieves the smart card information that the smart card credential provider stored in the registry. This call is redirected if the user is in a remote session. If the smart card is removed, ScPolicySvc is notified.
+
+4.  ScPolicySvc calls Remote Desktop Services to take the appropriate action if the request is to sign out the user or to disconnect the user's session, which might result in data loss. If the setting is configured to lock the computer when the smart card is removed, ScPolicySvc sends a message to Winlogon to lock the computer.
+
+## See also
+
+[How Smart Card Sign-in Works in Windows](smart-card-how-smart-card-sign-in-works-in-windows.md)

windows/keep-secure/smart-card-smart-cards-for-windows-service.md

@@ -0,0 +1,107 @@
+---
+title: Smart Cards for Windows Service (Windows 10)
+description: This topic for the IT professional and smart card developers describes how the Smart Cards for Windows service manages readers and application interactions.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Smart Cards for Windows Service
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional and smart card developers describes how the Smart Cards for Windows service (formerly called Smart Card Resource Manager) manages readers and application interactions.
+
+The Smart Cards for Windows service provides the basic infrastructure for all other smart card components as it manages smart card readers and application interactions on the computer. It is fully compliant with the specifications set by the PC/SC Workgroup. For information about these specifications, see the [PC/SC Workgroup Specifications Overview](http://www.pcscworkgroup.com/specifications/overview.php).
+
+The Smart Cards for Windows service runs in the context of a local service, and it is implemented as a shared service of the services host (svchost) process. The Smart Cards for Windows service, Scardsvr, has the following service description:
+
+```
+<serviceData
+    dependOnService="PlugPlay"
+    description="@%SystemRoot%\System32\SCardSvr.dll,-5"
+    displayName="@%SystemRoot%\System32\SCardSvr.dll,-1"
+    errorControl="normal"
+    group="SmartCardGroup"
+    imagePath="%SystemRoot%\system32\svchost.exe -k LocalServiceAndNoImpersonation"
+    name="SCardSvr"
+    objectName="NT AUTHORITY\LocalService"
+    requiredPrivileges="SeCreateGlobalPrivilege,SeChangeNotifyPrivilege"
+    sidType="unrestricted"
+    start="demand"
+    type="win32ShareProcess"
+    >
+  <failureActions resetPeriod="900">
+       <actions>
+          <action
+              delay="120000"
+              type="restartService"
+          />
+          <action
+              delay="300000"
+              type="restartService"
+          />
+          <action
+               delay="0"
+              type="none"
+          />
+      </actions>
+  </failureActions>
+  <securityDescriptor name="ServiceXSecurity"/>
+</serviceData>
+
+  <registryKeys buildFilter="">
+      <registryKey keyName="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SCardSvr\Parameters">
+      <registryValue
+          name="ServiceDll"
+          value="%SystemRoot%\System32\SCardSvr.dll"
+          valueType="REG_EXPAND_SZ"
+          />
+      <registryValue
+          name="ServiceMain"
+          value="CalaisMain"
+          valueType="REG_SZ"
+          />
+      <registryValue
+          name="ServiceDllUnloadOnStop"
+          value="1"
+          valueType="REG_DWORD"
+          />
+      </registryKey>
+  </registryKeys>
+```
+
+> **Note**&nbsp;&nbsp;For winscard.dll to be invoked as the proper class installer, the INF file for a smart card reader must specify the following for **Class** and **ClassGUID**:<br>
+`Class=SmartCardReader`<br>`ClassGuid={50DD5230-BA8A-11D1-BF5D-0000F805F530}`
+
+By default, the service is configured for manual mode. Creators of smart card reader drivers must configure their INFs so that they start the service automatically and winscard.dll files call a predefined entry point to start the service during installation. The entry point is defined as part of the **SmartCardReader** class, and it is not called directly. If a device advertises itself as part of this class, the entry point is automatically invoked to start the service when the device is inserted. Using this method ensures that the service is enabled when it is needed, but it is also disabled for users who do not use smart cards.
+
+When the service is started, it performs several functions:
+
+1.  It registers itself for service notifications.
+
+2.  It registers itself for Plug and Play (PnP) notifications related to device removal and additions.
+
+3.  It initializes its data cache and a global event that signals that the service has started.
+
+> **Note**&nbsp;&nbsp;For smart card implementations, consider sending all communications in Windows operating systems with smart card readers through the Smart Cards for Windows service. This provides an interface to track, select, and communicate with all drivers that declare themselves members of the smart card reader device group.
+
+The Smart Cards for Windows service categorizes each smart card reader slot as a unique reader, and each slot is also managed separately, regardless of the device's physical characteristics. The Smart Cards for Windows service handles the following high-level actions:
+
+-   Device introduction
+
+-   Reader initialization
+
+-   Notifying clients of new readers
+
+-   Serializing access to readers
+
+-   Smart card access
+
+-   Tunneling of reader-specific commands
+
+## See also
+
+[How Smart Card Sign-in Works in Windows](smart-card-how-smart-card-sign-in-works-in-windows.md)

windows/keep-secure/smart-card-tools-and-settings.md

@@ -0,0 +1,27 @@
+---
+title: Smart Card Tools and Settings (Windows 10)
+description: This topic for the IT professional and smart card developer links to information about smart card debugging, settings, and events.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Smart Card Tools and Settings
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional and smart card developer links to information about smart card debugging, settings, and events.
+
+This section of the Smart Card Technical Reference contains information about the following:
+
+-   [Smart Cards Debugging Information](smart-card-debugging-information.md): Learn about tools and services in supported versions of Windows to help identify certificate issues.
+
+-   [Smart Card Group Policy and Registry Settings](smart-card-group-policy-and-registry-settings.md): Learn about smart card-related Group Policy settings and registry keys that can be set on a per-computer basis, including how to edit and apply Group Policy settings to local or domain computers.
+
+-   [Smart Card Events](smart-card-events.md): Learn about events that can be used to manage smart cards in an organization, including how to monitor installation, use, and errors.
+
+## See also
+
+[Smart Card Technical Reference](smart-card-windows-smart-card-technical-reference.md)

windows/keep-secure/smart-card-windows-smart-card-technical-reference.md

@@ -0,0 +1,65 @@
+---
+title: Smart Card Technical Reference (Windows 10)
+description: This technical reference for the IT professional and smart card developer describes the Windows smart card infrastructure for physical smart cards and how smart card-related components work in Windows.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Smart Card Technical Reference
+
+Applies To: Windows 10, Windows Server 2016
+
+The Smart Card Technical Reference describes the Windows smart card infrastructure for physical smart cards and how smart card-related components work in Windows. This document also contains information about tools that information technology (IT) developers and administrators can use to troubleshoot, debug, and deploy smart card-based strong authentication in the enterprise.
+
+## Audience
+
+This document explains how the Windows smart card infrastructure works. To understand this information, you should have basic knowledge of public key infrastructure (PKI) and smart card concepts. This document is intended for:
+
+-   Enterprise IT developers, managers, and staff who are planning to deploy or are using smart cards in their organization.
+
+-   Smart card vendors who write smart card minidrivers or credential providers.
+
+## What are smart cards?
+
+Smart cards are tamper-resistant portable storage devices that can enhance the security of tasks such as authenticating clients, signing code, securing e-mail, and signing in with a Windows domain account.
+
+Smart cards provide:
+
+-   Tamper-resistant storage for protecting private keys and other forms of personal information.
+
+-   Isolation of security-critical computations that involve authentication, digital signatures, and key exchange from other parts of the computer. These computations are performed on the smart card.
+
+-   Portability of credentials and other private information between computers at work, home, or on the road.
+
+Smart cards can be used to sign in to domain accounts only, not local accounts. When you use a password to sign in interactively to a domain account, Windows uses the Kerberos version 5 (v5) protocol for authentication. If you use a smart card, the operating system uses Kerberos v5 authentication with X.509 v3 certificates.
+
+**Virtual smart cards** were introduced in Windows Server 2012 and Windows 8 to alleviate the need for a physical smart card, the smart card reader, and the associated administration of that hardware. For information about virtual smart card technology, see [Virtual Smart Card Overview](virtual-smart-card-overview.md).
+
+## In this technical reference
+
+This reference contains the following topics.
+
+-   [How Smart Card Sign-in Works in Windows](smart-card-how-smart-card-sign-in-works-in-windows.md)
+
+    -   [Smart Card Architecture](smart-card-architecture.md)
+
+    -   [Certificate Requirements and Enumeration](smart-card-certificate-requirements-and-enumeration.md)
+
+    -   [Smart Card and Remote Desktop Services](smart-card-and-remote-desktop-services.md)
+
+    -   [Smart Cards for Windows Service](smart-card-smart-cards-for-windows-service.md)
+
+    -   [Certificate Propagation Service](smart-card-certificate-propagation-service.md)
+
+    -   [Smart Card Removal Policy Service](smart-card-removal-policy-service.md)
+
+-   [Smart Card Tools and Settings](smart-card-tools-and-settings.md)
+
+    -   [Smart Cards Debugging Information](smart-card-debugging-information.md)
+
+    -   [Smart Card Group Policy and Registry Settings](smart-card-group-policy-and-registry-settings.md)
+
+    -   [Smart Card Events](smart-card-events.md)

windows/keep-secure/virtual-smart-card-deploy-virtual-smart-cards.md

@@ -0,0 +1,275 @@
+---
+title: Deploy Virtual Smart Cards (Windows 10)
+description: This topic for the IT professional discusses the factors to consider when you deploy a virtual smart card authentication solution.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Deploy Virtual Smart Cards
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional discusses the factors to consider when you deploy a virtual smart card authentication solution.
+
+Traditional identity devices, such as physical smart cards, follow a predictable lifecycle in any deployment, as shown in the following diagram.
+
+![Diagram of physical smart card lifecycle](images/vsc-physical-smart-card-lifecycle.png)
+
+Physical devices are created by a dedicated manufacturer and then purchased by the corporation that will ultimately deploy it. The device passes through the personalization stage, where its unique properties are set. In smart cards, these properties are the administrator key, Personal Identification Number (PIN), PIN Unlock Key (PUK), and its physical appearance. To provision the device, it is loaded with the required certificates, such as a sign-in certificate. After you provision the device, it is ready for use. The device must simply be maintained. For example, you must replace cards when they are lost or stolen and reset PINs when users forget them. Finally, you’ll retire devices when they exceed their intended lifetime or when employees leave the company.
+
+This topic contains information about the following phases in a virtual smart card lifecycle:
+
+-   [Create and personalize virtual smart cards](#create-and-personalize-virtual-smart-cards)
+
+-   [Provision virtual smart cards](#provision-virtual-smart-cards)
+
+-   [Maintain virtual smart cards](#maintain-virtual-smart-cards)
+
+## Create and personalize virtual smart cards
+
+A corporation purchases the devices to deploy then. The device passes through the personalization stage, where its unique properties are set. In smart cards, these properties are the administrator key, Personal Identification Number (PIN), PIN Unlock Key (PUK), and its physical appearance. The security that is provided for a TPM virtual smart card is fully provisioned in the host TPM.
+
+### Trusted Platform Module readiness
+
+The TPM Provisioning Wizard, which is launched from the **TPM Management Console**, takes the user through all the steps to prepare the TPM for use.
+
+When you create virtual smart cards, consider the following actions in the TPM:
+
+-   **Enable and Activate**: TPMs are built in to many industry ready computers, but they often are not enabled and activated by default. In some cases, the TPM must be enabled and activated through the BIOS. For more information, see Initialize and Configure Ownership of the TPM.
+
+-   **Take ownership**: When you provision the TPM, you set an owner password for managing the TPM in the future, and you establish the storage root key. To provide anti-hammering protection for virtual smart cards, the user or a domain administrator must be able to reset the TPM owner password.
+    For corporate use of TPM virtual smart cards, we recommend that the corporate domain administrator restrict access to the TPM owner password by storing it in Active Directory, not in the local registry. When TPM ownership is set in Windows Vista, the TPM needs to be cleared and reinitialized. For more information, see Trusted Platform Module Technology Overview.
+
+-   **Manage**: You can manage ownership of a virtual smart card by changing the owner password, and you can manage anti-hammering logic by resetting the lockout time. For more information, see Manage TPM Lockout.
+
+A TPM might operate in reduced functionality mode. This could occur, for example, if the operating system cannot determine if the owner password is available to the user. In those cases, the TPM can be used to create a virtual smart card, but it is strongly recommended to bring the TPM to a fully ready state so that any unexpected circumstances will not leave the user blocked from using the computer.
+
+Those smart card deployment management tools that require a status check of a TPM before attempting to create a TPM virtual smart card can do so using the TPM WMI interface.
+
+Depending on the setup of the computer that is designated for installing TPM virtual smart cards, it might be necessary to provision the TPM before continuing with the virtual smart card deployment. For more information about provisioning, see [Use Virtual Smart Cards](virtual-smart-card-use-virtual-smart-cards.md).
+
+For more information about managing TPMs by using built-in tools, see Trusted Platform Module Services Group Policy Settings.
+
+### Creation
+
+A TPM virtual smart card simulates a physical smart card, and it uses the TPM to provide the same functionality as physical smart card hardware. A virtual smart card appears within the operating system as a physical smart card that is always inserted. Supported versions of the Windows operating system present a virtual smart card reader and virtual smart card to applications with the same interface as physical smart cards, but messages to and from the virtual smart card are translated to TPM commands. This process ensures the integrity of the virtual smart card through the three properties of smart card security:
+
+-   **Non-exportability**: Because all private information on the virtual smart card is encrypted by using the TPM on the host computer, it cannot be used on a different computer with a different TPM. Additionally, TPMs are designed to be tamper-resistant and non-exportable, so a malicious user cannot reverse engineer an identical TPM or install the same TPM on a different computer.
+    For more information, see [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md).
+
+-   **Isolated cryptography**: TPMs provide the same properties of isolated cryptography that is offered by physical smart cards, and this is utilized by virtual smart cards. Unencrypted copies of private keys are loaded only within the TPM and never into memory that is accessible by the operating system. All cryptographic operations with these private keys occur inside the TPM.
+
+-   **Anti-hammering**: If a user enters a PIN incorrectly, the virtual smart card responds by using the anti-hammering logic of the TPM, which rejects further attempts for a period of time instead of blocking the card. This is also known as lockout.
+    For more information, see [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md).
+
+There are several options for creating virtual smart cards, depending on the size of the deployment and budget of the organization. The lowest cost option is using Tpmvscmgr.exe to create cards individually on users’ computers. Alternatively, a virtual smart card management solution can be purchased to more easily accomplish virtual smart card creation on a larger scale and aid in further phases of deployment. Virtual smart cards can be created on computers that are to be provisioned for an employee or on those that are already in an employee’s possession. In either approach, there should be some central control over personalization and provisioning. If a computer is intended for use by multiple employees, multiple virtual smart cards can be created on a computer.
+
+For information about the TPM Virtual Smart Card command-line tool, see [Tpmvscmgr](virtual-smart-card-tpmvscmgr.md).
+
+### Personalization
+
+During virtual smart card personalization, the values for the administrator key, PIN, and PUK are assigned. As with a physical card, knowing the administrator key is important for resetting the PIN or for deleting the card in the future. (If a PUK is set, the administrator key can no longer be used to reset the PIN.)
+
+Because the administrator key is critical to the security of the card, it is important to consider the deployment environment and decide on the proper administrator key setting strategy. Options for these strategies include:
+
+-   **Uniform**: Administrator keys for all the virtual smart cards that are deployed in the organization are the same. Although this makes the maintenance infrastructure easy (only one key needs to be stored), it is highly insecure. This strategy might be sufficient for very small organizations, but if the administrator key is compromised, all virtual smart cards that use this key must be reissued.
+
+-   **Random, not stored**: Administrator keys are assigned randomly for all virtual smart cards, and they are not recorded. This is a valid option if the deployment administrators do not require the ability to reset PINs, and instead prefer to delete and reissue virtual smart cards. This could also be a viable strategy if the administrator prefers to set PUK values for the virtual smart cards and then use this value to reset PINs, if necessary.
+
+-   **Random, stored**: Administrator keys are assigned randomly and stored in a central location. Each card’s security is independent of the others. This is secure on a large scale unless the administrator key database is compromised.
+
+-   **Deterministic**: Administrator keys are the result of some function or known information. For example, the user ID could be used to randomly generate data that can be further processed through a symmetric encryption algorithm by using a secret. This administrator key can be similarly regenerated when needed, and it does not need to be stored. The security of this method relies on the security of the secret used.
+
+Although the PUK and the administrator key methodologies provide unlocking and resetting functionality, they do so in different ways. The PUK is a PIN that is simply entered on the computer to enable a user PIN reset.
+
+The administrator key methodology takes a challenge-response approach. The card provides a set of random data after users verify their identity to the deployment administrator. The administrator then encrypts the data with the administrator key and gives the encrypted data back to the user. If the encrypted data matches that produced by the card during verification, the card will allow PIN reset. Because the administrator key is never accessible by anyone other than the deployment administrator, it cannot be intercepted or recorded by any other party (including employees). This provides significant security benefits beyond using a PUK, an important consideration during the personalization process.
+
+TPM virtual smart cards can be personalized on an individual basis when they are created with the Tpmvscmgr command-line tool. Or organizations can purchase a management solution that can incorporate personalization into an automated routine. An additional advantage of such a solution is the automated creation of administrator keys. Tpmvscmgr.exe allows users to create their own administrator keys, which can be detrimental to the security of the virtual smart cards.
+
+## Provision virtual smart cards
+
+Provisioning is the process of loading specific credentials onto a TPM virtual smart card. These credentials consist of certificates that are created to give users access to a specific service, such as domain sign in. A maximum of 30 certificates is allowed on each virtual smart card. As with physical smart cards, several decisions must be made regarding the provisioning strategy, based on the environment of the deployment and the desired level of security.
+
+A high-assurance level of secure provisioning requires absolute certainty about the identity of the individual who is receiving the certificate. Therefore, one method of high-assurance provisioning is utilizing previously provisioned strong credentials, such as a physical smart card, to validate identity during provisioning. In-person proofing at enrollment stations is another option, because an individual can easily and securely prove his or her identity with a passport or driver’s license, although this can become infeasible on a larger scale. To achieve a similar level of assurance, a large organization can implement an “enroll-on-behalf-of” strategy, in which employees are enrolled with their credentials by a superior who can personally verify their identities. This creates a chain of trust that ensures individuals are checked in person against their proposed identities, but without the administrative strain of provisioning all virtual smart cards from a single central enrollment station.
+
+For deployments in which a high-assurance level is not a primary concern, you can use self-service solutions. These can include using an online portal to obtain credentials or simply enrolling for certificates by using Certificate Manager, depending on the deployment. Consider that virtual smart card authentication is only as strong as the method of provisioning. For example, if weak domain credentials (such as a password alone) are used to request the authentication certificate, virtual smart card authentication will be equivalent to using only the password, and the benefits of two-factor authentication are lost.
+
+For information about using Certificate Manager to configure virtual smart cards, see [Get Started with Virtual Smart Cards: Walkthrough Guide](virtual-smart-card-get-started.md).
+
+High-assurance and self-service solutions approach virtual smart card provisioning by assuming that the user’s computer has been issued prior to the virtual smart card deployment, but this is not always the case. If virtual smart cards are being deployed with new computers, they can be created, personalized, and provisioned on the computer before the user has contact with that computer.
+
+In this situation, provisioning becomes relatively simple, but identity checks must be put in place to ensure that the recipient of the computer is the individual who was expected during provisioning. This can be accomplished by requiring the employee to set the initial PIN under the supervision of the deployment administrator or manager.
+
+When you are provisioning your computers, you should also consider the longevity of credentials that are supplied for virtual smart cards. This choice must be based on the risk threshold of the organization. Although longer lived credentials are more convenient, they are also more likely to become compromised during their lifetime. To decide on the appropriate lifetime for credentials, the deployment strategy must take into account the vulnerability of their cryptography (how long it could take to crack the credentials), and the likelihood of attack.
+
+If a virtual smart card is compromised, administrators should be able to revoke the associated credentials, like they would with a lost or stolen laptop. This requires a record of which credentials match which user and computer, which is functionality that does not exist natively in Windows. Deployment administrators might want to consider add-on solutions to maintain such a record.
+
+### Virtual smart cards on consumer devices used for corporate access
+
+There are techniques that allow employees to provision virtual smart cards and enroll for certificates that can be used to authenticate the users. This is useful when employees attempt to access corporate resources from devices that are not joined to the corporate domain. Those devices can be further defined to not allow users to download and run applications from sources other than the Windows Store (for example, devices running Windows RT).
+
+You can use APIs that were introduced in Windows Server 2012 R2 and Windows 8.1 to build Windows Store apps that you can use to manage the full lifecycle of virtual smart cards. For more information, see [Create and delete virtual smart cards programmatically](virtual-smart-card-use-virtual-smart-cards.md#create-and-delete-virtual-smart-cards-programmatically).
+
+#### TPM ownerAuth in the registry
+
+When a device or computer is not joined to a domain, the TPM ownerAuth is stored in the registry under HKEY\_LOCAL\_MACHINE. This exposes some threats. Most of the threat vectors are protected by BitLocker, but threats that are not protected include:
+
+-   A malicious user possesses a device that has an active local sign-in session before the device locks. The malicious user could attempt a brute-force attack on the virtual smart card PIN, and then access the corporate secrets.
+
+-   A malicious user possesses a device that has an active virtual private network (VPN) session. The device is then compromised.
+
+The proposed mitigation for the previous scenarios is to use Exchange ActiveSync (EAS) policies to reduce the automatic lockout time from five minutes to 30 seconds of inactivity. Policies for automatic lockout can be set while provisioning virtual smart cards. If an organization wants more security, they can also configure a setting to remove the ownerAuth from the local device.
+
+For configuration information about the TPM ownerAuth registry key, see the Group Policy setting Configure the level of TPM owner authorization information available to the operating system.
+
+<!-- Replace following link if a newer one becomes available for similar content. -->
+
+For information about EAS policies, see [Exchange ActiveSync Policy Engine Overview](https://technet.microsoft.com/library/dn282287(v=ws.11).aspx).
+
+#### Managed and unmanaged cards
+
+The following table describes the important differences between managed and unmanaged virtual smart cards that exist on consumer devices:
+
+<!-- Check on whether the middle column header is correct - it probably should be [Managed cards](#managed-cards)    -->
+
+| Operation                          | [Managed and unmanaged cards](virtual-smart-card-deploy-virtual-smart-cards.md#managed-and-unmanaged-cards) | [Unmanaged cards](virtual-smart-card-deploy-virtual-smart-cards.md#unmanaged-cards) |
+|-----------------------------------------|--------------|----|
+| Reset PIN when the user forgets the PIN | Yes      | No, the card has to be deleted and created again.     |
+| Allow user to change the PIN            | Yes      | No, the card has to be deleted and created again.     |
+
+## Managed cards
+
+A managed virtual smart card can be serviced by the IT administrator or another person in that designated role. It allows the IT administrator to have influence or complete control over specific aspects of the virtual smart card from its creation to deletion. To manage these cards, a virtual smart card deployment management tool is often required.
+
+### Managed card creation
+
+A user can create blank virtual smart card by using the Tpmvscmgr command-line tool, which is a built-in tool that is run with administrative credentials through an elevated command prompt. This virtual smart card needs to be created with well-known parameters (such as default values), and it should be left unformatted (specifically, the **/generate** option should not be specified).
+
+The following command creates a virtual smart card that can later be managed by a smart card management tool launched from another computer (as explained in the next section):
+
+`tpmvscmgr.exe create /name "VirtualSmartCardForCorpAccess" /AdminKey DEFAULT /PIN PROMPT`
+
+Alternatively, instead of using a default administrator key, a user can enter an administrator key at the command line:
+
+`tpmvscmgr.exe create /name "VirtualSmartCardForCorpAccess" /AdminKey PROMPT /PIN PROMPT`
+
+In either case, the card management system needs to be aware of the initial administrator key that is used so that it can take ownership of the virtual smart card and change the administrator key to a value that is only accessible through the card management tool operated by the IT administrator. For example, when the default value is used, the administrator key is set to:
+
+`10203040506070801020304050607080102030405060708`
+
+For information about using this command-line tool, see [Tpmvscmgr](virtual-smart-card-tpmvscmgr.md).
+
+### Managed card management
+
+After the virtual smart card is created, the user needs to open a remote desktop connection to an enrollment station, for example, in a computer that is joined to the domain. Virtual smart cards that are associated with a client computer are available for use in the remote desktop connection. The user can open a card management tool inside the remote session that can take ownership of the card and provision it for use by the user. This requires that a user is allowed to establish a remote desktop connection from a non-domain-joined computer to a domain-joined computer. This might require a specific network configuration, such as through IPsec policies.
+
+When users need to reset or change a PIN, they need to use the remote desktop connection to complete these operations. They can use the built-in tools for PIN unlock and PIN change or the smart card management tool.
+
+### Certificate management for managed cards
+
+Similar to physical smart cards, virtual smart cards require certificate enrollment.
+
+#### Certificate issuance
+
+Users can enroll for certificates from within a remote desktop session that is established to provision the card. This process can also be managed by the smart card management tool that the user runs through the remote desktop connection. This model works for deployments that require the user to sign a request for enrollment by using a physical smart card. The driver for the physical smart card does not need to be installed on the client computer if it is installed on the remote computer. This is made possible by smart card redirection functionality that was introduced in Windows Server 2003, which ensures that smart cards that are connected to the client computer are available for use during a remote session.
+
+Alternatively, without establishing a remote desktop connection, users can enroll for certificates from the Certificate Management console (certmgr.msc) on a client computer. Users can also create a request and submit it to a server from within a custom certificate enrollment application (for example, a registration authority) that has controlled access to the certification authority (CA). This requires specific enterprise configuration and deployments for Certificate Enrollment Policies (CEP) and Certificate Enrollment Services (CES).
+
+#### Certificate lifecycle management
+
+You can renew certificates through remote desktop connections, certificate enrollment policies, or certificate enrollment services. Renewal requirements could be different from the initial issuance requirements, based on the renewal policy.
+
+Certificate revocation requires careful planning. When information about the certificate to be revoked is reliably available, the specific certificate can be easily revoked. When information about the certificate to be revoked is not easy to determine, all certificates that are issued to the user under the policy that was used to issue the certificate might need to be revoked. For example, this could occur if an employee reports a lost or compromised device, and information that associates the device with a certificate is not available.
+
+## Unmanaged cards
+
+Unmanaged virtual smart cards are not serviceable by an IT administrator. Unmanaged cards might be suitable if an organzation does not have an elaborate smart card deployment management tool and using remote desktop connections to manage the card is not desirable. Because unmanaged cards are not serviceable by the IT administrator, when a user needs help with a virtual smart card (for example, resetting or unlocking a PIN), the only option available to the user is to delete the card and create it again. This results in loss of the user’s credentials and he or she must re-enroll.
+
+### Unmanaged card creation
+
+A user can create a virtual smart card by using the Tpmvscmgr command-line tool, which is run with administrative credentials through an elevated command prompt. The following command creates an unmanaged card that can be used to enroll certificates:
+
+`tpmvscmgr.exe create /name "VirtualSmartCardForCorpAccess" /AdminKey RANDOM /PIN PROMPT /generate`
+
+This command creates a card with a randomized administrator key. The key is automatically discarded after the creation of the card. If users forget or want to change their PIN, they need to delete the card and create it again. To delete the card, a user can run the following command:
+
+`tpmvscmgr.exe destroy /instance <instance ID>`
+
+where &lt;instance ID&gt; is the value that is printed on the screen when the user creates the card. Specifically, for the first card created, the instance ID is ROOT\\SMARTCARDREADER\\0000).
+
+### Certificate management for unmanaged cards
+
+Depending on the security requirements that are unique to an organization, users can initially enroll for certificates from the certificate management console (certmgr.msc) or from within custom certificate enrollment applications. The latter method can create a request and submit it to a server that has access to the Certification Authority. This requires specific organizational configurations and deployments for certificate enrollment policies and certificate enrollment services. Windows has built-in tools, specifically Certreq.exe and Certutil.exe, which can be used by scripts to perform the enrollment from the command line.
+
+#### Requesting the certificate by providing domain credentials only
+
+The simplest way for users to request certificates is to provide their domain credentials through a script that can perform the enrollment through built-in components you have in place for certificate requests.
+
+Alternatively, an application (such as a line-of-business app) can be installed on the computer to perform enrollment by generating a request on the client. The request is submitted to an HTTP server, which can forward it to a registration authority.
+
+Another option is to have the user access an enrollment portal that is available through Internet Explorer. The webpage can use the scripting APIs to perform certificate enrollment.
+
+#### Signing the request with another certificate
+
+You can provide users with a short-term certificate through a Personal Information Exchange (.pfx) file. You can generate the .pfx file by initiating a request from a domain-joined computer. Additional policy constraints can be enforced on the .pfx file to assert the identity of the user.
+
+The user can import the certificate into the **MY** store (which is the user’s certificate store). And your organization can present the user with a script that can be used to sign the request for the short-term certificate and to request a virtual smart card.
+
+For deployments that require users to use a physical smart card to sign the certificate request, you can use the procedure:
+
+1.  Users initiate a request on a domain-joined computer.
+
+2.  Users complete the request by using a physical smart card to sign the request.
+
+3.  Users download the request to the virtual smart card on their client computer.
+
+#### Using one-time password for enrollment
+
+Another option to ensure that users are strongly authenticated before virtual smart card certificates are issued is to send a user a one-time password through SMS, email, or phone. The user then types the one-time password during the certificate enrollment from an application or a script on a desktop that invokes built-in command-line tools.
+
+#### Certificate lifecycle management
+
+Certificate renewal can be done from the same tools that are used for the initial certificate enrollment. Certificate enrollment policies and certificate enrollment services can also be used to perform automatic renewal.
+
+Certificate revocation requires careful planning. When information about the certificate to be revoked is reliably available, the specific certificate can be easily revoked. When information about the certificate to be revoked is not easy to determine, all certificates that are issued to the user under the policy that was used to issue the certificate might need to be revoked. For example, this could occur if an employee reports a lost or compromised device, and information that associates the device with a certificate is not available.
+
+## Maintain virtual smart cards
+
+Maintenance is a significant portion of the virtual smart card lifecycle and one of the most important considerations from a management perspective. After virtual smart cards are created, personalized, and provisioned, they can be used for convenient two-factor authentication. Deployment administrators must be aware of several common administrative scenarios, which can be approached by using a purchased virtual smart card solution or on a case-by-case basis with in-house methods.
+
+**Renewal**: Renewing virtual smart card credentials is a regular task that is necessary to preserve the security of a virtual smart card deployment. Renewal is the result of a signed request from a user who specifies the key pair desired for the new credentials. Depending on user’s choice or deployment specification, the user can request credentials with the same key pair as previously used, or choose a newly generated key pair.
+
+When renewing with a previously used key, no extra steps are required because a strong certificate with this key was issued during the initial provisioning. However, when the user requests a new key pair, you must take the same steps that were used during provisioning to assure the strength of the credentials. Renewal with new keys should occur periodically to counter sophisticated long-term attempts by malicious users to infiltrate the system. When new keys are assigned, you must ensure that the new keys are being used by the expected individuals on the same virtual smart cards.
+
+**Resetting PINs**: Resetting virtual smart card PINs is also a frequent necessity, because employees forget their PINs. There are two ways to accomplish this, depending on choices made earlier in the deployment: Use a PUK (if the PUK is set), or use a challenge-response approach with the administration key. Before resetting the PIN, the user’s identity must be verified by using some means other than the card—most likely the verification method that you used during initial provisioning (for example, in-person proofing). This is necessary in user-error scenarios when users forget their PINs. However, you should never reset a PIN if it has been compromised because the level of vulnerability after the PIN is exposed is difficult to identify. The entire card should be reissued.
+
+**Lockout reset**: A frequent precursor to resetting a PIN is the necessity of resetting the TPM lockout time because the TPM anti-hammering logic will be engaged with multiple PIN entry failures for a virtual smart card. This is currently device specific.
+
+**Retiring cards**: The final aspect of virtual smart card management is retiring cards when they are no longer needed. When an employee leaves the company, it is desirable to revoke domain access. Revoking sign-in credentials from the certification authority (CA) accomplishes this goal.
+
+The card should be reissued if the same computer is used by other employees without reinstalling the operating system. Reusing the former card can allow the former employee to change the PIN after leaving the organization, and then hijack certificates that belong to the new user to obtain unauthorized domain access. However, if the employee takes the virtual smart card-enabled computer, it is only necessary to revoke the certificates that are stored on the virtual smart card.
+
+### Emergency preparedness
+
+#### Card reissuance
+
+The most common scenario in an organization is reissuing virtual smart cards, which can be necessary if the operating system is reinstalled or if the virtual smart card is compromised in some manner. Reissuance is essentially the recreation of the card, which involves establishing a new PIN and administrator key and provisioning a new set of associated certificates. This is an immediate necessity when a card is compromised, for example, if the virtual smart card-protected computer is exposed to an adversary who might have access to the correct PIN. Reissuance is the most secure response to an unknown exposure of a card’s privacy. Additionally, reissuance is necessary after an operating system is reinstalled because the virtual smart card device profile is removed with all other user data when the operating system is reinstalled.
+
+#### Blocked virtual smart card
+
+The anti-hammering behavior of a TPM virtual smart card is different from that of a physical smart card. A physical smart card blocks itself after the user enters the wrong PIN a few times. A TPM virtual smart card enters a timed delay after the user enters the wrong PIN a few times. If the TPM is in the timed-delay mode, when the user attempts to use the TPM virtual smart card, the user is notified that the card is blocked. Furthermore, if you enable the integrated unlock functionality, the user can see the user interface to unlock the virtual smart card. Unlocking the virtual smart card does not reset the TPM lockout. The user needs to perform an extra step to reset the TPM lockout or wait for the timed delay to expire.
+
+## See also
+
+[Understanding and Evaluating Virtual Smart Cards](virtual-smart-card-understanding-and-evaluating.md)
+
+[Get Started with Virtual Smart Cards: Walkthrough Guide](virtual-smart-card-get-started.md)
+
+[Use Virtual Smart Cards](virtual-smart-card-use-virtual-smart-cards.md)
+
+[Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md)
+
+[Tpmvscmgr](virtual-smart-card-tpmvscmgr.md)

windows/keep-secure/virtual-smart-card-evaluate-security.md

@@ -0,0 +1,61 @@
+---
+title: Evaluate Virtual Smart Card Security (Windows 10)
+description: This topic for the IT professional describes security characteristics and considerations when deploying TPM virtual smart cards.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Evaluate Virtual Smart Card Security
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional describes security characteristics and considerations when deploying TPM virtual smart cards.
+
+## Virtual smart card non-exportability details
+
+A crucial aspect of TPM virtual smart cards is their ability to securely store and use secret data, specifically that the secured data is non-exportable. Data can be accessed and used within the virtual smart card system, but it is meaningless outside of its intended environment. In TPM virtual smart cards, security is ensured with a secure key hierarchy, which includes several chains of encryption. This originates with the TPM storage root key, which is generated and stored within the TPM and never exposed outside the chip. The TPM key hierarchy is designed to allow encryption of user data with the storage root key, but it authorizes decryption with the user PIN in such a way that changing the PIN doesn’t require re-encryption of the data.
+
+The following diagram illustrates the secure key hierarchy and the process of accessing the user key.
+
+![Diagram of the process of accessing the user key](images/vsc-process-of-accessing-user-key.png)
+
+The following keys are stored on the hard disk:
+
+-   User key
+
+-   Smart card key, which is encrypted by the storage root key
+
+-   Authorization key for the user key decryption, which is encrypted by the public portion of the smart card key
+
+When the user enters a PIN, the use of the decrypted smart card key is authorized with this PIN. If this authorization succeeds, the decrypted smart card key is used to decrypt the auth key. The auth key is then provided to the TPM to authorize the decryption and use of the user’s key that is stored on the virtual smart card.
+
+The auth key is the only sensitive data that is used as plaintext outside the TPM, but its presence in memory is protected by Microsoft Data Protection API (DPAPI), such that before being stored in any way, it is encrypted. All data other than the auth key is processed only as plaintext within the TPM, which is completely isolated from external access.
+
+## Virtual smart card anti-hammering details
+
+The anti-hammering functionality of virtual smart cards relies on the anti-hammering functionality of the TPM that is enabling the virtual smart card. However, the TPM version 1.2 and subsequent specifications (as designed by the Trusted Computing Group) provide very flexible guidelines for responding to hammering. The spec requires only that the TPM implement protection against trial-and-error attacks on the user PIN, PUK, and challenge/response mechanism.
+
+The Trusted Computing Group also specifies that if the response to attacks involves suspending proper function of the TPM for some period of time or until administrative action is taken, the TPM must prevent running the authorized TPM commands. The TPM can prevent running any TPM commands until the termination of the attack response. Beyond using a time delay or requiring administrative action, a TPM could also force a reboot when an attack is detected. The Trusted Computing Group allows manufacturers a level of creativity in their choice of implementation. Whatever methodology is chosen by TPM manufacturers determines the anti-hammering response of TPM virtual smart cards. Some typical aspects of protection from attacks include:
+
+1.  Allow only a limited number of wrong PIN attempts before enabling a lockout that enforces a time delay before any further commands are accepted by the TPM.
+
+    > **Note**  Introduced in Windows Server 2012 R2 and Windows 8.1, if the user enters the wrong PIN five consecutive times for a virtual smart card (which works in conjunction with the TPM), the card is blocked. When the card is blocked, it has to be unblocked by using the administrative key or the PUK.
+
+1.  Increase the time delay exponentially as the user enters the wrong PIN so that an excessive number of wrong PIN attempts quickly trigger long delays in accepting commands.
+
+2.  Have a failure leakage mechanism to allow the TPM to reset the timed delays over a period of time. This is useful in cases where a valid user has entered the wrong PIN occasionally, for example, due to complexity of the PIN.
+
+As an example, it will take 14 years to guess an 8-character PIN for a TPM that implements the following protection:
+
+1.  Number of wrong PINs allowed before entering lockout (threshold): 9
+
+2.  Time the TPM is in lockout after the threshold is reached: 10 seconds
+
+3.  Timed delay doubles for each wrong PIN after the threshold is reached
+
+## See also
+
+[Understanding and Evaluating Virtual Smart Cards](virtual-smart-card-understanding-and-evaluating.md)

windows/keep-secure/virtual-smart-card-get-started.md

@@ -0,0 +1,165 @@
+---
+title: Get Started with Virtual Smart Cards - Walkthrough Guide (Windows 10)
+description: This topic for the IT professional describes how to set up a basic test environment for using TPM virtual smart cards.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Get Started with Virtual Smart Cards: Walkthrough Guide
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional describes how to set up a basic test environment for using TPM virtual smart cards.
+
+Virtual smart cards are a technology from Microsoft, which offer comparable security benefits in two-factor authentication to physical smart cards. They also offer more convenience for users and lower cost for organizations to deploy. By utilizing Trusted Platform Module (TPM) devices that provide the same cryptographic capabilities as physical smart cards, virtual smart cards accomplish the three key properties that are desired by smart cards: non-exportability, isolated cryptography, and anti-hammering.
+
+This step-by-step walkthrough shows you how to set up a basic test environment for using TPM virtual smart cards. After you complete this walkthrough, you will have a functional virtual smart card installed on the Windows computer.
+
+**Time requirements**
+
+You should be able to complete this walkthrough in less than one hour, excluding installing software and setting up the test domain.
+
+**Walkthrough steps**
+
+-   [Prerequisites](#prerequisites)
+
+-   [Step 1: Create the certificate template](#step-1-create-the-certificate-template)
+
+-   [Step 2: Create the TPM virtual smart card](#step-2-create-the-tpm-virtual-smart-card)
+
+-   [Step 3: Enroll for the certificate on the TPM Virtual Smart Card](#step-3-enroll-for-the-certificate-on-the-tpm-virtual-smart-card)
+
+> **Important**  This basic configuration is for test purposes only. It is not intended for use in a production environment.
+
+## Prerequisites
+
+You will need:
+
+-   A computer running Windows 10 with an installed and fully functional TPM (version 1.2 or version 2.0).
+
+-   A test domain to which the computer listed above can be joined.
+
+-   Access to a server in that domain with a fully installed and running certification authority (CA).
+
+## Step 1: Create the certificate template
+
+On your domain server, you need to create a template for the certificate that you will request for the virtual smart card.
+
+### To create the certificate template
+
+1.  On your server, open the Microsoft Management Console (MMC). One way to do this is to type **mmc.exe** from the **Start** menu, right-click **mmc.exe**, and click **Run as administrator**.
+
+2.  Click **File**, and then click **Add/Remove Snap-in**.
+
+    ![Add or remove snap-in](images/vsc-02-mmc-add-snap-in.png)
+
+3.  In the available snap-ins list, click **Certificate Templates**, and then click **Add**.
+
+    ![Add Certificate Templates snap-in](images/vsc-03-add-certificate-templates-snap-in.png)
+
+4.  Certificate Templates is now located under **Console Root** in the MMC. Double-click it to view all the available certificate templates.
+
+5.  Right-click the **Smartcard Logon** template, and click **Duplicate Template**.
+
+    ![Duplicating the Smartcard Logon template](images/vsc-04-right-click-smartcard-logon-template.png)
+
+6.  On the **Compatibility** tab, under **Certification Authority**, review the selection, and change it if needed.
+
+    ![Compatibility tab, certification authority setting](images/vsc-05-certificate-template-compatibility.png)
+
+7.  On the **General** tab:
+
+    1.  Specify a name, such as **TPM Virtual Smart Card Logon**.
+
+    2.  Set the validity period to the desired value.
+
+8.  On the **Request Handling** tab:
+
+    1.  Set the **Purpose** to **Signature and smartcard logon**.
+
+    2.  Click **Prompt the user during enrollment**.
+
+9.  On the **Cryptography** tab:
+
+    1.  Set the minimum key size to 2048.
+
+    2.  Click **Requests must use one of the following providers**, and then select **Microsoft Base Smart Card Crypto Provider**.
+
+10.  On the **Security** tab, add the security group that you want to give **Enroll** access to. For example, if you want to give access to all users, select the **Authenticated users** group, and then select **Enroll** permissions for them.
+
+11.  Click **OK** to finalize your changes and create the new template. Your new template should now appear in the list of Certificate Templates.
+
+12.  Select **File**, then click **Add/Remove Snap-in** to add the Certification Authority snap-in to your MMC console. When asked which computer you want to manage, select the computer on which the CA is located, probably **Local Computer**.
+
+    ![Add Certification Authority snap-in](images/vsc-06-add-certification-authority-snap-in.png)
+
+13.  In the left pane of the MMC, expand **Certification Authority (Local)**, and then expand your CA within the Certification Authority list.
+
+14.  Right-click **Certificate Templates**, click **New**, and then click **Certificate Template to Issue**.
+
+    ![Right-click menu for Certificate Templates](images/vsc-07-right-click-certificate-templates.png)
+
+15.  From the list, select the new template that you just created (**TPM Virtual Smart Card Logon**), and then click **OK**.
+
+    > **Note**  It can take some time for your template to replicate to all servers and become available in this list.
+
+    ![Selecting a certificate template](images/vsc-08-enable-certificate-template.png)
+
+16.  After the template replicates, in the MMC, right-click in the Certification Authority list, click **All Tasks**, and then click **Stop Service**. Then, right-click the name of the CA again, click **All Tasks**, and then click **Start Service**.
+
+    ![Stopping and starting the service](images/vsc-09-stop-service-start-service.png)
+
+## Step 2: Create the TPM virtual smart card
+
+In this step, you will create the virtual smart card on the client computer by using the command-line tool, [Tpmvscmgr.exe](virtual-smart-card-tpmvscmgr.md).
+
+### To create the TPM virtual smart card
+
+1.  On a domain-joined computer, open a Command Prompt window with Administrative credentials.
+
+    ![Cmd prompt, Run as administrator](images/vsc-10-cmd-run-as-administrator.png)
+
+2.  At the command prompt, type the following, and then press ENTER:
+
+    `tpmvscmgr.exe create /name TestVSC /pin default /adminkey random /generate`
+
+    This will create a virtual smart card with the name **TestVSC**, omit the unlock key, and generate the file system on the card. The PIN will be set to the default, 12345678. To be prompted for a PIN, instead of **/pin default** you can type **/pin prompt**.
+
+    For more information about the Tpmvscmgr command-line tool, see [Use Virtual Smart Cards](virtual-smart-card-use-virtual-smart-cards.md) and [Tpmvscmgr](virtual-smart-card-tpmvscmgr.md).
+
+4.  Wait several seconds for the process to finish. Upon completion, Tpmvscmgr.exe will provide you with the device instance ID for the TPM Virtual Smart Card. Store this ID for later reference because you will need it to manage or remove the virtual smart card.
+
+## Step 3: Enroll for the certificate on the TPM Virtual Smart Card
+
+The virtual smart card must be provisioned with a sign-in certificate for it to be fully functional.
+
+### To enroll the certificate
+
+1.  Open the Certificates console by typing **certmgr.msc** on the **Start** menu.
+
+2.  Right-click **Personal**, click **All Tasks**, and then click **Request New Certificate**.
+
+    ![Request New Certificate](images/vsc-11-certificates-request-new-certificate.png)
+
+3.  Follow the prompts and when offered a list of templates, select the **TPM Virtual Smart Card Logon** check box (or whatever you named the template in Step 1).
+
+    ![Certificate enrollment, select certificate](images/vsc-12-certificate-enrollment-select-certificate.png)
+
+4.  If prompted for a device, select the Microsoft virtual smart card that corresponds to the one you created in the previous section. It displays as **Identity Device (Microsoft Profile)**.
+
+5.  Enter the PIN that was established when you created the TPM virtual smart card, and then click **OK**.
+
+6.  Wait for the enrollment to finish, and then click **Finish**.
+
+The virtual smart card can now be used as an alternative credential to sign in to your domain. To verify that your virtual smart card configuration and certificate enrollment were successful, sign out of your current session, and then sign in. When you sign in, you will see the icon for the new TPM virtual smart card on the Secure Desktop (sign in) screen or you will be automatically directed to the TPM smart card sign-in dialog box. Click the icon, enter your PIN (if necessary), and then click **OK**. You should be signed in to your domain account.
+
+## See also
+
+-   [Understanding and Evaluating Virtual Smart Cards](virtual-smart-card-understanding-and-evaluating.md)
+
+-   [Use Virtual Smart Cards](virtual-smart-card-use-virtual-smart-cards.md)
+
+-   [Deploy Virtual Smart Cards](virtual-smart-card-deploy-virtual-smart-cards.md)

windows/keep-secure/virtual-smart-card-overview.md

@@ -0,0 +1,123 @@
+---
+title: Virtual Smart Card Overview (Windows 10)
+description: This topic for IT professional provides an overview of the virtual smart card technology that was developed by Microsoft, and links to additional topics about virtual smart cards.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Virtual Smart Card Overview
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for IT professional provides an overview of the virtual smart card technology that was developed by Microsoft and includes [links to additional topics](#see-also) to help you evaluate, plan, provision, and administer virtual smart cards.
+
+**Did you mean…**
+
+-   [Smart Cards](smart-card-windows-smart-card-technical-reference.md)
+
+## Feature description
+
+Virtual smart card technology from Microsoft offers comparable security benefits to physical smart cards by using two-factor authentication. Virtual smart cards emulate the functionality of physical smart cards, but they use the Trusted Platform Module (TPM) chip that is available on computers in many organizations, rather than requiring the use of a separate physical smart card and reader. Virtual smart cards are created in the TPM, where the keys that are used for authentication are stored in cryptographically secured hardware.
+
+By utilizing TPM devices that provide the same cryptographic capabilities as physical smart cards, virtual smart cards accomplish the three key properties that are desired for smart cards: non-exportability, isolated cryptography, and anti-hammering.
+
+## Practical applications
+
+Virtual smart cards are functionally similar to physical smart cards and appear in Windows as smart cards that are always-inserted. Virtual smart cards can be used for authentication to external resources, protection of data by secure encryption, and integrity through reliable signing. They are easily deployed by using in-house methods or a purchased solution, and they can become a full replacement for other methods of strong authentication in a corporate setting of any scale.
+
+### Authentication use cases
+
+**Two-factor authentication‒based remote access**
+
+After a user has a fully functional TPM virtual smart card, provisioned with a sign-in certificate, the certificate is used to gain strongly authenticated access to corporate resources. When the proper certificate is provisioned to the virtual card, the user need only provide the PIN for the virtual smart card, as if it was a physical smart card, to sign in to the domain.
+
+In practice, this is as easy as entering a password to access the system. Technically, it is far more secure. Using the virtual smart card to access the system proves to the domain that the user who is requesting authentication has possession of the personal computer upon which the card has been provisioned and knows the virtual smart card PIN. Because this request could not have possibly originated from a system other than the system certified by the domain for this user’s access, and the user could not have initiated the request without knowing the PIN, a strong two-factor authentication is established.
+
+**Client authentication**
+
+Virtual smart cards can also be used for client authentication by using Secure Socket Layer (SSL) or a similar technology. Similar to domain access with a virtual smart card, an authentication certificate can be provisioned for the virtual smart card, provided to a remote service, as requested in the client authentication process. This adheres to the principles of two-factor authentication because the certificate is only accessible from the computer that hosts the virtual smart card, and the user is required to enter the PIN for initial access to the card.
+
+**Virtual smart card redirection for remote desktop connections**
+
+The concept of two-factor authentication associated with virtual smart cards relies on the proximity of users to the computers that they access domain resources through. Therefore, when a user remotely connects to a computer that is hosting virtual smart cards, the virtual smart cards that are located on the remote computer cannot be used during the remote session. However, the virtual smart cards that are stored on the connecting computer (which is under physical control of the user) are loaded onto the remote computer, and they can be used as if they were installed by using the remote computer’s TPM. This extends a user’s privileges to the remote computer, while maintaining the principles of two-factor authentication.
+
+**Windows To Go and virtual smart cards**
+
+Virtual smart cards work well with Windows To Go, where a user can boot into a supported version of Windows from a compatible removable storage device. A virtual smart card can be created for the user, and it is tied to the TPM on the physical host computer to which the removable storage device is connected. When the user boots the operating system from a different physical computer, the virtual smart card will not be available. This can be used for scenarios when a single physical computer is shared by many users. Each user can be given a removable storage device for Windows To Go, which has a virtual smart card provisioned for the user. This way, users are only able to access their personal virtual smart card.
+
+### Confidentiality use cases
+
+**S/MIME email encryption**
+
+Physical smart cards are designed to hold private keys that can be used for email encryption and decryption. This functionality also exists in virtual smart cards. By using S/MIME with a user’s public key to encrypt email, the sender of an email can be assured that only the person with the corresponding private key will be able to decrypt the email. This assurance is a result of the non-exportability of the private key. It never exists within reach of malicious software, and it remains protected by the TPM—even during decryption.
+
+**BitLocker for data volumes**
+
+sBitLocker Drive Encryption technology makes use of symmetric-key encryption to protect the content of a user’s hard drive. This ensures that if the physical ownership of a hard drive is compromised, an adversary will not be able to read data off the drive. The key used to encrypt the drive can be stored in a virtual smart card, which necessitates knowledge of the virtual smart card PIN to access the drive and possession of the computer that is hosting the TPM virtual smart card. If the drive is obtained without access to the TPM that hosts the virtual smart card, any brute force attack will be very difficult.
+
+BitLocker can also be used to encrypt portable drives, which involves storing keys in virtual smart cards. In this scenario (unlike using BitLocker with a physical smart card), the encrypted drive can be used only when it is connected to the host for the virtual smart card that is used to encrypt the drive, because the BitLocker key is only accessible from this computer. However, this method can be useful to ensure the security of backup drives and personal storage uses outside the main hard drive.
+
+### Data integrity use case
+
+**Signing data**
+
+To verify authorship of data, a user can sign it by using a private key that is stored in the virtual smart card. Digital signatures confirm the integrity and origin of the data. If the key is stored in an operating system that is accessible, a malicious user could access it and use it to modify already signed data or to spoof the key owner’s identity. However, if this key is stored in a virtual smart card, it can be used only to sign data on the host computer. It cannot be exported to other systems (intentionally or unintentionally, such as with malware theft). This makes digital signatures far more secure than other methods for private key storage.
+
+## New and changed functionality as of Windows 8.1
+
+Enhancements in Windows 8.1 enabled developers to build Windows Store apps to create and manage virtual smart cards.
+
+The DCOM Interfaces for Trusted Platform Module (TPM) Virtual Smart Card device management protocol provides a Distributed Component Object Model (DCOM) Remote Protocol interface used for creating and destroying virtual smart cards. A virtual smart card is a device that presents a device interface complying with the PC/SC specification for PC-connected interface devices to its host operating system (OS) platform. This protocol does not assume anything about the underlying implementation of virtual smart card devices. In particular, while it is primarily intended for the management of virtual smart cards based on TPMs, it can also be used to manage other types of virtual smart cards.
+
+**What value does this change add?**
+
+Starting with Windows 8.1, application developers can build into their apps the following virtual smart card maintenance capabilities to relieve some of your administrative burdens.
+
+-   Create a new virtual smart card or select a virtual smart card from the list of available virtual smart cards on the system. Identify the one that the application is supposed to work with.
+
+-   Personalize the virtual smart card.
+
+-   Change the admin key.
+
+-   Diversify the admin key which allows the user to unblock the PIN in a PIN-blocked scenario.
+
+-   Change the PIN.
+
+-   Reset or Unblock the PIN.
+
+-   Destroy the virtual smart card.
+
+**What works differently?**
+
+Starting with Windows 8.1, Windows Store app developers are able to build apps that have the capability to prompt the user to reset or unblock and change a virtual smart card PIN. This places more responsibility on the user to maintain their virtual smart card but it can also provide a more consistent user experience and administration experience in your organization.
+
+For more information about developing Windows Store apps with these capabilities, see [Trusted Platform Module Virtual Smart Card Management Protocol](https://msdn.microsoft.com/library/hh880895.aspx).
+
+For more information about managing these capabilities in virtual smart cards, see [Understanding and Evaluating Virtual Smart Cards](virtual-smart-card-understanding-and-evaluating.md).
+
+## Hardware requirements
+
+To use the virtual smart card technology, TPM 1.2 is the minimum required for computers running Windows 10 or Windows Server 2016.
+
+## Software requirements
+
+To use the virtual smart card technology, computers must be running one of the following operating systems:
+
+- Windows Server 2016
+- Windows Server 2012 R2
+- Windows Server 2012
+- Windows 10
+- Windows 8.1
+- Windows 8
+
+## See also
+
+- [Understanding and Evaluating Virtual Smart Cards](virtual-smart-card-understanding-and-evaluating.md)
+- [Get Started with Virtual Smart Cards: Walkthrough Guide](virtual-smart-card-get-started.md)
+- [Use Virtual Smart Cards](virtual-smart-card-use-virtual-smart-cards.md)
+- [Deploy Virtual Smart Cards](virtual-smart-card-deploy-virtual-smart-cards.md)
+- [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md)
+- [Tpmvscmgr](virtual-smart-card-tpmvscmgr.md)

windows/keep-secure/virtual-smart-card-tpmvscmgr.md

@@ -0,0 +1,84 @@
+---
+title: Tpmvscmgr (Windows 10)
+description: This topic for the IT professional describes the Tpmvscmgr command-line tool, through which an administrator can create and delete TPM virtual smart cards on a computer.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Tpmvscmgr
+
+Applies To: Windows 10, Windows Server 2016
+
+The Tpmvscmgr command-line tool allows users with Administrative credentials to create and delete TPM virtual smart cards on a computer. For examples of how this command can be used, see [Examples](#examples).
+
+## Syntax
+
+`Tpmvscmgr create [/quiet] /name <name> /AdminKey {DEFAULT | PROMPT | RANDOM} [/PIN {DEFAULT | PROMPT}] [/PUK {DEFAULT | PROMPT}] [/generate] [/machine <machine name>] [/pinpolicy [policy options]] [/attestation {AIK_AND_CERT | AIK_ONLY}] [/?]`
+
+`Tpmvscmgr destroy [/quiet] [/instance <device instance ID>] [/machine <machine name>] [/?]`
+
+### Parameters for Create command
+
+The Create command sets up new virtual smart cards on the user’s system. It returns the instance ID of the newly created card for later reference if deletion is required. The instance ID is in the format ROOT\\SMARTCARDREADER\\000n where n starts from 0 and is increased by 1 each time you create a new virtual smart card.
+
+| Parameter | Description |
+|-----------|-------------|
+| /name | Required. Indicates the name of the new virtual smart card. |
+| /AdminKey | Indicates the desired administrator key that can be used to reset the PIN of the card if the user forgets the PIN.<br>**DEFAULT** Specifies the default value of 010203040506070801020304050607080102030405060708.<br>**PROMPT**&nbsp;&nbsp;Prompts the user to enter a value for the administrator key.<br>**RANDOM**&nbsp;&nbsp;Results in a random setting for the administrator key for a card that is not returned to the user. This creates a card that might not be manageable by using smart card management tools. When generated with RANDOM, the administrator key must be entered as 48 hexadecimal characters. |
+| /PIN | Indicates desired user PIN value.<br>**DEFAULT**&nbsp;&nbsp;Specifies the default PIN of 12345678.<br>**PROMPT**&nbsp;&nbsp;Prompts the user to enter a PIN at the command line. The PIN must be a minimum of eight characters, and it can contain numerals, characters, and special characters. |
+| /PUK | Indicates the desired PIN Unlock Key (PUK) value. The PUK value must be a minimum of eight characters, and it can contain numerals, characters, and special characters. If the parameter is omitted, the card is created without a PUK.<br>**DEFAULT**&nbsp;&nbsp;Specifies the default PUK of 12345678.<br>**PROMPT**&nbsp;&nbsp;Prompts the user to enter a PUK at the command line. |
+| /generate | Generates the files in storage that are necessary for the virtual smart card to function. If the /generate parameter is omitted, it is equivalent to creating a card without this file system. A card without a file system can be managed only by a smart card management system such as Microsoft System Center Configuration Manager. |
+| /machine | Allows you to specify the name of a remote computer on which the virtual smart card can be created. This can be used in a domain environment only, and it relies on DCOM. For the command to succeed in creating a virtual smart card on a different computer, the user running this command must be a member in the local administrators group on the remote computer. |
+| /pinpolicy | If **/pin prompt** is used, **/pinpolicy** allows you to specify the following PIN policy options:<br>**minlen** &lt;minimum PIN length&gt;<br>&nbsp;&nbsp;&nbsp;If not specificed, defaults to 8. The lower bound is 4.<br>**maxlen** &lt;maximum PIN length&gt;<br>&nbsp;&nbsp;&nbsp;If not specificed, defaults to 127. The upper bound is 127.<br>**uppercase**&nbsp;&nbsp;Can be **ALLOWED**, **DISALLOWED**, or **REQUIRED.** Default is **ALLOWED.**<br>**lowercase**&nbsp;&nbsp;Can be **ALLOWED**, **DISALLOWED**, or **REQUIRED.** Default is **ALLOWED.**<br>**digits**&nbsp;&nbsp;Can be **ALLOWED**, **DISALLOWED**, or **REQUIRED.** Default is **ALLOWED.**<br>**specialchars**&nbsp;&nbsp;Can be **ALLOWED**, **DISALLOWED**, or **REQUIRED.** Default is **ALLOWED.**<br><br>When using **/pinpolicy**, PIN characters must be printable ASCII characters. |
+| /attestation | Configures attestation (subject only). This attestation uses an [Attestation Identity Key (AIK) certificate](https://msdn.microsoft.com/library/mt766230.aspx#gt_89a2ba3c-80af-4d1f-88b3-06ec3489fd5a) as a trust anchor to vouch that the virtual smart card keys and certificates are truly hardware bound. The attestation methods are:<br>**AIK_AND_CERT**&nbsp;&nbsp;Creates an AIK and obtains an AIK certificate from the Microsoft cloud certification authority (CA). This requires the device to have a TPM with an [EK certificate](https://msdn.microsoft.com/library/cc249746.aspx#gt_6aaaff7f-d380-44fb-91d3-b985e458eb6d). If this option is specified and there is no network connectivity, it is possible that creation of the virtual smart card will fail.<br>**AIK_ONLY**&nbsp;&nbsp;Creates an AIK but does not obtain an AIK certificate. |
+| /? | Displays Help for this command. |
+
+### Parameters for Destroy command
+
+The Destroy command securely deletes a virtual smart card from a computer.
+
+> [!WARNING]
+> When a virtual smart card is deleted, it cannot be recovered.
+
+| **Parameter** | **Description**   |
+|---------------|-------------------|
+| /instance     | Specifies the instance ID of the virtual smart card to be removed. The instanceID was generated as output by Tpmvscmgr.exe when the card was created. The **/instance** parameter is a required field for the Destroy command.   |
+| /machine      | Allows you to specify the name of a remote computer on which the virtual smart card will be deleted. This can be used in a domain environment only, and it relies on DCOM. For the command to succeed in deleting a virtual smart card on a different computer, the user running this command must be a member in the local administrators group on the remote computer. |
+| /?            | Displays Help for this command.  |
+
+## Remarks
+
+Membership in the Administrators group (or equivalent) on the target computer is the minimum required to run all the parameters of this command.
+
+For alphanumeric inputs, the full 127 character ASCII set is allowed.
+
+## Examples
+
+The following command shows how to create a virtual smart card that can be later managed by a smart card management tool launched from another computer.
+
+    tpmvscmgr.exe create /name "VirtualSmartCardForCorpAccess" /AdminKey DEFAULT /PIN PROMPT
+
+Alternatively, instead of using a default administrator key, you can create an administrator key at the command line. The following command shows how to create an administrator key.
+
+    tpmvscmgr.exe create /name "VirtualSmartCardForCorpAccess" /AdminKey PROMPT /PIN PROMPT
+
+The following command will create the unmanaged virtual smart card that can be used to enroll certificates.
+
+    tpmvscmgr.exe create /name "VirtualSmartCardForCorpAccess" /AdminKey RANDOM /PIN PROMPT /generate
+
+The preceding command will create a virtual smart card with a randomized administrator key. The key is automatically discarded after the card is created. This means that if the user forgets the PIN or wants to the change the PIN, the user needs to delete the card and create it again. To delete the card, the user can run the following command.
+
+    tpmvscmgr.exe destroy /instance <instance ID>
+
+where &lt;instance ID&gt; is the value printed on the screen when the user created the card. Specifically, for the first card created, the instance ID is ROOT\\SMARTCARDREADER\\0000.
+
+The following command will create a TPM virtual smart card with the default value for the administrator key and a specified PIN policy and attestation method:
+
+    tpmvscmgr.exe create /name "VirtualSmartCardForCorpAccess" /PIN PROMPT /pinpolicy minlen 4 maxlen 8 /AdminKey DEFAULT /attestation AIK_AND_CERT /generate
+
+## Additional references
+
+-   [Virtual Smart Card Overview](virtual-smart-card-overview.md)

windows/keep-secure/virtual-smart-card-understanding-and-evaluating.md

@@ -0,0 +1,136 @@
+---
+title: Understanding and Evaluating Virtual Smart Cards (Windows 10)
+description: This topic for IT professional provides information about how smart card technology can fit into your authentication design, and provides links to additional topics about virtual smart cards.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Understanding and Evaluating Virtual Smart Cards
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional describes the virtual smart card technology that was developed by Microsoft; suggests how it can fit into your authentication design; and provides links to additional resources that you can use to design, deploy, and troubleshoot virtual smart cards.
+
+Virtual smart card technology uses cryptographic keys that are stored on computers that have the Trusted Platform Module (TPM) installed. Virtual smart cards offer comparable security benefits to conventional smart cards by using two-factor authentication. The technology also offers more convenience for users and has a lower cost to deploy. By utilizing TPM devices that provide the same cryptographic capabilities as conventional smart cards, virtual smart cards accomplish the three key properties that are desired for smart cards: non-exportability, isolated cryptography, and anti-hammering.
+
+Virtual smart cards are functionally similar to physical smart cards. They appear as always-inserted smart cards, and they can be used for authentication to external resources, protection of data by secure encryption, and integrity through reliable signing. Because TPM-enabled hardware is readily available and virtual smart cards can be easily deployed by using existing certificate enrollment methods, virtual smart cards can become a full replacement for other methods of strong authentication in a corporate setting of any scale.
+
+This topic contains the following sections:
+
+-   [Comparing virtual smart cards with physical smart cards](#comparing-virtual-smart-cards-with-physical-smart-cards):
+    Compares properties, functional aspects, security, and cost.
+
+-   [Authentication design options](#authentication-design-options):
+    Describes how passwords, smart cards, and virtual smart cards can be used to reach authentication goals in your organization.
+
+-   [See also](#see-also):
+    Links to other topics that can help you design, deploy, and troubleshoot virtual smart cards.
+
+## Comparing virtual smart cards with physical smart cards
+
+Virtual smart cards function much like physical smart cards, but they differ in that they protect private keys by using the TPM of the computer instead of smart card media.
+
+A virtual smart card appears to applications as a conventional smart card. Private keys in the virtual smart card are protected, not by isolation of physical memory, but by the cryptographic capabilities of the TPM. All sensitive information is encrypted by using the TPM and then stored on the hard drive in its encrypted form.
+
+All cryptographic operations occur in the secure, isolated environment of the TPM, and the unencrypted private keys are never used outside this environment. So like physical smart cards, virtual smart cards remain secure from any malware on the host. Additionally, if the hard drive is compromised in some way, a malicious user will not be able to access keys that are stored in the virtual smart card because they are securely encrypted by using the TPM. Keys can also be protected by BitLocker Drive Encryption.
+
+Virtual smart cards maintain the three key properties of physical smart cards:
+
+-   **Non-exportability**: Because all private information on the virtual smart card is encrypted by using the TPM on the host computer, it cannot be used on a different computer with a different TPM. Additionally, TPMs are designed to be tamper-resistant and non-exportable, so a malicious user cannot reverse engineer an identical TPM or install the same TPM on a different computer.
+    For more information, see [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md).
+
+-   **Isolated cryptography**: TPMs provide the same properties of isolated cryptography that are offered by physical smart cards, and this is utilized by virtual smart cards. Unencrypted copies of private keys are loaded only within the TPM and never into memory that is accessible by the operating system. All cryptographic operations with these private keys occur inside the TPM.
+
+-   **Anti-hammering**: If a user enters a PIN incorrectly, the virtual smart card responds by using the anti-hammering logic of the TPM, which rejects further attempts for a period of time instead of blocking the card. This is also known as lockout.
+    For more information, see [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md).
+
+The following subsections compare the functionality, security, and cost of virtual smart cards and physical smart cards.
+
+**Functionality**
+
+The virtual smart card system that was designed by Microsoft closely mimics the functionality of conventional smart cards. The most striking difference to the end user is that the virtual smart card is essentially a smart card that is always inserted into the computer. There is no method to export the user’s virtual smart card for use on other computers, which adds to the security of virtual smart cards. If a user requires access to network resources on multiple computers, multiple virtual smart cards can be issued for that user. Additionally, a computer that is shared among multiple users can host multiple virtual smart cards for different users.
+
+The basic user experience for a virtual smart card is as simple as using a password to access a network. Because the smart card is loaded by default, the user must simply enter the PIN that is tied to the card to gain access. Users are no longer required to carry cards and readers or to take physical action to use the card.
+
+Additionally, although the anti-hammering functionality of the virtual smart card is equally secure to that of a physical smart card, virtual smart card users are never required to contact an administrator to unblock the card. Instead, they simply wait a period of time (depending on the TPM specifications) before they reattempt to enter the PIN. Alternatively, the administrator can reset the lockout by providing owner authentication data to the TPM on the host computer.
+
+**Security**
+
+Physical smart cards and virtual smart cards offer comparable levels of security. They both implement two-factor authentication for using network resources. However, they differ in certain aspects, including physical security and the practicality of an attack. Due to their compact and portable design, conventional smart cards are most frequently kept close to their intended user. They offer little opportunity for acquisition by a potential adversary, so any sort of interaction with the card is difficult without committing some variety of theft.
+
+TPM virtual smart cards, however, reside on a user’s computer that may frequently be left unattended, which provides an opportunity for a malicious user to hammer the TPM. Although virtual smart cards are fully protected from hammering (as are physical smart cards), this accessibility makes the logistics of an attack somewhat simpler. Additionally, the anti-hammering behavior of a TPM smart card differs in that it only presents a time delay in response to repeated PIN failures, as opposed to fully blocking the user.
+
+However, there are several advantages provided by virtual smart cards to mitigate these slight security deficits. Most importantly, a virtual smart card is much less likely to be lost. Virtual smart cards are integrated into computers and devices that the user already owns for other purposes and has incentive to keep safe. If the computer or device that hosts the virtual smart card is lost or stolen, a user will more immediately notice its loss than the loss of a physical smart card. When a computer or device is identified as lost, the user can notify the administrator of the system, who can revoke the certificate that is associated with the virtual smart card on that device. This precludes any future unauthorized access on that computer or device if the PIN for the virtual smart card is compromised.
+
+**Cost**
+
+If a company wants to deploy physical smart cards, they need to purchase smart cards and smart card readers for all employees. Although relatively inexpensive options can be found, options that ensure the three key properties of smart card security (most notably, non-exportability) are more expensive. If employees have computers with a built-in TPM, virtual smart cards can be deployed with no additional material costs. These computers and devices are relatively common in the market.
+
+Additionally, the maintenance cost of virtual smart cards is less than that for physical smart cards, which are easily lost, stolen, or broken from normal wear. TPM virtual smart cards are only lost or broken if the host computer or device is lost or broken, which in most cases is much less frequently.
+
+**Comparison summary**
+
+| Physical Smart Cards                        | TPM virtual smart cards           |
+|---------------------|-------------------|
+| Protects private keys by using the built-in cryptographic functionality of the card.                        | Protects private keys by using the cryptographic functionality of the TPM.     |
+| Stores private keys in isolated non-volatile memory on the card, which means that access to private keys is only from the card, and access is never allowed to the operating system.                                          | Stores encrypted private keys on the hard drive. The encryption ensures that these keys can only be decrypted and used in the TPM, not in the accessible memory of the operating system.         |
+| Guarantees non-exportability through the card manufacturer, which includes isolating private information from operating system access.                             | Guarantees non-exportability through the TPM manufacturer, which includes the inability of an adversary to replicate or remove the TPM.        |
+| Performs and isolates cryptographic operations within the built-in capabilities of the card.                | Performs and isolates cryptographic operations in the TPM of the user’s computer or device.                                           |
+| Provides anti-hammering through the card. After a certain number of failed PIN entry attempts, the card blocks further access until administrative action is taken.         | Provides anti-hammering through the TPM. Successive failed attempts increase the device lockout time (the time the user has to wait before trying again). This can be reset by an administrator. |
+| Requires that users carry their smart card and smart card reader with them to access network resources.     | Allows users to access their TPM-enabled computers or devices, and potentially access the network, without additional equipment.      |
+| Enables credential portability by inserting the smart card into smart card readers that are attached to other computers.                                           | Prevents exporting credentials from a given computer or device. However, virtual smart cards can be issued for the same user on multiple computers or devices by using additional certificates.  |
+| Enables multiple users to access network resources through the same computer by inserting their personal smart cards.      | Enables multiple users to access network resources through the same computer or device by issuing a virtual smart card for each user on that computer or device.                                 |
+| Requires the user to carry the card, making it more difficult for an attacker to access the device and launch a hammering attempt.                                 | Stores virtual smart card on the user’s computer, which may be left unattended and allow a greater risk window for hammering attempts.         |
+| Provides a generally single-purpose device that is carried explicitly for the purpose of authentication. The smart card can be easily misplaced or forgotten.      | Installs the virtual smart card on a device that has other purposes for the user, so the user has greater incentive to be responsible for the computer or device.                                |
+| Alerts users that their card is lost or stolen only when they need to sign in and notice it is missing.     | Installs the virtual smart card on a device that the user likely needs for other purposes, so users will notice its loss much more quickly. This reduces the associated risk window.             |
+| Requires companies to invest in smart cards and smart card readers for all employees.                       | Requires that companies ensure all employees have TPM-enabled computers, which are relatively common.                                 |
+| Enables using a smart card removal policy to affect system behavior when the smart card is removed. For example, the policy can dictate if the user’s sign-in session is locked or terminated when the user removes the card. | Eliminates the necessity for a smart card removal policy because a TPM virtual smart card is always present and cannot be removed from the computer.     |
+
+## Authentication design options
+
+The following section presents several commonly used options and their respective strengths and weaknesses, which organizations can consider for authentication.
+
+**Passwords**
+
+A password is a secret string of characters that is tied to the identification credentials for a user’s account. This establishes the user’s identity. Although passwords are the most commonly used form of authentication, they are also the weakest. In a system where passwords are used as the sole method of user authentication, only individuals who know their passwords are considered valid users.
+
+Password authentication places a great deal of responsibility on the user. Passwords must be sufficiently complex so they cannot be easily guessed, but they must be simple enough to be committed to memory and not stored in a physical location. Even if this balance is successfully achieved, a wide variety of attacks exist (such as brute force attacks, eavesdropping, and social engineering tactics) where a malicious user can acquire a user’s password and impersonate that person’s identity. A user often will not realize that the password is compromised, which makes it is easy for a malicious user to maintain access to a system if a valid password has been obtained.
+
+**One-time passwords**
+
+A one-time password (OTP) is similar to a traditional password, but it is more secure in that it can be used only once to authenticate a user. The method for determining each new password varies by implementation. However, assuming a secure deployment of each new password, OTPs have several advantages over the classic password model of authentication. Most importantly, if a given OTP token is intercepted in transmission between the user and the system, the interceptor cannot use it for any future transactions. Similarly, if a malicious user obtains a valid user’s OTP, the interceptor will have limited access to the system (only one session).
+
+**Smart cards**
+
+Smart cards are physical authentication devices, which improve on the concept of a password by requiring that users actually have their smart card device with them to access the system, in addition to knowing the PIN that provides access to the smart card. Smart cards have three key properties that help maintain their security:
+
+-   **Non-exportability**: Information stored on the card, such as the user’s private keys, cannot be extracted from one device and used in another medium.
+
+-   **Isolated cryptography**: Any cryptographic operations that are related to the card (such as secure encryption and decryption of data) occur in a cryptographic processor on the card, so malicious software on the host computer cannot observe the transactions.
+
+-   **Anti-hammering**: To prevent access to the card by a brute-force attack, a set number of consecutive unsuccessful PIN entry attempts blocks the card until administrative action is taken.
+
+Smart cards provide greatly enhanced security over passwords alone, because it is much more difficult for a malicious user to gain and maintain access to a system. Most importantly, access to a smart card system requires that users have a valid card and that they know the PIN that provides access to that card. It is extremely difficult for a thief to acquire the card and the PIN.
+
+Additional security is achieved by the singular nature of the card because only one copy of the card exists, only one individual can use the sign-in credentials, and users will quickly notice if the card has been lost or stolen. This greatly reduces the risk window of credential theft when compared to using a password alone.
+
+Unfortunately, this additional security comes with added material and support costs. Traditional smart cards are expensive to purchase (cards and card readers must be supplied to employees), and they also can be easily misplaced or stolen.
+
+**Virtual smart cards**
+
+To address these issues, virtual smart cards emulate the functionality of traditional smart cards, but instead of requiring the purchase of additional hardware, they utilize technology that users already own and are more likely to have with them at all times. Theoretically, any device that can provide the three key properties of smart cards (non-exportability, isolated cryptography, and anti-hammering) can be commissioned as a virtual smart card. However, the virtual smart card platform developed by Microsoft is currently limited to the use of the Trusted Platform Module (TPM) chip, which is installed on most modern computers.
+
+Virtual smart cards that utilize a TPM provide the three main security principles of traditional smart cards (non-exportability, isolated cryptography, and anti-hammering). They are also less expensive to implement and more convenient for users. Because many corporate computers already have a built-in TPM, there is no cost associated with purchasing new hardware. The user’s possession of a computer or device is equivalent to the possession of a smart card, and a user’s identity cannot be assumed from any other computer or device without administrative provisioning of further credentials. Thus, two-factor authentication is achieved because the user must have a computer that is set up with a virtual smart card and know the PIN to use the virtual smart card.
+
+## See also
+
+-   [Get Started with Virtual Smart Cards: Walkthrough Guide](virtual-smart-card-get-started.md)
+
+-   [Use Virtual Smart Cards](virtual-smart-card-use-virtual-smart-cards.md)
+
+-   [Deploy Virtual Smart Cards](virtual-smart-card-deploy-virtual-smart-cards.md)
+
+-   [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md)

windows/keep-secure/virtual-smart-card-use-virtual-smart-cards.md

@@ -0,0 +1,95 @@
+---
+title: Use Virtual Smart Cards (Windows 10)
+description: This topic for the IT professional describes requirements for virtual smart cards and provides information about how to use and manage them.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: Justinha
+---
+
+# Use Virtual Smart Cards
+
+Applies To: Windows 10, Windows Server 2016
+
+This topic for the IT professional describes requirements for virtual smart cards, how to use virtual smart cards, and tools that are available to help you create and manage them.
+
+## Requirements, restrictions, and limitations
+
+| Area        | Requirements and details  |
+|-------------|---------------------------|
+| Supported operating systems  | Windows Server 2016 <br>Windows Server 2012 R2 <br>Windows Server 2012 <br>Windows 10 <br>Windows 8.1 <br>Windows 8  |
+| Supported Trusted Platform Module (TPM)                        | Any TPM that adheres to the TPM main specifications for version 1.2 or version 2.0 (as set by the Trusted Computing Group) is supported for use as a virtual smart card. For more information, see the [TPM Main Specification](http://www.trustedcomputinggroup.org/resources/tpm_main_specification).      |
+| Supported virtual smart cards per computer                     | Ten smart cards can be connected to a computer or device at one time. This includes physical and virtual smart cards combined. <br><br>**Note**<br>You can create more than one virtual smart card; however, after creating more than four virtual smart cards, you may start to notice performance degradation. Because all smart cards appear as if they are always inserted, if more than one person shares a computer or device, each person can see all the virtual smart cards that are created on that computer or device. If the user knows the PIN values for all the virtual smart cards, the user will also be able to use them.<br> |
+| Supported number of certificates on a virtual smart card       | A single TPM virtual smart card can contain 30 distinct certificates with the corresponding private keys. Users can continue to renew certificates on the card until the total number of certificates on a card exceeds 90. The reason that the total number of certificates is different from the total number of private keys is that sometimes the renewal can be done with the same private key—in which case a new private key is not generated.       |
+| PIN, PIN Unlock Key (PUK), and Administrative key requirements | The PIN and the PUK must be a minimum of eight characters that can include numerals, alphabetic characters, and special characters.<br>The Administrative key must be entered as 48 hexadecimal characters. It is a 3-key triple DES with ISO/IEC 9797 padding method 2 in CBC chaining mode.                 |
+
+## Using Tpmvscmgr.exe
+
+To create and delete TPM virtual smart cards for end users, the Tpmvscmgr command-line tool is included as a command-line tool with the operating system. You can use the **Create** and **Delete** parameters to manage virtual smart cards on local or remote computers. For information about using this tool, see [Tpmvscmgr](virtual-smart-card-tpmvscmgr.md).
+
+## Create and delete virtual smart cards programmatically
+
+Virtual smart cards can also be created and deleted by using APIs. For more information, see the following classes and interfaces:
+
+-   [TpmVirtualSmartCardManager](https://msdn.microsoft.com/library/windows/desktop/hh707171(v=vs.85).aspx)
+
+-   [RemoteTpmVirtualSmartCardManager](https://msdn.microsoft.com/library/windows/desktop/hh707166(v=vs.85).aspx)
+
+-   [ITpmVirtualSmartCardManager](https://msdn.microsoft.com/library/windows/desktop/hh707160(v=vs.85).aspx)
+
+-   [ITPMVirtualSmartCardManagerStatusCallBack](https://msdn.microsoft.com/library/windows/desktop/hh707161(v=vs.85).aspx)
+
+You can use APIs that were introduced in the Windows.Device.SmartCards namespace in Windows Server 2012 R2 and Windows 8.1 to build Windows Store apps to manage the full lifecycle of virtual smart cards. For information about how to build an app to do this, see [Strong Authentication: Building Apps That Leverage Virtual Smart Cards in Enterprise, BYOD, and Consumer Environments | Build 2013 | Channel 9](http://channel9.msdn.com/events/build/2013/2-041).
+
+The following table describes the features that can be developed in a Windows Store app:
+
+| Feature                                      | Physical Smart Card | Virtual Smart Card |
+|----------------------------------------------|---------------------|--------------------|
+| Query and monitor smart card readers              | Yes                      | Yes                     |
+| List available smart cards in a reader, and retrieve the card name and card ID                 | Yes           | Yes        |
+| Verify if the administrative key of a card is correct      | Yes                      | Yes                     |
+| Provision (or reformat) a card with a given card ID        | Yes                      | Yes                     |
+| Change the PIN by entering the old PIN and specifying a new PIN      | Yes                      | Yes                     |
+| Change the administrative key, reset the PIN, or unblock the smart card by using a challenge/response method | Yes     | Yes      |
+| Create a virtual smart card                       | Not applicable           | Yes                     |
+| Delete a virtual smart card                       | Not applicable           | Yes                     |
+| Set PIN policies                                  | No                       | Yes                     |
+
+For more information about these Windows APIs, see:
+
+-   [Windows.Devices.SmartCards namespace (Windows)](https://msdn.microsoft.com/library/windows/apps/windows.devices.smartcards.aspx)
+
+-   [Windows.Security.Cryptography.Certificates namespace (Windows)](https://msdn.microsoft.com/library/windows/apps/windows.security.cryptography.certificates.aspx)
+
+## Distinguishing TPM-based virtual smart cards from physical smart cards
+
+To help users visually distinguish a Trusted Platform Module (TPM)-based virtual smart card from physical smart cards, the virtual smart card has a different icon. The following icon is displayed during sign in, and on other screens that require the user to enter the PIN for a virtual smart card.
+
+![Icon for a virtual smart card](images/vsc-virtual-smart-card-icon.png)
+
+A TPM-based virtual smart card is labeled **Security Device** in the user interface.
+
+## Changing the PIN
+
+The PIN for virtual smart card can be changed by pressing Ctrl+Alt+Del, and then selecting the TPM virtual smart card under **Sign in options**.
+
+## Resolving issues
+
+### TPM not provisioned
+
+For a TPM-based virtual smart card to function properly, a provisioned TPM must be available on the computer. If the TPM is disabled in the BIOS, or it is not provisioned with full ownership and the storage root key, the TPM virtual smart card creation will fail.
+
+If the TPM is initialized after creating a virtual smart card, the card will no longer function, and it will need to be re-created.
+
+If the TPM ownership was established on a Windows Vista installation, the TPM will not be ready to use virtual smart cards. The system administrator needs to clear and initialize the TPM for it to be suitable for creating TPM virtual smart cards.
+
+If the operating system is reinstalled, prior TPM virtual smart cards are no longer available and need to be re-created. If the operating system is upgraded, prior TPM virtual smart cards will be available to use in the upgraded operating system.
+
+### TPM in lockout state
+
+Sometimes, due to frequent incorrect PIN attempts from a user, the TPM may enter the lockout state. To resume using the TPM virtual smart card, it is necessary to reset the lockout on the TPM by using the owner’s password or to wait for the lockout to expire. Unblocking the user PIN does not reset the lockout in the TPM. When the TPM is in lockout, the TPM virtual smart card appears as if it is blocked. When the TPM enters the lockout state because the user entered an incorrect PIN too many times, it may be necessary to reset the user PIN by using the virtual smart card management tools, such as Tpmvscmgr command-line tool.
+
+## See also
+
+For information about authentication, confidentiality, and data integrity use cases, see [Virtual Smart Card Overview](virtual-smart-card-overview.md).