| Managing Single Sign-On and Smart CardsFor Red Hat Enterprise Linux 6Edition 6.2 Legal NoticeCopyright © 2010, 2011 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution-Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Java® is a registered trademark of Oracle and/or its affiliates. XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries. All other trademarks are the property of their respective owners.
1801 Varsity Drive
Raleigh, NC 27606-2072 USA
Phone: +1 919 754 3700
Phone: 888 733 4281
Fax: +1 919 754 3701
August 13, 2009, revised December 6, 2011 Daftar IsiAbstractThis guide is for both users and administrators for Red Hat Enterprise Linux 6 to learn how to manage personal certificates and keys using the Enterprise Security Client. The Enterprise Security Client is a simple GUI which works as a frontend for the Red Hat Certificate System token management system. The Enterprise Security Client allows users of Red Hat Enterprise Linux 6 to format and manage smart cards easily as part of a single sign-on solution. The Enterprise Security Client is a simple user interface which formats and manages smart cards. This guide is intended for everyday users of Certificate System, who use the Enterprise Security Client to manage their smart cards. Certificate System agents should read the Certificate System Agent's Guide for information on how to perform agent tasks, such as handling certificate requests and revoking certificates. Before reading this guide, be familiar with the following concepts: Public-key cryptography and the Secure Sockets Layer (SSL) protocol Intranet, extranet, Internet security, and the role of digital certificates in a secure enterprise LDAP and Red Hat Directory Server
This guide covers information on managing smart cards, security and single sign-on related services in Red Hat Enterprise Linux, PAM, and Kerberos. To understand the complete range of security concepts inherent in Red Hat Enterprise Linux 6, including using SELinux, refer to these guides in the Red Hat Enterprise Linux documentation set: Red Hat Enterprise Linux Deployment Guide covers a comprehensive selection of security and configuration topics, including access controls, network configuration, SELinux, and single sign-on, along with other deployment and management considerations. Red Hat Enterprise Linux Security Guide provides an overview of security concepts, such as server security and potential network threats, and describes how to configure Red Hat Enterprise Linux 6 servers and workstations, virtual private networks, and firewalls for effective security. It also covers how to assess vulnerabilities in the system and to detect and respond to intrusions. Red Hat Enterprise Linux SELinux Guide gives an overview of SELinux concepts and details how to configure and use SELinux effectively on a Red Hat Enterprise Linux system. Red Hat Enterprise Linux Installation Guide provides procedures and options for installing Red Hat Enterprise Linux 6.
Some very basic information on using other end user web services for the Certificate System CA and RA systems is covered in Using End User Services. For basic certificate management, that is all many users need to know. Managing Smart Cards with the Enterprise Security Client and the End User's Guide, together, are both for end users of Red Hat Certificate System. The Certificate System Agent's Guide covers how agents can approve and reject certificate requests and manage user certificates through other Certificate System subsystems, such as the Online Certificate Status Responder (which checks the revocation status) and the Data Recovery Manager (which recovers the certificate information if a token or a certificate is lost). 2. Examples and Formatting2.1. Formatting for Examples and CommandsAll of the examples for Red Hat Certificate System commands, file locations, and other usage are given for Red Hat Enterprise Linux 6 systems. Be certain to use the appropriate commands and files for your platform. Example 1. Example CommandTo start the Red Hat Certificate System Certificate Manager: service pki-ca start All of the tools for Red Hat Certificate System are located in the /usr/bin directory. These tools can be run from any location without specifying the tool location. Certain words are represented in different fonts, styles, and weights. Different character formatting is used to indicate the function or purpose of the phrase being highlighted. Other formatting styles draw attention to important text. A note provides additional information that can help illustrate the behavior of the system or provide more detail for a specific issue. Important information is necessary, but possibly unexpected, such as a configuration change that will not persist after a reboot. A warning indicates potential data loss, as may happen when tuning hardware for maximum performance. If there is any error in this guide or there is any way to improve the documentation, please let us know. Bugs can be filed against the documentation for Red Hat Enterprise Linux through Bugzilla, http://bugzilla.redhat.com/bugzilla. Make the bug report as specific as possible, so we can be more effective in correcting any issues: Select the Red Hat Enterprise Linux product. Set the component to doc-Managing_Smart_Cards. Set the version number to 6. For errors, give the page number (for the PDF) or URL (for the HTML), and give a succinct description of the problem, such as incorrect procedure or typo. For enhancements, put in what information needs to be added and why. Give a clear title for the bug. For example, "Incorrect command example for setup script options" is better than "Bad example".
We appreciate receiving any feedback - requests for new sections, corrections, improvements, enhancements, even new ways of delivering the documentation or new styles of docs. You are welcome to contact Red Hat Content Services directly at [email protected]. | Revision History |
|---|
| Revision 6.2-5 | 2012-07-18 | Anthony Towns | | | Revision 6.2-4 | December 5, 2011 | Ella Deon Lackey | | Release for GA of Red Hat Enterprise Linux 6.2. | | Added PIV and CAC card to supported smart cards list, per Errata RHEA-2011:11755. |
| | Revision 6.1-0 | Thu May 5, 2011 | Ella Deon Lackey | | Updated draft for Red Hat Enterprise Linux 6.1. | | Added note on formatting enable_ocsp=true so that smart card authentication properly triggers OCSP requests, per Bugzilla 583109 and 590689. | | Fixed typos, per Bugzilla 630533, 683705, 695205. | | Found or removed references to missing images, per Bugzilla 630523 and 695207. | | Updated Kerberos directory paths for new locations in RHEL 6, per Bugzilla 630525, 630526, and 630527. | | Added instructions to install meta package 'Smart card support' for smart card configuration, per Bugzilla 693750. | | Updated the packages to install to get the required rlogin and rsh files, per Bugzilla 695544. | | Updated the default esc-prefs.js file for the Enterprise Security Client, removed references to a separate xulrunner installation, updated the Enterprise Security Client menu location, and updated the Enterprise Security Client directory paths, per Bugzilla 630528, 630529, 630530, and 605812. | | Updated the browser and mail client configuration procedures for the current versions of Firefox and Thunderbird, per Bugzilla 630531 and 630532. | | Removed references to 50-default.perms, since this file was removed in Red Hat Enterprise Linux 6, per Bugzilla 630524. | | Updates to the procedures for enabling Security Officer Mode, per Bugzilla 688402. | | Minor edits to the Kerberos and PAM sections after development review for Red Hat Enterprise Linux 6.1. | | Added new information for installing Kerberos-related packages, per feedback from QE. |
| | Revision 6.0-0 | Thu Oct 22 2009 | Ella Deon Lackey | | Initial draft for Red Hat Enterprise Linux 6. |
|
Chapter 1. Introduction to the Enterprise Security ClientThe Enterprise Security Client is a tool for Red Hat Certificate System which simplifies managing smart cards. End users can use security tokens (smart cards) to store user certificates used for applications such as single sign-on access and client authentication. End users are issued the tokens containing certificates and keys required for signing, encryption, and other cryptographic functions. After a token is enrolled, applications such as Mozilla Firefox and Thunderbird can be configured to recognize the token and use it for security operations, like client authentication and S/MIME mail. The Enterprise Security Client provides the following capabilities: Supports Global Platform-compliant smart cards. Enrolls security tokens so they are recognized by the token management system in Red Hat Certificate System. Maintains the security token, such as re-enrolling a token. Provides information about the current status of the token or tokens being managed. Supports server-side key generation through the Certificate System subsystems so that keys can be archived and recovered on a separate token if a token is lost.
1.1. Red Hat Enterprise Linux, Single Sign-On, and AuthenticationNetwork users frequently have to submit multiple passwords for the various services they use, such as email, web browsing and intranets, and servers on the network. Maintaining multiple passwords, and constantly being prompted to enter them, is a hassle for users and administrators. Single sign-on is a configuration which allows administrators to create a single password store so that users can log in once, using a single password, and be authenticated to all network resources. Red Hat Enterprise Linux 6 supports single sign-on for several resources, including logging into workstations and unlocking screensavers, accessing encrypted web pages using Mozilla Firefox, and sending encrypted email using Mozilla Thunderbird. Single sign-on is both a convenience to users and another layer of security for the server and the network. Single sign-on hinges on secure and effective authentication. Red Hat Enterprise Linux provides two authentication mechanisms which can be used to enable single sign-on: Kerberos-based authentication Smart card-based authentication, using the Enterprise Security Client tied into the public-key infrastructure implemented by Red Hat Certificate System
One of the cornerstones of establishing a secure network environment is making sure that access is restricted to people who have the right to access the network. If access is allowed, users can authenticate to the system, meaning they can verify their identities. Many systems use Kerberos to establish a system of short-lived credentials, called tickets, which are generated ad hoc at a user request. The user is required to present credentials in the form of a username-password pair that identify the user and indicate to the system that the user can be issued a ticket. This ticket can be referenced repeatedly by other services, like websites and email, requiring the user to go through only a single authentication process. An alternative method of verifying an identity is presenting a certificate. A certificate is an electronic document which identifies the entity which presents it. With smart card-based authentication, these certificates are stored on a small hardware device called a smart card or token. When a user inserts a smart card, the smart card presents the certificates to the system and identifies the user so the user can be authenticated. Single sign-on using smart cards goes through three steps: A user inserts a smart card into the card reader. This is detected by the pluggable authentication modules (PAM) on Red Hat Enterprise Linux. The system maps the certificate to the user entry and then compares the presented certificates on the smart card to the certificates stored in the user entry. If the certificate is successfully validated against the key distribution center (KDC), then the user is allowed to log in.
Smart card-based authentication builds on the simple authentication layer established by Kerberos by adding additional identification mechanisms (certificates) and physical access requirements. 1.2. Red Hat Certificate System and the Enterprise Security ClientRed Hat Certificate System creates, manages, renews, and revokes certificates and keys. For managing smart cards, the Certificate System has a token management system to generate keys, create certificate requests, and receive certificates. Two subsystems - the Token Key Service (TKS) and Token Processing System (TPS) - are used to process token-related operations. The Enterprise Security Client is the interface which allows the smart card and user to access the token management system. A total of four Certificate System subsystems are involved with managing tokens, two for managing the tokens (TKS and TPS) and two for managing the keys and certificates within the public-key infrastructure (CA and DRM). The Token Processing System (TPS) interacts with smart cards to help them generate and store keys and certificates for a specific entity, such as a user or device. Smart card operations go through the TPS and are forwarded to the appropriate subsystem for action, such as the Certificate Authority to generate certificates or the Data Recovery Manager to archive and recover keys. The Token Key Service (TKS) generates, or derives, symmetric keys used for communication between the TPS and smart card. Each set of keys generated by the TKS is unique because they are based on the card's unique ID. The keys are formatted on the smart card and are used to encrypt communications, or provide authentication, between the smart card and TPS. The Certificate Authority (CA) creates and revokes user certificates stored on the smart card. Optionally, the Data Recovery Manager (DRM) archives and recovers keys for the smart card.
As Figure 1.1, "How Certificate System Manages Smart Cards" shows, the TPS is the central hub in the Red Hat Certificate System token management system. The token communicates with the TPS directly. The TPS then communicates with the TKS to derive a set of unique keys that can be used for TPS-token communication (1). When the smart card is enrolled, new private keys are created for the token; those keys can be archived in a DRM (2), if key archival is configured. The CA then processes the certificate request (3) and issues the certificates to store on the token. The TPS sends those certificates back to the Enterprise Security Client (4), and they are saved to the token.The Enterprise Security Client is the conduit through which TPS communicates with each token over a secure HTTP channel (HTTPS), and, through the TPS, with the Certificate System. To use the tokens, the Token Processing System must be able to recognize and communicate with them. The tokens must first be enrolled to populate the tokens with required keys and certificates and add the tokens to the Certificate System. The Enterprise Security Client provides the user interface for users to format and manage smart cards. Chapter 2. Using Pluggable Authentication Modules (PAM)Pluggable authentication modules are a common framework for authentication and security. Both of Red Hat Enterprise Linux's single sign-on methods - Kerberos and smart cards - depend on underlying PAM configuration. Understanding and using PAM can be very beneficial for planning and implementing a secure, efficient single sign-on solution. Programs that grant users access to a system use authentication to verify each other's identity (that is, to establish that a user is who they say they are). Historically, each program had its own way of authenticating users. In Red Hat Enterprise Linux, many programs are configured to use a centralized authentication mechanism called Pluggable Authentication Modules ( PAM). PAM uses a pluggable, modular architecture, which affords the system administrator a great deal of flexibility in setting authentication policies for the system. PAM is a useful system for developers and administrators for several reasons: PAM provides a common authentication scheme that can be used with a wide variety of applications. PAM provides significant flexibility and control over authentication for both system administrators and application developers. PAM provides a single, fully-documented library which allows developers to write programs without having to create their own authentication schemes.
PAM has an extensive documentation set with much more detail about both using PAM and writing modules to extend or integrate PAM with other applications. Almost all of the major modules and configuration files with PAM have their own manpages. Additionally, the /usr/share/doc/pam-version# directory contains a System Administrators' Guide, a Module Writers' Manual, and the Application Developers' Manual, as well as a copy of the PAM standard, DCE-RFC 86.0. The libraries for PAM are available at http://www.kernel.org/pub/linux/libs/pam/. This is the primary distribution website for the Linux-PAM project, containing information on various PAM modules, frequently asked questions, and additional PAM documentation. 2.2. PAM Configuration FilesThe /etc/pam.d/ directory contains the PAM configuration files for each PAM-aware application. Each PAM-aware application or service has a file in the /etc/pam.d/ directory. Each file in this directory has the same name as the service to which it controls access. The PAM-aware program is responsible for defining its service name and installing its own PAM configuration file in the /etc/pam.d/ directory. For example, the login program defines its service name as login and installs the /etc/pam.d/login PAM configuration file. Each PAM configuration file contains a group of directives that define the module and any controls or arguments with it. The directives all have a simple syntax that identifies the module purpose (interface) and the configuration settings for the module. module_interface control_flag module_name module_arguments
2.2.2.1. PAM Module InterfacesFour types of PAM module interface are available. Each of these corresponds to a different aspect of the authorization process: auth - This module interface authenticates use. For example, it requests and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships or Kerberos tickets. account - This module interface verifies that access is allowed. For example, it checks if a user account has expired or if a user is allowed to log in at a particular time of day. password - This module interface is used for changing user passwords. session - This module interface configures and manages user sessions. Modules with this interface can also perform additional tasks that are needed to allow access, like mounting a user's home directory and making the user's mailbox available.
An individual module can provide any or all module interfaces. For instance, pam_unix.so provides all four module interfaces. In a PAM configuration file, the module interface is the first field defined. For example: authrequiredpam_unix.so This instructs PAM to use the pam_unix.so module's auth interface. Module interface directives can be stacked, or placed upon one another, so that multiple modules are used together for one purpose. If a module's control flag uses the sufficient or requisite value, then the order in which the modules are listed is important to the authentication process. Stacking makes it easy for an administrator to require specific conditions to exist before allowing the user to authenticate. For example, the reboot command normally uses several stacked modules, as seen in its PAM configuration file: [root@MyServer ~]# cat /etc/pam.d/reboot#%PAM-1.0authsufficientpam_rootok.soauthrequiredpam_console.so#authincludesystem-authaccountrequiredpam_permit.so The first line is a comment and is not processed. auth sufficient pam_rootok.so - This line uses the pam_rootok.so module to check whether the current user is root, by verifying that their UID is 0. If this test succeeds, no other modules are consulted and the command is executed. If this test fails, the next module is consulted. auth required pam_console.so - This line uses the pam_console.so module to attempt to authenticate the user. If this user is already logged in at the console, pam_console.so checks whether there is a file in the /etc/security/console.apps/ directory with the same name as the service name (reboot). If such a file exists, authentication succeeds and control is passed to the next module. #auth include system-auth - This line is commented and is not processed. account required pam_permit.so - This line uses the pam_permit.so module to allow the root user or anyone logged in at the console to reboot the system.
2.2.2.2. PAM Control FlagsAll PAM modules generate a success or failure result when called. Control flags tell PAM what do with the result. Modules can be stacked in a particular order, and the control flags determine how important the success or failure of a particular module is to the overall goal of authenticating the user to the service. There are several simple flags, which use only a keyword to set the configuration: required - The module result must be successful for authentication to continue. If the test fails at this point, the user is not notified until the results of all module tests that reference that interface are complete. requisite - The module result must be successful for authentication to continue. However, if a test fails at this point, the user is notified immediately with a message reflecting the first failed required or requisite module test. sufficient - The module result is ignored if it fails. However, if the result of a module flagged sufficient is successful and no previous modules flagged required have failed, then no other results are required and the user is authenticated to the service. optional - The module result is ignored. A module flagged as optional only becomes necessary for successful authentication when no other modules reference the interface. include - Unlike the other controls, this does not relate to how the module result is handled. This flag pulls in all lines in the configuration file which match the given parameter and appends them as an argument to the module.
The order in which required modules are called is not critical. Only the sufficient and requisite control flags cause order to become important. There are many complex control flags that can be set. These are set in attribute=value pairs; a complete list of attributes is available in the pam.d manpage. 2.2.2.3. PAM Module NamesThe module name provides PAM with the name of the pluggable module containing the specified module interface. The directory name is omitted because the application is linked to the appropriate version of libpam, which can locate the correct version of the module. 2.2.2.4. PAM Module ArgumentsPAM uses arguments to pass information to a pluggable module during authentication for some modules. For example, the pam_userdb.so module uses information stored in a Berkeley DB file to authenticate the user. Berkeley DB is an open source database system embedded in many applications. The module takes a db argument so that Berkeley DB knows which database to use for the requested service. For example: authrequiredpam_userdb.so db=/path/to/BerkeleyDB_file Invalid arguments are generally ignored and do not otherwise affect the success or failure of the PAM module. Some modules, however, may fail on invalid arguments. Most modules report errors to the /var/log/secure file. 2.2.3. Sample PAM Configuration FilesExample 2.1, "Simple PAM Configuration" is a sample PAM application configuration file: Example 2.1. Simple PAM Configuration#%PAM-1.0authrequired pam_securetty.soauthrequired pam_unix.so nullokauthrequired pam_nologin.soaccountrequired pam_unix.sopasswordrequired pam_cracklib.so retry=3passwordrequired pam_unix.so shadow nullok use_authtoksessionrequired pam_unix.so The first line is a comment, indicated by the hash mark ( #) at the beginning of the line. Lines two through four stack three modules for login authentication. auth required pam_securetty.so - This module ensures that if the user is trying to log in as root, the tty on which the user is logging in is listed in the /etc/securetty file, if that file exists. If the tty is not listed in the file, any attempt to log in as root fails with a Login incorrect message. auth required pam_unix.so nullok - This module prompts the user for a password and then checks the password using the information stored in /etc/passwd and, if it exists, /etc/shadow. The argument nullok instructs the pam_unix.so module to allow a blank password. auth required pam_nologin.so - This is the final authentication step. It checks whether the /etc/nologin file exists. If it exists and the user is not root, authentication fails. In this example, all three auth modules are checked, even if the first auth module fails. This prevents the user from knowing at what stage their authentication failed. Such knowledge in the hands of an attacker could allow them to more easily deduce how to crack the system. account required pam_unix.so - This module performs any necessary account verification. For example, if shadow passwords have been enabled, the account interface of the pam_unix.so module checks to see if the account has expired or if the user has not changed the password within the allowed grace period. password required pam_cracklib.so retry=3 - If a password has expired, the password component of the pam_cracklib.so module prompts for a new password. It then tests the newly created password to see whether it can easily be determined by a dictionary-based password cracking program. The argument retry=3 specifies that if the test fails the first time, the user has two more chances to create a strong password. password required pam_unix.so shadow nullok use_authtok - This line specifies that if the program changes the user's password, using the password interface of the pam_unix.so module. The argument shadow instructs the module to create shadow passwords when updating a user's password. The argument nullok instructs the module to allow the user to change their password from a blank password, otherwise a null password is treated as an account lock. The final argument on this line, use_authtok, provides a good example of the importance of order when stacking PAM modules. This argument instructs the module not to prompt the user for a new password. Instead, it accepts any password that was recorded by a previous password module. In this way, all new passwords must pass the pam_cracklib.so test for secure passwords before being accepted.
session required pam_unix.so - The final line instructs the session interface of the pam_unix.so module to manage the session. This module logs the user name and the service type to /var/log/secure at the beginning and end of each session. This module can be supplemented by stacking it with other session modules for additional functionality.
2.3. Creating PAM ModulesNew PAM modules can be created or added at any time for use by PAM-aware applications. PAM-aware programs can immediately use the new module and any methods it defines without being recompiled or otherwise modified. This allows developers and system administrators to mix-and-match, as well as test, authentication methods for different programs without recompiling them. Documentation on writing modules is included in the /usr/share/doc/pam-version# directory. 2.4. PAM and Administrative Credential CachingA number of graphical administrative tools in Red Hat Enterprise Linux provide users with elevated privileges for up to five minutes using the pam_timestamp.so module. It is important to understand how this mechanism works, because a user who walks away from a terminal while pam_timestamp.so is in effect leaves the machine open to manipulation by anyone with physical access to the console. In the PAM timestamp scheme, the graphical administrative application prompts the user for the root password when it is launched. When the user has been authenticated, the pam_timestamp.so module creates a timestamp file. By default, this is created in the /var/run/sudo/ directory. If the timestamp file already exists, graphical administrative programs do not prompt for a password. Instead, the pam_timestamp.so module freshens the timestamp file, reserving an extra five minutes of unchallenged administrative access for the user. You can verify the actual state of the timestamp file by inspecting the file in the /var/run/sudo/user directory. For the desktop, the relevant file is unknown:root. If it is present and its timestamp is less than five minutes old, the credentials are valid. The existence of the timestamp file is indicated by an authentication icon, which appears in the notification area of the panel. 2.4.1. Removing the Timestamp FileBefore abandoning a console where a PAM timestamp is active, it is recommended that the timestamp file be destroyed. To do this from a graphical environment, click the authentication icon on the panel. This causes a dialog box to appear. Click the Forget Authorization button to destroy the active timestamp file. The PAM timestamp file has some important characteristics: Refer to the pam_timestamp_check man page for more information about destroying the timestamp file using pam_timestamp_check. 2.4.2. Common pam_timestamp DirectivesThe pam_timestamp.so module accepts several directives, with two used most commonly: timestamp_timeout - Specifies the period (in seconds) for which the timestamp file is valid. The default value is 300 (five minutes). timestampdir - Specifies the directory in which the timestamp file is stored. The default value is /var/run/sudo/.
|
| |
