Repository Views

The vSEC:CMS application maintains detailed repositories for operations performed on the system. This article will describe the different repositories.

Transaction Log

Transactions performed with the vSEC:CMS can be viewed from this page. If there is a registered end user smart card attached the transaction log dialog will show the card serial number of the inserted end user smart card in the upper right corner and show only the actions for this end user smart card. If there is no user smart card attached the dialog shows all actions performed with the vSEC:CMS. If the Clear filter button is enabled, clicking this button will show all actions performed with the vSEC:CMS. Clicking the Copy button will copy the content of table into the system clipboard and this could be pasted into a CSV file for example.

This repository table will provide the following details by default:

ID: Internal identifier for the record.

Time: the time and date that the transaction took place.

Operator: the operator who performed the operation.

CSN: the smart card serial number.

Comment: brief description about the transaction carried out.

It is possible to customize the table columns presented in this table. Right click the table column names and select Configure. In the Available window are the column's that can be added to the table. Select an entry and a short description will appear below the Available window. The already used columns appear in the Selected window. Select an entry and it is possible to change the name of the column title in the Label field and the position that the column will appear in the table using the Up and Down buttons.

Note
Please refer to the article vSEC:CMS Transaction Logs for more details on transaction logs.

Smart Cards

The Smart Cards repository view displays the end user card(s) managed by the vSEC:CMS. It is possible to filter the search by entering an Assigned ID into the Filtered by ID field. If the operator attaches a registered user smart card to the system, the screen shows the repository entry for the inserted user smart card only. It is also possible to filter the repository by the card templates that the user smart cards have been issued with. The Clear filter option will show all user cards in the repository. If the operator selects one entry from the list and clicks Trans. log(s) button, the Transaction Log option will be shown with the transactions for the selected user card.

Click the Advanced filter button to perform advanced search filters. Select either Apply filter on individual directory fields or Filter on invalid or missing user records.

If the filter selected is Apply filter on individual directory fields then you can enter a filter in the filter field. For example, if it is required to find all users who have been issued with smart cards that have an email address domain of versasec.com, simply enter versasec.com into the filter field. Only vSEC:CMS variables that have been assigned to directory attributes will be available here.

If the filter selected is Filter on invalid or missing user records then the vSEC:CMS will search all records and any user who has been issued with a smart card where the user's DN is not valid anymore will be reported. For example, a user's DN may have changed therefore this would be useful to determine such users.

Click the Copy button to export the content of this table into the system clipboard where it can be saved as a CSV file for example.

It is possible to make adjustments to the user's DN for a user from this page. The user's DN is used by the vSEC:CMS to uniquely identify them in the system. Scenarios may arise where a user is moved from one organizational unit to another, thereby meaning that their DN will change. Click the Fix ID button to change a user's DN as is stored in the vSEC:CMS.

To change a user's DN, select a user from the Smart Cards table and click the Fix ID button. Details about the smart card, the smart card type and the current DN that the user is associated with are shown. Click the Verify button to verify whether the current user DN as stored in the vSEC:CMS is valid. If the user's DN has changed click the Get ID button and search for the user who's DN has changed or type in the user's DN and click theVerify button to verify that the DN is correct. Click Ok to update the vSEC:CMS database for this user's DN.

The process status of the user smart card can be changed from this screen. An operator can select an entry and depending on the current status of the card it is possible to change the status to Activate, Inactivate, Revoke, and Delete.

This table will provide the following details by default:

ID: a unique identifier for the repository entry.

Last Action at: the time and date that the last action with performed by the vSEC:CMS on the smart card.

CSN: the smart card serial number.

RFID: the RFID smart card serial number if the card has an RFID chip that is managed by the vSEC:CMS.

Wiegand: the wiegand code ID if the card has an RFID chip that is managed by the vSEC:CMS.

Key ID: the master key identifier of the master key used to diversify the user smart card administration key.

Assigned ID: the identifier, if any, assigned to the user smart card.

Template: the smart card template set to the user smart card.

Status: the current process status that the user smart card is in.

It is possible to perform batch operations from this repository view. The batch operations that can be performed are activate, inactivate, revoke and delete. Selections can be manually selected from the table or an input file can be used. If an input file is used the details inside the input file will need to match the contents of a column in the table. For example, if it is required to batch select based on the CSN of cards in the table then right click on the header for CSN and select Add selection item(s) by “CSN”. You will then be prompted to select the input file. If the CSN that are to be batch selected are, for example, 570100014186B30B5215FFFF and 570100014186B30B5315FFFF, then the input file should be:

570100014186B30B5215FFFF

570100014186B30B5315FFFF

Each line in the input file should correspond to a CSN in this example. These entries will then be automatically selected and the batch operations of activate, inactivate, revoke and delete could be performed.

Archived Keys

