Client Card Auto-Update Configuration

When the Card auto-update with ActivID CMS component is installed during ActivClient setup, it:

  • Installs components specific to the card auto-update feature.

  • Configures the Enable Card Auto-Update policy to Enabled.

  • Configures the Hide Check for Card Update menu policy to Yes.

However, card auto-update is operational only after you configure the ActivID CMS connection information with the data specific to your environment.

Policy Name: Enable Card Auto-Update

Description:

Defines if ActivClient will automatically check if inserted smart cards can be updated with card content updates available in the ActivID CMS. The smart card update process starts if updates are available.

If this card auto-update is enabled, then the ActivID CMS server URL must be specified for ActivClient to perform the Auto-update check.

Possible Values:

  • Not Configured

  • Enabled

  • Disabled

Policy Name: CMS Server URL

Description:

Defines the connection URL for the ActivID CMS server (see the ActivID CMS documentation). The port number must be included in the URL.

Example: http://cms.mycompany.com:89898

If this setting is not configured or disabled, then no automatic update check is performed on card insertion.

Possible Values:

  • Not Configured

  • Enabled – enter the ActivID CMS server URL

  • Disabled

The ActivClient card auto-update feature contacts ActivID CMS to check if a card update request is available for the inserted smart card. This check starts shortly after card insertion.

For corporations that use the smart card for Windows Logon, we expect that many users will insert their card at about the same time, when they arrive at their desk and connect to the network (between 8am and 9am). As many processes start at Windows Logon, they compete for resources. To avoid this resource constraint, ActivClient delays the connection to ActivID CMS by a few minutes. Also, to avoid overloading ActivID CMS with too many simultaneous connections, ActivClient automatically spreads the load: ActivClient will contact ActivID CMS after a randomized number of minutes after card insertion; this random number is between 0 (that is, at card insertion) and a configurable number. The default is 120 minutes (two hours), which means that ActivClient will contact ActivID CMS between 0 and 120 minutes after Windows Logon.

It is recommended that you select the maximum value between five minutes and 120 minutes. If a value higher than 120 minutes is selected, we expect that many users will remove their card from the reader before ActivClient connects to ActivID CMS, therefore losing the opportunity to check for a card update.

If the user removes the card before the check is performed, then the process happens again at the next card insertion – with a different random delay.

Policy Name: Maximum delay for card update check after Windows Logon

Description:

Defines how long (in minutes) ActivClient waits after Microsoft Windows logon before it contacts ActivID CMS to determine if smart card updates are available.

To spread the requests received by ActivID CMS, this delay is a random value – between 0 and the maximum delay defined in this setting (in minutes).

Recommended values are between 5 and 120.

If this setting is not configured, then the delay is set to 120 minutes.

Possible Values:

  • Not Configured

  • Enabled – displays the default value, 120, and can be updated

  • Disabled

Note: This policy also includes the case of a card used for Windows screen unlock.

For corporations that do not use the smart card for Windows Logon, we expect that the smart card will be inserted only for few minutes, that is only when the smart card-enabled application is used (for example, VPN client for smart card authentication, email client for email signature / decryption, internet browser for secure web access).

To cater for this type of use cases, ActivClient uses another policy to define when to contact ActivID CMS: ActivClient checks if card updates are available after a randomized number of minutes after card insertion. This random number is between 0 (that is, at card insertion) and a configurable number. The default is five minutes, which means that ActivClient will contact ActivID CMS between 0 and five minutes after card insertion.

It is recommended that you select the maximum value between one minute and ten minutes. If a value higher than ten minutes is selected, we expect that many users will remove their card from the reader before ActivClient connects to ActivID CMS, therefore losing the opportunity to check for a card update.

If the user removes the card before the check is performed, then the process happens again at the next card insertion – with a different random delay.

Policy Name: Maximum delay for card update check after card insertion

Description:

Defines how long (in minutes) ActivClient waits after card insertion before it contacts ActivID CMS to determine if smart card updates are available. This delay is a random value – between 0 and the maximum delay defined in this setting (in minutes).

Recommended values are between 1 and 10.

If this setting is not configured, then the delay is set to 5 minutes.

Possible Values:

  • Not Configured

  • Enabled – displays the default value, 5, and can be updated

  • Disabled

ActivClient includes a policy to define the frequency to check for card updates. The default value is seven days, which represents a weekly check.

When the number of days has passed, ActivClient will contact ActivID CMS a few minutes after card insertion – delay defined in the policies described above. If the card is removed before the check happens, or if ActivID CMS is not available, or if the user cancels the card update request, then ActivClient will contact ActivID CMS again at the next card insertion (after the usual delay).

  • If ActivClient manages to contact ActivID CMS, and if there is no update request available, ActivClient resets the 'counter' for the frequency. The next check will be performed a week later.

  • If ActivClient manages to contact ActivID CMS, where an update is available, and if the user proceeds with the card update, then ActivClient resets the 'counter' for the frequency. The next check will be performed a week later.

  • If ActivClient manages to contact ActivID CMS, where an update is available, but if the user does not proceed with the card update, then ActivClient will repeat the process at the next card insertion (after the usual delay).

Policy Name: Frequency of update (in days)

Description:

Defines the interval (in days) between checks for smart card updates.

If this setting is not configured, then the update frequency is set to 7 days.

Possible Values:

  • Not Configured

  • Enabled – displays the default value, 7, and can be updated

  • Disabled