diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.xml b/en_US.ISO8859-1/books/handbook/security/chapter.xml index 146374a604..08be7f8c0b 100644 --- a/en_US.ISO8859-1/books/handbook/security/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/security/chapter.xml @@ -1366,23 +1366,24 @@ kadmin> exit - <application>Kerberos</application> Enabling a Client - with Heimdal + Configuring a Client to use + <application>Kerberos</application> Kerberos5 configure clients - Setting up a client computer is easy as only - /etc/krb5.conf is needed. Securely copy - this file over to the client computer from the + To configure a client to use + Kerberos, securely copy + /etc/krb5.conf + to the client computer from the KDC. - Test the client by attempting to use &man.kinit.1;, - &man.klist.1;, and &man.kdestroy.1; from the client to obtain, - show, and then delete a ticket for the principal created - above. Kerberos applications + Test the client by using kinit, + klist, and kdestroy from the client to obtain, + show, and then delete an existing ticket for the principal. + Kerberos applications should also be able to connect to Kerberos enabled servers. If that does not work but obtaining a ticket does, the problem is @@ -1390,26 +1391,21 @@ kadmin> exit KDC. When testing a Kerberized application, try using a packet - sniffer such as &man.tcpdump.1; to confirm that the password + sniffer such as tcpdump to confirm that the password is not sent in the clear. - Various non-core Kerberos - client applications are available. The minimal - installation in &os; installs &man.telnetd.8; as the only - Kerberos enabled service. - - The Heimdal port installs + Various Kerberos + client applications are available. + &os; installs telnetd as the only + Kerberos enabled service. The + Heimdal package or port installs Kerberos enabled versions of - &man.ftpd.8;, &man.rshd.8;, &man.rcp.1;, &man.rlogind.8;, and + ftpd, rshd, + rcp, rlogind, and a few other less common programs. The MIT - port also contains a full suite of + port contains a full suite of Kerberos client applications. - - - - User Configuration Files: <filename>.k5login</filename> - and <filename>.k5users</filename> .k5login @@ -1433,7 +1429,7 @@ kadmin> exit The .k5login and .k5users files, placed in a user's home directory, can be used to solve this problem. For example, if - .k5login with the following contents is + the following .k5login is placed in the home directory of webdevelopers, both principals listed will have access to that account without requiring a @@ -1446,16 +1442,64 @@ jdoe@example.org .k5users. + + <acronym>MIT</acronym> Differences + + The major difference between the MIT and + Heimdal implementations is that kadmin has a different, but + equivalent, set of commands and uses a different protocol. + If the KDC is MIT, the + Heimdal version of kadmin cannot be used to administer + the KDC remotely, and vice versa. + + Client applications may also use slightly different + command line options to accomplish the same tasks. + Following the instructions at + Kerberos http://web.mit.edu/Kerberos/www/ + is recommended. Be careful of path issues: the + MIT port installs into + /usr/local/ by default, and the + &os; system applications run instead of the + MIT versions if PATH lists + the system directories first. + + + With the &os; MIT + security/krb5 port, be sure to read + /usr/local/share/doc/krb5/README.FreeBSD + installed by the port to understand why logins via + telnetd and klogind behave + somewhat oddly. Correcting the incorrect permissions + on cache file behavior requires that the + login.krb5 binary be used for + authentication so that it can properly change ownership for + the forwarded credentials. + + + The following edits should also be made to + rc.conf: + + kerberos5_server="/usr/local/sbin/krb5kdc" +kadmind5_server="/usr/local/sbin/kadmind" +kerberos5_server_flags="" +kerberos5_server_enable="YES" +kadmind5_server_enable="YES" + + <application>Kerberos</application> Tips, Tricks, and Troubleshooting + When configuring and troubleshooting + Kerberos, keep the following points + in mind: + - When using either the Heimdal or + When using either Heimdal or MIT - KerberosKerberos5troubleshooting - ports, ensure that the PATH lists the + Kerberos, ensure that the PATH lists the Kerberos versions of the client applications before the system versions. @@ -1467,12 +1511,6 @@ jdoe@example.org clocks using NTP. - - MIT and Heimdal interoperate - except for &man.kadmin.8;, which is not - standardized. - - If the hostname is changed, the host/ principal must be @@ -1485,7 +1523,7 @@ jdoe@example.org All hosts in the realm must be both forward and reverse resolvable in DNS or, at a - minimum, in /etc/hosts. CNAMEs + minimum, exist in /etc/hosts. CNAMEs will work, but the A and PTR records must be correct and in place. The error message for unresolvable hosts is not intuitive: Kerberos5 refuses authentication @@ -1496,31 +1534,30 @@ jdoe@example.org Some operating systems that act as clients to the KDC do not set the permissions for - &man.ksu.1; to be setuid ksu to be setuid root. This means that - &man.ksu.1; does not work. This is not a + ksu does not work. This is a permissions problem, not a KDC error. With MIT - Kerberos, in order to allow a + Kerberos, to allow a principal to have a ticket life longer than the default ten hours, use modify_principal at the - &man.kadmin.8; prompt to change the maxlife of both the + &man.kadmin.8; prompt to change the maxlife of both the principal in question and the krbtgt principal. Then - the principal can use kinit -l to + class="username">krbtgt principal. The + principal can then use kinit -l to request a ticket with a longer lifetime. - When running a packet sniffer on the KDC to aid in troubleshooting while - running &man.kinit.1; from a workstation, the Ticket + running kinit from a workstation, the Ticket Granting Ticket (TGT) is sent - immediately upon running &man.kinit.1;, even before the + immediately, even before the password is typed. This is because the Kerberos server freely transmits a TGT to any unauthorized @@ -1528,7 +1565,7 @@ jdoe@example.org encrypted in a key derived from the user's password. When a user types their password, it is not sent to the KDC, it is instead used to decrypt - the TGT that &man.kinit.1; already + the TGT that kinit already obtained. If the decryption process results in a valid ticket with a valid time stamp, the user has valid Kerberos credentials. @@ -1541,17 +1578,16 @@ jdoe@example.org This second layer of encryption allows the Kerberos server to verify the authenticity of each TGT. - - To use long ticket lifetimes, such as a week, when + To use long ticket lifetimes when using OpenSSH to connect to the machine where the ticket is stored, make sure that Kerberos is set to no in - sshd_config or else tickets will be + /etc/ssh/sshd_config. Otherwise, tickets will be deleted at log out. @@ -1578,106 +1614,45 @@ jdoe@example.org - Differences with the <acronym>MIT</acronym> - Port - - The major difference between MIT and - Heimdal relates to &man.kadmin.8; which has a different, but - equivalent, set of commands and uses a different protocol. - If the KDC is MIT, the - Heimdal version of &man.kadmin.8; cannot be used to administer - the KDC remotely, and vice versa. - - The client applications may also use slightly different - command line options to accomplish the same tasks. - Following the instructions on the MIT - Kerberos web - site is recommended. Be careful of path issues: the - MIT port installs into - /usr/local/ by default, and the - normal system applications run instead of - MIT versions if PATH lists - the system directories first. - - - With the &os; MIT - security/krb5 port, be sure to read - /usr/local/share/doc/krb5/README.FreeBSD - installed by the port to understand why logins via - &man.telnetd.8; and klogind behave - somewhat oddly. Correcting the incorrect permissions - on cache file behavior requires that the - login.krb5 binary be used for - authentication so that it can properly change ownership for - the forwarded credentials. - - - The following edits should also be made to - rc.conf: - - kerberos5_server="/usr/local/sbin/krb5kdc" -kadmind5_server="/usr/local/sbin/kadmind" -kerberos5_server_flags="" -kerberos5_server_enable="YES" -kadmind5_server_enable="YES" - - This is done because the applications for - MIT Kerberos installs binaries in the - /usr/local hierarchy. - - - - Mitigating Limitations Found in - <application>Kerberos</application> + Mitigating <application>Kerberos</application> Limitations Kerberos5 limitations and shortcomings - - <application>Kerberos</application> is an All or - Nothing Approach - - Every service enabled on the network must be modified - to work with Kerberos, or be - otherwise secured against network attacks, or else the - user's credentials could be stolen and re-used. An example - of this would be Kerberos - enabling all remote shells but not converting the - POP3 mail server which sends passwords in + Since Kerberos is an all or + nothing approach, every service enabled on the network must either be modified + to work with Kerberos or be + otherwise secured against network attacks. This is to prevent + user credentials from being stolen and re-used. An example is when + Kerberos is + enabled on all remote shells but the non-Kerberized + POP3 mail server sends passwords in plain text. - - - <application>Kerberos</application> is Intended for - Single-User Workstations - - In a multi-user environment, - Kerberos is less secure. This is - because it stores the tickets in /tmp, + Kerberos is intended for + single-user workstations. In a multi-user environment, + Kerberos is less secure as it + stores the tickets in /tmp, which is readable by all users. If a user is sharing a - computer with other users, it is possible that the user's + computer, it is possible that the user's tickets can be stolen or copied by another user. - This can be overcome with the -c - command-line option or, preferably, the + This can be overcome with kinit -c + or, preferably, the KRB5CCNAME environment variable. Storing the ticket in the user's home directory and using file permissions are commonly used to mitigate this problem. - - - The KDC is a Single Point of Failure - - By design, the KDC must be as secure + The KDC is a single point of failure. By design, the + KDC must be as secure as its master password database. The KDC should have absolutely no other services running on it and should be physically secure. The danger is high because Kerberos stores all passwords - encrypted with the same master key which is + encrypted with the same master key which is stored as a file on the KDC. A compromised master key is not quite as bad as one @@ -1687,56 +1662,49 @@ kadmind5_server_enable="YES" KDC is secure, an attacker cannot do much with the master key. - Additionally, if the KDC is + If the KDC is unavailable, network services are unusable as authentication cannot be performed. This can be alleviated with a single master KDC and one or more slaves, and with careful implementation of secondary or fall-back authentication using PAM. - - - - <application>Kerberos</application> - Shortcomings Kerberos allows users, hosts and services to authenticate between themselves. It does not have a mechanism to authenticate the - KDC to the users, hosts or services. - This means that a trojanned &man.kinit.1; could record all + KDC to the users, hosts, or services. + This means that a trojanned kinit could record all user names and passwords. File system integrity checking tools like security/tripwire can alleviate this. - - Access Issues with Kerberos and &man.ssh.1; + Access Issues with Kerberos and <command>ssh</command> &man.ssh.1; - There are a few issues with both Kerberos and &man.ssh.1; - that need to be addressed if they are used. Kerberos is an + Kerberos is an excellent authentication protocol, but there are bugs in the - kerberized versions of &man.telnet.1; and &man.rlogin.1; that + kerberized versions of telnet and rlogin that make them unsuitable for dealing with binary streams. By default, Kerberos does not encrypt a session unless - is used whereas &man.ssh.1; encrypts + is used, whereas ssh encrypts everything. - While &man.ssh.1; works well, it forwards encryption keys + While ssh works well, it forwards encryption keys by default. This introduces a security risk to a user who - uses &man.ssh.1; to access an insecure machine from a secure + uses ssh to access an insecure machine from a secure workstation. The keys themselves are not exposed, but - &man.ssh.1; installs a forwarding port for the duration of the + ssh installs a forwarding port for the duration of the login. If an attacker has broken root on the insecure machine, he can utilize that port to gain access to any other machine that those keys unlock. - It is recommended that &man.ssh.1; is used in combination - with Kerberos whenever possible for staff logins and - &man.ssh.1; can be compiled with Kerberos support. This + It is recommended that ssh is used in combination + with Kerberos whenever possible for staff logins as it + can be compiled with Kerberos support. This reduces reliance on potentially exposed SSH keys while protecting passwords via Kerberos. Keys should only be used for automated tasks from secure machines as this