Single Sign-on (SSO)

Introduction

The Community Enterprise Linux SSO functionality reduces the number of times Community Enterprise Linux desktop users have to enter their passwords. Several major applications leverage the same underlying authentication and authorization mechanisms so that users can log in to Community Enterprise Linux from the log-in screen, and then not need to re-enter their passwords. These applications are detailed below.

In addition, users can log in to their machines even when there is no network (offline mode) or where network connectivity is unreliable, for example, wireless access. In the latter case, services will degrade gracefully.

Supported Applications

The following applications are currently supported by the unified log-in scheme in Community Enterprise Linux:

• Login

• Screensaver
• Firefox and Thunderbird

Supported Authentication Mechanisms

Community Enterprise Linux currently supports the following authentication mechanisms:

• Kerberos name/password login

• Smart card/PIN login

Supported Smart Cards

Community Enterprise Linux has been tested with the Cyberflex e-gate card and reader, but any card that complies with both Java card 2.1.1 and Global Platform 2.0.1 specifications should operate correctly, as should any reader that is supported by PCSC-lite.

Community Enterprise Linux has also been tested with Common Access Cards (CAC). The supported reader for CAC is the SCM SCR 331 USB Reader.

As of Community Enterprise Operating System.2, Gemalto smart cards (Cyberflex Access 64k v2, standard with DER SHA1 value configured as in PKCSI v2.1) are now supported. These smart cards now use readers compliant with Chip/Smart Card Interface Devices (CCID).

Advantages of Community Enterprise Linux Single Sign-on

Numerous security mechanisms currently exist that utilize a large number of protocols and credential stores. Examples include SSL, SSH, IPsec, and Kerberos. Community Enterprise Linux SSO aims to unify these schemes to support the requirements listed above. This does not mean replacing Kerberos with X.509v3 certificates, but rather uniting them to reduce the burden on both system users and the administrators who manage them.

To achieve this goal, Community Enterprise Linux:

• Provides a single, shared instance of the NSS crypto libraries on each operating system.

• Ships the Certificate System's Enterprise Security Client (ESC) with the base operating system. The ESC application monitors smart card insertion events. If it detects that the user has inserted a smart card that was designed to be used with the Community Enterprise Linux Certificate System server product, it displays a user interface instructing the user how to enroll that smart card.
• Unifies Kerberos and NSS so that users who log in to the operating system using a smart card also obtain a Kerberos credential (which allows them to log in to file servers, etc.)

Getting Started with your new Smart Card

Before you can use your smart card to log in to your system and take advantage of the increased security options this technology provides, you need to perform some basic installation and configuration steps. These are described below.

This section provides a high-level view of getting started with your smart card. More detailed information is available in the CentOS Certificate System Enterprise Security Client Guide.

• Make sure you have the nss-tools package loaded.

• Download and install your corporate-specific root certificates. Use the following command to install the root CA certificate:

  certutil -A -d /etc/pki/nssdb -n "root ca cert" -t "CT,C,C" \
   -i ./ca_cert_in_base64_format.crt

• Verify that you have the following RPMs installed on your system: esc, pam_pkcs11, coolkey, ifd-egate, ccid, gdm, authconfig, and authconfig-gtk.

• Enable Smart Card Login Support

  1. On the Gnome Title Bar, select System->Administration->Authentication.

  2. Type your machine's root password if necessary.

  3. In the Authentication Configuration dialog, click the Authentication tab.

  4. Select the Enable Smart Card Support check box.

  5. Click the Configure Smart Card... button to display the Smartcard Settings dialog, and specify the required settings:

     • Require smart card for login - Clear this check box. After you have successfully logged in with the smart card you can select this option to prevent users from logging in without a smart card.
  6. Card Removal Action - This controls what happens when you remove the smart card after you have logged in. The available options are:
     • Lock - Removing the smart card locks the X screen.
  7. Ignore - Removing the smart card has no effect.

• If you need to enable the Online Certificate Status Protocol (OCSP), open the /etc/pam_pkcs11/pam_pkcs11.conf file, and locate the following line:

  enable_ocsp = false;

  Change this value to true, as follows:

  enable_ocsp = true;

• Enroll your smart card