The Archived Keys repository view display the archived keys created by the vSEC:CMS. The table of archived keys provides the following details by default:

ID: the identifier of the key as stored by the vSEC:CMS.

Created at: the time and date that the archived key was created.

User DN: the user DN that the archived key was issued to.

Card Template: the card template that was used to issue the archived key.

Cert Template: the certificate template used when issuing the archived key.

Master Keys

The Master Keys repository view shows the master key(s) used by the vSEC:CMS. If an entry is selected in the list and the operator clicks View smart card(s) button the Smart Cards repository view will be shown with information about the user smart cards registered with the selected master key. Click the Copy button to export the content of this table into the system clipboard where it can be saved to a CSV file for example.

This table will provide the following details by default:

Key ID: the identifier for the master key(s) created by the vSEC:CMS.

Created at: the time and date that the master key was created.

User smart cards: the number of user smart cards registered with the master key.

Comment: a description message to describe the master key.

Smart Card Transfer

From this page, it is possible to migrate registered user smart cards from other smart card management systems.

Currently, it is possible to migrate from the following CMS systems:

MS Forefront Identity Manager Certificate Manager (FIM CM);
Versasec vSEC:CMS K-Series;
Gemalto DAS / IDAdmin 100;
Safenet/Thales SAM.

FIM CM Transfer

Follow the instructions in this section to perform a migration from FIM CM.

Note
It will be necessary to generate an encryption key that should be used when exporting the registered smart cards from FIM CM.

Click the Import button to select a PKCS#12 file that contains the encryption key that was used to encrypt the FIM CM exported smart card data file, or, click the Create New Encryptor button to generate an encryption key.

If the Create New Encryptor button is clicked to generate an encryption key, then this key will remain on the operator token and will never leave the token. Click the Copy button to get the public encryption key. This key will be used to encrypt the smart card data when exporting the smart card data from FIM CM.

If the Import button was selected from the previous step, browse to the location of the PKCS#12 file and enter the password and key type. The Container field will automatically be generated by the vSEC:CMS and is used as an identifier.

On clicking the Import button, the operator will be prompted to enter their passcode to complete the import.

After exporting the smart cards from FIM CM, the generated transfer file will be saved as an .sctf (smart card transfer file) file.

Browse to the location of the transfer file.

Click the Import button and enter the operator passcode to progress to the next stage of the transfer.

From the next dialog enable the Filter on user directory location and select the directory tree, which is required to be imported. The number to the left of the directory tree is the number of entries in the particular tree. The figure under the Available heading is the total number of entries in the imported file. The figure under the Validated heading is the total number of entries validated in the imported file. The figure under the New cards heading is the total number of new user card entries in the imported file that are currently not present in the vSEC:CMS. The figure under the Selected heading is the total number of entries selected that will be imported. The figure under the Available licenses heading is the total number of licenses that currently exist in the vSEC:CMS. The figure under the Invalid heading is the number of invalid entries read from the imported file. The figure under the To update heading is the number of entries read from the imported file that will be updated if the import is performed. The figure under the Ignore heading is the number of entries that have been ignored when read from the imported file.

From the next dialog enable the Filter on smart card state and select the card states that are to be imported. The number to the left of the card state is the number of entries in the particular state.

From the next dialog, the selected user's card details will be presented before they are imported. Uncheck the Import box for any smart card that is not to be imported.

From the final dialog, it is possible to export a report for the imported data by clicking the Export button.

vSEC:CMS K-Series Transfer

If the vSEC:CMS K-Series is used to manage an organizations smart cards and it is required to upgrade to the vSEC:CMS, this migration can be performed from the vSEC:CMS K-Series section.

During the migration from the vSEC:CMS K-Series to the vSEC:CMS the following operations will be performed:

The vSEC:CMS will import smart cards, transaction logs, PIN policies and master keys from the vSEC:CMS K-Series;
The vSEC:CMS will remove the transferred smart cards from the vSEC:CMS K-Series repository and decrease the license count on the vSEC:CMS K-Series by the number of cards transferred;
The imported smart cards will be assigned to a newly created card template and set the smart card status to active;
PIN policy and master key migration will only be transferred on the first migration from a K-Series instance;
Smart card specific transaction logs will only be transferred for registered cards that are imported, for example, if an operator of vSEC:CMS K-Series registers and then unregisters smart cards in vSEC:CMS K-Series, those transaction logs will not be imported;
If the vSEC:CMS K-Series is used again after the migration, it is possible to perform another migration. If, however, the master key on the vSEC:CMS K-Series is changed, then any smart card registered using this new master will not be migrated if a migration is attempted.

Note
In order to perform a migration, the operator will need to have access to the vSEC:CMS K-Series database file; possession of the vSEC:CMS K-Series operator smart card and knowledge of the vSEC:CMS K-Series passcode. The vSEC:CMS K-Series needs to be in Secure System Mode to perform a migration.

