mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-19 20:33:42 +00:00
updates
This commit is contained in:
Paolo Matarazzo
@ -9,12 +9,12 @@ ms.reviewer: ardenw
|
||||
|
||||
This topic for the IT professional describes the behavior of Remote Desktop Services when you implement smart card sign-in.
|
||||
|
||||
Smart card redirection logic and **WinSCard** API are combined to support multiple redirected sessions into a single process.
|
||||
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
|
||||
- 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
|
||||
|
||||
@ -86,10 +86,6 @@ For information about this option for the command-line tool, see [-addstore](/pr
|
||||
> [!NOTE]
|
||||
> 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*>
|
||||
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)
|
||||
@ -135,14 +135,13 @@ In response to a CryptAcquireContext call in CryptoAPI, the Base CSP tries to ma
|
||||
|
||||
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**
|
||||
> [!NOTE]
|
||||
> Before opening a key by using the smart card KSP, a call to NCryptOpenStorageProvider (`MS\_SMART\_CARD\_KEY\_STORAGE\_PROVIDER`) must be made.
|
||||
> 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>` |
|
||||
| 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 |
|
||||
|
||||
@ -152,62 +151,63 @@ The Base CSP and smart card KSP cache smart card handle information about the ca
|
||||
|
||||
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.)
|
||||
1. Create a new container. (The CNG equivalent of CryptAcquireContext with dwFlags set to CRYPT_NEWKEYSET is NCryptCreatePersistedKey.)
|
||||
1. Open an existing container. (The CNG equivalent of CryptAcquireContext to open the container is NCryptOpenKey.)
|
||||
1. Delete a container. (The CNG equivalent of CryptAcquireContext with dwFlags set to CRYPT\_DELETEKEYSET is NCryptDeleteKey.)
|
||||
1. 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. |
|
||||
| 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. |
|
||||
| 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.
|
||||
> [!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:
|
||||
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.
|
||||
1. Call CryptSetProvParam by specifying PP\_KEYEXCHANGE\_PIN or PP\_SIGNATURE\_PIN and a null-terminated ASCII PIN.
|
||||
1. Release the context acquired in Step 1.
|
||||
1. Call CryptAcquireContext with CRYPT\_NEWKEYSET, and specify the type I container specification level.
|
||||
1. Call CryptGenKey to create the key.
|
||||
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
|
||||
1. Call CryptSetProvParam by specifying `PP_KEYEXCHANGE_PIN` or `PP_SIGNATURE_PIN` and a null-terminated ASCII PIN.
|
||||
1. Release the context acquired in Step 1
|
||||
1. Call CryptAcquireContext with `CRYPT_NEWKEYSET`, and specify the type I container specification level
|
||||
1. 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 shows the selection steps performed by the Windows operating system.
|
||||
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 select **Cancel**. If the user cancels the operation, the operation fails. The flow chart shows the selection steps performed by the Windows operating system.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
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.)
|
||||
1. 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.)
|
||||
1. For container specification level II only, the name of the default container on the chosen smart card is determined.
|
||||
1. 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.
|
||||
1. If the system attempts to create a new container, if the specified container already exists on this smart card, the process fails.
|
||||
1. Find the requested smart card reader. If it cannot be found, the process fails (this requires a cache search by reader name)
|
||||
1. 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)
|
||||
1. For container specification level II only, the name of the default container on the chosen smart card is determined
|
||||
1. 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
|
||||
1. 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
|
||||
|
||||
@ -215,26 +215,28 @@ For container specification levels III and IV, a broader method is used to match
|
||||
|
||||
#### Open an existing default container (no reader specified)
|
||||
|
||||
> **Note** This operation requires that you use the smart card with the Base CSP.
|
||||
> [!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.
|
||||
1. 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.
|
||||
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
|
||||
1. 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.
|
||||
> [!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).
|
||||
|
||||
1. 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.
|
||||
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)
|
||||
1. 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.
|
||||
> [!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.
|
||||
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.
|
||||
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
|
||||
@ -249,7 +251,7 @@ For other operations, the caller may be able to acquire a "verify" context again
|
||||
1. 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
|
||||
1. 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
|
||||
1. 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 povided 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.
|
||||
1. 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 povided 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
|
||||
|
||||
@ -262,13 +264,13 @@ The following diagram shows the Cryptography architecture that is used by the Wi
|
||||
> [!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<br>- Read-only (used only by CryptGetProvParam)<br>- Caller responsible for closing the certificate store<br>- Certificate encoded using PKCS\_7\_ASN\_ENCODING or X509\_ASN\_ENCODING<br>- CSP should set KEY\_PROV\_INFO on certificates<br>- Certificate store should be assumed to be an in-memory store<br>- Certificates should have a valid CRYPT\_KEY\_PROV\_INFO as a property |
|
||||
| PP\_ROOT\_CERTSTORE | - Read and Write (used by CryptGetProvParam and CryptSetProvParam)<br>- Used to write a collection of root certificates to the smart card or return HCERTSTORE, which contains root certificates from the smart card<br>- Used primarily for joining a domain by using a smart card<br>- Caller responsible for closing the certificate store |
|
||||
| PP\_SMARTCARD\_READER | - Read-only (used only by CryptGetProvParam)<br>- Returns the smart card reader name as an ANSI string that is used to construct a fully qualified container name (that is, a smart card reader plus a container) |
|
||||
| PP\_SMARTCARD\_GUID | - Return smart card GUID (also known as a serial number), which should be unique for each smart card<br>- Used by the certificate propagation service to track the source of a root certificate|
|
||||
| PP\_UI\_PROMPT | - Used to set the search string for the SCardUIDlgSelectCard card insertion dialog box<br>- Persistent for the entire process when it is set<br>- Write-only (used only by CryptSetProvParam) |
|
||||
| Property | Description |
|
||||
|--|--|
|
||||
| `PP_USER_CERTSTORE` | - Used to return an `HCERTSTORE` that contains all user certificates on the smart card<br>- Read-only (used only by `CryptGetProvParam`)<br>- Caller responsible for closing the certificate store<br>- Certificate encoded using `PKCS_7_ASN_ENCODING` or `X509_ASN_ENCODING`<br>- CSP should set `KEY_PROV_INFO` on certificates<br>- Certificate store should be assumed to be an in-memory store<br>- Certificates should have a valid `CRYPT_KEY_PROV_INFO` as a property |
|
||||
| `PP_ROOT_CERTSTORE` | - Read and Write (used by `CryptGetProvParam` and `CryptSetProvParam`)<br>- Used to write a collection of root certificates to the smart card or return `HCERTSTORE`, which contains root certificates from the smart card<br>- Used primarily for joining a domain by using a smart card<br>- Caller responsible for closing the certificate store |
|
||||
| `PP_SMARTCARD_READER` | - Read-only (used only by `CryptGetProvParam`)<br>- Returns the smart card reader name as an ANSI string that is used to construct a fully qualified container name (that is, a smart card reader plus a container) |
|
||||
| `PP_SMARTCARD_GUID `| - Return smart card GUID (also known as a serial number), which should be unique for each smart card<br>- Used by the certificate propagation service to track the source of a root certificate |
|
||||
| `PP_UI_PROMPT` | - Used to set the search string for the `SCardUIDlgSelectCard` card insertion dialog box<br>- Persistent for the entire process when it is set<br>- Write-only (used only by `CryptSetProvParam`) |
|
||||
|
||||
### Implications for CSPs in Windows
|
||||
|
||||
|
||||
@ -12,53 +12,43 @@ This topic for the IT professional describes the certificate propagation service
|
||||
|
||||
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.
|
||||
> [!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.
|
||||
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
|
||||
1. The arrow labeled **R** represents the possibility of a remote session and the use of smart card redirection
|
||||
1. The arrow labeled **2** indicates the certification to the reader
|
||||
1. The arrow labeled **3** indicates the access to the certificate store during the client session
|
||||
|
||||
2. The arrow labeled **R** represents the possibility of a remote session and the use of smart card redirection.
|
||||
|
||||
3. The arrow labeled **2** indicates the certification to the reader.
|
||||
|
||||
4. The arrow labeled **3** indicates the access to the certificate store during the client session.
|
||||
|
||||
**Certificate propagation service**
|
||||
### Certificate propagation service
|
||||
|
||||
|
||||
|
||||
1. A signed-in user inserts a smart card.
|
||||
1. A signed-in user inserts a smart card
|
||||
1. CertPropSvc is notified that a smart card was inserted
|
||||
1. CertPropSvc reads all certificates from all inserted smart cards. The certificates are written to the user's personal certificate store
|
||||
|
||||
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.
|
||||
> [!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.
|
||||
- `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
|
||||
- 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.
|
||||
|
||||
|
||||
@ -13,19 +13,19 @@ This topic for the IT professional and smart card developers describes how certi
|
||||
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).
|
||||
> 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).
|
||||
1. 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>\\
|
||||
1. 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>\
|
||||
1. 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.
|
||||
1. The name of the container is retrieved by using the PP\_CONTAINER parameter with CryptGetProvParam.
|
||||
1. 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.
|
||||
1. If the operation in Step 5 fails, the default container context from Step 3 is queried for the AT\_KEYEXCHANGE key.
|
||||
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. The name of the container is retrieved by using the PP_CONTAINER parameter with CryptGetProvParam.
|
||||
1. 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.
|
||||
1. If the operation in Step 5 fails, the default container context from Step 3 is queried for the AT_KEYEXCHANGE key.
|
||||
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 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.
|
||||
@ -59,9 +59,9 @@ Following are the steps that are performed during a smart card sign-in:
|
||||
|
||||
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 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.
|
||||
@ -70,27 +70,28 @@ Following are the steps that are performed during a smart card sign-in:
|
||||
|
||||
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 is not in the same forest because it enables a certificate to be mapped to multiple user accounts.
|
||||
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 is not 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)).
|
||||
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.<br>If the authentication is performed by using a certificate that uses key encipherment, the preauthentication data consists of the user's public certificate and the certificate that is encrypted with the corresponding private key.
|
||||
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.
|
||||
|
||||
1. 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).
|
||||
1. 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.
|
||||
1. 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.
|
||||
1. 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.
|
||||
1. 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.
|
||||
1. The domain controller returns the TGT to the client as part of the KRB\_AS\_REP response.
|
||||
1. 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
|
||||
> [!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.
|
||||
|
||||
@ -107,7 +108,7 @@ Following are the steps that are performed during a smart card sign-in:
|
||||
|
||||
For more information about the Kerberos protocol, see [Microsoft Kerberos](/windows/win32/secauthn/microsoft-kerberos).
|
||||
|
||||
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.
|
||||
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
|
||||
|
||||
@ -117,7 +118,7 @@ Active Directory Certificate Services provides three kinds of certificate templa
|
||||
- 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.
|
||||
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
|
||||
|
||||
@ -135,7 +136,7 @@ The smart card certificate has specific format requirements when it is used with
|
||||
| extended key usage (EKU) | The smart card sign-in object identifier is not required.<br><br>**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. |
|
||||
| Subject alternative name | E-mail ID is not required for smart card sign-in. |
|
||||
| Subject | Not required |
|
||||
| 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.) |
|
||||
| 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.) |
|
||||
| CRL | Not required |
|
||||
| UPN | Not required |
|
||||
| Notes | You can enable any certificate to be visible for the smart card credential provider. |
|
||||
@ -144,7 +145,7 @@ The smart card certificate has specific format requirements when it is used with
|
||||
|
||||
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: `<Issuer Name>` `<Subject Name`. The `<Issuer Name>` and `<Subject Name>` are taken from the client certificate, with '\\r' and '\\n' replaced with ','.
|
||||
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: `<Issuer Name>` `<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
|
||||
|
||||
@ -178,7 +179,7 @@ The following figure illustrates the process of mapping user accounts for sign-i
|
||||
|
||||
|
||||
|
||||
NT\_AUTH policy is best described in the CERT\_CHAIN\_POLICY\_NT\_AUTH parameter section of the CertVerifyCertificateChainPolicy function. For more information, see [CertVerifyCertificateChainPolicy](/windows/win32/api/wincrypt/nf-wincrypt-certverifycertificatechainpolicy).
|
||||
NT_AUTH policy is best described in the CERT_CHAIN_POLICY_NT_AUTH parameter section of the CertVerifyCertificateChainPolicy function. For more information, see [CertVerifyCertificateChainPolicy](/windows/win32/api/wincrypt/nf-wincrypt-certverifycertificatechainpolicy).
|
||||
|
||||
## Smart card sign-in for a single user with one certificate into multiple accounts
|
||||
|
||||
@ -206,7 +207,7 @@ For example, if Certificate1 has CN=CNName1, Certificate2 has CN=User1, and Cert
|
||||
|
||||
## 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`.
|
||||
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.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Smart Card Technical Reference
|
||||
description: Learn about the Windows smart card infrastructure for physical smart cards, and how smart card-related components work in Windows.
|
||||
ms.reviewer: ardenw
|
||||
ms.topic: reference
|
||||
ms.topic: overview
|
||||
ms.date: 11/06/2023
|
||||
---
|
||||
|
||||
|
||||
@ -93,7 +93,8 @@ On your domain server, you need to create a template for the certificate that yo
|
||||
|
||||
15. From the list, select the new template that you just created (**TPM Virtual Smart Card Logon**), and then click **OK**.
|
||||
|
||||
> **Note** It can take some time for your template to replicate to all servers and become available in this list.
|
||||
> [!NOTE]
|
||||
> It can take some time for your template to replicate to all servers and become available in this list.
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user