NOTE: CentOS Enterprise Linux 5 is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux 5 is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux 5.
The Red Hat Enterprise Linux SSO functionality reduces the number of times Red Hat 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 Red Hat 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.
42.3.1.1. Supported Applications
The following applications are currently supported by the unified log-in scheme in Red Hat Enterprise Linux:
Login
Screensaver
Firefox and Thunderbird
42.3.1.2. Supported Authentication Mechanisms
Red Hat Enterprise Linux currently supports the following authentication mechanisms:
Kerberos name/password login
Smart card/PIN login
42.3.1.3. Supported Smart Cards
Red Hat 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.
Red Hat Enterprise Linux has also been tested with Common Access Cards (CAC). The supported reader for CAC is the SCM SCR 331 USB Reader.
42.3.1.4. Advantages of Red Hat 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. Red Hat 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, Red Hat 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 Red Hat 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.)
42.3.2. 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.
Note
This section provides a high-level view of getting started with your smart card. More detailed information is available in the Red Hat Certificate System Enterprise Security Client Guide.
Log in with your Kerberos name and password
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
On the Gnome Title Bar, select System->Administration->Authentication.
Type your machine's root password if necessary.
In the Authentication Configuration dialog, click the Authentication tab.
Select the Enable Smart Card Support check box.
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.
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.
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:
Change to the root account and create a file called /etc/pam_pkcs11/cn_map.
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
42.3.2.1. 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.
42.3.3. 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 user inserts their smart card into the smart card reader on their workstation. This event is recognized by the Enterprise Security Client (ESC).
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.
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.
42.3.5. 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 address bar of Firefox, type about:config to display the list of current configuration options.
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.
Note
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 42.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:
[user@host ~] $ kinit
Password for [email protected]:
[user@host ~] $ klist
Ticket cache: FILE:/tmp/krb5cc_10920
Default principal: [email protected]
Valid starting Expires Service principal
10/26/06 23:47:54 10/27/06 09:47:54 krbtgt/[email protected]
renew until 10/26/06 23:47:54
Kerberos 4 ticket cache: /tmp/tkt10920
klist: You have no tickets cached
42.3.5.1. 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:
Close all instances of Firefox.
Open a command shell, and enter the following commands:
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:
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.