Click the Proceed button to begin the work flow.

Click the Browse to browse to the location of the vSEC:CMS K-Series database file that is to be migrated.

If the vSEC:CMS K-Series operator smart card is not attached to the system that the vSEC:CMS is running on the operator will be informed to insert the smart card.

On inserting the vSEC:CMS K-Series smart card, information about the smart card(s), transactions logs, master keys and PIN policies set in the vSEC:CMS K-Series will be displayed. Enter the vSEC:CMS K-Series operator passcode and click the Import button to start the migration.

Enter the vSEC:CMS operator passcode when prompted.

Gemalto DAS / IDADMIN 100

It is possible to migrate smart cards managed by the Gemalto DAS / IDADMIN 100 (referred to as DAS in this article) smart card management tool to the vSEC:CMS. This section will describe the steps to be carried out in order to migrate from DAS to vSEC:CMS using a CSV file. It is required that the VS DAS MT Administration Guide.pdf document be referred to in order to create the CSV file that will be used to migrate DAS managed smart cards to the vSEC:CMS.

Prerequisites

It will be necessary for the vSEC:CMS operator to have possession of the DAS controller smart card and knowledge of this controller smart card PIN.

The smart cards registered with the DAS tool will need to be added to a CSV file which will be used by the vSEC:CMS during the migration flow. It is assumed that the required smart card information is already captured in a CSV file ready to be imported using the migration steps as described below.

Migration Steps

Follow the steps in this section to perform the migration.

From the Repository - Smart Card Transfer page click the Proceed button in the Gemalto DAS section.

If it is required that the card information for DAS managed cards are to be sent from the end users workstation using the vSEC:CMS USS application then click the Auto collect button. From this dialog, it is possible to enable the auto collection through the USS. When a smart card user attaches a DAS managed smart card to their workstation where the USS application is running in the system tray the enabled information will be sent to the vSEC:CMS. Enable the Collect windows logon credentials if the logged-on user's Windows domain username credential is to be sent. It is important to note that this will be the current logged on user domain credential that will be sent. Enable the Collect certificate UPN field(s) to send the users UPN retrieved from the user certificate if one exists on the smart card. Enter or browse to the location on the server where the information will be sent into the Folder to store collected data field. Enable the Show message to the user when data has been collected if the user should be presented with a message informing them that the DAS managed card details have successfully been sent to the server.

With the DAS controller smart card attached, enter the PIN for the controller smart card.

Browse to the CSV file that contains the required information about the smart cards registered to the DAS tool (see the prerequisites section above) and select the separator used in the CSV file.

Click the Proceed button to continue.

Enter the vSEC:CMS operator passcode.

From the Step 1 dialog enable the Filter on user directory location and select the directory tree, which is required to be imported. The number to the left of the directory tree is the number of entries in the particular tree. The figure under the Available heading is the total number of entries in the imported file. The figure under the Validated heading is the total number of entries validated in the imported file. The figure under the New cards heading is the total number of new user card entries in the imported file that are currently not present in the vSEC:CMS. The figure under the Selected heading is the total number of entries selected that will be imported. The figure under the Available licenses heading is the total number of licenses that currently exist in the vSEC:CMS. The figure under the Invalid heading is the number of invalid entries read from the imported file. The figure under the To update heading is the number of entries read from the imported file that will be updated if the import is performed. The figure under the Ignore heading is the number of entries that have been ignored when read from the imported file.

From the Step 2 dialog enable the Filter on smart card state and select the card states that are to be imported. The number to the left of the card state is the number of entries in the particular state.

From the Step 3 dialog, the selected user's card details will be presented before they are imported. Uncheck the Import box for any smart card that is not to be imported.

A short summary will be presented. Click Yes to continue.

From the Step 5 dialog, it is possible to export a report for the imported data by clicking the Export button.

Click Close to complete the migration.

Batch Processes

The Batch Process repository view displays the end user card(s) that have been batched registered and/or issued with the vSEC:CMS. Select a batch from the list and click the View details button to view specific details about the particular batch process. Clicking the Copy button will copy the content of this table into the system clipboard which can be saved to a CSV file for example.

This table will provide the following details by default:

Batch ID: the batch ID for the particular batch job.

Executed at: the time and date that the batch process was performed.

Executed by: the operator who performed the operation.

Process: the process(es) actually performed.

# of cards: the number of smart cards batch processed for the particular batch.

Comment: an additional comment for information purposes.

If an entry is selected and the View details button is clicked a dialog with additional information will be presented as described below.

If a smart card that has been batch processed is attached to the system that the vSEC:CMS is running on only entries for that particular card will be shown. In order to view all batch operations, click the Show all button. Clicking the Copy button will copy the content of this dialog into the hosts system clipboard which can be saved to a CSV file for example.

