Cari di RHE Linux 
     RHE Linux User Manual
Daftar Isi ☛
(Sebelumnya) 17 : Chapter 3. Using Kerberos17 : Chapter 6. Configuring Ap ... (Berikutnya)

Managing Single Sign-On and Smart Cards

Chapter 4. Setting up Enterprise Security Client

4.1. Installing the Smart Card Package Group
4.2. Launching the Smart Card Manager UI
4.3. Overview of Enterprise Security Client Configuration
4.3.1. Enterprise Security Client File Locations
4.3.2. About the Preferences Configuration Files
4.3.3. About the XUL and JavaScript Files in the Enterprise Security Client
4.4. Configuring Phone Home
4.4.1. About Phone Home Profiles
4.4.2. Setting Global Phone Home Information
4.4.3. Adding Phone Home Information to a Token Manually
4.4.4. Configuring the TPS to Use Phone Home
4.5. Using Security Officer Mode
4.5.1. Enabling Security Officer Mode
4.5.2. Enrolling a New Security Officer
4.5.3. Using Security Officers to Manage Users
4.6. Configuring SSL Connections with the TPS
4.7. Customizing the Smart Card Enrollment User Interface
4.8. Disabling LDAP Authentication for Token Operations

The following sections contain basic instructions on using the Enterprise Security Client for token enrollment, formatting, and password reset operations.

4.1. Installing the Smart Card Package Group

Packages used to manage smart cards, such as esc, should already be installed on the Red Hat Enterprise Linux system. If the packages are not installed or need to be updated, all of the smart card-related packages can be pulled in by installing the Smart card support package group. For example:
yum groupinstall "Smart card support"

4.2. Launching the Smart Card Manager UI

There are two aspects to launching the Enterprise Security Client UI. The Enterprise Security Client process must be started and it runs silently, waiting to detect any inserted smart card or token. The Smart Card Manager UI for the Enterprise Security Client opens automatically when smart cards are inserted or can be opened manually.

Initiate the Enterprise Security Client daemon (escd) from the command line:
esc

This daemon listens silently for smart cards and opens the GUI as soon as a smart card is inserted.

To open the Smart Card Manager GUI manually, click Applications, System Tools, and then Smart Card Manager.
Selecting the Smart Card Manager Item in the Menu
Figure 4.1. Selecting the Smart Card Manager Item in the Menu

4.3. Overview of Enterprise Security Client Configuration

The Enterprise Security Client is an intermediary frontend that provides connections between users (and their tokens), the Token Processing System, and certificate authority. The Enterprise Security Client provides two slightly different interfaces:

  • A local interface, based on XUL and JavaScript

  • A web-hosted interface which can be used for remote access, based on CGIs, HTML, and JavaScript

The primary Enterprise Security Client user interface, which is accessed from the local server, incorporates Mozilla XULRunner technology. XULRunner is a runtime package which hosts standalone applications based on XUL, an XML markup language with a rich feature set for user interfaces and offers several advantages over HTML for applications:

  • A wide UI widget set and greater control over the presentation.

  • Local markup to the client machine, so it has a greater privilege level than HTML.

  • JavaScript as the scripting language for convenient program logic scripting and the ability to leverage XPCOM technology.

All of the files for the web-hosted interface can be customized and edited to change the behavior or appearance of the Enterprise Security Client, within reason.

The Enterprise Security Client, in conjunction with the Token Processing System, supports different user profiles so that different types of users have different token enrollment paths. Both the Enterprise Security Client and TPS also support different token profiles, so that the certificate settings can be custom-defined for different types of tokens. Both of these configurations are set in the TPS, and are described in the Certificate System Administrator's Guide.

4.3.1. Enterprise Security Client File Locations

This reference shows the different directories and file locations for the different client machines.

On Red Hat Enterprise Linux 32-bit, the Enterprise Security Client is installed by its binary RPM to the default location, /usr/lib/esc-1.1.0/esc. On Red Hat Enterprise Linux 64-bit systems, the installation directory is /usr/lib64/esc-1.1.0/esc.

NOTE

The Enterprise Security Client uses some specific XUL configuration files, but, overall, the Enterprise Security Client uses the system XULRunner packages on Red Hat Enterprise Linux.
Table 4.1. Enterprise Security Client File and Directory Locations
File or DirectoryPurpose
application.iniXULRunner application configuration file.
components/XPCOM components.
chrome/Directory for Chrome components and additional application files for Enterprise Security Client XUL and JavaScript.
defaults/Enterprise Security Client default preferences.
escThe script which launches the Enterprise Security Client.

4.3.2. About the Preferences Configuration Files

The Enterprise Security Client is configured similarly to Mozilla applications, using preferences files. The primary configuration file is esc-prefs.js, which is installed with Enterprise Security Client. The second one is prefs.js in the Mozilla profiles directory, which is created when the Enterprise Security Client is first launched.

The Enterprise Security Client uses the Mozilla configuration preferences for each of the supported platforms. The default configuration file on Red Hat Enterprise Linux 32-bit is in /usr/lib/esc-1.1.0/defaults/preferences/esc-prefs.js. On Red Hat Enterprise Linux 64-bit, this is in /usr/lib64/esc-1.1.0/defaults/preferences/esc-prefs.js.

The esc-prefs.js file specifies the default configuration to use when the Enterprise Security Client is first launched. This includes parameters to connect to the TPS subsystem, set the password prompt, and configure Phone Home information. Each setting is prefaced by the word pref, then the parameter and value are enclosed in parentheses. For example:
pref(parameter, value);

The esc-prefs.js file parameters are listed in Table 4.2, "esc-prefs.js Parameters". The default esc-prefs.js file is shown in Example 4.1, "Default esc-prefs.js File".
Table 4.2. esc-prefs.js Parameters
ParameterDescriptionNotes and Defaults
toolkit.defaultChromeURIDefines the URL for the Enterprise Security Client to use to contact the XUL Chrome page.("toolkit.defaultChromeURI", "chrome://esc/content/settings.xul")
esc.tps.message.timeoutSets a timeout period, in seconds, for connecting to the TPS.("esc.tps.message.timeout","90");
esc.disable.password.promptEnables the password prompt, which means that a password is required to read the certificate information off the smart card.

The password prompt is disabled by default, so anyone can use the Enterprise Security Client. However, in security contexts, like when a company uses security officers to manage token operations, then enable the password prompt to restrict access to the Enterprise Security Client.

("esc.disable.password.prompt","yes");
esc.global.phone.home.url

Sets the URL to use to contact the TPS server.

