Windows smartcard authentication

Please Wait Results: 10 rates. Trademarks are property of their respective owners. Quick Search. A t tachments 0 Page History. Skip to end of banner. Jira links. Created by Andreas Laumann , last modified on Mar 30, Skip to end of metadata. Prerequisites A compatible environment capable of providing Smart Card Authentication, as well as administrator access to the client Mac endpoints is required to enable Smart Card Authentication on macOS.

Right-click the Windows Start button and select Run. Type certtmpl. For Validity period, ensure the timeframe you specify does not exceed the restrictions for your Certification Authority. Ensure the option to Publish certificate in Active Directory is selected. Select the Compatibility tab and make the following changes as needed: Select the operating system OS that matches the OS of the Certification Authority.

For Certificate recipient, select the oldest Windows operating system in your Active Directory domain. Select the Request Handling tab and make the following changes as needed: For Purpose, select Signature and encryption.

Ensure the option for Include symmetric algorithms allowed by the subject is selected. Ensure the option for Renew with the same key is selected. This option may be disabled if Windows 7 and below are included in the Compatibility settings. Check the option For automatic renewal of smart card certificates, use the existing key if a new key cannot be created. Select the option for Enroll subject without requiring any user input. On the Cryptography tab make the following changes as needed: Provider category: Select Key Storage Provider from the dropdown.

Algorithm name: Select RSA. Minimum key size: Select the option for Requests must use one of the following providers. For Request hash, select SHA from the list displayed.

On the Security tab make the following changes as needed: Group or user names: Confirm the domain group you want to allow access to the template is listed.

If not, click Add , enter the name of the group, and then click OK. Permissions for [group name]: Ensure Read and Enroll are checked. If users will be auto-enrolling using the built-in Windows functionality, also check Autoenroll. Click Apply , and then click OK to close the template properties window. Close the Certificate Templates window. For Certificate recipient, select the oldest Windows operating system in your domain environment. Virtual smart cards were introduced in Windows Server and Windows 8 to alleviate the need for a physical smart card, the smart card reader, and the associated administration of that hardware.

For information about virtual smart card technology, see Virtual Smart Card Overview. Certificate Requirements and Enumeration. Smart Card and Remote Desktop Services.

Smart Cards for Windows Service. Certificate Propagation Service. Smart Card Removal Policy Service. Smart Card Tools and Settings. Smart Cards Debugging Information. Skip to main content. This browser is no longer supported. The global data cache is hosted in the Smart Cards for Windows service. These API calls make global data caching functionality available to applications. Every smart card that conforms to the smart card minidriver specification has a byte card identifier.

This value is used to uniquely identify cached data that pertains to a given smart card. These APIs allow an application to add data to and read data from the global cache. After a smart card is authenticated, it will not differentiate among host-side applications—any application can access private data on the smart card. To mitigate this, the smart card enters an exclusive state when an application authenticates to the smart card.

However, this means that other applications cannot communicate with the smart card and will be blocked. Therefore, such exclusive connections are minimized. The issue is that a protocol such as the Kerberos protocol requires multiple signing operations. Therefore, the protocol requires exclusive access to the smart card over an extended period, or it require multiple authentication operations. This is where the PIN cache is used to minimize exclusive use of the smart card without forcing the user to enter a PIN multiple times.

The following example illustrates how this works. In this scenario, there are two applications: Outlook and Internet Explorer. The applications use smart cards for different purposes. E-mail data is sent to the smart card for the signature operation. The Outlook client formats the response and sends the e-mail. The TLS-related private key operation occurs on the smart card, and the user is authenticated and signed in.

The user returns to Outlook to send another signed e-mail. The PIN is encrypted and stored in memory. The following sections in this topic describe how Windows leverages the smart card architecture to select the correct smart card reader software, provider, and credentials for a successful smart card sign-in:. Container specification levels. Create a new container in silent context. Smart card selection behavior. Make a smart card reader match. Open an existing default container no reader specified.

Open an existing GUID-named container no reader specified. Create a new container no reader specified. The caller can provide a container name with varying levels of specificity, as shown in the following table, and sorted from most-specific to least-specific requests.

Similarly, in response to a NCryptOpenKey call in CNG, the smart card KSP tries to match the container the same way, and it takes the same container format, as shown in the following table. The Base CSP and smart card KSP cache smart card handle information about the calling process and about the smart cards the process has accessed. Create a new container. Open an existing container. Delete a container. 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 context flags used as restrictions for the container creation operation. In addition to container operations and container specifications, you must consider other user options, such as the CryptAcquireContext flags, during smart card selection.

This operation occurs as follows:. In some of the following scenarios, the user can be prompted to insert a smart card. If the user context is silent, this operation fails and no UI is displayed. Otherwise, in response to the UI, the user can insert a smart card or click Cancel. If the user cancels the operation, the operation fails. The flow chart in Figure 3 shows the selection steps performed by the Windows operating system. 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.

The Base CSP smart card selection callbacks cache this information. 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:.