The Process(es) provides details on what process(es) have been applied during the batch.

CSN : the smart card serial number.

User ID : the specific user that the smart card is assigned to.

Card template : the specific card template that was applied to the smart card.

Result : indicates whether the operation was successful or not

Executed at : the date and time that the operation was performed.

If an entry is selected from the previous dialog and the Result button is clicked, additional information about the particular smart card that was batch processed will be provided.

Reports

From the Reports page, it is possible to configure advanced reporting that will allow operators to create report templates that can be used to generate reports from the vSEC:CMS. Reports can be used to, for example, retrieve information about smart cards issued and managed by the vSEC:CMS. Operators may wish to generate reports on all smart card issued and in an active state for example.

Follow the instructions below to configure report templates. The instructions below will demonstrate how to create a report that will retrieve all issued smart cards that have been issued with an email address whose domain is versasec.com and whose state is in an active state.

From the Repository - Reports page click the Manage button to start creating a report template.

Click the Add button.

Enter a template name and enter a description to describe the report that this template is to be used for.

Click the Configure query button to configure specific data that is required to be retrieved.

Click the Configure directories button.

From the Available window select the available variables and click the add button to move the variable to the Selected window. In this example, the variable ${UserEmail} is assigned to the directory attribute mail and ${UserJobtitle} is assigned to the directory attribute title.

On selecting the variable from the Selected window, the LDAP query string will be available in the LDAP query window. It is possible to edit this and enter the LDAP query string required for the data to be returned. For example, if it is required to retrieve all users who have been issued with smart cards who have an email address of specific domain AND who have a job title of Doctor then select both variables from the Available window and move them to the Selected window. Then select an entry in the Selected window and the LDAP query string will be displayed in the LDAP query window. The syntax will be similar to below:

(|(${UserJobTitle}=Doctor)(${UserEmail}))

Which means that a user's email address OR the user's job title will be retrieved.

If we want to retrieve only user's email address who have a specific domain name AND a specific job title, therefore the LDAP query should be changed to:

(&(${UserJobTitle}=Doctor)(${UserEmail}))

Click OK to save.

Note
For LDAP queries, it is important to make sure that the LDAP is not restricted to a search limit otherwise all data may not be retrieved when running reports. This is highlighted here for information purposes and not the responsibility of the vSEC:CMS application.

From the resultant dialog, the selected attribute that we want to use is now added as a query field. It is possible to enter text into the Filter field. In this example, the report will search for all email addresses for all user smart cards that have been issued to versasec.com, therefore we add versasec.com into the Filter field.

Click the Configure CMS repository button and from the Available window select the variable ${DbCardsStatus} and click the add button to add it to the Selected window and click OK to save.

Click the Filter field for the variable ${DbCardsStatus} just added. This will open a selection dialog. All the status checkbox states are selected but greyed out by default which means that the query will search for all smart card states regardless of what state the smart card is in. Click the Initiated checkbox until the checkbox is not greyed out and enabled since it is required that the filter searches for all smart cards in an active state and click OK to save. The Filter field for this Query Field will now say Must Active. Click OK to save.

Click the Configure result fields to configure what columns will be created in the report.

The Style sheet file can be used to import an XSL style sheet for your specific requirements. By default, a generic XSL style sheet is incorporated. This can be replaced by clicking the Import button. Click the Save default button to export the default XSL style sheet from the system. Click the Reset to default to restore the system to the default style sheet at any time.

From this dialog, the columns that are required to be populated by the report are configured. In this example report we will create the following columns:

User's Display Name which will be associated with the available variable name ${DbCardsIdDisp};
User's DN which will be associated with the available variable name ${DbCardsIdDn};
User's Email Address which will be associated with the available variable name ${UserEmail};
Smart Card Status which will be associated with the available variable name ${DbCardsStatusStr};
Date Card Active which will be associated with the available variable name ${DbCardsLastchangedStr}.

Select the variables added to the Selected window and in the Column Title enter the name that will appear as the column title in the report.

Click OK to save.

From the Reports page select the template created and click the Generate button to generate the report. Depending on the number of records in the system the report generation can take some time.

System Logs

The System Logs page displays system specific events for the vSEC:CMS. The events that are captured here are service stop and start events, operator events such as login events and failed operator login events.

The system logs table will provide the following details by default:

ID: a unique identifier for the repository entry.

Time: the time when the operation was performed.

Operator: the operator who performed the operation.

Computer: the host computer name where the operation was performed from.

Action: the actual operation that was performed.

Data: the CSN of the operator who performed the action.

Device Management

From Device Management a number of sub menu options are available. These are described in the sections below.

Managed Devices

From the Managed Devices page, it is possible to manage devices that have Virtual Smart Cards (VSC) that are managed by the vSEC:CMS. This allows for the centralized management of devices that are issued with VSC and managed by the vSEC:CMS.