Normally, the Phone Home information is set on the token already through its applet. If a token does not have Phone Home information, meaning it has no way to contact the TPS server, then the Enterprise Security Client checks for a global default Phone Home URL.

This setting is only checked if it is explicitly set. This setting also applies to every token formatted through the client, so setting this parameter forces all tokens to point to the same TPS. Only use this parameter if that specific behavior is desired.

("esc.global.phone.home.url", "http://server.example.com:7888/cgi-bin/home/index.cgi");
esc.global.alt.nss.db

Points to a directory that contains a common security database that is used by all Enterprise Security Client users on the server.

Phone Home URL.

This setting is only checked if it is explicitly set. If this is not set, then each user accesses only each individual profile security database, rather than a shared database.

prefs("esc.global.alt.nss.db", "C:/Documents and Settings/All Users/shared-db");

Example 4.1. Default esc-prefs.js File

The comments in this file are not included in the example.
#pref("toolkit.defaultChromeURI", "chrome://esc/content/settings.xul");pref("signed.applets.codebase_principal_support",true); for internal use only  pref("capability.principal.codebase.p0.granted", "UniversalXPConnect"); for internal use only  pref("capability.principal.codebase.p0.id", "file://"); for internal use only  pref("esc.tps.message.timeout","90");#Do we populate CAPI certs on windows?pref("esc.windows.do.capi","yes");#Sample Security Officer Enrollment UI#pref("esc.security.url","http://test.host.com:7888/cgi-bin/so/enroll.cgi");#Sample Security Officer Workstation UI#pref("esc.security.url","https://dhcp-170.sjc.redhat.com:7889/cgi-bin/sow/welcome.cgi");#Hide the format button or not.pref("esc.hide.format","no");#Use this if you absolutely want a global phone home url for all tokens#Not recommended!#pref("esc.global.phone.home.url","http:/test.host.com:7888/cgi-bin/home/index.cgi");

When the Enterprise Security Client is launched, it creates a separate, unique profile directory for each user on the system. These profiles are stored in ~/.redhat/esc/alphanumeric_string.default/prefs.js in Red Hat Enterprise Linux 6.

NOTE

When the Enterprise Security Client requires any changes to a user's configuration values, the updated values are written to the user's profile area, not to the default JavaScript file.

Table 4.3, "prefs.js Parameters" lists the most relevant parameters for the prefs.js file. Editing this file is tricky. The prefs.js file is generated and edited dynamically by the Enterprise Security Client, and manual changes to this file are overwritten when the Enterprise Security Client exits.
Table 4.3. prefs.js Parameters
ParameterDescriptionNotes and Defaults
esc.tps.urlSets a URL for the Enterprise Security Client to use to connect to the TPS. This is not set by default.
esc.key.token_ID.tps.url

Sets the hostname and port to use to contact a TPS.

If this Phone Home information was not burned into the card at the factory, it can be manually added to the card by adding the TPS URL, an enrollment page URL, the issuer's name, and Phone Home URL.

("esc.key.token_ID.tps.url" = "http://server.example.com:7888/nk_service");
esc.key.token_ID.tps.enrollment-ui.url

Gives the URL to contact the enrollment page for enroll certificates on the token.

If this Phone Home information was not burned into the card at the factory, it can be manually added to the card by adding the TPS URL, an enrollment page URL, the issuer's name, and Phone Home URL.
("esc.key.token_ID.tps.enrollment-ui.url" = "http://server.example.com:7888/cgi_bin/esc.cgi?");
esc.key.token_ID.issuer.name

Gives the name of the organization enrolling the token.
("esc.key.token_ID.issuer.name" = "Example Corp");
esc.key.token_ID.phone.home.url

Gives the URL to use to contact the Phone Home functionality for the TPS.

The global Phone Home parameter sets a default to use with any token enrollment, if the token does not specify the Phone Home information. By setting this parameter to a specific token ID number, the specified Phone Home parameter applies only to that token.
("esc.key.token_ID.phone.home.url" = "http://server.example.com:7888/cgi-bin/home/index.cgi?");
esc.security.url

Points to the URL to use for security officer mode.

If this is pointed to the security officer enrollment form, then the Enterprise Security Client opens the forms to enroll security officer tokens. If this is pointed to the security officer workstation URL, then it opens the workstation to enroll regular users with security officer approval.
("esc.security.url","https://server.example.com:7888/cgi-bin/so/enroll.cgi");

4.3.3. About the XUL and JavaScript Files in the Enterprise Security Client

Smart Card Manager stores the XUL markup and JavaScript functionality in /usr/lib[64]/esc-1.1.0/chrome/content/esc/.

The primary Enterprise Security Client XUL files are listed in Table 4.4, "Main XUL Files".
Table 4.4. Main XUL Files
FilenamePurpose
settings.xulContains the code for the Settings page.
esc.xulContains the code for the Enrollment page.
config.xulContains the code for the configuration UI.

The primary Smart Card Manager JavaScript files are listed in the following table.
Table 4.5. Main JavaScript Files
FilenamePurpose
ESC.jsContains most of the Smart Card Manager JavaScript functionality.
TRAY.jsContains the tray icon functionality.
AdvancedInfo.jsContains the code for the Diagnostics feature.
GenericAuth.jsContains the code for the authentication prompt. This prompt is configurable from the TPS server, which requires dynamic processing by the Smart Card Manager.

4.4. Configuring Phone Home

The Phone Home feature in the Enterprise Security Client associates information within each smart card with information that points to distinct TPS servers and Smart Card Manager UI pages. Whenever the Enterprise Security Client accesses a new smart card, it can connect to the TPS instance and retrieve the Phone Home information.

Phone Home retrieves and then caches this information; because the information is cached locally, the TPS subsystem does not have to be contacted each time a formatted smart card is inserted.

The information can be different for every key or token, which means that different TPS servers and enrollment URLs can be configured for different corporate or customer groups. Phone Home makes it possible to configure different TPS servers for different issuers or company units, without having to configure the Enterprise Security Client manually to locate the correct server and URL.

NOTE

In order for the TPS subsystem to utilize the Phone Home feature, Phone Home must be enabled in the TPS configuration file, as follows:
op.format.userKey.issuerinfo.enable=trueop.format.userKey.issuerinfo.value=http://server.example.com

4.4.1. About Phone Home Profiles

The Enterprise Security Client is based on Mozilla XULRunner. Consequently, each user has a profile similar to the user profiles used by Mozilla Firefox and Thunderbird. The Enterprise Security Client accesses the configuration preferences file. When the Enterprise Security Client caches information for each token, the information is stored in the user's configuration file. The next time the Enterprise Security Client is launched, it retrieves the information from the configuration file instead of contacting the server again.

