diff options
Diffstat (limited to 'kerberosIV/doc/setup.texi')
| -rw-r--r-- | kerberosIV/doc/setup.texi | 809 |
1 files changed, 0 insertions, 809 deletions
diff --git a/kerberosIV/doc/setup.texi b/kerberosIV/doc/setup.texi deleted file mode 100644 index eea758303c9..00000000000 --- a/kerberosIV/doc/setup.texi +++ /dev/null @@ -1,809 +0,0 @@ -@node How to set up a realm, One-Time Passwords, What is Kerberos?, Top -@chapter How to set up a realm - -@quotation -@flushleft - Who willed you? or whose will stands but mine? - There's none protector of the realm but I. - Break up the gates, I'll be your warrantize. - Shall I be flouted thus by dunghill grooms? - --- King Henry VI, 6.1 -@end flushleft -@end quotation - -@menu -* How to set up the kerberos server:: -* Install the client programs:: -* Install the kerberised services:: -* Install a slave kerberos server:: -* Cross-realm functionality :: -@end menu - -@node How to set up the kerberos server, Install the client programs, How to set up a realm, How to set up a realm -@section How to set up the kerberos server - -@menu -* Choose a realm name:: -* Choose a kerberos server:: -* Install the configuration files:: -* Install the /etc/services:: -* Install the kerberos server:: -* Set up the server:: -* Add a few important principals:: -* Start the server:: -* Try to get tickets:: -* Create initial ACL for the admin server:: -* Start the admin server:: -* Add users to the database:: -* Automate the startup of the servers:: -@end menu - -@node Choose a realm name, Choose a kerberos server, How to set up the kerberos server, How to set up the kerberos server -@subsection Choose a realm name - -A -@cindex realm -realm is an administrative domain. Kerberos realms are usually -written in uppercase and consist of a Internet domain -name@footnote{Using lowercase characters in the realm name might break -in mysterious ways. This really should have been fixed, but has not.}. -Call your realm the same as your Internet domain name if you do not have -strong reasons for not doing so. It will make life easier for you and -everyone else. - -@node Choose a kerberos server, Install the configuration files, Choose a realm name, How to set up the kerberos server -@subsection Choose a kerberos server - -You need to choose a machine to run the -@pindex kerberos -kerberos server program. If the kerberos database residing on this host -is compromised, your entire realm will be compromised. Therefore, this -machine must be as secure as possible. Preferably it should not run any -services other than Kerberos. The secure-minded administrator might -only allow logins on the console. - -This machine has also to be reliable. If it is down, you will not be -able to use any kerberised services unless you have also configured a -slave server (@pxref{Install a slave kerberos server}) - -Running the kerberos server requires very little CPU power and a small -amount of disk. An old PC with some hundreds of megabytes of free disk -space should do fine. Most of the disk space will be used for various -logs. - -@node Install the configuration files, Install the /etc/services, Choose a kerberos server, How to set up the kerberos server -@subsection Install the configuration files - -There are two important configuration files: @file{/etc/kerberosIV/krb.conf} and -@file{/etc/kerberosIV/krb.realms}. -@pindex krb.conf -@pindex krb.realms - -The @file{krb.conf} file determines which machines are servers for -different realms. The format of this file is: - -@example -THIS.REALM -THIS.REALM kerberos.this.realm admin server -THIS.REALM kerberos-1.this.realm -ANOTHER.REALM kerberos.another.realm -@end example - -The first line defines the name of the local realm. Line two defines the -name of the master kerberos server and the database administration -server for this realm. You can define any number of kerberos slave -servers similar to the one defined in line three. The clients will try -to contact the servers in the order they are defined in @file{krb.conf}. - -To disable kerberos on your system place a '#'-sign as the first character -on the first line in @file{/etc/kerberosIV/krb.conf}. This will disable any -kerberos authentication on your system. - -The @samp{admin server} clause at the first entry states that this is -the master server -@cindex master server -(the one to contact when modifying the database, such as changing -passwords). There should be only one such entry for each realm. - -In the original MIT Kerberos 4 (as in most others), the server -specification could only take the form of a host-name. To facilitate -having kerberos servers in odd places (such as behind a firewall), -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{udp} or @samp{tcp}, 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 750 if -undefined. - -You can also talk HTTP with your KDC, in that case you specify an URL, -like @samp{http://@var{host}[:@var{port}]}. If you for some reason need -to use a HTTP proxy, you can specify the proxy in the @samp{krb4_proxy} -environment variable, also in URL format. The default for port in this -case is 80. - -If the information about a realm is missing from the @file{krb.conf} -file, or if the information is wrong, the following methods will be -tried in order. - -@enumerate -@item -If you have an SRV-record (@cite{RFC 2052}) for your realm it will be -used. This record should be of the form -@samp{kerberos-iv.@var{protocol}.@var{REALM}}, where @var{proto} is -either @samp{udp} or @samp{tcp}. (Note: the current implementation does -not look at priority or weight when deciding which server to talk to.) -@item -If there isn't any SRV-record, it tries to find a TXT-record for the -same domain. The contents of the record should have the same format as the -host specification in @file{krb.conf}. (Note: this is a temporary -solution if your name server doesn't support SRV records. The clients -should work fine with SRV records, so if your name server supports them, -they are very much preferred.) -@item -If no valid kerberos server is found, it will try to talk udp to the -service @samp{kerberos-iv} with fall-back to port 750 with -@samp{kerberos.@var{REALM}} (which is also assumed to be the master -server), and then @samp{kerberos-1.@var{REALM}}, -@samp{kerberos-2.@var{REALM}}, and so on. -@end enumerate - -We strongly recommend that you add a CNAME @samp{kerberos.@var{REALM}} -pointing to your kerberos master server. - -The @file{krb.realms} file is used to find out what realm a particular -host belongs to. An example of this file could look like: - -@example -this.realm THIS.REALM -.this.realm THIS.REALM -foo.com SOME.OTHER.REALM -www.foo.com A.STRANGE.REALM -.foo.com FOO.REALM -@end example - -Entries starting with a dot are taken as the name of a domain. Entries -not starting with a dot are taken as a host-name. The first entry matched -is used. The entry for @samp{this.realm} is only necessary if there is a -host named @samp{this.realm}. - -If no matching realm is found in @file{krb.realms}, DNS is searched for -the correct realm. For example, if we are looking for host @samp{a.b.c}, -@samp{krb4-realm.a.b.c} is first tried and then @samp{krb4-realm.b.c} -and so on. The entry should be a TXT record containing the name of the -realm, such as: - -@example -krb4-realm.pdc.kth.se. 7200 TXT "NADA.KTH.SE" -@end example - -If this didn't help the domain name sans the first part in uppercase is -tried. - -The plain vanilla version of Kerberos doesn't have any fancy methods of -getting realms and servers so it is generally a good idea to keep -@file{krb.conf} and @file{krb.realms} up to date. - -@node Install the /etc/services, Install the kerberos server, Install the configuration files, How to set up the kerberos server -@subsection Updating /etc/services - -(Obsolete in OpenBSD) - -You should append or merge the contents of @file{services.append} to -your @file{/etc/services} files or NIS-map. Remove any unused factory -installed kerberos port definitions to avoid possible conflicts. -@pindex services - -Most of the programs will fall back to the default ports if the port -numbers are not found in @file{/etc/services}, but it is convenient to -have them there anyway. - -@node Install the kerberos server, Set up the server, Install the /etc/services, How to set up the kerberos server -@subsection Install the kerberos server - -You should have already chosen the machine where you want to run the -kerberos server and the realm name. The machine should also be as -secure as possible (@pxref{Choose a kerberos server}) before installing -the kerberos server. In this example, we will install a kerberos server -for the realm @samp{FOO.SE} on a machine called @samp{hemlig.foo.se}. - -@node Set up the server, Add a few important principals, Install the kerberos server, How to set up the kerberos server -@subsection Setup the server - -Login as root on the console of the kerberos server. Run -@kbd{kdb_init}: -@pindex kdb_init - -@example -@cartouche -hemlig# kdb_init -Realm name [default FOO.SE ]: -You will be prompted for the database Master Password. -It is important that you NOT FORGET this password. - -Enter Kerberos master password: -Verifying password -Enter Kerberos master password: -@end cartouche -@end example - -If you have set up the configuration files correctly, @kbd{kdb_init} -should choose the correct realm as the default, otherwise a (good) guess -is made. Enter the master password. - -This password will only be used for encrypting the kerberos database on -disk and for generating new random keys. You will not have to remember -it, only to type it again when you run @kbd{kstash}. Choose something -long and random. Now run @kbd{kstash} using the same password: -@pindex kstash - -@example -@cartouche -hemlig# kstash - -Enter Kerberos master password: - -Current Kerberos master key version is 1. - -Master key entered. BEWARE! -Wrote master key to /etc/kerberosIV/master_key -@end cartouche -@end example - -After entering the same master password it will be saved in the file -@file{/etc/kerberosIV/master_key} and the kerberos server will read it when needed. Write down -the master password and put it in a sealed envelope in a safe, you might -need it if your disk crashes or should you want to set up a slave -server. - -@code{kdb_init} initializes the database with a few entries: - -@table @samp -@item krbtgt.@var{REALM} -The key used for authenticating to the kerberos server. - -@item changepw.kerberos -The key used for authenticating to the administrative server, i.e. when -adding users, changing passwords, and so on. - -@item default -This entry is copied to new items when these are added. Enter here the -values you want new entries to have, particularly the expiry date. - -@item K.M -This is the master key and it is only used to verify that the master key -that is saved un-encrypted in @file{/etc/kerberosIV/master_key} is correct and corresponds to -this database. - -@end table - -@code{kstash} only reads the master password and writes it to -@file{/etc/kerberosIV/master_key}. This enables the kerberos server to start without you -having to enter the master password. This file (@file{/etc/kerberosIV/master_key}) is only -readable by root and resides on a ``secure'' machine. - -@node Add a few important principals, Start the server, Set up the server, How to set up the kerberos server -@subsection Add a few important principals - -Now the kerberos database has been created, containing only a few -principals. The next step is to add a few more so that you can test -that it works properly and so that you can administer your realm without -having to use the console on the kerberos server. Use @kbd{kdb_edit} -to edit the kerberos database directly on the server. -@pindex kdb_edit - -@code{kdb_edit} is intended as a bootstrapping and fall-back mechanism -for editing the database. For normal purposes, use the @code{kadmin} -program (@pxref{Add users to the database}) - -The following example shows the adding of the principal -@samp{nisse.admin} into the kerberos database. This principal is used -by @samp{nisse} when administrating the kerberos database. Later on the -normal principal for @samp{nisse} will be created. Replace @samp{nisse} -and @samp{password} with your own username and password. - -@example -@cartouche -hemlig# kdb_edit -n -Opening database... -Current Kerberos master key version is 1. - -Master key entered. BEWARE! -Previous or default values are in [brackets] , -enter return to leave the same, or new value. - -Principal name: <nisse> -Instance: <admin> - -<Not found>, Create [y] ? <> - -Principal: nisse, Instance: admin, kdc_key_ver: 1 -New Password: <password> -Verifying password -New Password: <password> - -Principal's new key version = 1 -Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? <> -Max ticket lifetime (*5 minutes) [ 255 ] ? <> -Attributes [ 0 ] ? <> -Edit O.K. -Principal name: <> -@end cartouche -@end example - -@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. - -@node Start the server, Try to get tickets, Add a few important principals, How to set up the kerberos server -@subsection Start the server - -@pindex kerberos -@example -@cartouche -hemlig# /usr/libexec/kerberos & -Kerberos server starting -Sleep forever on error -Log file is /var/log/kerberos.log -Current Kerberos master key version is 1. - -Master key entered. BEWARE! - -Current Kerberos master key version is 1 -Local realm: FOO.SE -@end cartouche -@end example - -@node Try to get tickets, Create initial ACL for the admin server, Start the server, How to set up the kerberos server -@subsection Try to get tickets - -You can now verify that these principals have been added and that the -server is working correctly. - -@pindex kinit -@example -@cartouche -hemlig# kinit -eBones International (hemlig.foo.se) -Kerberos Initialization -Kerberos name: <nisse.admin> -Password: <password> -@end cartouche -@end example - -If you do not get any error message from @code{kinit}, then everything -is working (otherwise, see @ref{Common error messages}). Use -@code{klist} to verify the tickets you acquired with @code{kinit}: - -@pindex klist -@example -@cartouche -hemlig# klist -Ticket file: /tmp/tkt0 -Principal: nisse.admin@@FOO.SE - -Issued Expires Principal -May 24 21:06:03 May 25 07:06:03 krbtgt.FOO.SE@@FOO.SE -@end cartouche -@end example - -@node Create initial ACL for the admin server, Start the admin server, Try to get tickets, How to set up the kerberos server -@subsection Create initial ACL for the admin server - -The admin server, @code{kadmind}, uses a series of files to determine who has -@pindex kadmind -the right to perform certain operations. The files are: -@file{admin_acl.add}, @file{admin_acl.get}, @file{admin_acl.del}, and -@file{admin_acl.mod}. Create these with @samp{nisse.admin@@FOO.SE} as -the contents. -@pindex admin_acl.add -@pindex admin_acl.get -@pindex admin_acl.del -@pindex admin_acl.mod - -@example -@cartouche -hemlig# echo "nisse.admin@@FOO.SE" >> /etc/kerberosIV/admin_acl.add -hemlig# echo "nisse.admin@@FOO.SE" >> /etc/kerberosIV/admin_acl.get -hemlig# echo "nisse.admin@@FOO.SE" >> /etc/kerberosIV/admin_acl.mod -hemlig# echo "nisse.admin@@FOO.SE" >> /etc/kerberosIV/admin_acl.del -@end cartouche -@end example - -Later on you may wish to add more users with administration -privileges. Make sure that you create both the administration principals -and add them to the admin server ACL. - -@node Start the admin server, Add users to the database, Create initial ACL for the admin server, How to set up the kerberos server -@subsection Start the admin server - -@pindex kadmind -@example -@cartouche -hemlig# /usr/libexec/kadmind & -KADM Server KADM0.0A initializing -Please do not use 'kill -9' to kill this job, use a -regular kill instead - -Current Kerberos master key version is 1. - -Master key entered. BEWARE! -@end cartouche -@end example - -@node Add users to the database, Automate the startup of the servers, Start the admin server, How to set up the kerberos server -@subsection Add users to the database - -Use the @code{kadmin} client to add users to the database: -@pindex kadmin - -@example -@cartouche -hemlig# kadmin -u nisse.admin -m -Welcome to the Kerberos Administration Program, version 2 -Type "help" if you need it. -admin: <add nisse> -Admin password: <nisse.admin's password> -Maximum ticket lifetime? (255) [Forever] -Attributes? [0x00] -Expiration date (enter yyyy-mm-dd) ? [Sat Jan 1 05:59:00 2000] -Password for nisse: -Verifying password Password for nisse: -nisse added to database. -@end cartouche -@end example - -Add whatever other users you want to have in the same way. Verify that -a user is in the database and check the database entry for that user: - -@example -@cartouche -admin: <get nisse> -Info in Database for nisse.: -Max Life: 255 (Forever) Exp Date: Sat Jan 1 05:59:59 2000 - -Attribs: 00 key: 0 0 -admin: <^D> -Cleaning up and exiting. -@end cartouche -@end example - -@node Automate the startup of the servers, , Add users to the database, How to set up the kerberos server -@subsection Automate the startup of the servers - -Add the lines that were used to start the kerberos server and the -admin server to your startup scripts (@file{/etc/rc} or similar). -@pindex rc - -@node Install the client programs, Install the kerberised services, How to set up the kerberos server, How to set up a realm -@section Install the client programs - -(Obsolete in OpenBSD) - -Making a machine a kerberos client only requires a few steps. First you -might need to change the configuration files as with the kerberos -server. (@xref{Install the configuration files}, and @pxref{Install the -/etc/services}) Also you need to make the programs in -@file{/usr/athena/bin} available. This can be done by adding the -@file{/usr/athena/bin} directory to the users' paths, by making symbolic -links, or even by copying the programs. - -You should also verify that the local time on the client is synchronised -with the time on the kerberos server by some means. The maximum allowed -time difference between the participating servers and a client is 5 -minutes. -@cindex NTP. -One good way to synchronize the time is NTP (Network Time Protocol), see -@url{http://www.eecis.udel.edu/~ntp/}. - -If you need to run the client programs on a machine where you do not -have root-access, you can hopefully just use the binaries and no -configuration will be needed. The heuristics used are mentioned above -(see @ref{Install the configuration files}). If this is not the case -and you need to have @file{krb.conf} and/or @file{krb.realms}, you can -copy them into a directory of your choice and -@pindex krb.conf -@pindex krb.realms -set the environment variable @var{KRBCONFDIR} to point at this -@cindex KRBCONFDIR -directory. - -To test the client functionality, run the @code{kinit} program: - -@example -@cartouche -foo$ kinit -eBones International (foo.foo.se) -Kerberos Initialization -Kerberos name: <nisse> -Password: <password> - -foo$ klist -Ticket file: /tmp/tkt4711 -Principal: nisse@@FOO.SE - -Issued Expires Principal -May 24 21:06:03 May 25 07:06:03 krbtgt.FOO.SE@@FOO.SE -@end cartouche -@end example - -@node Install the kerberised services, Install a slave kerberos server, Install the client programs, How to set up a realm -@section Install the kerberised services - -(Obsolete in OpenBSD) - -These includes @code{rsh}, @code{rlogin}, @code{telnet}, @code{ftp}, -@code{rxtelnet}, and so on. -@pindex rsh -@pindex rlogin -@pindex telnet -@pindex ftp -@pindex rxtelnet - -First follow the steps mentioned in the prior section to make it a -client and verify its operation. Change @file{inetd.conf} next to use -the new daemons. Look at the file -@pindex inetd.conf -@file{etc/inetd.conf.changes} to see the changes that we recommend you -perform on @file{inetd.conf}. - -You should at this point decide what services you want to run on -each machine. - -@subsection rsh, rlogin, and rcp -@pindex rsh -@pindex rlogin -@pindex rcp - -These exist in kerberised versions and ``old-style'' versions. The -different versions use different port numbers, so you can choose none, -one, or both. If you do not want to use ``old-style'' r* services, you -can let the programs output the text ``Remote host requires Kerberos -authentication'' instead of just refusing connections to that port. -This is enabled with the @samp{-v} option. The kerberised services -exist in encrypted and non-encrypted versions. The encrypted services -have an ``e'' prepended to the name and the programs take @samp{-x} as an -option indicating encryption. - -Our recommendation is to only use the kerberised services and give -explanation messages for the old ports. - -@subsection telnet -@pindex telnet - -The telnet service always uses the same port and negotiates as to which -authentication method should be used. The @code{telnetd} program has -@pindex telnetd -an option ``-a user'' that only allows kerberised and authenticated -connections. If this is not included, it falls back to using clear text -passwords. For obvious reasons, we recommend that you enable this -option. If you want to use one-time passwords (@pxref{One-Time -Passwords}) you can use the ``-a otp'' option which will allow OTPs or -kerberised connections. - -@subsection ftp -@pindex ftp - -The ftp service works as telnet does, with just one port being used. By -default only kerberos authenticated connections are allowed. You can -specify additional levels that are thus allowed with these options: - -@table @asis -@item @kbd{-a otp} -Allow one-time passwords (@pxref{One-Time Passwords}) -@item @kbd{-a ftp} -Allow anonymous login (as user ``ftp'' or ``anonymous''). -@item @kbd{-a safe} -The same as @kbd{-a ftp}, for backwards compatibility. -@item @kbd{-a plain} -Allow clear-text passwords. -@item @kbd{-a none} -The same as @kbd{-a ftp -a plain}. -@item @kbd{-a user} -A no-op, also there for backwards compatibility reasons. -@end table - -When running anonymous ftp you should read the man page on @code{ftpd} -which explains how to set it up. - -@subsection pop -@pindex popper - -The Post Office Protocol (POP) is used to retrieve mail from the mail -hub. The @code{popper} program implements the standard POP3 protocol -and the kerberised KPOP. Use the @samp{-k} option to run the kerberos -version of the protocol. This service should only be run on your mail -hub. - -@subsection kx -@pindex kx - -@code{kx} allows you to run X over a kerberos-authenticated and -encrypted connection. This program is used by @code{rxtelnet}, -@code{tenletxr}, and @code{rxterm}. - -If you have some strange kind of operating system with X libraries that -do not allow you to use unix-sockets, you need to specify the @samp{-t} -@pindex kxd -option to @code{kxd}. Otherwise it should be sufficient by adding the -daemon in @file{inetd.conf}. - -@subsection kauth -@pindex kauth - -This service allows you to create tickets on a remote host. To -enable it just insert the corresponding line in @file{inetd.conf}. - -@section srvtabs -@pindex srvtab - -In the same way every user needs to have a password registered with -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/kerberosIV/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 -@pindex ksrvutil -following: - -@example -@cartouche -bar# ksrvutil -p nisse.admin get -Name [rcmd]: <> -Instance [bar]: <> -Realm [FOO.SE]: <> -Is this correct? (y,n) [y] <> -Add more keys? (y,n) [n] <> -Password for nisse.admin@@FOO.SE: <nisse.admin's password> -Written rcmd.bar -rcmd.bar@@FOO.SE -Old keyfile in /etc/srvtab.old. -@end cartouche -@end example - -@subsection Complete test of the kerberised services - -Obtain a ticket on one machine (@samp{foo}) and use it to login with a -kerberised service to a second machine (@samp{bar}). The test should -look like this if successful: - -@example -@cartouche -foo$ kinit nisse -eBones International (foo.foo.se) -Kerberos Initialization for "nisse" -Password: <nisse's password> -foo$ klist -Ticket file: /tmp/tkt4711 -Principal: nisse@@FOO.SE - -Issued Expires Principal -May 30 13:48:03 May 30 23:48:03 krbtgt.FOO.SE@@FOO.SE -foo$ telnet bar -Trying 17.17.17.17... -Connected to bar.foo.se -Escape character is '^]'. -[ Trying mutual KERBEROS4 ... ] -[ Kerberos V4 accepts you ] -[ Kerberos V4 challenge successful ] -bar$ -@end cartouche -@end example - -You can also try with @code{rsh}, @code{rcp}, @code{rlogin}, -@code{rlogin -x}, and some other commands to see that everything is -working all right. - -@node Install a slave kerberos server, Cross-realm functionality , Install the kerberised services, How to set up a realm -@section Install a slave kerberos server - -It is desirable to have at least one backup (slave) server in case the -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. @xref{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. - -On the master, add a @samp{rcmd.kerberos} principal (using -@samp{ksrvutil get}). The -@pindex kprop -@code{kprop} program, running on the master, will use this when -authenticating to the -@pindex kpropd -@code{kpropd} daemons running on the slave servers. - -On your master server, create a file, e.g. @file{/etc/kerberosIV/slaves}, -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 /etc/kerberosIV/slave_dump}, and then run @code{kprop}. - -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 -slave servers, and comparing with the original file on the master -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. - -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 -keyfile. Remember that if you copy the file, do so on a safe media, not -over the network. Good means include floppy or paper. Paper is better, -since it is easier to swallow afterwards. - -The kerberos server should be started with @samp{-s} on the slave -servers. This enables sanity checks, for example checking the time since -the last update from the master. - -All changes to the database are made by @code{kadmind} at the master, -and then propagated to the slaves, so you should @strong{not} run -@code{kadmind} on the slaves. - -Finally add the slave servers to -@file{/etc/kerberosIV/krb.conf}. The clients will ask the servers in the order -specified by that file. - -Consider adding CNAMEs to your slave servers, see @ref{Install the -configuration files}. - -@node Cross-realm functionality , , Install a slave kerberos server, How to set up a realm -@section Cross-realm functionality - -Suppose you are residing in the realm @samp{MY.REALM}, how do you -authenticate to a server in @samp{OTHER.REALM}? Having valid tickets in -@samp{MY.REALM} allows you to communicate with kerberised services in that -realm. However, the computer in the other realm does not have a secret -key shared with the kerberos server in your realm. - -It is possible to add a shared key between two realms that trust each -other. When a client program, such as @code{telnet}, finds that the -other computer is in a different realm, it will try to get a ticket -granting ticket for that other realm, but from the local kerberos -server. With that ticket granting ticket, it will then obtain service -tickets from the kerberos server in the other realm. - -To add this functionality you have to add a principal to each realm. The -principals should be @samp{krbtgt.OTHER.REALM} in @samp{MY.REALM}, and -@samp{krbtgt.MY.REALM} in @samp{OTHER.REALM}. The two different -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. - -@example -@cartouche -blubb$ klist -Ticket file: /tmp/tkt3008 -Principal: joda@@NADA.KTH.SE - - Issued Expires Principal -Jun 7 02:26:23 Jun 7 12:26:23 krbtgt.NADA.KTH.SE@@NADA.KTH.SE -blubb$ telnet agat.e.kth.se -Trying 130.237.48.12... -Connected to agat.e.kth.se. -Escape character is '^]'. -[ Trying mutual KERBEROS4 ... ] -[ Kerberos V4 accepts you ] -[ Kerberos V4 challenge successful ] -Last login: Sun Jun 2 20:51:50 from emma.pdc.kth.se - -agat$ exit -Connection closed by foreign host. -blubb$ klist -Ticket file: /tmp/tkt3008 -Principal: joda@@NADA.KTH.SE - - Issued Expires Principal -Jun 7 02:26:23 Jun 7 12:26:23 krbtgt.NADA.KTH.SE@@NADA.KTH.SE -Jun 7 02:26:50 Jun 7 12:26:50 krbtgt.E.KTH.SE@@NADA.KTH.SE -Jun 7 02:26:51 Jun 7 12:26:51 rcmd.agat@@E.KTH.SE -@end cartouche -@end example |