mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 13:27:23 +00:00
Correctness/typo copyedit
windows/security/identity-protection/enterprise-certificate-pinning.md https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/e890ad26-c01b-4744-a8c3-b3e957305871#CORRECTNESS Line 101: exclude > excludes Line 109: then, wildcard > then wildcard windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/fbf76d9b-398e-4c35-9f42-7e5f64432f7f#CORRECTNESS Line 35: trust deployment, does not > trust deployment does not Line 90: technology, such as DirSync or Azure AD sync need > technology, such as DirSync or Azure AD sync, need windows/security/identity-protection/hello-for-business/retired/hello-how-it-works.md https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/75fb9e1f-9c73-4f30-9f9c-70d3bf630370#CORRECTNESS Line 58: keys > key Lines 65 and 74: Any time > Anytime windows/security/identity-protection/smart-cards/smart-card-and-remote-desktop-services.md https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/29e7c53f-7633-454a-8474-522cf3bd3c20#CORRECTNESS Line 66: Remote Desktop Services enable > Remote Desktop Services enables windows/security/identity-protection/smart-cards/smart-card-architecture.md https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/9a406540-b330-4be9-a714-a1997e1482b0#CORRECTNESS Line 125: it require > it requires windows/security/identity-protection/smart-cards/smart-card-events.md https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/d03be924-73ef-455a-92c5-a8227c3cca56#CORRECTNESS Line 53: could not to be > could not be windows/security/identity-protection/smart-cards/smart-card-group-policy-and-registry-settings.md https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/859b68c2-dd5d-49c6-93d4-e01aba2935b3#CORRECTNESS Lines 96, 152, 167, 185, 258 (x2), 262, 268, 306, and 311: sign in > sign-in Line 198: clean up > clean-up windows/security/identity-protection/smart-cards/smart-card-removal-policy-service.md https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/12a919ae-26c5-416d-be2e-5e31fe29e752#CORRECTNESS Line 33: sign in > sign-in
This commit is contained in:
Angela Fleischmann
parent
cdcf5eb2f3
commit
2c88cd4fae
@ -98,7 +98,7 @@ The **Certificate** element can have the following attributes.
|
||||
| **File** | Path to a file containing one or more certificates. Where the certificate(s) can be encoded as: <br>- single certificate <br>- p7b <br>- sst <br> These files can also be Base64 formatted. All **Site** elements included in the same **PinRule** element can match any of these certificates. | Yes (File, Directory, or Base64 must be present). |
|
||||
| **Directory** | Path to a directory containing one or more of the above certificate files. Skips any files not containing any certificates. | Yes (File, Directory, or Base64 must be present). |
|
||||
| **Base64** | Base64 encoded certificate(s). Where the certificate(s) can be encoded as: <br>- single certificate <br>- p7b <br> - sst <br> This allows the certificates to be included in the XML file without a file directory dependency. <br> Note: <br> You can use **certutil -encode** to convert a .cer file into base64. You can then use Notepad to copy and paste the base64 encoded certificate into the pin rule. | Yes (File, Directory, or Base64 must be present). |
|
||||
| **EndDate** | Enables you to configure an expiration date for when the certificate is no longer valid in the pin rule. <br>If you are in the process of switching to a new root or CA, you can set the **EndDate** to allow matching of this element’s certificates.<br> If the current time is past the **EndDate**, then, when creating the certificate trust list (CTL), the parser outputs a warning message and exclude the certificate(s) from the Pin Rule in the generated CTL.<br> For help with formatting Pin Rules, see [Representing a Date in XML](#representing-a-date-in-xml).| No.|
|
||||
| **EndDate** | Enables you to configure an expiration date for when the certificate is no longer valid in the pin rule. <br>If you are in the process of switching to a new root or CA, you can set the **EndDate** to allow matching of this element’s certificates.<br> If the current time is past the **EndDate**, then, when creating the certificate trust list (CTL), the parser outputs a warning message and excludes the certificate(s) from the Pin Rule in the generated CTL.<br> For help with formatting Pin Rules, see [Representing a Date in XML](#representing-a-date-in-xml).| No.|
|
||||
|
||||
#### Site element
|
||||
|
||||
@ -106,7 +106,7 @@ The **Site** element can have the following attributes.
|
||||
|
||||
| Attribute | Description | Required |
|
||||
|-----------|-------------|----------|
|
||||
| **Domain** | Contains the DNS name to be matched for this pin rule. When creating the certificate trust list, the parser normalizes the input name string value as follows: <br>- If the DNS name has a leading "*", it's removed. <br>- Non-ASCII DNS name is converted to ASCII Puny Code. <br>- Upper case ASCII characters are converted to lower case. <br>If the normalized name has a leading ".", then, wildcard left-hand label matching is enabled. For example, ".xyz.com" would match "abc.xyz.com". | Yes.|
|
||||
| **Domain** | Contains the DNS name to be matched for this pin rule. When creating the certificate trust list, the parser normalizes the input name string value as follows: <br>- If the DNS name has a leading "*", it's removed. <br>- Non-ASCII DNS name is converted to ASCII Puny Code. <br>- Upper case ASCII characters are converted to lower case. <br>If the normalized name has a leading ".", then wildcard left-hand label matching is enabled. For example, ".xyz.com" would match "abc.xyz.com". | Yes.|
|
||||
| **AllSubdomains** | By default, wildcard left-hand label matching is restricted to a single left-hand label. This attribute can be set to "true" to enable wildcard matching of all of the left-hand labels.<br>For example, setting this attribute would also match "123.abc.xyz.com" for the ".xyz.com" domain value.| No.|
|
||||
|
||||
### Create a Pin Rules Certificate Trust List
|
||||
|
||||
@ -32,7 +32,7 @@ The distributed systems on which these technologies were built involved several
|
||||
|
||||
Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure Active Directory. The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2.
|
||||
|
||||
A hybrid Windows Hello for Business deployment needs an Azure Active Directory subscription. The hybrid key trust deployment, does not need a premium Azure Active Directory subscription.
|
||||
A hybrid Windows Hello for Business deployment needs an Azure Active Directory subscription. The hybrid key trust deployment does not need a premium Azure Active Directory subscription.
|
||||
|
||||
You can deploy Windows Hello for Business in any environment with Windows Server 2008 R2 or later domain controllers.
|
||||
If using the key trust deployment model, you MUST ensure that you have adequate (1 or more, depending on your authentication load) Windows Server 2016 or later Domain Controllers in each Active Directory site where users will be authenticating for Windows Hello for Business.
|
||||
@ -87,7 +87,7 @@ The minimum required Enterprise certificate authority that can be used with Wind
|
||||
|
||||
The two directories used in hybrid deployments must be synchronized. You need Azure Active Directory Connect to synchronize user accounts in the on-premises Active Directory with Azure Active Directory.
|
||||
|
||||
Organizations using older directory synchronization technology, such as DirSync or Azure AD sync need to upgrade to Azure AD Connect.
|
||||
Organizations using older directory synchronization technology, such as DirSync or Azure AD sync, need to upgrade to Azure AD Connect.
|
||||
|
||||
### Section Review
|
||||
|
||||
|
||||
@ -55,14 +55,14 @@ Containers can contain several types of key material:
|
||||
|
||||
- An authentication key, which is always an asymmetric public–private key pair. This key pair is generated during registration. It must be unlocked each time it’s accessed, by using either the user’s PIN or a previously generated biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key.
|
||||
- Virtual smart card keys are generated when a virtual smart card is generated and stored securely in the container. They’re available whenever the user’s container is unlocked.
|
||||
- The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP keys). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Azure AD accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
|
||||
- The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP key). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Azure AD accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
|
||||
|
||||
- The IDP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES), described more fully in [Network Device Enrollment Service Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831498(v=ws.11)). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as popular virtual private network systems, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container.
|
||||
- The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don’t have or need a PKI.
|
||||
|
||||
## How keys are protected
|
||||
|
||||
Any time key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There’s a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Work implementation takes advantage of onboard TPM hardware to generate and protect keys. However, Windows Hello and Windows Hello for Work do not require an onboard TPM. Administrators can choose to allow key operations in software, in which case any user who has (or can escalate to) administrative rights on the device can use the IDP keys to sign requests. As an alternative, in some scenarios, devices that don’t have a TPM can be remotely authenticated by using a device that does have a TPM, in which case all the sensitive operations are performed with the TPM and no key material is exposed.
|
||||
Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There’s a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Work implementation takes advantage of onboard TPM hardware to generate and protect keys. However, Windows Hello and Windows Hello for Work do not require an onboard TPM. Administrators can choose to allow key operations in software, in which case any user who has (or can escalate to) administrative rights on the device can use the IDP keys to sign requests. As an alternative, in some scenarios, devices that don’t have a TPM can be remotely authenticated by using a device that does have a TPM, in which case all the sensitive operations are performed with the TPM and no key material is exposed.
|
||||
|
||||
Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means he or she will have to use MFA to reauthenticate to the IDP before the IDP allows him or her to re-register). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.
|
||||
|
||||
@ -71,7 +71,7 @@ Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protect
|
||||
|
||||
When a user wants to access protected key material, the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called releasing the key. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. The user's PIN unlocks the protector key for the container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container.
|
||||
|
||||
These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It’s important to understand that although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or sign in to a website). Access through these APIs doesn’t require explicit validation through a user gesture, and the key material isn’t exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Windows Hello layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure the Microsoft Store to require reauthentication any time a user purchases an application, even though the same account and PIN or gesture were already used to unlock the device.
|
||||
These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It’s important to understand that although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or sign in to a website). Access through these APIs doesn’t require explicit validation through a user gesture, and the key material isn’t exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Windows Hello layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure the Microsoft Store to require reauthentication anytime a user purchases an application, even though the same account and PIN or gesture were already used to unlock the device.
|
||||
|
||||
For example, the authentication process for Azure Active Directory works like this:
|
||||
|
||||
|
||||
@ -63,7 +63,7 @@ When smart card-enabled single sign-in (SSO) is used for Remote Desktop Services
|
||||
|
||||
### 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.
|
||||
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.
|
||||
|
||||
|
||||
@ -122,7 +122,7 @@ The global data cache is hosted in the Smart Cards for Windows service. Windows
|
||||
|
||||
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.
|
||||
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 requires 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.
|
||||
|
||||
|
||||
@ -50,7 +50,7 @@ The smart card reader device name is constructed in the form <*VendorName*>
|
||||
|
||||
| **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's removed from the computer or the computer is restarted.<br><br>%1 = Windows error code<br>%2 = Smart card reader name<br>%3 = IOCTL being canceled<br>%4 = First 4 bytes of the command that was sent to the smart card |
|
||||
| 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 be canceled. This can leave the smart card reader in an unusable state until it's removed from the computer or the computer is restarted.<br><br>%1 = Windows error code<br>%2 = Smart card reader name<br>%3 = IOCTL being canceled<br>%4 = First 4 bytes of the command that was sent to the smart card |
|
||||
| 619 | Smart Card Reader '%2' hasn't 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 hasn't responded to an IOCTL after an unusually long period of time. Currently, this error is sent after a reader doesn't respond for 150 seconds. This can leave the smart card reader in an unusable state until it's removed from the computer or the computer is restarted.<br><br>%1 = Number of seconds the IOCTL has been waiting<br>%2 = Smart card reader name<br>%3 = IOCTL sent<br>%4 = First 4 bytes of the command that was sent to the smart card |
|
||||
|
||||
## Smart card error events
|
||||
|
||||
@ -93,7 +93,7 @@ The following table lists the default values for these GPO settings. Variations
|
||||
|
||||
### Allow certificates with no extended key usage certificate attribute
|
||||
|
||||
You can use this policy setting to allow certificates without an enhanced key usage (EKU) set to be used for sign in.
|
||||
You can use this policy setting to allow 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.
|
||||
@ -149,9 +149,9 @@ When this setting isn't turned on, the feature is not available.
|
||||
|
||||
### Allow signature keys valid for Logon
|
||||
|
||||
You can use this policy setting to allow signature key–based certificates to be enumerated and available for sign in.
|
||||
You can use this policy setting to allow signature key–based certificates to be enumerated and available for sign-in.
|
||||
|
||||
When this setting is turned on, any certificates that are available on the smart card with a signature-only key are listed on the sign-in screen.
|
||||
When this setting is turned on, any certificates that are available on the smart card with a signature-only key are listed on the sign-in screen.
|
||||
|
||||
When this setting isn't turned on, certificates available on the smart card with a signature-only key aren't listed on the sign-in screen.
|
||||
|
||||
@ -164,7 +164,7 @@ When this setting isn't turned on, certificates available on the smart card with
|
||||
|
||||
### Allow time invalid certificates
|
||||
|
||||
You can use this policy setting to permit certificates that are expired or not yet valid to be displayed for sign in.
|
||||
You can use this policy setting to permit certificates that are expired or not yet valid to be displayed for sign-in.
|
||||
|
||||
> [!NOTE]
|
||||
> Before Windows Vista, certificates were required to contain a valid time and to not expire. For a certificate to be used, it must be accepted by the domain controller. This policy setting only controls which certificates are displayed on the client computer.
|
||||
@ -182,7 +182,7 @@ When this policy setting isn't turned on, certificates that are expired or not y
|
||||
|
||||
### Allow user name hint
|
||||
|
||||
You can use this policy setting to determine whether an optional field appears during sign in and provides a subsequent elevation process where users can enter their username or username and domain, which associates a certificate with the user.
|
||||
You can use this policy setting to determine whether an optional field appears during sign-in and provides a subsequent elevation process where users can enter their username or username and domain, which associates a certificate with the user.
|
||||
|
||||
When this policy setting is turned on, users see an optional field where they can enter their username or username and domain.
|
||||
|
||||
@ -195,7 +195,7 @@ When this policy setting isn't turned on, users don't see this optional field.
|
||||
| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None |
|
||||
| Notes and resources | |
|
||||
|
||||
### Configure root certificate clean up
|
||||
### Configure root certificate clean-up
|
||||
|
||||
You can use this policy setting 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.
|
||||
|
||||
@ -255,17 +255,17 @@ This policy setting is applied to the computer after the [Allow time invalid cer
|
||||
|
||||
### Force the reading of all certificates from the smart card
|
||||
|
||||
You can use this policy setting 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.
|
||||
You can use this policy setting 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 turned on, Windows attempts to read all certificates from the smart card, regardless of the CSP feature set.
|
||||
When this policy setting is turned on, Windows attempts to read all certificates from the smart card, regardless of the CSP feature set.
|
||||
|
||||
When this policy isn't turned on, Windows attempts to read only the default certificate from smart cards that don't support retrieval of all certificates in a single call. Certificates other than the default aren't available for sign in.
|
||||
When this policy isn't turned on, Windows attempts to read only the default certificate from smart cards that don't support retrieval of all certificates in a single call. Certificates other than the default aren't available for sign-in.
|
||||
|
||||
| **Item** | **Description** |
|
||||
|--------------------------------------|----------------------------------------------------------------------------|
|
||||
| Registry key | **ForceReadingAllCertificates** |
|
||||
| Default values | No changes per operating system versions<br>Disabled and not configured are equivalent |
|
||||
| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None<br><br>**Important**: Enabling this policy setting can adversely impact performance during the sign in process in certain situations. |
|
||||
| Policy management | Restart requirement: None<br>Sign off requirement: None<br>Policy conflicts: None<br><br>**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
|
||||
@ -303,12 +303,12 @@ When this setting isn't turned on, Credential Manager can return plaintext PINs.
|
||||
|
||||
### Reverse the subject name stored in a certificate when displaying
|
||||
|
||||
You can use this policy setting to control the way the subject name appears during sign in.
|
||||
You can use this policy setting to control the way the subject name appears during sign-in.
|
||||
|
||||
> [!NOTE]
|
||||
> 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.
|
||||
|
||||
When this policy setting is turned on, the subject name during sign in appears reversed from the way that it's stored in the certificate.
|
||||
When this policy setting is turned on, the subject name during sign-in appears reversed from the way that it's stored in the certificate.
|
||||
|
||||
When this policy setting isn’t turned on, the subject name appears the same as it’s stored in the certificate.
|
||||
|
||||
|
||||
@ -30,7 +30,7 @@ The smart card removal policy service is applicable when a user has signed in wi
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user