When a smart card is inserted and Phone Home is launched, the Enterprise Security Client first checks the token for the Phone Home information. If no information is on the token, then the client checks the esc-prefs.js file for the esc.global.phone.home.url parameter.

If no Phone Home information is stored on the token and there is no global Phone Home parameter, the user is prompted for the Phone Home URL when a smart card is inserted, as shown in Figure 4.2, "Prompt for Phone Home Information". The other information is supplied and stored when the token is formatted. In this case, the company supplies the specific Phone Home URL for the user. After the user submits the URL, the format process adds the rest of the information to the Phone Home profile. The format process is not any different for the user.
Prompt for Phone Home Information
Figure 4.2. Prompt for Phone Home Information

4.4.2. Setting Global Phone Home Information

Phone Home is triggered automatically when a security token is inserted into a machine. The system immediately attempts to read the Phone Home URL from the token and to contact the TPS server. For new tokens or for previously formatted tokens, the Phone Home information may not be available to the card.

The Enterprise Security Client configuration file, esc-prefs.js, has a parameter which allows a global Phone Home URL default to be set. This parameter is esc.global.phone.home.url and is not in the file by default.

To define the global Phone Home URL:

  1. Remove any existing Enterprise Security Client user profile directory. Profile directories are created automatically when a smart card is inserted. By default, the profile directory is ~/.redhat/esc.

  2. Open the esc-prefs.js file.

    On Red Hat Enterprise Linux 6, the profile directory is /usr/lib/esc-1.1.0/defaults/preferences. On 64-bit systems, this is /usr/lib64/esc-1.1.0/defaults/preferences.

  3. Add the global Phone Home parameter line to the esc-prefs.js file. For example:
    pref("esc.global.phone.home.url","http://server.example.com:7888/cgi-bin/home/index.cgi");

    The URL can reference a machine name, a fully-qualified domain name, or an IPv4 or IPv6 address, depending on the DNS and network configuration.

4.4.3. Adding Phone Home Information to a Token Manually

The Phone Home information can be manually put on a token in one of two ways:

  • The preferred method is that the information is burned onto the token at the factory. When the tokens are ordered from the manufacturer, the company supplies detailed information on how the tokens should be configured when shipped.

  • If tokens are blank, the company IT department can supply the information when formatting small groups of tokens.

The following information is used by the Phone Home feature for each smart card in the ~/.redhat/esc/alphanumeric_string.default/prefs.js file:

  • The TPS server and port. For example:
    "esc.key.token_ID.tps.url" = "http://server.example.com:7888/nk_service"

  • The TPS enrollment interface URL. For example:
    "esc.key.token_ID.tps.enrollment-ui.url" = "http://server.example.com:7888/cgi_bin/esc.cgi?"

  • The issuing company name or ID. For example:
    "esc.key.token_ID.issuer.name" = "Example Corp"

  • The Phone Home URL. For example:
    "esc.key.token_ID.phone.home.url" = "http://server.example.com:7888/cgi-bin/home/index.cgi?"

  • Optionally, a default browser URL to access when an enrolled smart card is inserted.
    "esc.key.token_ID.EnrolledTokenBrowserURL" = "http://www.test.example.com"

More of the parameters used by the prefs.js file are listed in Table 4.3, "prefs.js Parameters".

NOTE

The URLs for these parameters can reference a machine name, a fully-qualified domain name, or an IPv4 or IPv6 address, depending on the DNS and network configuration.

4.4.4. Configuring the TPS to Use Phone Home

The Phone Home feature and the different type of information used by it only work when the TPS has been properly configured to use Phone Home. If the TPS is not configured for Phone Home, then this feature is ignored. Phone Home is configured in the index.cgi in the /var/lib/pki-tps/cgi-bin/home directory; this prints the Phone Home information to XML.

Example 4.2, "TPS Phone Home Configuration File" shows an example XML file used by the TPS subsystem to configure the Phone Home feature.
Example 4.2. TPS Phone Home Configuration File
<ServiceInfo><IssuerName>Example Corp</IssuerName> <Services> <Operation>http://server.example.com:7888/nk_service ## TPS server URL </Operation> <UI>http://server.example.com:7888/cgi_bin/esc.cgi   ## OptionalEnrollment UI </UI> <EnrolledTokenBrowserURL>http://www.test.url.com   ## Optionalenrolled token url </EnrolledTokenBrowserURL> </Services></ServiceInfo>

The TPS configuration URI is the URL of the TPS server which returns the rest of the Phone Home information to the Enterprise Security Client. An example of this URL is http://server.example.com:7888/cgi-bin/home/index.cgi; the URL can reference the machine name, fully-qualified domain name, or an IPv4 or IPv6 address, as appropriate. When the TPS configuration URI is accessed, the TPS server is prompted to return all of the Phone Home information to the Enterprise Security Client.

To test the URL of the Smart Card server, enter the address in the TPS Config URI field, and click Test URL.

If the server is successfully contacted, a message box indicates success. If the test connection fails, an error dialog appears.

4.5. Using Security Officer Mode

The Enterprise Security Client, together with the TPS subsystem, supports a special security officer mode of operation. This mode allows a supervisory individual, a security officer, the ability to oversee the face to face enrollment of regular users in a given organization.

Security officer mode provides the ability to enroll individuals under the supervision of a security officer, a designated user-type who can manage other user's smart cards in face-to-face and very secure operations. Security officer mode overlaps with some regular user operations, with additional security features:

  • The ability to search for an individual within an organization.

  • An interface that displays a photo and other pertinent information about an individual.

  • The ability to enroll approved individuals.

  • Formatting or resetting a user's card.

  • Formatting or resetting a security officer's card.

  • Enrolling a temporary card for a user that has misplaced their primary card.

  • Storing TPS server information on a card. This Phone Home information is used by the Enterprise Security Client to contact a given TPS server installation.

Working in the security officer mode falls into two distinct areas:

  • Creating and managing security officers.

  • Managing regular users by security officers.

When security officer mode is enabled, the Enterprise Security Client uses an external user interface provided by the server. This interface takes control of smart card operations in place of the local XUL code that the Enterprise Security Client normally uses.

The external interface maintains control until security officer mode is disabled.

TIP

It is a good idea to run security officer clients over SSL, so make sure that the TPS is configured to run in SSL, and then point the Enterprise Security Client to the TPS's SSL agent port.

