Chat now with support
Chat with Support

Safeguard Authentication Services 5.1 - Authentication Services for Smart Cards Administration Guide

Privileged Access Suite for Unix Introducing Safeguard Authentication Services for Smart Cards Installing Safeguard Authentication Services for Smart Cards Configuring Safeguard Authentication Services for Smart Cards
Configuring the vendor’s PKCS#11 library Configuring the card slot for your PKCS#11 library Configuring PAM applications for smart card login Configuring certificates and CRLs Locking the screen saver upon card removal (macOS)
Testing Safeguard Authentication Services for Smart Cards Troubleshooting

Using console login with a smart card

To perform smart card login by means of the console

  1. Insert your smart card.

    The getty program prompts for a login.

  2. Enter your username or UPN at the Username: prompt.

    You must enter the username or UPN that is on the smart card.

  3. Enter your PIN at the Password: prompt.
  4. Click the Login button.

Configuring certificates and CRLs

Because Safeguard Authentication Services for Smart Cards uses Public Key cryptography, it must also obtain and manage Certificates and CRLs. This section includes background information on Public Key Infrastructure components, describes how these are used in Safeguard Authentication Services for Smart Cards, and demonstrates how to manage certificates and CRLs for use when authenticating to Active Directory.

Concepts

Public Key Infrastructure

Public key cryptography makes communication on the Internet possible by providing means for a large number of people to exchange secure messages without having to first agree on a shared key. However, to be able to securely encrypt a message, or verify the digital signature on a document, you must be sure that you are using the correct public key for the intended recipient. If you were to encrypt or verify a message with the wrong public key, then you may inadvertently send out information that can be decrypted by an attacker, or you may rely on the integrity of a document that has been modified in transit.

Both confidentiality and integrity rely on authenticating the sender and recipient to be sure that information goes to, or comes from the person intended. Despite the fact that public keys were created to solve the problem of key distribution, it seems to have replaced one key distribution problem with another.

One method of authenticating public keys is to have these keys (and information about the entity they belong to) digitally signed by a third party. This signed information is called a digital certificate (or commonly just a certificate) and the third party is known as a Certification Authority (CA).

While it is still necessary to obtain and authenticate the public key of the Certification Authority by some secure means, the problem of obtaining the public keys of all the people you wish to communicate with has been reduced to a problem of just obtaining a single key for a CA that has issued certificates for these people. CAs can also issue certificates to other CAs, so that it is possible to produce a chain of certificates (called a certification path) from a root CA (sometimes called a trust anchor) to the person or end entity with whom we wish to communicate.

The collection of algorithms, protocols, policies and procedures which enable us to build a scalable infrastructure for communicating using public key cryptography and certificates is known as a Public Key Infrastructure (PKI). PKIs are in everyday use around the world to provide security for banks, online merchants, traders and consumers alike.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating