Red Hat Linux Networking , System Administration (P31) pps

CAUTION Before logging out of this client system and configuring another, open a new login session to this host using the telnet or ssh commands to ensure that you can correctly log in using LDAP. If you encounter any problems, do not log out of this system until you have resolved them. Installing, Configuring, and Using Kerberos Kerberos is a distributed authentication service that was originally developed at the Massachusetts Institute of Technology (MIT) for use with MIT’s Athena project, a distributed computing environment. Kerberos was popularized by its use at MIT and in the AFS distributed file system, developed at Carnegie- Mellon University, Transarc Corporation, and now available as a supported IBM product and an open-source project. The security provided by Kerberos is so well-respected and robust that Kerberos has even been adopted by Microsoft as an underlying authentication model for Windows 2000 and subsequent versions of Windows. Kerberos is designed to provide secure authentication for client-server applications by using strong cryptography to enable clients to prove their identity to servers over the network. In more advanced Kerberos installations, clients and servers that have used Kerberos to prove their identity to each other can option- ally encrypt all subsequent communications to ensure privacy. This requires that all applications that exchange data over the network be either special Kerberos- aware versions or that they link with Kerberos-aware libraries. In its simplest form, Kerberos works by exchanging encrypted security information between clients, which can be users or machines, the Kerberos Authenti- cation Server, and the resource you are trying to access. The information that is initially exchanged when attempting to prove one’s identity is known as a ticket. The information used to encrypt tickets and subsequent communications is known as a key. After the identity of a client is verified, that client is granted a Kerberos token that can be used to verify the client’s identity to any Kerberos- aware service. For security reasons, Kerberos tokens are timestamped so that they automatically expire unless renewed by a user or service. The timestamps contained within Kerberos tokens (and tickets) can be verified only if the time and data are synchronized across Kerberos clients and servers. Kerberos authentication will fail if client and server clocks become skewed by more than 5 minutes. This is the suggested default value, which you can change in your Kerberos configuration files. We strongly suggest that you run Network Time Protocol (NTP) daemons on all Kerberos clients and servers to ensure that their clocks remain in sync. It is also a good idea to set up replicated time servers for any site using Kerberos so that your site can still synchronize client clocks if you encounter problems connecting to the Internet. 864 Chapter 34 43_599496 ch34.qxd 8/30/05 7:25 PM Page 864 Kerberos is often referred to as a trusted third-party authentication service because each participant in the Kerberos authentication process believes in Kerberos’s assessment of the identity of the other parties in that process. Ker- beros verifies each participant’s assessment using private keys that each participant generates during each stage of the authentication process. Kerberos is very robust and secure because all stages of the authentication process exchange encrypted information. At no point are passwords transmitted over the network without first being encrypted. Kerberos Terminology, Machine Roles, and Reliability As a sitewide authentication mechanism, Kerberos introduces some new terms that you must understand in order to use Kerberos effectively. The most basic of these is the idea of a realm, which is essentially a set of machines that uses a Kerberos server for authentication and that, therefore, trusts that server. In Kerberos configuration files, your realm is typically identified in uppercase characters to differentiate it from any, usually similar, DNS domain with which it is associated. Reliability is a critical aspect of a sitewide authentication mechanism. Ker- beros environments are protected against the failure of key systems and services by replicating those systems on slave systems. The most critical of these is the Key Distribution Center (KDC) system, the primary system for granting tickets and the system that houses the master copy of the Kerberos database. KDC slaves contain copies of the Kerberos database but cannot perform administrative functions; they only tickets grant in the event that the primary system is unavailable. TIP As a general rule, all KDC systems should be installed so that they can serve as either a master or a slave. In the event of a hardware problem with your primary KDC systems, this simplifies converting an existing slave to a new master KDC. Kerberos Packages for Linux The packages that provide Kerberos and Kerberos-related libraries, server processes, utilities, and header files on RHEL and Fedora Core systems are: ■■ krb5-workstation — Contains basic Kerberos programs (kinit, klist, kdestroy, kpasswd) as well as Kerberized versions of the telnet and ftp applications. This package should be installed on every client of a Kerberos server. ■■ krb5-server — Provides the programs that must be installed on a Kerberos 5 server or server replica. Implementing Network Security 865 43_599496 ch34.qxd 8/30/05 7:25 PM Page 865 ■■ krb5-libs — Contains the stared libraries required for Kerberos clients and servers. ■■ krbafs-utils — Provides versions of core utilities for the AFS distributed file system that are linked against the krbafs library. ■■ krbafs-devel — Includes header files and static libraries for devel- oping and compiling applications that use the krbafs library ■■ krbafs — Provides the krbafs shared library that enables programs to obtain tokens for the AFS distributed file system using Kerberos 4 cre- dentials without needing access to the official AFS libraries. ■■ krb5-auth-dialog — Contains a pop-up dialog that warns users when their Kerberos tickets are about to expire and enables them to renew them. ■■ krb5-devel — Includes header files and libraries necessary for devel- oping and compiling Kerberos 5 applications. ■■ pam_krb5 — Provides a PAM (Pluggable Authentication Module) that enables Kerberos authentication. This package also includes a PAM (pam_krb5afs) that can get tokens for the AFS distributed file system. NOTE The Kerberos packages supplied with Red Hat Linux are not the only Kerberos implementation available. Other freely available versions of Kerberos include the Heimdal project (www.pdc.kth.se/heimdal), the Shishi project (http://josefsson.org/shishi), and the original implementation from the Kerberos mothership at MIT (http://web.mit.edu/kerberos/www). Core Kerberos Utilities This section highlights the most common utilities associated with Kerberos authentication. For additional information about any of these processes or files, consult the online reference information for them by using the man command. All of these utilities are located in the /usr/kerberos/bin directory on a Fedora Core or RHEL system: ■■ kdestroy — Deletes and tokens owned by the current user. ■■ kinit — Enables you to obtain tokens manually for a specified user. ■■ klist — Lists the tokens of the current, or a specified, user. ■■ kdestroy — Deletes tokens owned by the current user. The /usr/kerberos/bin directory also contains Kerberized versions of common applications such as ftp, rcp, rsh, telnet, and so on. On systems that use Kerberos, you should put the /usr/bin/kerberos directory in the 866 Chapter 34 43_599496 ch34.qxd 8/30/05 7:26 PM Page 866 default PATH for users before standard system directories such as /usr/bin and /bin. Installing and Configuring a Kerberos Server After installing the krb5-libs, krb5-server, and krb5-workstation packages on the system that you are going to use as your primary Key Distribu- tion Center, the first step in configuring your Kerberos environment is to set up your master Key Distribution Center. The process for doing this is the following: 1. Edit the general Kerberos configuration file for your environment, /etc/krb5.conf. This file identifies the KDCs and admin servers in your Kerberos realm and provides default values for your realm, Kerberos applications, and for how your existing hostnames map into your Kerberos realm. A sample /etc/krb5.conf file for the realm VONHAGEN.ORG is the following: [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = VONHAGEN.ORG dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes [realms] VONHAGEN.ORG = { kdc = kerberos.vonhagen.org:88 admin_server = kerberos.vonhagen.org:749 default_domain = vonhagen.org } [domain_realm] .vonhagen.org = VONHAGEN.ORG vonhagen.org = VONHAGEN.ORG [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } Implementing Network Security 867 43_599496 ch34.qxd 8/30/05 7:26 PM Page 867 The defaults provided in the /etc/krb5.conf file installed by the krb5-server package are reasonable, except that you must change all instances of EXAMPLE.COM to the name of your realm and all instances of example.com to the name of your domain (VONHAGEN.ORG and vonhagen.org, respectively, in the previous example). You must also make sure that DNS or /etc/hosts entries exist on all clients for the systems that you identify as your default KDC and admin_server systems in the [realms] section. 2. Edit the Key Distribution Center configuration file, /var/kerberos /krb5kdc/kdc.conf. The location of this file is provided in the [kdc] section of the /etc/krb5.conf file. As with the /etc/krb5.conf file, the primary change that you must make to this file is to change the instance of EXAMPLE.COM to the name of your realm, which is VONHAGEN.ORG in the following example: [kdcdefaults] acl_file = /var/kerberos/krb5kdc/kadm5.acl dict_file = /usr/share/dict/words admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab v4_mode = nopreauth [realms] VONHAGEN.ORG = { master_key_type = des-cbc-crc supported_enctypes = des3-hmac-sha1:normal arcfour-hmac:normal \ des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal \ des-cbc-crc:v4 des-cbc-crc:afs3 } 3. Use the kdb5_util command on the Master KDC to create the Ker- beros database and your stash file. You will have to enter the master database password twice, for verification purposes. The stash file is a local, encrypted copy of the master key that is used to automatically authenticate the KDC as part of your system’s startup sequence. # /usr/kerberos/sbin/kdb5_util create -r VONHAGEN.ORG -s Loading random data Initializing database ‘/var/kerberos/krb5kdc/principal’ for realm ‘vonhagen.org’, master key name ‘K/M@vonhagen.org’ You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: Re-enter KDC database master key to verify: This command creates various files in the directory specified in the kdcdefaults section of your kdc.conf file: two Kerberos database files (principal.db and principal.ok), the Kerberos 868 Chapter 34 43_599496 ch34.qxd 8/30/05 7:26 PM Page 868 administrative database file (principal.kadm5), the database lock file (principal.kadm5.lock), and the stash file (.k5stash). 4. Edit the ACL definition file, /var/kerberos/krb5kdc/kadm5.acl, changing the default realm (EXAMPLE.COM) to the name of the realm that you are creating (VONHAGEN.ORG, in this example). The default entry in this file, which begins with */admin, gives any user with an admin instance (such as wvh/admin, which you create in the next step) complete access to and control over the realm’s Kerberos database. After updating this file for our example realm, this file looks like the following: */admin@VONHAGEN.ORG * TIP Kerberos administrative permissions are very granular and enable you to grant different levels of administrative privileges to certain users and system administrators. See the Kerberos documentation in /usr/share/doc/krb5- server-version for more detailed information about expressing different levels of Kerberos permissions in this file. If you subsequently want to refine the permissions with a user who has an associated /admin instance, you should create an entry for that user in the /var/kerberos/krb5kdc /kadm5.acl file before the default * permissions entry for /admin users. 5. Use the kadmin.local command to add each of your system administrators to the Kerberos database. The kadmin.local command is a Kerberos-aware version of the standard kadmin utility that does not first authenticate to a Kerberos database and is, therefore, used for boot- strapping Kerberos on a KDC. Entries in the Kerberos database are known as principals. The following example adds an admin instance for the user ‘wvh’: # /usr/kerberos/sbin/kadmin.local kadmin.local: addprinc wvh/admin WARNING: no policy specified for wvh/admin@VONHAGEN.ORG; defaulting to no policy Enter password for principal “wvh/admin@VONHAGEN.ORG”: Re-enter password for principal “wvh/admin@VONHAGEN.ORG”: Principal “wvh/admin@VONHAGEN.ORG” created. 6. Add a standard user entry for the nonadmin version of the principal that you just created and then exit the kadmin.local utility, as in the following example. Adding a standard principal enables default authentication by the associated entity. You will eventually need to create a principal for each user that you want to be able to authenticate using Kerberos. Most sites do this by writing a script that also created Kerberos principals when creating standard user accounts. Implementing Network Security 869 43_599496 ch34.qxd 8/30/05 7:26 PM Page 869 kadmin.local: addprinc wvh WARNING: no policy specified for wvh@VONHAGEN.ORG; defaulting to no policy Enter password for principal “wvh@VONHAGEN.ORG”: Re-enter password for principal “wvh@VONHAGEN.ORG”: Principal “wvh@VONHAGEN.ORG” created. kadmin.local: quit 7. Now, the fun begins! Start the various Kerberos-related services using the following commands: # /sbin/service krb5kdc start # /sbin/service kadmin start # /sbin/service krb524 start At this point, you’re ready to install and start a Kerberos client, as explained in the next section. Before doing anything else, you should verify that your server can hand out tickets by using the kinit command to explicitly request one for the administrative principal that you created earlier. You can then use the klist command to verify its contents, and then destroy the ticket (just to clean up) using the kdestroy command. The following example shows this sequence: $ kinit wvh Password for wvh@VONHAGEN.ORG: $ klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: wvh@VONHAGEN.ORG Valid starting Expires Service principal 05/03/05 22:09:04 05/04/05 22:09:04 krbtgt/VONHAGEN.ORG/VONHAGEN.ORG Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached $ kdestroy Enabling Kerberos Clients and Applications Setting up a system as a Kerberos client is simple: 1. Copy the /etc/krb5.conf file from your KDC to the client. 2. Enable a sample application. Use krb-telnet, a Kerberos-aware version of the classic telnet application, as a test application. The krb- telnet server is managed by your system’s inet daemon. To enable krb-telnet, modify the file /etc/xinetd.d/krb-telnet changing the disable entry from yes to no, as in the following example: # default: off # description: The Kerberized telnet server accepts normal telnet 870 Chapter 34 43_599496 ch34.qxd 8/30/05 7:26 PM Page 870 # sessions, but can also use Kerberos 5 authentication. service telnet { Flags = REUSE socket_type = stream wait = no user = root server = /usr/kerberos/sbin/telnetd log_on_failure += USERID disable = no } 3. Restart your system’s inet daemon using the following command: # /etc/init.d/xinetd.d restart 4. Telnet to your system and make sure that you can log in successfully. After you log in, you can use the klist command to verify that you’ve automatically been granted the appropriate Kerberos tokens, as in the following example: $ klist Ticket cache: FILE:/tmp/krb5cc_p4979 Default principal: wvh@VONHAGEN.ORG Valid starting Expires Service principal 05/07/05 10:00:46 05/08/05 10:00:46 krbtgt/VONHAGEN.ORG@VONHAGEN.ORG Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached Congratulations, Kerberos is working! The next step in taking full advan- tage of Kerberos is to integrate it into your system’s login authentication process, as described in the next section. TIP As mentioned earlier in this section, make sure that the time and date are synchronized between your KDCs and any Kerberos client systems before proceeding with this section. By default, a difference of more than five minutes will cause Kerberos authentication to fail. Using Kerberos for Login Authentication If you are going to be using Kerberos for login authentication, testing Kerberos clients such as krb-telnet, as described in the previous section, is a great way to make sure that your Kerberos server is working and that your clients can communicate with it successfully. When you’re sure that everything’s working correctly, integrating Kerberos with the PAMs used for your system’s login process is a logical next step. Implementing Network Security 871 43_599496 ch34.qxd 8/30/05 7:26 PM Page 871 The authconfig applications provided by the RHEL and Fedora distribu- tions simplifies integrating new authentication mechanisms by making all of the necessary modifications to the /etc/pam.d/system-auth PAM control file for you. To enable Kerberos authentication across your system, do the following: 1. Run the /usr/bin/authconfig command and Use Kerberos in the Authentication section of the Authentication Configuration screen. Figure 34-7 shows this screen with the correct option selected. 2. Select Next and press Enter to proceed to the next screen and enter the name of your realm and the IP addresses or hostnames of your KDC and admin server (which are the same in the examples used in this chapter). Figure 34-8 shows this screen with the options appropriate to this example selected. Select OK and press Enter to exit the authconfig application. NOTE Using DNS to locate hosts and associated Kerberos realms requires adding special entries to your DNS server configuration files. For more information about this process, see the documentation in /usr/share/doc /krb5-server-version for more information. 3. After exiting from authconfig, log out and log back in. After you log in, use the klist command to verify that you have Kerberos tokens, which will display information identical to that shown at the end of the previous section. Figure 34-7 Selecting Kerberos authentication in authconfig. 872 Chapter 34 43_599496 ch34.qxd 8/30/05 7:26 PM Page 872 Figure 34-8 Kerberos environment settings in authconfig. After using authconfig, your /etc/pam.d/system-auth file will look like the following: auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so broken_shadow account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_krb5.so account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_krb5.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so TIP If you have any problems with Kerberos login authentication, enable PAM debugging in your /etc/krb5.conf file so that you can quickly identify and resolve authentication-related problems with login and other system applications that use PAMs. To do this, simply set the debug entry in the PAM section of the [appdefaults] stanza to true and restart your Kerberos server. Implementing Network Security 873 43_599496 ch34.qxd 8/30/05 7:26 PM Page 873 [...]... Red Hat Enterprise Linux In particular, the first section of this chapter gives you some general troubleshooting techniques that you can use to solve many problems you may encounter, not just the ones in this chapter Other sections in this chapter help you resolve problems related to installation, the file system, networking, and booting the system A final section addresses a few common problems that... dm- 0, internal journal kjournald starting Commit interval 5 seconds EXT3 FS on hda 2, internal journal EXT3-fs: mounted filesystem with ordered data mode SELinux: initialized (dev hda 2, type ext3 ), uses xattr SELinux: initialized (dev tmpfs, type tmpfs ), uses transition SIDs Adding 1048568k swap on /dev/VolGroup00/LogVol01 Priority:-1 extents:1 SELinux: initialized (dev binfmt_misc, type binfmt_misc ),. .. File Systems If you get an error message that the Virtual File Allocation Table (VFAT) file system, the Windows file system, is not supported when using the mount command to mount a DOS/Windows floppy disk, log in as the root user and execute the following command: # /sbin/modprobe vfat This command loads the necessary modules that Red Hat Linux needs in order to provide support for DOS/Windows file systems... Problems Solving File System Problems Solving Networking Problems Solving NFS Problems Exploring Miscellaneous Problems Making an Emergency Boot Disk Even the best-laid plans rarely survive contact with reality, and Red Hat Enterprise Linux is no exception This chapter describes various problems that can occur with various subsystems and features of Fedora Core and Red Hat Enterprise Linux and suggests... your system, remember the order in which the hosts.allow and hosts.deny files are read and applied The program that starts Internet services consults /etc/hosts.allow first If TCP wrappers does not find a matching rule, it applies the first matching rule, if any, in /etc/hosts.deny If neither file contains a match, access is granted If you performed an upgrade of Red Hat Linux from an earlier version,... you, but is it really? Suppose that you get a call from a user who reports being unable to check email This is the problem, right? Not being able to check email may not be the real problem, but a symptom, the underlying problem may not be so obvious What is the problem? Is it the physical network connection, or the DNS server, the default gateway, or perhaps the email client is improperly configured... causes We know that the physical network connections are good and our DNS and router configurations are good as well If the problem is affecting only one user, we can make a good guess that the problem is related to that specific user’s system Obviously something changed in the configuration of that user’s system and we can continue our problem solving there by examining that particular system, specifically... you are unable to mount one or more partitions after an upgrade, the problem could be due to the use of partition labels Red Hat Linux uses partition labels to help prevent problems that occur when moving hard drives around in a system For example, if / is on /dev/sdb and a new drive is added to the system with a lower SCSI ID, the drive that was previously /dev/sdb becomes /dev/sdc This change causes... listed in what we feel are the most useful order The Internet A great source of information is the Internet Many times when I have a problem with my system, I use my favorite search engine and do a search for the problem I am having A problem that occurs with your Fedora Core or Red Hat Troubleshooting and Problem Solving Enterprise Linux system has most likely already occurred on another system somewhere... disk with the umount command, make sure that your current directory is not located on the floppy disk (use the pwd command) Red Hat Linux cannot unmount a file system or disk of any sort if a process is using it, which includes having a current working directory located anywhere on the file system If you cannot use the cd command to change your current working directory, execute the following command . reality, and Red Hat Enter- prise Linux is no exception. This chapter describes various problems that can occur with various subsystems and features of Fedora Core and Red Hat Enterprise Linux. installation, the file system, networking, and booting the system. A final section addresses a few common problems that do not fit into other categories. Troubleshooting Techniques Trying to fix a system. idea of a realm, which is essentially a set of machines that uses a Kerberos server for authentication and that, therefore, trusts that server. In Kerberos configuration files, your realm is