4.5.1. Enabling Security Officer Mode

There are two areas where the security officer mode must be configured, both in the TPS and in the Enterprise Security Client's esc-prefs.js file.

In the TPS:

  1. Add the security officer user entry to the TPS database as a member of the TUS Officers group. This group is created by default in the TPS LDAP database and is the expected location for all security officer user entries.

    TIP

    It can be simpler to add and copy user entries in the LDAP database using the Red Hat Directory Server Console. Using the Directory Server Console is described in the Red Hat Directory Server Administrators Guide in section 3.1.2, "Creating Directory Entries."

    There are two subtrees associated with the TPS, each associated with a different database. (Commonly, both databases can be on the same server, but that is not required.)

    • The first suffix, within the authentication database, is for external users; the TPS checks their user credentials against the directory to authenticate any user attempting to enroll a smart card. This has a distinguished name (DN) like dc=server,dc=example,dc=com.

    • The other database is used for internal TPS instance entries, including TPS agents, administrators, and security officers. This subtree is within the internal database for the TPS, which includes the token database. This subtree has a DN based on the TPS server, like dc=server.example.com-pki-tps. The TUS Officers group entry is under the dc=server.example.com-pki-tps suffix.
    The LDAP directory and the suffix are defined in the token profile in the TPS CS.cfg file in the authId and baseDN parameters for the security officer's auth instance. For example:
    auth.instance.1.authId=ldap2auth.instance.1.baseDN=dc=sec officers,dc=server.example.com-pki-tps

    Any security officer entry has to be a child entry of the TUS Officers group entry. This means that the group entry is the main entry, and the user entry is directly beneath it in the directory tree.

    The TUS Officers group entry is cn=TUS Officers,ou=Groups,dc=server.example.com-pki-tps.

    For example, to add the security officer entry using ldapmodify:
    /usr/lib/mozldap/ldapmodify -a -D "cn=Directory Manager" -w secret -p 389 -h server.example.com dn: uid=jsmith,cn=TUS Officers,ou=Groups,dc=server.example.com-pki-tpsobjectclass: inetorgpersonobjectclass: organizationalPersonobjectclass: personobjectclass: topsn: smithuid: jsmithcn: John Smithmail: [email protected]: secret

    Press the Enter key twice to send the entry, or use Ctrl+D.

Then, configure the Enterprise Security Client.

  1. First, trust the CA certificate chain.

    NOTE

    This step is only required if the certificate is not yet trusted in the Enterprise Security Client database.

    If you want to point the Enterprise Security Client to a database which already contains the required certificates, use the esc.global.alt.nss.db in the esc-prefs.js file to point to another database.

    1. Open the CA's end-entities page.
      https://server.example.com:9444/ca/ee/ca/

    2. Click the Retrieval tab, and download the CA certificate chain.

    3. Open the Enterprise Security Client.
      esc

    4. Click the View Certificates button.

    5. Click the Authorities tab.

    6. Click the Import button, and import the CA certificate chain.

    7. Set the trust settings for the CA certificate chain.

  2. Then, format and enroll the security officer's token. This token is used to access the security officer Smart Card Manager UI.

    1. Insert a blank token.

    2. When the prompt for the Phone Home information opens, enter the security officer URL.
      /var/lib/pki-tps/cgi-bin/so/index.cgi

    3. Click the Format button to format the security officer's token.

    4. Close the interface and stop the Enterprise Security Client.

    5. Add two parameters in the esc-prefs.js file. The first, esc.disable.password.prompt, sets security officer mode. The second, esc.security.url, points to the security officer enrollment page. Just the presence of the esc.security.url parameter instructs the Enterprise Security Client to open in security officer mode next time it opens.
      pref("esc.disable.password.prompt","no");pref("esc.security.url","https://server.example.com:7888/cgi-bin/so/enroll.cgi");

    6. Start the Enterprise Security Client again, and open the UI.
      esc

    7. The Enterprise Security Client is configured to connect to the security officer enrollment form in order to enroll the new security officer's token. Enroll the token as described in Section 4.5.2, "Enrolling a New Security Officer".

    8. Close the interface and stop the Enterprise Security Client.

    9. Edit the esc-prefs.js file again, and this time change the esc.security.url parameter to point to the security officer workstation page.
      pref("esc.security.url","https://server.example.com:7889/cgi-bin/sow/welcome.cgi");

    10. Restart the Enterprise Security Client again. The UI now points to the security officer workstation to allow security officers to enroll tokens for regular users.

To disable security officer mode, close the Smart Card Manager GUI, stop the escd process, and comment out the esc.security.url and esc.disable.password.prompt lines in the esc-prefs.js file. When the esc process is restarted, it starts in normal mode.

4.5.2. Enrolling a New Security Officer

Security officers are set up using a separate, unique interface rather than the one for regular enrollments or the one used for security officer-managed enrollments.

  1. Make sure the esc process is running.
    esc

    With security officer mode enabled in the esc-pref.js file (Section 4.5.1, "Enabling Security Officer Mode"), the security officer enrollment page opens.

  2. In the Security Officer Enrollment window, enter the LDAP user name and password of the new security officer and a password that will be used with the security officer's smart card.

    NOTE

    If the password is stored using the SSHA hash, then any exclamation point (!) and dollar sign ($) characters in the password must be properly escaped for a user to bind successfully to the Enterprise Security Client on Windows XP and Vista systems.

    • For the dollar sign ($) character, escape the dollar sign when the password is created: 
      \$
      Then, enter only the dollar sign ($) character when logging into the Enterprise Security Client.

    • For the exclamation point (!) character, escape the character when the password is created and when the password is entered to log into the Enterprise Security Client. 
      \!

  3. Click Enroll My Smartcard.

This produces a smart card which contains the certificates needed by the security officer to access the Enterprise Security Client security officer, so that regular users can be enrolled and managed within the system.

4.5.3. Using Security Officers to Manage Users

The security officer Station page manages regular users through operations such as enrolling new or temporary cards, formatting cards, and setting the Phone Home URL.

4.5.3.1. Enrolling a New User