• If you are using a CAC card, you also need to perform the following steps:

  1. Change to the root account and create a file called /etc/pam_pkcs11/cn_map.

  2. Add the following entry to the cn_map file:

     MY.CAC_CN.123454 -> myloginid

     where MY.CAC_CN.123454 is the Common Name on your CAC and myloginid is your UNIX login ID.

• Logout

Troubleshooting

If you have trouble getting your smart card to work, try using the following command to locate the source of the problem:

pklogin_finder debug

If you run the pklogin_finder tool in debug mode while an enrolled smart card is plugged in, it attempts to output information about the validity of certificates, and if it is successful in attempting to map a login ID from the certificates that are on the card.

How Smart Card Enrollment Works

Smart cards are said to be enrolled when they have received an appropriate certificate signed by a valid Certificate Authority (CA). This involves several steps, described below:

• The enrollment page is displayed on the user's desktop. The user completes the required details and the user's system then connects to the Token Processing System (TPS) and the CA.
• The TPS enrolls the smart card using a certificate signed by the CA.

  

  Figure 46.4. How Smart Card Enrollment Works

  
  

How Smart Card Login Works

This section provides a brief overview of the process of logging in using a smart card.

• The system then looks up the user's current certificates and verifies their validity. The certificate is then mapped to the user's UID.
• This is validated against the KDC and login granted.

  

  Figure 46.5. How Smart Card Login Works

  
  

  You cannot log in with a card that has not been enrolled, even if it has been formatted. You need to log in with a formatted, enrolled card, or not using a smart card, before you can enroll a new card.

  Refer to "Kerberos" and "Pluggable Authentication Modules (PAM)" for more information on Kerberos and PAM.

Configuring Firefox to use Kerberos for SSO

You can configure Firefox to use Kerberos for Single Sign-on. In order for this functionality to work correctly, you need to configure your web browser to send your Kerberos credentials to the appropriate KDC.The following section describes the configuration changes and other requirements to achieve this.

• In the Filter field, type negotiate to restrict the list of options.
• Double-click the network.negotiate-auth.trusted-uris entry to display the Enter string value dialog box.
• Enter the name of the domain against which you want to authenticate, for example, .example.com.
• Repeat the above procedure for the network.negotiate-auth.delegation-uris entry, using the same domain.

  You can leave this value blank, as it allows Kerberos ticket passing, which is not required.

  If you do not see these two configuration options listed, your version of Firefox may be too old to support Negotiate authentication, and you should consider upgrading.

  

  Figure 46.6. Configuring Firefox for SSO with Kerberos

  
  

  You now need to ensure that you have Kerberos tickets. In a command shell, type kinit to retrieve Kerberos tickets. To display the list of available tickets, type klist. The following shows an example output from these commands:

  ~]$ kinit
  Password for user@EXAMPLE.COM:
  ~]$ klist
  Ticket cache: FILE:/tmp/krb5cc_10920
  Default principal: user@EXAMPLE.COM
  Valid starting     Expires            Service principal
  10/26/06 23:47:54  10/27/06 09:47:54  krbtgt/USER.COM@USER.COM
          renew until 10/26/06 23:47:54
  Kerberos 4 ticket cache: /tmp/tkt10920
  klist: You have no tickets cached

Troubleshooting

If you have followed the configuration steps above and Negotiate authentication is not working, you can turn on verbose logging of the authentication process. This could help you find the cause of the problem. To enable verbose logging, use the following procedure:

• Open a command shell, and enter the following commands:

  export NSPR_LOG_MODULES=negotiateauth:5
  export NSPR_LOG_FILE=/tmp/moz.log

• Restart Firefox from that shell, and visit the website you were unable to authenticate to earlier. Information will be logged to /tmp/moz.log, and may give a clue to the problem. For example:

  -1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken()
  -1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failure
  No credentials cache found

  This indicates that you do not have Kerberos tickets, and need to run kinit.

  If you are able to run kinit successfully from your machine but you are unable to authenticate, you might see something like this in the log file:

  -1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken()
  -1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure
  Server not found in Kerberos database

  This generally indicates a Kerberos configuration problem. Make sure that you have the correct entries in the [domain_realm] section of the /etc/krb5.conf file. For example:

  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM

  If nothing appears in the log it is possible that you are behind a proxy, and that proxy is stripping off the HTTP headers required for Negotiate authentication. As a workaround, you can try to connect to the server using HTTPS instead, which allows the request to pass through unmodified. Then proceed to debug using the log file, as described above.