Before describing the details on how to configure the centralized device management of VSC it is important to understand the philosophy behind centralized device management. As VSC reside on a physical device, such as laptop or tablet, it becomes important to be able to manage the device in a secure manner in relation to the end user who the VSC is to be issued to. Using a centralized device management model, it is possible for vSEC:CMS operators with the appropriate role to manage devices that are allowed to be issued with VSCs.

In order to be able to use the centralized device management model each TPM enabled device in your organization that is to be issued with a VSC needs to be installed with the vSEC:CMS Remote Service Device Management (RSDM) service and the vSEC:CMS User Self-Service (USS) application. The RSDM will require administration rights to install as this is a Windows service. Additionally, a registry key will need to be set on the device which points to the vSEC:CMSRSDM service on the server side i.e. the vSEC:CMS RSDM Service. The registry key needs to be set in the below location on the device for 64-bit OS:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_RSDM\Service]

The registry key needs to be set in the below location on the device for 32-bit OS:

[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_RSDM\Service]

The registry key name is soap.server.url and should be type String. For example, if the vSEC:CMS server host name is myserver.example.com and the RSDM is configured for HTTP and the port configured is 80 the value would be:

http://myserver.example.com/rsdm

Additionally, it is possible to set this registration key by passing in a parameter to the installer. For example, run the installer from a command prompt as below:

> vSEC_CMS_RSDM.exe /url="http://<server_host_name>:<port>/rsdm"

Where <server_host_name> is the host name of the server where the vSEC:CMS is installed and <port> is the port number of the RSDM service configured in the vSEC:CMS.

If it is required to do a silent install of the RSDM service then from a command prompt run the installer as below:

> vSEC_CMS_RSDM.exe /url="http://<server_host_name>:<port>/rsdm" /S

Where <server_host_name> is the host name of the server where the vSEC:CMS is installed and <port> is the port number of the RSDM service configured in the vSEC:CMS.

Once the RSDM is installed and configured on the device the service will send a SOAP message to the vSEC:CMS server-side informing it that the device is available to be managed. An operator will then need to select the device in the repository table and send an Issue action message to the device informing it that the device can now be created and issued with a VSC. By default, the RSDM service on the client device will be polling on the server to check if any messages exist on the server which they need to process. Once the RSDM service on the client retrieves the message it will then process the request and perform whatever task the server-side has requested it to perform.

Alternatively, the RSDM service on the client device can be configured to use a UDP broadcast notification to be sent from the server side as a push notification. This will mean that the client device will wait until it receives a push notification from an operator before it will begin performing the operations as requested on the server-side. If this is configured, then the RSDM polling mechanism on the device will be disabled.

Note
The push mechanism on the client device will revert back to polling mechanism if a broadcast message is not possible to be sent, for whatever reason, from the server-side down to the client device. When a client device starts it will send a request to the server-side requesting the server to send a test broadcast message. If the client does not get a broadcast message within a 5 second period the client will determine that it is not possible to receive broadcast messages from the server and revert back to polling. It is possible to override this by setting a registry key on the client device to always use the push mechanism. In order to configure this override, you should set a type STRING with a name of ‘rsdm.msg.notify.broadcast.settings’ and a value of ‘-1,0,0,0,1’. For 32-bit systems this should be set here [HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_RSDM\Service\] and for 64-bit systems set here [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_RSDM\Service\].

On the vSEC:CMSfrom the Repository - Managed Devices page the devices registered will be shown in a table.

Click the Refresh button to update the table with devices that may have been added to the system.

Select an entry from the table and right click to get access to various options. These options are:

Issue: Select this option if it is required to initiate a VSC issuance operation on the selected device which will result in the device receiving a message thereby allowing the device to start an issuance.
Retire: Select this option to perform a VSC retire operation which will result in all VSC on the device being retired from the vSEC:CMS along with all certificate(s) on these VSCs being revoked on the CA. Additionally the VSC(s) on the device will be removed.
Delete: Select this option to delete the VSC from the vSEC:CMSas a managed device.
Synchronize: This option will ensure that the client device and server are fully in sync with regards to the expected state that the device should be in.
Clear message cache: Remove cache messages that have been cached on the server side. A message will be cached if the device was not online to receive the message.
Repository: Smart Cards: This will open the Card Repository page for the VSC(s) issued to the device.
Repository: Device Management Logs: This will open the complete history from the Device Management Logs repository.
Edit Flags: When a virtual smart card token is issued the flag for the device will be set to Device is blocked for remote issuance. This means that it will not be possible for a device to issue additional virtual smart cards for the device thereby giving more management control to the operator. If it is required that a device can be issued with an additional virtual smart card an operator can right click the entry in the table and select this option to reset the flag. It is possible to view the status of the flag from the table by right clicking the table header and selecting Configure. Then add the variable ${DbRsdmDeviceFlagsStr} to the selected window. Flags can be in either IssuancePending or IssuanceBlocked state. If the device is in IssuancePending state it means that the issuance command has been sent to the client device but the client has not picked this up yet as the client is offline. If the device is in IssuanceBlocked state it means that the issuance command has been sent to the client device and the client has received the command.
Copy selected: It is possible to copy the contents of a selected entry and paste the values into a text editor by selecting this option.
Details: This will display more detailed information about the VSC. See below for more details on this.
TPM Information: From version 5.1 any client host that is registering for the first time will have the details about the actual TPM installed on the client captured here. The information captured here can be used if troubleshooting issues on the client if the TPM is not operational as expected.