There is one significant difference between enrolling a user's smart card in security officer mode and the process in Section 5.3, "Enrolling a Smart Card Automatically" and Section 5.4.6, "Enrolling Smart Cards". All processes require logging into an LDAP database to verify the user's identity, but the security officer mode has an extra step to compare some credentials presented by the user against some information in the database (such as a photograph).

  1. Make sure the esc process is running. If necessary, start the process.
    esc

    Also, make sure that security officer mode is enabled, as described in Section 4.5.1, "Enabling Security Officer Mode".

  2. Then open the Smart Card Manager UI.

    NOTE

    Ensure that there is a valid and enrolled security officer card plugged into the computer. A security officer's credentials are required to access the following pages.

  3. Click Continue to display the security officer Station page. The client prompts for the password for the security officer's card (which is required for SSL client authentication) or to select the security officer's signing certificate from the drop-down menu.

  4. Click the Enroll New Card link to display the Security Officer Select User page.

  5. Enter the LDAP name of the user who is to receive a new smart card.

  6. Click Continue. If the user exists, the Security Officer Confirm User page opens.

  7. Compare the information returned in the Smart Card Manager UI to the person or credentials that are present.

  8. If all the details are correct, click Continue to display the Security Officer Enroll User page. This page prompts the officer to insert a new smart card into the computer.

  9. If the smart card is properly recognized, enter the new password for this card and click Start Enrollment.

A successful enrollment produces a smart card that a user can use to access the secured network and services for which the smart card was made.

4.5.3.2. Performing Other Security Officer Tasks

All of the other operations that can be performed for regular users by a security officer - issuing temporary tokens, re-enrolling tokens, or setting a Phone Home URL - are performed as described in Chapter 4, Setting up Enterprise Security Client, after opening the security officer UI.

  1. Make sure the esc process is running. If necessary, start the process.
    esc

    Also, make sure that security officer mode is enabled, as described in Section 4.5.1, "Enabling Security Officer Mode".

  2. Then open the Smart Card Manager UI.

    NOTE

    Ensure that there is a valid and enrolled security officer card plugged into the computer. A security officer's credentials are required to access the following pages.

  3. Click Continue to display the security officer Station page. If prompted, enter the password for the security officer's card. This is required for SSL client authentication.

  4. Select the operation from the menu (enrolling a temporary token, formatting the card, or setting the Phone Home URL).

  5. Continue the operation as described in Chapter 4, Setting up Enterprise Security Client.

4.5.3.3. Formatting an Existing Security Officer Smart Card

IMPORTANT

Reformatting a token is a destructive operation to the security officer's token and should only be done if absolutely needed.

  1. Make sure that security officer mode is enabled, as described in Section 4.5.1, "Enabling Security Officer Mode".

  2. Open the Smart Card Manager UI.

    NOTE

    Ensure that there is a valid and enrolled security officer card plugged into the computer. A security officer's credentials are required to access the following pages.

  3. Click Continue to display the security officer Station page. If prompted, enter the password for the security officer's card. This is required for SSL client authentication.

  4. Select the operation from the menu (enrolling a temporary token, formatting the card, or setting the Phone Home URL).

  5. Click Format SO Card. Because the security officer card is already inserted, the following screen displays:

  6. Click Format to begin the operation.

When the card is successfully formatted, the security officer's card values are reset. Another security officer's card must be used to enter security officer mode and perform any further operations.

4.6. Configuring SSL Connections with the TPS

By default, the TPS communicates with the Enterprise Security Client over standard HTTP. It is also possible, and in many situations desirable, to secure the TPS-client communications by using HTTP over SSL (HTTPS).

The Enterprise Security Client has to have the CA certificate for the CA which issued the TPS's certificates in order to trust the TPS connection. From there, the Enterprise Security Client can be configured to connect to the TPS's SSL certificate.

  1. Download the CA certificate used by the TPS.

    1. Open the CA's end user pages in a web browser.
      https://server.example.com:9444/ca/ee/ca/

    2. Click the Retrieval tab at the top.

    3. In the left menu, click the Import CA Certificate Chain link.

    4. Choose the radio button to download the chain as a file, and remember the location and name of the downloaded file.

  2. Open the Enterprise Security Client.

  3. Import the CA certificate.

    1. Click the View Certificates button.

    2. Click the Authorities tab.

    3. Click Import.

    4. Browse to the CA certificate chain file, and select it.

    5. When prompted, confirm that you want to trust the CA.

  4. The Enterprise Security Client needs to be configured to communicate with the TPS over SSL; this is done by setting the Phone Home URL, which is the default URL the Enterprise Security Client uses to connect to the TPS.

  5. Insert a new, blank token into the machine.

    Blank tokens are unformatted, so they do not have an existing Phone Home URL, and the URL must be set manually. Formatted tokens (tokens can be formatted by the manufacturer or by your IT department) already have the URL set, and thus do not prompt to set the Phone Home URL.

  6. Fill in the new TPS URL with the SSL port information. For example:
    https://server.example.com:7890/cgi-bin/home/index.cgi

  7. Click the Test button to send a message to the TPS.

    If the request is successful, the client opens a dialog box saying that the Phone Home URL was successfully obtained.

4.7. Customizing the Smart Card Enrollment User Interface

The TPS subsystem displays a generically-formatted smart card enrollment screen which is opened automatically when an uninitialized smart card is inserted. This is actually comprised of three pages, depending on the mode in which the client is running:

  • /var/lib/pki-tps/cgi-bin/home/Enroll.html for regular enrollments

  • /var/lib/pki-tps/cgi-bin/so/Enroll.html for security officer enrollments

  • /var/lib/pki-tps/cgi-bin/sow/Enroll.html for security officer workstation enrollments (users enrolled through the security officer UI)

    NOTE

    The security officer workstation directory contains other HTML files for other token operations, such as formats and PIN resets.

There can be even more enrollment pages if there are custom user profiles.

These enrollment pages are basic HTML and JavaScript, which allows them to be easily customized for both their appearance and functionality. The resources, such as images and JavaScript files, referenced by the enrollment file are located in the corresponding docroot/ directory, such as /var/lib/pki-tps/docroot/esc/sow for the security officer enrollment file in /var/lib/pki-tps/cgi-bin/sow.

There are several ways that the smart card enrollment pages can be customized. The first, and simplest, is changing the text on the page. The page title, section headings, field names, and descriptions can all be changed by editing the HTML file, as shown in the extracts in Example 4.3, "Changing Page Text".
Example 4.3. Changing Page Text
<!-- Change the title if desired --><title>Enrollment</title>...<p class="headerText">Smartcard Enrollment</p>...<!-- Insert customized descriptive text here. --><p class="bodyText">You have plugged in your smart card!     After answering a few easy questions, you will be able to use your smart card.     </p><p class="bodyText"> Now we would like you to identify yourself.  </p>...<table> <tr>  <td><p >LDAP User ID: </p></td>  <td> </td>  <td><input type="text" id="_zz17_snametf" value=""></td>  </tr></table>

