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.
The following applications are currently supported by the unified log-in scheme in Red Hat Enterprise Linux:
-
Login
-
Screensaver
-
Firefox and Thunderbird
Red Hat Enterprise Linux currently supports the following authentication mechanisms:
-
Kerberos name/password login
-
Smart card/PIN login
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.
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.)
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
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.
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.
This section provides a brief overview of the process of logging in using a smart card.
-
When the user inserts their smart card into the smart card reader, this event is recognized by the PAM facility, which prompts for the user's PIN.
-
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.
Note
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 Section 42.6, “Kerberos” and Section 42.4, “Pluggable Authentication Modules (PAM)” for more information on Kerberos and PAM.
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.
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
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:
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.