A number of important information about the device is presented when the Details option is selected. The Device ID is the unique identifier for this device in the vSEC:CMS. The Computer name is the full name of the device as retrieved from Windows. The Device name is the name of the device as retrieved from Windows. The Device status shows the current status of the device. The Online status provides real-time status for the device if it is currently on line or not. The Assigned user ID is the Windows user who the device is first issued to. The Assigned user DN is the full DN of the Windows user who the device is first issued to. The Device registered is a timestamp when the device was first registered. The Assigned to user is a timestamp of when the device was first assigned to a user. The Last seen online is a timestamp of when the device was last online. The Last message sent is a timestamp of the last time a message was sent from the server to the device. The Authentication keys is the number of authentication keys that have been saved in the vSEC:CMS database that meet the criteria as configured in Options - Device Management for Trusted certificates. This information is stored now for information purposes and will be used in later versions to perform client authentication when managing devices. The Device type provides information about the device operating system. Currently only Windows is supported therefore the value will be set to 1. The Pending messages are the number of pending messages that are due to be sent from the vSEC:CMS to the device. The Virtual Smart Cards section list the VSC serial number and the information about the status of the VSC. The Authentication key(s) will list information about the authentication keys that will be used in future version of vSEC:CMSto authenticate the client devices.

Click the Copy button which will copy the contents of the table into the system clipboard. The contents can then be copied into a text editor and saved as a CSV file, for example, and used for reporting purposes.

Execute an Issuance

An operator with the appropriate role can select a device and right click and then select Issue which will open a dialog.

As this is the first time that a device is to be managed the management task Select task drop-down list will be empty. Click the Manage button to create a management task template and click the Add button to create a management task template.

In Template name enter an appropriate name for the template.

From the Smart card template to issue drop-down list select an already created VSC card template that will be used to issue the VSC. The card template selected here will then only be available from this management task.

Select the Enable username+password logon if it is required to set the local registry key on the device to allow the end user to log onto the device using their Windows domain username and password if the device is already configured to enforce smart card logon. By enabling this setting the local registry key below will be set to a value of 0

[HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\ScForceOption]

Important
If a GPO is in place that configures the device to enforce smart card logon then the GPO will override the registry key.

Select the Automatically return to former state and enter timeout period in the field provided. This will set the registry key above back to a value of 1 enforcing smart card logon. This may be required if the device was not issued within an appropriate period of time thereby requiring that the device be returned to its former configured state.

Enable the Launch user self-service after user logon checkbox if it is required to automatically launch the USS application when the user logs into their device which will allow for a streamlined VSC creation and issuance work flow. The USS will need to be running in system tray mode on the device in order for this flow to occur.

Enable the Force logout after issuance and enforce sc logon if it is required to force the user to logout after setting the PIN code for the VSC at the end of the issuance work flow through the USS. This would only be required if it is required to enforce Windows smart card logon.

Enable the Minimize user interaction if it is required to have less end user participation during the self-service issuance flow. This will change the flow from an end user perspective. If this option is enabled the end user will be prompted to enter their authentication credential and their PIN code at the start of the issuance flow. Then the issuance flow will begin with a less intrusive issuance dialog running in the bottom left corner of the user’s screen.

In the Description window, a detailed description of the management task template can be added if required.

In the Permissions section, it is possible to configure what operator role is allowed to perform the template. Click the Edit button to select from the available roles available on the system.

Click Save to save and close the template.

Now click the Perform button to send the message to the device which will inform the device that it can issue a VSC and sets any settings that may have been configured in the management task template.

If the device is online a success message will be displayed. On the client device, the user can then start the USS application and issue the device.

Otherwise the message will be cached and sent to the device once it comes online.

Configure Poll or Push for RSDM

Poll Mechanism

By default, client devices which have VSCs issued and managed centrally by thevSEC:CMS will poll the server in order to check if any messages are available to execute. The polling is performed through the RSDM service that is installed on each client device. This RSDM service will send a message to the server every configured millisecond (ms) to the server. The polling configuration can be seen from the Repository - Managed Devices page and selecting a managed device and click the Details button. The values displayed for Message transport parameter indicate what is configured for the polling frequency.