The styles of the page can be changed through two files: the style.css CSS style sheet and the logo image, logo.png.
Example 4.4. Changing Page Styles
<link rel=stylesheet class="edunwman1" href="/esc/home/style.css" type="text/css">...<table width="100%" class="logobar">  <tr> <td><img alt="" src="/home/logo.jpg"> </td> <td>  <p class="headerText">Smartcard Enrollment</p> </td>  </tr></table>

The style.css file is a standard CSS file, so all of the tags and classes can be defined as follows:
body {background-color: grey; font-family: arial; font-size: 7p}

More information on CSS is available at http://www.w3.org/Style/CSS/learning.

The last way to customize the Enroll.html files is through the JavaScript file which sets the page functionality. This file controls features like the progress meter, as well as processing the inputs which are used to authenticate the user to the user directory.
Example 4.5. Changing Page Script
<progressmeter id="_zz17_progress-id" hidden="true" align = "center"/>...<table> <tr>  <td><p >LDAP User ID: </p></td>  <td> </td>  <td><input type="text" id="snametf" value=""></td>  </tr></table>

WARNING

Be very cautious about changing the util.js file. If this file is improperly edited, it can break the Enterprise Security Client UI and prevent tokens from being enrolled.

The complete /var/lib/pki-tps/cgi-bin/home/Enroll.html file is in Example 4.6, "Complete Enroll.html File".
Example 4.6. Complete Enroll.html File
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><link rel=stylesheet class="edunwman1" href="/esc/home/style.css" type="text/css"><title>Enrollment</title></head><script type="text/JavaScript" src="/esc/home/util.js"></script><body onload="InitializeBindingTable();" onunload=cleanup()><progressmeter id="_zz17_progress-id" hidden="true" align = "center"/><table width="100%" class="logobar">  <tr> <td><img alt="" src="/home/logo.jpg"> </td> <td>  <p class="headerText">Smartcard Enrollment</p>p </td>  </tr></table>  <table id="_zz17_BindingTable" width="200px"align="center"> <tr id="_zz17_HeaderRow"> </tr>  </table>  <p class="bodyText">You have plugged in your smart card! After answering a few easy questions, you will be able to use your smart card.  </p>p  <p class="bodyText">  Now we would like you to identify yourself.   </p>p <table>  <tr> <td><p >LDAP User ID: </p>p</td> <td> </td> <td><input type="text" id="_zz17_snametf"  value=""></td> <td> </td> <td><p>LDAP Password: </p>p</td> <td> </td> <td><input type="password" id="_zz17_snamepwd" value=""></td>  </tr>  </table>  <p class="bodyText"> Before you can use your smart card, you will need a password to protect it.</p>p  <table>  <tr> <td><p >Password:</p>p</td> <td><input type="password" id="_zz17_pintf" name="pintf" value=""></td> <td><p >Re-Enter Password:</p>p</td> <td><input type="password" id="_zz17_reenterpintf" name="reenterpintf" value=""></td> </table> <br> <table width="100%">  <tr> <td align="right">  <input type="button" id="_zz17_enrollbtn" name="enrollbtn" value="Enroll My Smartcard" onClick="DoEnrollCOOLKey();"> </td>  </tr> </table></body></html>

4.8. Disabling LDAP Authentication for Token Operations

By default, each user who requests a token operation is authenticated against an LDAP directory. If the user has an entry, then the operation is allowed; if the user does not have an entry, then the operation is rejected.

For testing or for certain types of users, then it can be simpler or preferable to disable LDAP authentication. This is not configured in the Enterprise Security Client configuration, but in the Token Processing System configuration, and must be done by a TPS administrator.

  1. Stop the TPS subsystem.
    service pki-tps stop

  2. Open the TPS configuration file.
    vim /var/lib/pki-tps/conf/CS.cfg

  3. Set the authentication parameters to false.
    op.operation_type.token_type.loginRequest.enable=falseop.operation_type.token_type.auth.enable=false

    The operation_type is the token operation for which LDAP authentication is being disabled, such as enroll, format, or pinreset. Disabling authentication for one operation type does not disable it for any other operation types.

    The token_type is the token profile. There are default profiles for regular users, security officers, and the users enrolled by security officers. There can also be custom token types for other kinds of users or certificates.

    For example:
    op.enroll.userKey.loginRequest.enable=falseop.enroll.userKey.pinReset.enable=false

  4. Restart the TPS subsystem.
    service pki-tps start

Editing the TPS configuration is covered in the Certificate System Administrator's Guide.

Managing Single Sign-On and Smart Cards

Chapter 5. Using Smart Cards with the Enterprise Security Client

5.1. Supported Smart Cards
5.2. Setting up Users to Be Enrolled
5.3. Enrolling a Smart Card Automatically
5.4. Managing Smart Cards
5.4.1. Formatting the Smart Card
5.4.2. Resetting a Smart Card Password
5.4.3. Viewing Certificates
5.4.4. Importing CA Certificates
5.4.5. Adding Exceptions for Servers
5.4.6. Enrolling Smart Cards
5.5. Diagnosing Problems
5.5.1. Errors
5.5.2. Events

When a smart card is enrolled, it means that user-specific keys and certificates are generated and placed on the card. In Red Hat Enterprise Linux, the interface that works between the user and the system which issues certificates is the Enterprise Security Client. The Enterprise Security Client recognizes when a smart card is inserted (or removed) and signals the appropriate subsystem in Red Hat Certificate System. That subsystem then generates the certificate materials and sends them to the Enterprise Security Client, which writes them to the token. That is the enrollment process.

The following sections contain basic instructions on using the Enterprise Security Client for token enrollment, formatting, and password reset operations.

5.1. Supported Smart Cards

The Enterprise Security Client supports smart cards which are JavaCard 2.1 or higher and Global Platform 2.01-compliant and was tested using the following cards:

  • Safenet 330J Java smart cards

  • Gemalto 64K V2 tokens, both as a smart card and GemPCKey USB form factor key

  • Gemalto GCx4 72K and TOPDLGX4 144K common access cards (CAC)

  • Oberthur ID One V5.2 common access cards (CAC)

  • Personal identity verification (PIV) cards, compliant with FIPS 201

NOTE

Enterprise Security Client does not provision PIV or CAC cards, but it will read them and display information.

Smart card testing was conducted using the SCM SCR331 CCID reader.

The only card manager applet supported with Enterprise Security Client is the CoolKey applet.

5.2. Setting up Users to Be Enrolled

