deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-18 20:03:40 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

updates

Browse Source
This commit is contained in:
Paolo Matarazzo
2023-11-21 14:44:31 -05:00
parent 6f2b9667a0
commit d4273eb2b4
3 changed files with 32 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
windows/security/identity-protection/smart-cards/smart-card-and-remote-desktop-services.md
View File

@ -1,9 +1,10 @@
---
ms.date: 11/07/2023
ms.date: 11/21/2023
title: Smart Card and Remote Desktop Services
description: This topic for the IT professional describes the behavior of Remote Desktop Services when you implement smart card sign-in.
ms.topic: conceptual
ms.topic: concept-article
---
# Smart Card and Remote Desktop Services
This topic for the IT professional describes the behavior of Remote Desktop Services when you implement smart card sign-in.
@ -25,7 +26,7 @@ In a Remote Desktop scenario, a user is using a remote server for running servic
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`
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`
1. 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
1. The authentication is performed by the LSA in session 0
1. 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
@ -44,7 +45,7 @@ When smart card-enabled single sign-in (SSO) is used for Remote Desktop Services
Remote Desktop Services enables 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.
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 isn't in the same domain or workgroup, the following command can be used to deploy the certificate:

16
windows/security/identity-protection/smart-cards/smart-card-certificate-propagation-service.md
View File

@ -1,15 +1,13 @@
---
title: Certificate Propagation Service
description: This topic for the IT professional describes the certificate propagation service (CertPropSvc), which is used in smart card implementation.
title: Certificate propagation service
description: Learn about the certificate propagation service (CertPropSvc), which is used in smart card implementation.
ms.topic: concept-article
ms.date: 08/24/2021
ms.date: 11/21/2023
---
# Certificate Propagation Service
# Certificate propagation service
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).
The certificate propagation service (CertPropSvc) is a Windows service that activates when a user inserts a smart card in a reader that is attached to the device. The action causes the certificates 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.
@ -47,9 +45,9 @@ Root certificate propagation is responsible for the following smart card deploym
- Joining the domain
- Accessing a network remotely
In both cases, the computer isn't joined to a domain, and therefore, trust isn't 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.
In both cases, the computer isn't joined to a domain, and therefore, trust isn't 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 might 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).
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 might 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).

40
windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md
View File

@ -23,23 +23,23 @@ When a smart card is inserted, the following steps are performed.
1. The certificate is then queried from the key context by using KP_CERTIFICATE. The certificate is added to an in-memory certificate store.
1. 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).
1. The certificate must not be in the AT_SIGNATURE part of a container.
1. The certificate must have a valid user principal name (UPN).
1. The certificate must have the digital signature key usage.
1. The certificate must have the smart card logon EKU.
1. The certificate must be valid, based on the computer system clock (not expired or valid with a future date)
1. The certificate must not be in the AT_SIGNATURE part of a container
1. The certificate must have a valid user principal name (UPN)
1. The certificate must have the digital signature key usage
1. 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).
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)
1. The process then chooses a certificate, and the PIN is entered.
1. LogonUI.exe packages the information and sends it to Lsass.exe to process the sign-in attempt.
1. If successful, LogonUI.exe closes. This causes the context acquired in Step 3 to be released.
1. The process then chooses a certificate, and the PIN is entered
1. LogonUI.exe packages the information and sends it to Lsass.exe to process the sign-in attempt
1. If successful, `LogonUI.exe` closes. This causes the context acquired in Step 3 to be released
## 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) doesn't reacquire the session context; it relies instead on the Cryptographic Service Provider to handle the session change.
Client certificates that don't 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.
Client certificates that don't 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.
@ -53,22 +53,22 @@ The following diagram illustrates how smart card sign-in works in the supported
Following are the steps that are performed during a smart card sign-in:
1. Winlogon requests the sign-in UI credential information.
1. Winlogon requests the sign-in UI credential information
1. 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).
1. Gets a list of smart card readers (by using the WinSCard API) and the list of smart cards inserted in each of them.
1. 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.
1. Gets credential information (a list of known credentials, or if no credentials exist, the smart card reader information that Windows detected)
1. Gets a list of smart card readers (by using the WinSCard API) and the list of smart cards inserted in each of them
1. 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, 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.
1. Notifies the sign-in UI that it has new credentials.
1. Notifies the sign-in UI that it has new credentials
1. 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.
1. The user enters the PIN, and then presses ENTER. The smart card credential provider encrypts the PIN.
1. 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 isn't in the same forest because it enables a certificate to be mapped to multiple user accounts.
1. 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.
1. Winlogon presents the data from LogonUI to the LSA with the user information in LSALogonUser.
1. 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
1. The user enters the PIN, and then presses ENTER. The smart card credential provider encrypts the PIN
1. 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 isn't in the same forest because it enables a certificate to be mapped to multiple user accounts
1. 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
1. Winlogon presents the data from LogonUI to the LSA with the user information in LSALogonUser
1. 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.\