Changeset View
Changeset View
Standalone View
Standalone View
documentation/content/el/books/handbook/security/_index.adoc
Show First 20 Lines • Show All 1,113 Lines • ▼ Show 20 Lines | |||||
[NOTE] | [NOTE] | ||||
==== | ==== | ||||
If you run a packet sniffer on your KDC to add in troubleshooting and then run `kinit` from a workstation, you will notice that your TGT is sent immediately upon running `kinit` - even before you type your password! The explanation is that the Kerberos server freely transmits a TGT (Ticket Granting Ticket) to any unauthorized request; however, every TGT is encrypted in a key derived from the user's password. Therefore, when a user types their password it is not being sent to the KDC, it is being used to decrypt 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. These credentials include a session key for establishing secure communications with the Kerberos server in the future, as well as the actual ticket-granting ticket, which is actually encrypted with the Kerberos server's own key. This second layer of encryption is unknown to the user, but it is what allows the Kerberos server to verify the authenticity of each TGT. | If you run a packet sniffer on your KDC to add in troubleshooting and then run `kinit` from a workstation, you will notice that your TGT is sent immediately upon running `kinit` - even before you type your password! The explanation is that the Kerberos server freely transmits a TGT (Ticket Granting Ticket) to any unauthorized request; however, every TGT is encrypted in a key derived from the user's password. Therefore, when a user types their password it is not being sent to the KDC, it is being used to decrypt 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. These credentials include a session key for establishing secure communications with the Kerberos server in the future, as well as the actual ticket-granting ticket, which is actually encrypted with the Kerberos server's own key. This second layer of encryption is unknown to the user, but it is what allows the Kerberos server to verify the authenticity of each TGT. | ||||
==== | ==== | ||||
* If you want to use long ticket lifetimes (a week, for example) and you are using OpenSSH to connect to the machine where your ticket is stored, make sure that Kerberos `TicketCleanup` is set to `no` in your [.filename]#sshd_config# or else your tickets will be deleted when you log out. | * If you want to use long ticket lifetimes (a week, for example) and you are using OpenSSH to connect to the machine where your ticket is stored, make sure that Kerberos `TicketCleanup` is set to `no` in your [.filename]#sshd_config# or else your tickets will be deleted when you log out. | ||||
* Remember that host principals can have a longer ticket lifetime as well. If your user principal has a lifetime of a week but the host you are connecting to has a lifetime of nine hours, you will have an expired host principal in your cache and the ticket cache will not work as expected. | * Remember that host principals can have a longer ticket lifetime as well. If your user principal has a lifetime of a week but the host you are connecting to has a lifetime of nine hours, you will have an expired host principal in your cache and the ticket cache will not work as expected. | ||||
* When setting up a [.filename]#krb5.dict# file to prevent specific bad passwords from being used (the manual page for `kadmind` covers this briefly), remember that it only applies to principals that have a password policy assigned to them. The [.filename]#krb5.dict# files format is simple: one string per line. Creating a symbolic link to [.filename]#/usr/shared/dict/words# might be useful. | * When setting up a [.filename]#krb5.dict# file to prevent specific bad passwords from being used (the manual page for `kadmind` covers this briefly), remember that it only applies to principals that have a password policy assigned to them. The [.filename]#krb5.dict# files format is simple: one string per line. Creating a symbolic link to [.filename]#/usr/share/dict/words# might be useful. | ||||
=== Differences with the MIT port | === Differences with the MIT port | ||||
The major difference between the MIT and Heimdal installs relates to the `kadmin` program which has a different (but equivalent) set of commands and uses a different protocol. This has a large implications if your KDC is MIT as you will not be able to use the Heimdal `kadmin` program to administer your KDC remotely (or vice versa, for that matter). | The major difference between the MIT and Heimdal installs relates to the `kadmin` program which has a different (but equivalent) set of commands and uses a different protocol. This has a large implications if your KDC is MIT as you will not be able to use the Heimdal `kadmin` program to administer your KDC remotely (or vice versa, for that matter). | ||||
The client applications may also take slightly different command line options to accomplish the same tasks. Following the instructions on the MITKerberos web site (http://web.mit.edu/Kerberos/www/[http://web.mit.edu/Kerberos/www/]) is recommended. Be careful of path issues: the MIT port installs into [.filename]#/usr/local/# by default, and the "normal" system applications may be run instead of MIT if your `PATH` environment variable lists the system directories first. | The client applications may also take slightly different command line options to accomplish the same tasks. Following the instructions on the MITKerberos web site (http://web.mit.edu/Kerberos/www/[http://web.mit.edu/Kerberos/www/]) is recommended. Be careful of path issues: the MIT port installs into [.filename]#/usr/local/# by default, and the "normal" system applications may be run instead of MIT if your `PATH` environment variable lists the system directories first. | ||||
[NOTE] | [NOTE] | ||||
==== | ==== | ||||
With the MITpackage:security/krb5[] port that is provided by FreeBSD, be sure to read the [.filename]#/usr/local/shared/doc/krb5/README.FreeBSD# file installed by the port if you want to understand why logins via `telnetd` and `klogind` behave somewhat oddly. Most importantly, 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. | With the MITpackage:security/krb5[] port that is provided by FreeBSD, be sure to read the [.filename]#/usr/local/share/doc/krb5/README.FreeBSD# file installed by the port if you want to understand why logins via `telnetd` and `klogind` behave somewhat oddly. Most importantly, 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 [.filename]#rc.conf# must also be modified to contain the following configuration: | The [.filename]#rc.conf# must also be modified to contain the following configuration: | ||||
[.programlisting] | [.programlisting] | ||||
.... | .... | ||||
kerberos5_server="/usr/local/sbin/krb5kdc" | kerberos5_server="/usr/local/sbin/krb5kdc" | ||||
kadmind5_server="/usr/local/sbin/kadmind" | kadmind5_server="/usr/local/sbin/kadmind" | ||||
▲ Show 20 Lines • Show All 1,174 Lines • Show Last 20 Lines |