When the Token Processing System is installed, one of its configuration settings is the LDAP directory which contains the users who are allowed to enroll a token. Only users who are stored within this authentication directory are allowed to enroll, format, or have a token. Before attempting to enroll a token or smart card, make sure that the person requesting the operation has an entry in the LDAP directory.

The TPS is configured to look at a specific base DN in the LDAP directory. This is configured in the TPS's CS.cfg:
 auth.instance.0.baseDN=dc=example,dc=com     auth.instance.0.hostport=server.example.com:389

For a user to be allowed to enroll a token, the user must be somewhere below the base DN.

If the user does not already have an entry, then the administrator must add the user to the specified LDAP directory in the specified base DN before any tokens can be enrolled for the user.
 /usr/bin/ldapmodify -a -D "cn=Directory Manager" -w secret -p 389 -h server.example.com     dn: uid=jsmith,ou=People, dc=example,dc=com     objectclass: person objectclass: inetorgperson objectclass: top uid: jsmith cn: John Smith email: [email protected] userPassword: secret

5.3. Enrolling a Smart Card Automatically

Because the Enterprise Security Client is configured using the Phone Home feature, enrolling a smart card is extremely easy. Because the information needed to contact the backend TPS server is provided with each smart card, the user is guided quickly and easily through the procedure.

To enroll an uninitialized smart card:

NOTE

This procedure assumes that the smart card is uninitialized and the appropriate Phone Home information has been configured.

  1. Ensure that the Enterprise Security Client is running.

  2. Insert an uninitialized smart card, pre-formatted with the Phone Home information for the TPS and the enrollment interface URL for the user's organization.

    The smart card can be added either by placing a USB form factor smart card into a free USB slot, or by inserting a standard, full-sized smart card into a smart card reader.

    When the system recognizes the smart card, it displays a message indicating it has detected an uninitialized smart card.

  3. Click Enroll My Smart Card Now to display the smart card enrollment form.

    NOTE

    If you remove the card at this point, a message displays stating that the smart card can no longer be detected. Reinsert the card to continue with the enrollment process.

    The enrollment files are accessed remotely; they reside on the TPS instance. If the network connection is bad or broken, then an error may come up saying Check the Network Connection and Try Again. It is also possible that the enrollment window appears to open but the enrollment process does not proceed. The enrollment pages can be cached if the Enterprise Security Client previously connect to them successfully, so the enrollment UI opens even if the network is offline. Try restarting Enterprise Security Client and check the network connection.

  4. Because the Smart Card Manager now knows where the enrollment UI is located (it is included in the Phone Home information), the enrollment form is displayed for the user to enter the required information.

    This illustration shows the default enrollment UI included with the TPS server. This UI is a standard HTML form, which you can customize to suit your own deployment requirements. This could include adding a company logo or adding and changing field text.

    See Section 4.7, "Customizing the Smart Card Enrollment User Interface" for information on customizing the UI.

  5. The sample enrollment UI requires the following information for the TPS server to process the smart card enrollment operation:

    • LDAP User ID. This is the LDAP user ID of the user enrolling the smart card; this can also be a screen name or employee or customer ID number.

    • LDAP Password. This is the password corresponding to the user ID entered; this can be a simple password or a customer number.

      NOTE

      The LDAP user ID and password are related to the Directory Server user. The TPS server is usually associated with a Directory Server, which stores user information and through which the TPS authenticates users.

      Passwords must conform to the password policy configured in the Directory Server.

    • Password and Re-Enter Password. These fields set and confirm the smart card's password, used to protect the card information.

  6. After you have entered all required information, click Enroll My Smart Card to submit the information and enroll the card.

  7. When the enrollment process is complete, a message page opens which shows that the card was successfully enrolled and can offer custom instructions on using the newly-enrolled smart card.

5.4. Managing Smart Cards

You can use the Manage Smart Cards page to perform many of the operations that can be applied to one of the cryptographic keys stored on the token.

You can use this page to format the token, set and reset the card's password, and to display card information. Two other operations, enrolling tokens and viewing the diagnostic logs, are also accessed through the Manage Smart Cards page. These operations are addressed in other sections.

Manage Smart Cards Page
Figure 5.1. Manage Smart Cards Page

5.4.1. Formatting the Smart Card

When you format a smart card, it is reset to the uninitialized state. This removes all previously generated user key pairs and erases the password set on the smart card during enrollment.

The TPS server can be configured to load newer versions of the applet and symmetric keys onto the card. The TPS supports the CoolKey applet which is shipped with Red Hat Enterprise Linux 6.

To format a smart card:

  1. Insert a supported smart card into the computer. Ensure that the card is listed in the Active Smart Cards table.

  2. In the Smart Card Functions section of the Manage Smart Cards screen, click Format.

  3. If the TPS has been configured for user authentication, enter the user credentials in the authentication dialog, and click Submit.

  4. During the formatting process, the status of the card changes to BUSY and a progress bar is displayed. A success message is displayed when the formatting process is complete. Click OK to close the message box.

  5. When the formatting process is complete, the Active Smart Cards table shows the card status as UNINITIALIZED.

5.4.2. Resetting a Smart Card Password

  1. Insert a supported smart card into the computer. Ensure that the card is listed in the Active Smart Cards table.

  2. In the Smart Card Functions section of the Manage Smart Cards screen, click Reset Password to display the Password dialog.

  3. Enter a new smart card password in the Enter new password field.

  4. Confirm the new smart card password in the Re-Enter password field, and then click OK.

  5. If the TPS has been configured for user authentication, enter the user credentials in the authentication dialog, and click Submit.

  6. Wait for the password to finish being reset.

5.4.3. Viewing Certificates

The Smart Card Manager can display basic information about a selected smart card, including stored keys and certificates. To view certificate information:

  1. Insert a supported smart card into the computer. Ensure that the card is listed in the Active Smart Cards table.

  2. Select the card from the list, and click View Certificates.

    This displays basic information about the certificates stored on the card, including the serial number, certificate nickname, and validity dates.

  3. To view more detailed information about a certificate, select the certificate from the list and click View.

5.4.4. Importing CA Certificates

The XULRunner Gecko engine implements stringent controls over which SSL-based URLs can be visited by client like a browser or the Enterprise Security Client. If the Enterprise Security Client (through the XULRunner framework) does not trust a URL, the URL can not be visited.

One way to trust an SSL-based URL is to import and trust the CA certificate chain of the CA which issued the certificates for the site. (The other is to create a trust security exception for the site, as in Section 5.4.5, "Adding Exceptions for Servers".)

