diff options
Diffstat (limited to 'crypto/kerberosIV/doc/setup.texi')
| -rw-r--r-- | crypto/kerberosIV/doc/setup.texi | 117 |
1 files changed, 88 insertions, 29 deletions
diff --git a/crypto/kerberosIV/doc/setup.texi b/crypto/kerberosIV/doc/setup.texi index 4d2d0ff..24a955d 100644 --- a/crypto/kerberosIV/doc/setup.texi +++ b/crypto/kerberosIV/doc/setup.texi @@ -92,7 +92,9 @@ ANOTHER.REALM kerberos.another.realm @end example The first line defines the name of the local realm. The next few lines -optionally defines supplementary local realms. The rest of the file +optionally defines supplementary local realms. +@cindex supplementary local realms +The rest of the file defines the names of the kerberos servers and the database administration servers for all known realms. You can define any number of kerberos slave servers similar to the one defined on line @@ -111,7 +113,7 @@ support has been added for ports other than the default (750), and protocols other than UDP. The formal syntax for an entry is now -@samp{@var{[proto}/@var{]host[}:@var{port]}}. @var{proto} is either +@samp{[@var{proto}/]@var{host}[:@var{port}]}. @var{proto} is either @samp{UDP}, @samp{TCP}, or @samp{HTTP}, and @var{port} is the port to talk to. Default value for @var{proto} is @samp{UDP} and for @var{port} whatever @samp{kerberos-iv} is defined to be in @file{/etc/services} or @@ -145,6 +147,14 @@ server), and then @samp{kerberos-1.@var{REALM}}, @samp{kerberos-2.@var{REALM}}, and so on. @end enumerate +SRV records have been supported in BIND since 4.9.5T2A. An example +would look like the following in the zone file: + +@example +kerberos-iv.udp.foo.se. 1M IN SRV 1 0 750 kerberos-1.foo.se. +kerberos-iv.udp.foo.se. 1M IN SRV 0 0 750 kerberos.foo.se. +@end example + We strongly recommend that you add a CNAME @samp{kerberos.@var{REALM}} pointing to your kerberos master server. @@ -190,31 +200,43 @@ beginning with a hash (#) are ignored. The currently defined variables are: @table @samp -@item krb4_proxy -@cindex krb4_proxy -When getting tickets via HTTP, this specifies the proxy to use. The -default is to speak directly to the KDC. -@item kdc_time_sync -@cindex kdc_time_sync +@item kdc_timeout +@cindex kdc_timeout +The time in seconds to wait for an answer from the KDC (the default is 4 +seconds). +@item kdc_timesync +@cindex kdc_timesync This flag enables storing of the time differential to the KDC when getting an initial ticket. This differential is used later on to compute the correct time. This can help if your machine doesn't have a working clock. -@item kdc_timeout -@cindex kdc_timeout -This allows you to change the default (4 seconds) timeout when talking -to the KDC. +@item firewall_address +@cindex firewall_address +The IP address that hosts outside the firewall see when connecting from +within the firewall. If this is specified, the code will try to compute +the value for @samp{reverse_lsb_test}. +@item krb4_proxy +@cindex krb4_proxy +When getting tickets via HTTP, this specifies the proxy to use. The +default is to speak directly to the KDC. +@item krb_default_tkt_root +@cindex krb_default_tkt_root +The default prefix for ticket files. The default is @file{/tmp/tkt}. +Normally the uid or tty is appended to this prefix. +@item krb_default_keyfile +@cindex krb_default_keyfile +The file where the server keys are stored, the default is @file{/etc/srvtab}. +@item nat_in_use +@cindex nat_in_use +If the client is behind a Network Address Translator (NAT). +@cindex Network Address Translator +@cindex NAT @item reverse_lsb_test @cindex reverse_lsb_test Reverses the test used by @code{krb_mk_safe}, @code{krb_rd_safe}, @code{krb_mk_priv}, and @code{krb_rd_priv} to compute the ordering of the communicating hosts. This test can cause truble when using firewalls. -@item firewall_address -@cindex firewall_address -The IP address that hosts outside the firewall see when connecting from -within the firewall. If this is specified, the code will try to compute -the value for @samp{reverse_lsb_test}. @end table @node Install the /etc/services, Install the kerberos server, Install the configuration files, How to set up the kerberos server @@ -242,12 +264,15 @@ for the realm @samp{FOO.SE} on a machine called @samp{hemlig.foo.se}. @subsection Setup the server Login as root on the console of the kerberos server. Add -@file{/usr/athena/bin} and @file{/usr/athena/sbin} to your path. Run +@file{/usr/athena/bin} and @file{/usr/athena/sbin} to your path. Create +the directory @file{/var/kerberos} (@kbd{mkdir /var/kerberos}), which is +where the database will be stored. Then, to create the database, run @kbd{kdb_init}: @pindex kdb_init @example @cartouche +hemlig# mkdir /var/kerberos hemlig# kdb_init Realm name [default FOO.SE ]: You will be prompted for the database Master Password. @@ -366,6 +391,8 @@ Principal name: <> @code{kdb_edit} will loop until you hit the @kbd{return} key at the ``Principal name'' prompt. Now you have added nisse as an administrator. +@page + @node Start the server, Try to get tickets, Add a few important principals, How to set up the kerberos server @subsection Start the server @@ -470,7 +497,7 @@ Use the @code{kadmin} client to add users to the database: @example @cartouche -hemlig# kadmin -u nisse.admin -m +hemlig# kadmin -p nisse.admin -m Welcome to the Kerberos Administration Program, version 2 Type "help" if you need it. admin: <add nisse> @@ -669,11 +696,34 @@ the kerberos server, every service needs to have a shared key with the kerberos server. The service keys are stored in a file, usually called @file{/etc/srvtab}. This file should not be readable to anyone but root, in order to keep the key from being divulged. The name of this principal -in the kerberos database is usually the service and the host. The key -for the pop service is called @samp{pop.@var{hostname}}. The one for -rsh/rlogin/telnet is named @samp{rcmd.@var{hostname}}. (rcmd comes from -``remote command''). To create these keys you will use the the -@code{ksrvutil} program. Perform the +in the kerberos database is usually the service name and the hostname. Examples +of such principals are @samp{pop.@var{hostname}} and +@samp{rcmd.@var{hostname}}. (rcmd comes from ``remote command''.) Here +is a list of the most commonly used srvtab types and what programs use them. + +@table @asis +@item rcmd.@var{hostname} +rsh, rcp, rlogin, telnet, kauth, su, kx +@item rcmd.kerberos +kprop +@item pop.@var{hostname} +popper, movemail, push +@item sample.@var{hostname} +sample_server, simple_server +@item changepw.kerberos +kadmin, kpasswd +@item krbtgt.@var{realm} +kerberos (not stored in any srvtab) +@item ftp.@var{hostname} +ftp (also tries with rcmd.@var{hostname}) +@item zephyr.zephyr +Zephyr +@item afs or afs.@var{cellname} +Andrew File System +@end table + +To create these keys you will use the the @code{ksrvutil} program. +Perform the @pindex ksrvutil following: @@ -733,9 +783,7 @@ master server fails. It is possible to have any number of such slave servers but more than three usually doesn't buy much more redundancy. First select a good server machine. (@pxref{Choose a kerberos -server}). Since the master and slave servers will use copies of the same -database, they need to use the same master key. Add the master key on -the slave with @code{kstash}. (@pxref{Set up the server}) +server}). On the master, add a @samp{rcmd.kerberos} (note, it should be literally ``kerberos'') principal (using @samp{ksrvutil get}). The @@ -760,8 +808,13 @@ that contains the hostnames of your kerberos slave servers. Start @code{kpropd} with @samp{kpropd -i} on your slave servers. -On your master server, create a dump of the database with @samp{kdb_util -slave_dump /var/kerberos/slave_dump}, and then run @code{kprop}. +On your master server, create a dump of the database and then propagate +it. + +@example +foo# kdb_util slave_dump /var/kerberos/slave_dump +foo# kprop +@end example You should now have copies of the database on your slave servers. You can verify this by issuing @samp{kdb_util dump @var{file}} on your @@ -771,6 +824,10 @@ server. Note that the entries will not be in the same order. This procedure should be automated with a script run regularly by cron, for instance once an hour. +Since the master and slave servers will use copies of the same +database, they need to use the same master key. Add the master key on +the slave with @code{kstash}. (@pxref{Set up the server}) + To start the kerberos server on slaves, you first have to copy the master key from the master server. You can do this either by remembering the master password and issuing @samp{kstash}, or you can just copy the @@ -815,6 +872,8 @@ principals should be @samp{krbtgt.OTHER.REALM} in @samp{MY.REALM}, and principals should have the same key (and key version number). Remember to transfer this key in a safe manner. This is all that is required. +@page + @example @cartouche blubb$ klist |