For example, if the Message transport parameter had a value of 100, 10 / 600000 / 60000, 2 ms. The meaning of each value here is described below:

100, 10

This means that the client device will send a message every 100 ms to the server asking if there are any execute messages waiting on the server for this device. When the server gets this message, it will wait 10 ms to see if it receives any execute commands from an operator in that 10ms window. If an execute operation is sent, say within 5 ms, then the server will respond to the client with the execute message. If there is no execute message sent within the 10 ms then the server will respond to the client informing them that there is no execute message to be processed.

/ 600000 /

This is the period in ms that the polling settings 100, 10 (above) will be performed for. After this period the settings 60000, 2 will be in effect.

60000, 2

This means that the client-side device will send a message every 60000 ms to the server asking if there are any execute messages waiting on the server for this device. When the server gets this message, it will wait 2 ms to see if it receives any execute commands from an operator in that 2ms window. If an execute operation is sent, say within 1 ms, then the server will respond to the client with the execute message. If there is no execute message sent within the 2 ms then the server will respond to the client informing them that there is no execute message to be processed.

The default settings can be changed on the server via registry key. The registry name is rsdm.msg.notify.settings and it is a String value and needs to be set here:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service]

Therefore if you wanted to change the default settings to, for example, '200, 10 / 600000 / 60000, 2 ms' then the value that you should set in the registry key should be '200,10,600000,60000,2'.

Push Mechanism

It is possible to disable the poll mechanism as described in the previous section. This will result in client devices using a push mechanism to receive notification from the server side when execute notifications are sent from an operator. The RSDM service on the client device will then need to be configured to listen on a port for UDP broadcasts from the server. The registry key name that needs to be set isrsdm.msg.notify.broadcast.port and it is a DWORD (decimal) value that should be the port number that the client device will listen on. The key should be set here for 64-bit OS:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_RSDM\Service]

And here for 32-bit OS:

[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_RSDM\Service]

When the system is configured in this way you will see information in the Details section for a selected device. The Online status will show that the current device is configured to use push mechanism. In the Message transport parameter you will see that the polling mechanism is disabled and in the Listening on UDP port you will see the port number that the client device is configured to listen on.

Batch Operations

From version 4.9.0.12 it is possible to perform batch operations from the Managed Devices repository view. The batch operations that can be performed are issue, retire, delete and synchronize. It is recommended to limit the size of batch operations to a maximum of 100 as putting too high a number of batch operations will put additional load on the server side which could have adverse effects.

Selections can be manually selected from the table or an input file can be used. If an input file is used the details inside the input file will need to match the contents of a column in the table. For example, if it is required to batch select based on the Device ID in the table then right click on the header for Device ID and select Add selection item(s) by “Device ID”. You will then be prompted to select the input file. If the Device IDs that are to be batch selected are, for example, 4-0091789 and 4-0091790, then the input file should contain the entries as below:

4-0091789

4-0091790

Each line in the input file should correspond to a Device ID in this example. These entries will then be automatically selected and the batch operations of issue, retire, delete and synchronize could be performed.

Invalidate RSDM Messages

From version 4.9.0.12 RSDM issuance messages can be configured to timeout after a configurable period of time. For example, clients, for whatever reason, may not always perform the actual issuance when the issue command is sent from the server. Then there may be a considerable buildup of clients who potentially could start issuing concurrently which in turn could result in heavy load being put on the server. By configuring RSDM messages to expire gives the operators more control during the deployment stage.

In order to configure this feature a registry of type DWORD named rsdm.msg.expiry.enabled and a value of 1 needs to be set here:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service]

Additionally, the period of time in seconds that the message should stay valid for needs to be set through registry in the same location. This should be a DWORD named rsdm.msg.expiry.period.sec and the value set as decimal. For example, if you want the message to expire after 1 minute then you would enter a decimal value of 60. If a client is then sent an issue command from the server the status flag for the message will be in Issuing state if the client is online. If after 1 minute the client does not act on the issuance command the server will invalidate the message on the server. If the client after this period then tries to start the issuance command the message status flag on the server will be in an IssuingBlocked state and the client will not be able to issue the smart card.

In parallel on the client device side it is possible to configure an expiry timeout. In order to configure this feature a registry of type DWORD named msg.expiry.sec and a decimal value in seconds should be entered for the period after which the client should invalidate the message. On a 64-bit OS the value should be set here:

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Versatile Security\vSEC_CMS_RSDM\Service]

On a 32-bit OS the value should be set here:

[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_RSDM\Service]

If this is configured on the client, and the client is online, and the server sends an issuance command but the client does not actually start the issuance within this configured period on the client then if the client attempts to start the issuance after this the actual issuance will actually fail. On the server side the device flag status will be put into an IssuingBlocked state.