Any CA which issues certificates for smart cards must be trusted by the Enterprise Security Client application, which means that its CA certificate must be imported into the Enterprise Security Client.

  1. Open the CA's end user pages in a web browser.
    https://server.example.com:9444/ca/ee/ca/

  2. Click the Retrieval tab at the top.

  3. In the left menu, click the Import CA Certificate Chain link.

  4. Choose the radio button to download the chain as a file, and remember the location and name of the downloaded file.

  5. Open the Smart Card Manager GUI.

  6. Click the View Certificates button.

  7. Click the Authorities tab.

  8. Click Import.

  9. Browse to the CA certificate chain file, and select it.

  10. When prompted, confirm that you want to trust the CA.

5.4.5. Adding Exceptions for Servers

The XULRunner Gecko engine implements stringent controls over which SSL-based URLs can be visited by client like a browser or the Enterprise Security Client. If the Enterprise Security Client (through the XULRunner framework) does not trust a URL, the URL can not be visited.

One way to trust an SSL-based URL is to create a trust security exception for the site, which imports the certificate for the site and forces the Enterprise Security Client to recognize it. (The other option is to import the CA certificate chain for the site and automatically trust it, as in Section 5.4.4, "Importing CA Certificates".)

The smart card can be used to access services or websites over SSL that require special security exceptions; these exceptions can be configured through the Enterprise Security Client, similar to configuring exceptions for websites in a browser like Mozilla Firefox.

  1. Open the Smart Card Manager UI.

  2. Click the View Certificates button.

  3. Click the Servers tab.

  4. Click Add Exception.

  5. Enter the URL, including any port numbers, for the site or service which the smart card will be used to access. Then click the Get Certificates button to download the server certificate for the site.

  6. Click Confirm Security Exception to add the site to the list of allowed sites.

5.4.6. Enrolling Smart Cards

Most smart cards will be automatically enrolled using the automated enrollment procedure, described in Section 5.3, "Enrolling a Smart Card Automatically". You can also use the Manage Smart Cards facility to manually enroll a smart card.

If you enroll a token with the user key pairs, then the token can be used for certificate-based operations such as SSL client authentication and S/MIME.

NOTE

The TPS server can be configured to generate the user key pairs on the server and then archived in the DRM subsystem for recovery if the token is lost.

To enroll a smart card manually:

  1. Insert a supported, unenrolled smart card into the computer. Ensure that the card is listed in the Active Smart Cards table.

  2. Click Enroll to display the Password dialog.

  3. Enter a new key password in the Enter a password field.

    Confirm the new password in the Re-Enter a password field.

  4. Click OK to begin the enrollment.

  5. If the TPS has been configured for user authentication, enter the user credentials in the authentication dialog, and click Submit.

  6. If the TPS has been configured to archive keys to the DRM, the enrollment process will begin generating and archiving keys.

When the enrollment is complete, the status of the smart card is displayed as ENROLLED.

5.5. Diagnosing Problems

The Enterprise Security Client includes basic diagnostic tools and a simple interface to log errors and common events, such as inserting and removing a smart card or changing the card's password. The diagnostic tools can identify and notify users about problems with the Enterprise Security Client, smart cards, and TPS connections.

To open the Diagnostics Information window:

  1. Open the Smart Card Manager UI.

  2. Select the smart card to check from the list.

  3. Click the Diagnostics button.

  4. This opens the Diagnostic Information window for the selected smart card.

The Diagnostics Information screen displays the following information:

  • The Enterprise Security Client version number (listed as the Smart Card Manager version).

  • The version information for the XULRunner framework upon which the client is running.

  • The number of cards detected by the Enterprise Security Client.

For each card detected, the following information is displayed:

  • The version of the applet running on the smart card.

  • The alpha-numeric ID of the smart card.

  • The card's status, which can be any of the three things:

    • NO_APPLET No key was detected.

    • UNINITIALIZED. The key was detected, but no certificates have been enrolled.

    • ENROLLED. The detected card has been enrolled with certificate and card information.

  • The card's Phone Home URL. This is the URL from which all Phone Home information is obtained.

  • The card issuer name, such as Example Corp.

  • The card's answer-to-reset (ATR) string. This is a unique value that can be used to identify different classes of smart cards. For example:
    3BEC00FF8131FE45A0000000563333304A330600A1

  • The TPS Phone Home URL.

  • The TPS server URL. This is retrieved through Phone Home.

  • The TPS enrollment form URL. This is retrieved through Phone Home.

  • Detailed information about each certificate contained on the card.

  • A running log of the most recent Enterprise Security Client errors and common events.

The Enterprise Security Client records two types of diagnostic information. It records errors that are returned by the smart card, and it records events that have occurred through the Enterprise Security Client. It also returns basic information about the smart card configuration.

5.5.1. Errors

  • The Enterprise Security Client does not recognize a card.

  • Problems occur during a smart card operation, such as a certificate enrollment, password reset, or format operation.

  • The Enterprise Security Client loses the connection to the smart card. This can happen when problems occur communicating with the PCSC daemon.

  • The connection between the Enterprise Security Client and TPS is lost.

Smart cards can report certain error codes to the TPS; these are recorded in the TPS's tps-debug.log or tps-error.log files, depending on the cause for the message.
Table 5.1. Smart Card Error Codes
Return CodeDescription
General Error Codes
6400No specific diagnosis
6700Wrong length in Lc
6982Security status not satisfied
6985Conditions of use not satisfied
6a86Incorrect P1 P2
6d00Invalid instruction
6e00Invalid class
Install Load Errors
6581Memory Failure
6a80Incorrect parameters in data field
6a84Not enough memory space
6a88Referenced data not found
Delete Errors
6200Application has been logically deleted
6581Memory failure
6985Referenced data cannot be deleted
6a88Referenced data not found
6a82Application not found
6a80Incorrect values in command data
Get Data Errors
6a88Referenced data not found
Get Status Errors
6310More data available
6a88Referenced data not found
6a80Incorrect values in command data
Load Errors
6581Memory failure
6a84Not enough memory space
6a86Incorrect P1/P2
6985Conditions of use not satisfied

5.5.2. Events

  • Simple events such as card insertions and removals, successfully completed operations, card operations that result in an error, and similar events.

  • Errors are reported from the TPS to the Enterprise Security Client.

  • The NSS crypto library is initialized.

  • Other low-level smart card events are detected.
(Sebelumnya) 17 : Chapter 3. Using Kerberos17 : Chapter 6. Configuring Ap ... (Berikutnya)