diff --git a/browsers/edge/Index.md b/browsers/edge/Index.md index 29090e5faa..e261955400 100644 --- a/browsers/edge/Index.md +++ b/browsers/edge/Index.md @@ -21,7 +21,11 @@ localizationpriority: high Microsoft Edge is the new, default web browser for Windows 10, helping you to experience modern web standards, better performance, improved security, and increased reliability. Microsoft Edge also introduces new features like Web Note, Reading View, and Cortana that you can use along with your normal web browsing abilities. Microsoft Edge lets you stay up-to-date through the Windows Store and to manage your enterprise through Group Policy or your mobile device management (MDM) tools. -
**Note**
This content isn't meant to be a step-by-step guide, so not everything that's talked about in this guide will be necessary for you to manage and deploy Microsoft Edge in your company.
+
+> **Note**
This content isn't meant to be a step-by-step guide, so not everything that's talked about in this guide will be necessary for you to manage and deploy Microsoft Edge in your company.
+
+
+> **Note**
For more info about the potential impact of using Microsoft Edge in a large organization, you can download an infographic from here: [Total Economic Impact of Microsoft Edge: Infographic](https://www.microsoft.com/en-us/download/details.aspx?id=53892).
## In this section
@@ -58,3 +62,4 @@ You'll need to keep running them using IE11. If you don't have IE11 installed an
- [Internet Explorer 11 (IE11) - Deployment Guide for IT Pros](https://go.microsoft.com/fwlink/p/?LinkId=760644)
- [Internet Explorer 11 - FAQ for IT Pros](https://go.microsoft.com/fwlink/p/?LinkId=760645)
- [Internet Explorer Administration Kit 11 (IEAK 11) - Administrator's Guide](https://go.microsoft.com/fwlink/p/?LinkId=760646)
+
diff --git a/browsers/edge/enterprise-guidance-using-microsoft-edge-and-ie11.md b/browsers/edge/enterprise-guidance-using-microsoft-edge-and-ie11.md
index a3dcf46f40..67b924eaef 100644
--- a/browsers/edge/enterprise-guidance-using-microsoft-edge-and-ie11.md
+++ b/browsers/edge/enterprise-guidance-using-microsoft-edge-and-ie11.md
@@ -44,6 +44,7 @@ IE11 offers enterprises additional security, manageability, performance, backwar
- **Administration.** IE11 can use the Internet Explorer Administration Kit (IEAK) 11 or MSIs for deployment, and includes more than 1,600 Group Policies and preferences for granular control.
## Related topics
+- [Total Economic Impact of Microsoft Edge: Infographic](https://www.microsoft.com/en-us/download/details.aspx?id=53892)
- [Web Application Compatibility Lab Kit for Internet Explorer 11](https://technet.microsoft.com/en-us/browser/mt612809.aspx)
- [Download Internet Explorer 11](http://windows.microsoft.com/en-US/internet-explorer/download-ie)
- [Microsoft Edge - Deployment Guide for IT Pros](https://technet.microsoft.com/itpro/microsoft-edge/index)
diff --git a/windows/keep-secure/TOC.md b/windows/keep-secure/TOC.md
index 0143dc9421..eaedfbf278 100644
--- a/windows/keep-secure/TOC.md
+++ b/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)
diff --git a/windows/keep-secure/change-history-for-keep-windows-10-secure.md b/windows/keep-secure/change-history-for-keep-windows-10-secure.md
index 2660f5d265..759d44b4af 100644
--- a/windows/keep-secure/change-history-for-keep-windows-10-secure.md
+++ b/windows/keep-secure/change-history-for-keep-windows-10-secure.md
@@ -12,12 +12,17 @@ author: brianlic-msft
# Change history for Keep Windows 10 secure
This topic lists new and updated topics in the [Keep Windows 10 secure](index.md) documentation for [Windows 10 and Windows 10 Mobile](../index.md).
-## October 2016
-
+## November 2016
| New or changed topic | Description |
| --- | --- |
|[Protect your enterprise data using Windows Information Protection (WIP)](protect-enterprise-data-using-wip.md), [Create a Windows Information Protection (WIP) policy using Microsoft Intune](create-wip-policy-using-intune.md), and [Create and deploy a Windows Information Protection (WIP) policy using System Center Configuration Manager](create-wip-policy-using-sccm.md) |Added additional details about what happens when you turn off WIP. |
|[Create and deploy a VPN policy for Windows Information Protection (WIP) using Microsoft Intune](create-vpn-and-wip-policy-using-intune.md) |Changed WIPModeID to EDPModeID, to match the CSP. |
+
+
+## October 2016
+
+| New or changed topic | Description |
+| --- | --- |
|[List of enlightened Microsoft apps for use with Windows Information Protection (WIP)](enlightened-microsoft-apps-and-wip.md) |Added Microsoft Remote Desktop information. |
|[Create and deploy a Windows Information Protection (WIP) policy using System Center Configuration Manager](create-wip-policy-using-sccm.md) and [Create a Windows Information Protection (WIP) policy using Microsoft Intune](create-wip-policy-using-intune.md) |Updated the text about where the optioanl icon overlay appears.|
|[Limitations while using Windows Information Protection (WIP)](limitations-with-wip.md) |Added content about using ActiveX controls.|
diff --git a/windows/keep-secure/credential-guard.md b/windows/keep-secure/credential-guard.md
index 4a101d0101..ce40f1c03f 100644
--- a/windows/keep-secure/credential-guard.md
+++ b/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.
-> 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).
+> Starting in Widows 10, 1607, TPM 2.0 is required.
## Credential Guard requirements for baseline protections
@@ -92,7 +93,7 @@ The following tables describes additional hardware and firmware requirements, an
-### 2017 Additional Qualification Requirements for Credential Guard (starting with next major release of Windows 10)
+### 2017 Additional Qualification Requirements for Credential Guard (starting with the next major release of Windows 10)
| Protection for Improved Security - requirement | Description |
|---------------------------------------------|----------------------------------------------------|
diff --git a/windows/keep-secure/images/sc-image101.png b/windows/keep-secure/images/sc-image101.png
new file mode 100644
index 0000000000..d0c7a632b5
Binary files /dev/null and b/windows/keep-secure/images/sc-image101.png differ
diff --git a/windows/keep-secure/images/sc-image201.gif b/windows/keep-secure/images/sc-image201.gif
new file mode 100644
index 0000000000..226a747881
Binary files /dev/null and b/windows/keep-secure/images/sc-image201.gif differ
diff --git a/windows/keep-secure/images/sc-image203.gif b/windows/keep-secure/images/sc-image203.gif
new file mode 100644
index 0000000000..de2a310572
Binary files /dev/null and b/windows/keep-secure/images/sc-image203.gif differ
diff --git a/windows/keep-secure/images/sc-image205.png b/windows/keep-secure/images/sc-image205.png
new file mode 100644
index 0000000000..69b536054c
Binary files /dev/null and b/windows/keep-secure/images/sc-image205.png differ
diff --git a/windows/keep-secure/images/sc-image206.gif b/windows/keep-secure/images/sc-image206.gif
new file mode 100644
index 0000000000..07e187cfaa
Binary files /dev/null and b/windows/keep-secure/images/sc-image206.gif differ
diff --git a/windows/keep-secure/images/sc-image302.gif b/windows/keep-secure/images/sc-image302.gif
new file mode 100644
index 0000000000..346db734db
Binary files /dev/null and b/windows/keep-secure/images/sc-image302.gif differ
diff --git a/windows/keep-secure/images/sc-image402.png b/windows/keep-secure/images/sc-image402.png
new file mode 100644
index 0000000000..ec97224017
Binary files /dev/null and b/windows/keep-secure/images/sc-image402.png differ
diff --git a/windows/keep-secure/images/sc-image403.png b/windows/keep-secure/images/sc-image403.png
new file mode 100644
index 0000000000..22965326bc
Binary files /dev/null and b/windows/keep-secure/images/sc-image403.png differ
diff --git a/windows/keep-secure/images/sc-image404.png b/windows/keep-secure/images/sc-image404.png
new file mode 100644
index 0000000000..2bb988a668
Binary files /dev/null and b/windows/keep-secure/images/sc-image404.png differ
diff --git a/windows/keep-secure/images/sc-image405.png b/windows/keep-secure/images/sc-image405.png
new file mode 100644
index 0000000000..99e7a7b21a
Binary files /dev/null and b/windows/keep-secure/images/sc-image405.png differ
diff --git a/windows/keep-secure/images/sc-image406.png b/windows/keep-secure/images/sc-image406.png
new file mode 100644
index 0000000000..8eb3c3c630
Binary files /dev/null and b/windows/keep-secure/images/sc-image406.png differ
diff --git a/windows/keep-secure/images/sc-image407.png b/windows/keep-secure/images/sc-image407.png
new file mode 100644
index 0000000000..47ceb8f10a
Binary files /dev/null and b/windows/keep-secure/images/sc-image407.png differ
diff --git a/windows/keep-secure/images/sc-image501.gif b/windows/keep-secure/images/sc-image501.gif
new file mode 100644
index 0000000000..b1463b5d14
Binary files /dev/null and b/windows/keep-secure/images/sc-image501.gif differ
diff --git a/windows/keep-secure/images/vsc-02-mmc-add-snap-in.png b/windows/keep-secure/images/vsc-02-mmc-add-snap-in.png
new file mode 100644
index 0000000000..2d626ecf94
Binary files /dev/null and b/windows/keep-secure/images/vsc-02-mmc-add-snap-in.png differ
diff --git a/windows/keep-secure/images/vsc-03-add-certificate-templates-snap-in.png b/windows/keep-secure/images/vsc-03-add-certificate-templates-snap-in.png
new file mode 100644
index 0000000000..e5c40ce136
Binary files /dev/null and b/windows/keep-secure/images/vsc-03-add-certificate-templates-snap-in.png differ
diff --git a/windows/keep-secure/images/vsc-04-right-click-smartcard-logon-template.png b/windows/keep-secure/images/vsc-04-right-click-smartcard-logon-template.png
new file mode 100644
index 0000000000..b6fa6b75ba
Binary files /dev/null and b/windows/keep-secure/images/vsc-04-right-click-smartcard-logon-template.png differ
diff --git a/windows/keep-secure/images/vsc-05-certificate-template-compatibility.png b/windows/keep-secure/images/vsc-05-certificate-template-compatibility.png
new file mode 100644
index 0000000000..110fb05099
Binary files /dev/null and b/windows/keep-secure/images/vsc-05-certificate-template-compatibility.png differ
diff --git a/windows/keep-secure/images/vsc-06-add-certification-authority-snap-in.png b/windows/keep-secure/images/vsc-06-add-certification-authority-snap-in.png
new file mode 100644
index 0000000000..f770d2f259
Binary files /dev/null and b/windows/keep-secure/images/vsc-06-add-certification-authority-snap-in.png differ
diff --git a/windows/keep-secure/images/vsc-07-right-click-certificate-templates.png b/windows/keep-secure/images/vsc-07-right-click-certificate-templates.png
new file mode 100644
index 0000000000..893abc8f34
Binary files /dev/null and b/windows/keep-secure/images/vsc-07-right-click-certificate-templates.png differ
diff --git a/windows/keep-secure/images/vsc-08-enable-certificate-template.png b/windows/keep-secure/images/vsc-08-enable-certificate-template.png
new file mode 100644
index 0000000000..f060ca7e3e
Binary files /dev/null and b/windows/keep-secure/images/vsc-08-enable-certificate-template.png differ
diff --git a/windows/keep-secure/images/vsc-09-stop-service-start-service.png b/windows/keep-secure/images/vsc-09-stop-service-start-service.png
new file mode 100644
index 0000000000..4f3a65766f
Binary files /dev/null and b/windows/keep-secure/images/vsc-09-stop-service-start-service.png differ
diff --git a/windows/keep-secure/images/vsc-10-cmd-run-as-administrator.png b/windows/keep-secure/images/vsc-10-cmd-run-as-administrator.png
new file mode 100644
index 0000000000..b9a6538540
Binary files /dev/null and b/windows/keep-secure/images/vsc-10-cmd-run-as-administrator.png differ
diff --git a/windows/keep-secure/images/vsc-11-certificates-request-new-certificate.png b/windows/keep-secure/images/vsc-11-certificates-request-new-certificate.png
new file mode 100644
index 0000000000..4eeba26de7
Binary files /dev/null and b/windows/keep-secure/images/vsc-11-certificates-request-new-certificate.png differ
diff --git a/windows/keep-secure/images/vsc-12-certificate-enrollment-select-certificate.png b/windows/keep-secure/images/vsc-12-certificate-enrollment-select-certificate.png
new file mode 100644
index 0000000000..b8fb5e9635
Binary files /dev/null and b/windows/keep-secure/images/vsc-12-certificate-enrollment-select-certificate.png differ
diff --git a/windows/keep-secure/images/vsc-physical-smart-card-lifecycle.png b/windows/keep-secure/images/vsc-physical-smart-card-lifecycle.png
new file mode 100644
index 0000000000..17357828f0
Binary files /dev/null and b/windows/keep-secure/images/vsc-physical-smart-card-lifecycle.png differ
diff --git a/windows/keep-secure/images/vsc-process-of-accessing-user-key.png b/windows/keep-secure/images/vsc-process-of-accessing-user-key.png
new file mode 100644
index 0000000000..29682f1cd0
Binary files /dev/null and b/windows/keep-secure/images/vsc-process-of-accessing-user-key.png differ
diff --git a/windows/keep-secure/images/vsc-virtual-smart-card-icon.png b/windows/keep-secure/images/vsc-virtual-smart-card-icon.png
new file mode 100644
index 0000000000..4614d7684b
Binary files /dev/null and b/windows/keep-secure/images/vsc-virtual-smart-card-icon.png differ
diff --git a/windows/keep-secure/smart-card-and-remote-desktop-services.md b/windows/keep-secure/smart-card-and-remote-desktop-services.md
new file mode 100644
index 0000000000..5a2d8f9ed9
--- /dev/null
+++ b/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.
+
+
+
+**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)
diff --git a/windows/keep-secure/smart-card-architecture.md b/windows/keep-secure/smart-card-architecture.md
new file mode 100644
index 0000000000..84d38741cf
--- /dev/null
+++ b/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)
+
+
+
+## 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.
+
+
+
+**Figure 1** **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** 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** The Credential Provider API does not render the UI. It describes what needs to be rendered.
Only the password credential provider is available in safe mode.
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.
+
+
+
+**Figure 2** **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** 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 | \\\\.\\<Reader Name>\\<Container Name> |
+| II | Reader Name and Container Name (NULL) | \\\\.\\<Reader Name> |
+| III | Container Name Only | <Container Name> |
+| 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** 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.
+
+
+
+**Figure 3** **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** 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** 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** 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.
+
+
+
+**Figure 4** **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** 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
- Read-only (used only by CryptGetProvParam)
- Caller responsible for closing the certificate store
- Certificate encoded using PKCS\_7\_ASN\_ENCODING or X509\_ASN\_ENCODING
- CSP should set KEY\_PROV\_INFO on certificates
- Certificate store should be assumed to be an in-memory store
- Certificates should have a valid CRYPT\_KEY\_PROV\_INFO as a property |
+| PP\_ROOT\_CERTSTORE | - Read and Write (used by CryptGetProvParam and CryptSetProvParam)
- Used to write a collection of root certificates to the smart card or return HCERTSTORE, which contains root certificates from the smart card
- Used primarily for joining a domain by using a smart card
- Caller responsible for closing the certificate store |
+| PP\_SMARTCARD\_READER | - Read-only (used only by CryptGetProvParam)
- 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
- 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
- Persistent for the entire process when it is set
- 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).
diff --git a/windows/keep-secure/smart-card-certificate-propagation-service.md b/windows/keep-secure/smart-card-certificate-propagation-service.md
new file mode 100644
index 0000000000..4668d29aa8
--- /dev/null
+++ b/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**
+
+
+
+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)
diff --git a/windows/keep-secure/smart-card-certificate-requirements-and-enumeration.md b/windows/keep-secure/smart-card-certificate-requirements-and-enumeration.md
new file mode 100644
index 0000000000..16e40288d5
--- /dev/null
+++ b/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.
ECDH\_P256
ECDH
Curve P-256 from FIPS 186-2
ECDSA\_P256
ECDSA
Curve P-256 from FIPS 186-2
ECDH\_P384
ECDH
Curve P-384 from FIPS 186-2
ECDH\_P521
ECDH
Curve P-521 from FIPS 186-2
ECDSA\_P256
ECDH
Curve P-256 from FIPS 186-2
ECDSA\_P384
ECDSA
Curve P-384 from FIPS 186-2
ECDSA\_P521
ECDSA
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.
Keys are no longer restricted to the default container, and certificates in different containers can be chosen.
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**
+
+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** 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.
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** 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** 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:
\[1\]CRL Distribution Point
Distribution Point Name:
Full Name:
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.
**Note** 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)
The client authentication object identifier is required only if a certificate is used for SSL authentication.
- 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:
UPN=user1@contoso.com
The UPN OtherName object identifier is 1.3.6.1.4.1.311.20.2.3.
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: <I>"*<Issuer Name>*"<S>"*<Subject Name>*. The *<Issuer Name>* and *<Subject Name>* are taken from the client certificate, with '\\r' and '\\n' replaced with ','.
+
+**Certificate revocation list distribution points**
+
+
+
+**UPN in Subject Alternative Name field**
+
+
+
+**Subject and Issuer fields**
+
+
+
+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**
+
+
+
+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**
+
+
+
+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** 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** 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=*<DomainControllerName>*, 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)
+
diff --git a/windows/keep-secure/smart-card-debugging-information.md b/windows/keep-secure/smart-card-debugging-information.md
new file mode 100644
index 0000000000..c793347093
--- /dev/null
+++ b/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
+
+
+
+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 *<ComputerName>*.
+
+> **Note** 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
Value name: NtLmInfoLevel
Value type: DWORD
Value data: c0015003 |
+| Kerberos | HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Kerberos
Value name: LogToFile
Value type: DWORD
Value data: 00000001
HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Kerberos\\Parameters
Value name: KerbDebugLevel
Value type: DWORD
Value data: c0000043
HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Kerberos\\Parameters
Value name: LogToFile
Value type: DWORD
Value data: 00000001 |
+| KDC | HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Kdc
Value name: KdcDebugLevel
Value type: DWORD
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** 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)
diff --git a/windows/keep-secure/smart-card-events.md b/windows/keep-secure/smart-card-events.md
new file mode 100644
index 0000000000..7fcd797652
--- /dev/null
+++ b/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.
%1 = Windows error code
%2 = Smart card reader name
%3 = IOCTL being canceled
%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.
%1 = Number of seconds the IOCTL has been waiting
%2 = Smart card reader name
%3 = IOCTL sent
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%1 = Windows error code
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%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.
%1 = Windows error code
%2 = Name of the smart card reader
%3 = IOCTL that was sent
%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.
%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.
%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.
%1 = Windows error code
%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.
%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.
%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.
%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.
%1 = Smart card reader name
%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.
%1 = Smart card reader name
%2 = Name of new smart card device |
+
+## See also
+
+[Smart Card Technical Reference](smart-card-windows-smart-card-technical-reference.md)
diff --git a/windows/keep-secure/smart-card-group-policy-and-registry-settings.md b/windows/keep-secure/smart-card-group-policy-and-registry-settings.md
new file mode 100644
index 0000000000..7f3eb80f4e
--- /dev/null
+++ b/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** Smart card reader registry information is located in HKEY\_LOCAL\_MACHINE\\Software\\Microsoft\\Cryptography\\Calais\\Readers.
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** 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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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.
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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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.
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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
Policy conflicts: None
**Important** 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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Disabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Enabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Enabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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
Enabled and not configured are equivalent |
+| Policy management | Restart requirement: None
Sign off requirement: None
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.
Default value: 00000000 |
+| **AllowPrivateSignatureKeyImport** | A non-zero value allows RSA signature private keys to be imported for use in key archival scenarios.
Default value: 00000000 |
+| **DefaultPrivateKeyLenBits** | Defines the default length for private keys, if desired.
Default value: 00000400
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.
Default value: 00000000 |
+| **TransactionTimeoutMilliseconds** | Default timeout values allow you to specify whether transactions that take an excessive amount of time will fail.
Default value: 000005dc1500
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.
Default value: 00000000 |
+| **AllowPrivateECDSAKeyImport** | This value allows Elliptic Curve Digital Signature Algorithm (ECDSA) private keys to be imported for use in key archival scenarios.
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
Value = 1 |
+| HKEY\_LOCAL\_MACHINE\\SYSTEM\\CCS\\Control\\LSA\\Kerberos\\Parameters\\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors | Type = DWORD
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
scforceoption | Disabled | This security policy setting requires users to sign in to a computer by using a smart card.
**Enabled** Users can only sign in to the computer by using a smart card.
**Disabled** Users can sign in to the computer by using any method. |
+| Interactive logon: Smart card removal behavior
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:
**No Action**
**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.
**Force Logoff**: The user is automatically signed out when the smart card is removed.
**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.
**Note** 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** 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**
AllowFreshCredentials | Not Configured | This policy setting applies:
When server authentication was achieved through a trusted X509 certificate or Kerberos protocol.
To applications that use the CredSSP component (for example, Remote Desktop Services).
**Enabled**: You can specify the servers where the user's fresh credentials can be delegated.
**Not Configured**: After proper mutual authentication, delegation of fresh credentials is permitted to Remote Desktop Services running on any computer.
**Disabled**: Delegation of fresh credentials to any computer is not permitted.
**Note** 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:
Use *TERMSRV/\** for Remote Desktop Session Host (RD Session Host) running on any computer.
Use *TERMSRV/host.humanresources.fabrikam.com* for RD Session Host running on the host.humanresources.fabrikam.com computer.
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**
AllowFreshCredentialsWhenNTLMOnly | Not Configured | This policy setting applies:
When server authentication was achieved by using NTLM.
To applications that use the CredSSP component (for example, Remote Desktop).
**Enabled**: You can specify the servers where the user's fresh credentials can be delegated.
**Not Configured**: After proper mutual authentication, delegation of fresh credentials is permitted to RD Session Host running on any computer (TERMSRV/\*).
**Disabled**: Delegation of fresh credentials is not permitted to any computer.
**Note** 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.
See the **Allow Delegating Fresh Credentials** policy setting description for examples. |
+| **Deny Delegating Fresh Credentials**
DenyFreshCredentials | Not Configured | This policy setting applies to applications that use the CredSSP component (for example, Remote Desktop).
**Enabled**: You can specify the servers where the user's fresh credentials cannot be delegated.
**Disabled** or **Not Configured**: A server is not specified.
**Note** 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.
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)
diff --git a/windows/keep-secure/smart-card-how-smart-card-sign-in-works-in-windows.md b/windows/keep-secure/smart-card-how-smart-card-sign-in-works-in-windows.md
new file mode 100644
index 0000000000..a8e96e226c
--- /dev/null
+++ b/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.
diff --git a/windows/keep-secure/smart-card-removal-policy-service.md b/windows/keep-secure/smart-card-removal-policy-service.md
new file mode 100644
index 0000000000..dcd96bdf27
--- /dev/null
+++ b/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**
+
+
+
+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)
diff --git a/windows/keep-secure/smart-card-smart-cards-for-windows-service.md b/windows/keep-secure/smart-card-smart-cards-for-windows-service.md
new file mode 100644
index 0000000000..a0c0edd3dc
--- /dev/null
+++ b/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:
+
+```
+
+`Class=SmartCardReader`
`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** 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)
diff --git a/windows/keep-secure/smart-card-tools-and-settings.md b/windows/keep-secure/smart-card-tools-and-settings.md
new file mode 100644
index 0000000000..c84b997c09
--- /dev/null
+++ b/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)
diff --git a/windows/keep-secure/smart-card-windows-smart-card-technical-reference.md b/windows/keep-secure/smart-card-windows-smart-card-technical-reference.md
new file mode 100644
index 0000000000..bb376178cb
--- /dev/null
+++ b/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)
diff --git a/windows/keep-secure/virtual-smart-card-deploy-virtual-smart-cards.md b/windows/keep-secure/virtual-smart-card-deploy-virtual-smart-cards.md
new file mode 100644
index 0000000000..3c4dbe36c7
--- /dev/null
+++ b/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.
+
+
+
+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.
+
+
+
+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:
+
+
+
+| 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
**DEFAULT** Specifies the default value of 010203040506070801020304050607080102030405060708.
**PROMPT** Prompts the user to enter a value for the administrator key.
**RANDOM** 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.
**DEFAULT** Specifies the default PIN of 12345678.
**PROMPT** 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.
**DEFAULT** Specifies the default PUK of 12345678.
**PROMPT** 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:
**minlen** <minimum PIN length>
If not specificed, defaults to 8. The lower bound is 4.
**maxlen** <maximum PIN length>
If not specificed, defaults to 127. The upper bound is 127.
**uppercase** Can be **ALLOWED**, **DISALLOWED**, or **REQUIRED.** Default is **ALLOWED.**
**lowercase** Can be **ALLOWED**, **DISALLOWED**, or **REQUIRED.** Default is **ALLOWED.**
**digits** Can be **ALLOWED**, **DISALLOWED**, or **REQUIRED.** Default is **ALLOWED.**
**specialchars** Can be **ALLOWED**, **DISALLOWED**, or **REQUIRED.** Default is **ALLOWED.**
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:
**AIK_AND_CERT** 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.
**AIK_ONLY** 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
Windows Server 2012 R2
Windows Server 2012
Windows 10
Windows 8.1
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.
**Note**
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.
|
+| 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.
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.
+
+
+
+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).
diff --git a/windows/whats-new/security.md b/windows/whats-new/security.md
index 4cf480e9d7..a17f84be19 100644
--- a/windows/whats-new/security.md
+++ b/windows/whats-new/security.md
@@ -166,8 +166,9 @@ Credential Guard is another new feature in Windows 10 Enterprise that employs V
For more information about the hardware requirements for Credential Guard, see the [Windows 10 hardware considerations](#hardware) section. For more information about VBS in Windows 10, see the [Virtualization-based security](#virtualization-based-security) section.
-**Note**
-Because it requires isolated user mode and a Hyper-V hypervisor, you cannot configure Credential Guard on a VM, only on a physical computer.
+> [!NOTE]
+> Starting in Windows 10, version 1607, you can configure Credential Guard on a VM.
+
The Credential Guard feature is targeted at resisting the use of pass-the-hash and pass-the-ticket techniques. By employing a MFA option such as Microsoft Passport with Credential Guard, you can gain additional protection against such threats. For more in-depth information about how Credential Guard works and the specific mitigations it provides, see [Protect derived domain credentials with Credential Guard](../keep-secure/credential-guard.md).