Device Management Logs

The Device Management Logs page displays information about devices that have virtual smart cards that are managed by the vSEC:CMS. Specifically, the messages sent from the device and the centralized vSEC:CMS are captured here.

The device management logs table will provide the following details by default:

ID: a unique identifier for the repository entry.

Time: the time when the message was sent.

Device: the unique device ID for the managed device.

Operator: the operator who performed the operation.

Computer: the host computer name where the message was sent from.

Action: summary description of the message sent.

Data: details about the actual message content that was sent.

Managed Devices Events

In this repository view the Windows events, as reported in the Windows Event Viewer, for devices that are registered and managed by the vSEC:CMS will be shown. By default, this functionality will log Window events that are of Critical, Error or Warning level. The Windows events will be taken from the Application and System.

The Windows events will be reported for events where the Source type is Application Error and Windows Error Reporting as viewed from the Windows Event Viewer.

The events that will be captured in this repository view are:

scradproxy events – these are events captured when the vSEC:CMS VSC drivers are used.
TPM events – these are events captured when the TPM component is used.
Application Error events – these are Windows application error events captured for vSEC:CMS client components.
Windows Error Reporting events – these are Windows Error Reporting events captured for vSEC:CMS client components.
Internal events:
- Server-side events – errors during onboarding or credential issuances.
- Client-side events – events such as RSDM and VSC events.

This functionality can be configured through GPO. Please refer to the article Configure Windows GPO and look in the section Configure GPO for RSDM for details on this.

Enrollment Configuration

In this page it is possible to configure the card template(s), Windows group or users who can use the functionality as described in the article Windows Credential Enrolment Management. Please refer to this article for further details on this.

Smart Card Stock

The Smart Card Stock page displays information about card stock(s) configured to be used in the vSEC:CMS. See the article on Smart Card Stock for more details on this.

Smart Card Stock Logs

The Smart Card Stock Logs is a repository of all card stock(s) configured and used in the vSEC:CMS. See the article on Smart Card Stock for more details on this.

Pending Tasks

The Pending Tasks repository will list all pending tasks that an operator can then perform as general housekeeping tasks.

Pending tasks will be triggered in configurations where VSCs are managed by the vSEC:CMS. There are two ways that pending tasks can be triggered:

1. An end user deletes their VSC on their client. This will trigger a notification being sent to the server side informing the server that the VSC has been deleted. As the record still exists on the server it is best practice that this record is cleaned up by an operator. Therefore, this will appear and remain as a pending task until the operator cleans this up.

2. A device is for example re-imaged resulting in the device-id for the device changing. This will trigger a notification being sent to the server side informing the server that the device-id has changed. This will allow the operator to clean up the old device registered in the CMS as this would no longer be used/managed.

These pending tasks will appear in two different forms depending on which task is triggered.

If type 1 above is triggered then the task will appear in the table where the reason will state that the card was removed on the device.

An operator can right click on an entry where a number of options will be available:

If an operator selects Revoke/Delete the VSC entry will be deleted in the repository and a delete VSC request will be sent back to the client to delete the VSC from the device. This will result in the VSC being deleted on the client. Additionally, the VSC certificate(s) will be revoked on the CA.
If an operator selects Repository: Smart Cards the Repository - Smart Cards page will be opened.
If an operator selects Repository: Smart Card Logs the Repository - Transaction Logs page will be opened.
If an operator selects Delete the pending task will just be deleted and no other operation will be performed.
If an operator selects Details additional information will be displayed.

If type 2 above is triggered then the task will appear in the table where the reason will state Device registered as X-XXXXXXX.

An operator can right click on an entry where a number of options will be available:

If an operator selects Revoke/Delete the device and any VSCs on the device will be deleted in the repository. Additionally, the VSC certificate(s) will be revoked on the CA.
If an operator selects Repository: Smart Cards the Repository - Smart Cards page will be opened.
If an operator selects Repository: Smart Card Logs the Repository - Transaction Logs page will be opened.
If an operator selects Delete the pending task will just be deleted and no other operation will be performed.
If an operator selects Details additional information will be displayed.

Search

Transaction Log

Smart Cards

Archived Keys

Master Keys

Smart Card Transfer

FIM CM Transfer

vSEC:CMS K-Series Transfer

Gemalto DAS / IDADMIN 100

Prerequisites

Migration Steps

Batch Processes

Reports

System Logs

Device Management

Managed Devices

Execute an Issuance

Configure Poll or Push for RSDM

Poll Mechanism

Push Mechanism

Batch Operations

Invalidate RSDM Messages

Device Management Logs

Managed Devices Events

Enrollment Configuration

Smart Card Stock

Smart Card Stock Logs

Pending Tasks