diff options
| author |   hin <hin@openbsd.org> | 2000-07-19 18:54:52 +0000 |
|---|---|---|
| committer | hin <hin@openbsd.org> | 2000-07-19 18:54:52 +0000 |
| commit | a586533f88f76f6aa377846ec06eac1fe903e528 (patch) | |
| tree | 22a3216868adf0090cf1c97b12b9ceea6125b9c6 | |
| parent | OTP has never been supported in our kerberos implementation, and noone seems (diff) | |
| download | wireguard-openbsd-a586533f88f76f6aa377846ec06eac1fe903e528.tar.xz wireguard-openbsd-a586533f88f76f6aa377846ec06eac1fe903e528.zip | |
This file is no longer up to date; its sources has changed.
| -rw-r--r-- | kerberosIV/src/doc/kth-krb.info | 2253 |
1 files changed, 0 insertions, 2253 deletions
diff --git a/kerberosIV/src/doc/kth-krb.info b/kerberosIV/src/doc/kth-krb.info deleted file mode 100644 index 5c92af770fa..00000000000 --- a/kerberosIV/src/doc/kth-krb.info +++ /dev/null @@ -1,2253 +0,0 @@ -This is kth-krb.info, produced by makeinfo version 4.0 from -kth-krb.texi. - -INFO-DIR-SECTION Kerberos -START-INFO-DIR-ENTRY -* Kth-krb: (kth-krb). The Kerberos IV distribution from KTH -END-INFO-DIR-ENTRY - - -File: kth-krb.info, Node: Top, Next: Introduction, Prev: (dir), Up: (dir) - -KTH-krb -******* - -* Menu: - -* Introduction:: -* What is Kerberos?:: -* Installing programs:: -* How to set up a realm:: -* One-Time Passwords:: -* Resolving frequent problems:: -* Acknowledgments:: -* Index:: - - --- The Detailed Node Listing --- - -Installing programs - -* Installing from source:: -* Installing a binary distribution:: -* Finishing the installation:: -* Authentication modules:: - -Finishing the installation - -* Authentication modules:: - -Authentication modules - -* Digital SIA:: -* IRIX:: -* PAM:: - -How to set up a realm - -* How to set up the kerberos server:: -* Install the client programs:: -* Install the kerberised services:: -* Install a slave kerberos server:: -* Cross-realm functionality :: - -How to set up the kerberos server - -* 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:: - -One-Time Passwords - -* What are one time passwords?:: -* When to use one time passwords?:: -* Configuring OTPs:: - -Resolving frequent problems - -* Problems compiling Kerberos:: -* Problems with firewalls:: -* Common error messages:: -* Is Kerberos year 2000 safe?:: - - -File: kth-krb.info, Node: Introduction, Next: What is Kerberos?, Prev: Top, Up: Top - -Introduction -************ - -This is an attempt at documenting the Kerberos 4 distribution from -Kungliga Tekniska Högskolan (the Royal Institute of Technology in -Stockholm, Sweden). This distribution is based on eBones, but has been -improved in many ways. It is more portable, and several new features -have been added. It should run on any reasonably modern unix-like -system. - -In addition, some part compile and work on: - - * OS/2 with EMX - - * Windows 95/NT with gnu-win32 (with the proper amount of magic the - libraries should compile with Microsoft C as well) - -It should work on anything that is almost POSIX, has an ANSI C -compiler, a dbm library (for the server side), and BSD Sockets. - -A web-page is available at <http://www.pdc.kth.se/kth-krb/>. - -Bug reports -=========== - -If you cannot build the programs or they do not behave as you think they -should, please send us a bug report. The bug report should be sent to -`<kth-krb-bugs@pdc.kth.se>'. Please include information on what -machine and operating system (including version) you are running, what -you are trying to do, what happens, what you think should have happened, -an example for us to repeat, the output you get when trying the example, -and a patch for the problem if you have one. Please make any patches -with `diff -u' or `diff -c'. The more detailed the bug report is, the -easier it will be for us to reproduce, understand, and fix it. - -Suggestions, comments and other non bug reports are welcome. Send them -to `<kth-krb@pdc.kth.se>'. - - -File: kth-krb.info, Node: What is Kerberos?, Next: Installing programs, Prev: Introduction, Up: Top - -What is Kerberos? -***************** - - Now this Cerberus had three heads of dogs, - the tail of a dragon, and on his back the - heads of all sorts of snakes. - -- Pseudo-Apollodorus Library 2.5.12 - -Kerberos is a system for authenticating users and services on a network. -It is built upon the assumption that the network is "unsafe". For -example, data sent over the network can be eavesdropped and altered, and -addresses can also be faked. Therefore they cannot be used for -authentication purposes. - -Kerberos is a trusted third-party service. That means that there is a -third party (the kerberos server) that is trusted by all the entities on -the network (users and services, usually called "principals"). All -principals share a secret password (or key) with the kerberos server and -this enables principals to verify that the messages from the kerberos -server are authentic. Thus trusting the kerberos server, users and -services can authenticate each other. - -Basic mechanism -=============== - -In Kerberos, principals use "tickets" to prove that they are who they -claim to be. In the following example, A is the initiator of the -authentication exchange, usually a user, and B is the service that A -wishes to use. - -To obtain a ticket for a specific service, A sends a ticket request to -the kerberos server. The request basically contains A's and B's names. -The kerberos server checks that both A and B are valid principals. - -Having verified the validity of the principals, it creates a packet -containing A's and B's names, A's network address (A<ADDR>), the -current time (T<ISSUE>), the lifetime of the ticket (LIFE), and a -secret "session key" (K<AB>). This packet is encrypted with B's secret -key (K<B>). The actual ticket (T<AB>) looks like this: ({A, B, -A<ADDR>, T<ISSUE>, LIFE, K<AB>}K<B>). - -The reply to A consists of the ticket (T<AB>), B's name, the current -time, the lifetime of the ticket, and the session key, all encrypted in -A's secret key ({B, T<ISSUE>, LIFE, K<AB>, T<AB>}K<A>). A decrypts the -reply and retains it for later use. - - -Before sending a message to B, A creates an authenticator consisting of -A's name, A's address, the current time, and a "checksum" chosen by A, -all encrypted with the secret session key ({A, A<ADDR>, T<CURRENT>, -CHECKSUM}K<AB>). This is sent together with the ticket received from -the kerberos server to B. Upon reception, B decrypts the ticket using -B's secret key. Since the ticket contains the session key that the -authenticator was encrypted with, B can now also decrypt the -authenticator. To verify that A really is A, B now has to compare the -contents of the ticket with that of the authenticator. If everything -matches, B now considers A as properly authenticated. - -Different attacks -================= - -Impersonating A ---------------- - -An impostor, C could steal the authenticator and the ticket as it is -transmitted across the network, and use them to impersonate A. The -address in the ticket and the authenticator was added to make it more -difficult to perform this attack. To succeed C will have to either use -the same machine as A or fake the source addresses of the packets. By -including the time stamp in the authenticator, C does not have much -time in which to mount the attack. - -Impersonating B ---------------- - -C can masquerade B's network address, and when A sends her credentials, -C just pretend to verify them. C can't be sure that she is talking to A. - -Defense strategies -================== - -It would be possible to add a "replay cache" to the server side. The -idea is to save the authenticators sent during the last few minutes, so -that B can detect when someone is trying to retransmit an already used -message. This is somewhat impractical (mostly regarding efficiency), -and is not part of Kerberos 4; MIT Kerberos 5 contains it. - -To authenticate B, A might request that B sends something back that -proves that B has access to the session key. An example of this is the -checksum that A sent as part of the authenticator. One typical -procedure is to add one to the checksum, encrypt it with the session -key and send it back to A. This is called "mutual authentication". - -The session key can also be used to add cryptographic checksums to the -messages sent between A and B (known as "message integrity"). -Encryption can also be added ("message confidentiality"). This is -probably the best approach in all cases. - -Further reading -=============== - -The original paper on Kerberos from 1988 is `Kerberos: An -Authentication Service for Open Network Systems', by Jennifer Steiner, -Clifford Neuman and Jeffrey I. Schiller. - -A less technical description can be found in `Designing an -Authentication System: a Dialogue in Four Scenes' by Bill Bryant, also -from 1988. - -These and several other documents can be found on our web-page. - - -File: kth-krb.info, Node: Installing programs, Next: How to set up a realm, Prev: What is Kerberos?, Up: Top - -Installing programs -******************* - -You have a choise to either build the distribution from source code or -to install binaries, if they are available for your machine. - -We recommend building from sources, but using pre-compiled binaries -might be easier. If there are no binaries available for your machine or -you want to do some specific configuration, you will have to compile -from source. - -* Menu: - -* Installing from source:: -* Installing a binary distribution:: -* Finishing the installation:: -* .klogin:: -* Authentication modules:: - - -File: kth-krb.info, Node: Installing from source, Next: Installing a binary distribution, Prev: Installing programs, Up: Installing programs - -Installing from source -====================== - -To build this software un-tar the distribution and run the `configure' -script. - -To compile successfully, you will need an ANSI C compiler, such as -`gcc'. Other compilers might also work, but setting the "ANSI -compliance" too high, might break in parts of the code, not to mention -the standard include files. - -To build in a separate build tree, run `configure' in the directory -where the tree should reside. You will need a Make that understands -VPATH correctly. GNU Make works fine. - -After building everything (which will take anywhere from a few minutes -to a long time), you can install everything in `/usr/athena' with `make -install' (running as root). It is possible to install in some other -place, but it isn't recommended. To do this you will have to run -`configure' with `--prefix=/my/path'. - -If you need to change the default behavior, configure understands the -following options: - -`--enable-shared' - Create shared versions of the Kerberos libraries. Not really - recommended and might not work on all systems. - -`--with-ld-flags='FLAGS - This allows you to specify which extra flags to pass to `ld'. Since - this _overrides_ any choices made by configure, you should only use - this if you know what you are doing. - -`--with-cracklib='DIR - Use cracklib for password quality control in `kadmind'. This - option requires cracklib with the patch from - <ftp://ftp.pdc.kth.se/pub/krb/src/cracklib.patch>. - -`--with-dictpath='DICTPATH - This is the dictionary that cracklib should use. - -`--with-socks='DIR - If you have to traverse a firewall and it uses the SocksV5 protocol - (`RFC 1928'), you can build with socks-support. Point DIR to the - directory where you have socks5 installed. For more information - about socks see <http://www.socks.nec.com/>. - -`--with-readline='DIR - To enable history/line editing in `ftp' and `kadmin', any present - version of readline will be used. If you have readline installed - but in a place where configure does not manage to find it, you can - use this option. The code also looks for `libedit'. If there is - no library at all, the bundled version of `editline' will be used. - -`--with-mailspool='DIR - The configuration process tries to determine where your machine - stores its incoming mail. This is typically `/usr/spool/mail' or - `/var/mail'. If it does not work or you store your mail in some - unusual directory, this option can be used to specify where the - mail spool directory is located. This directory is only accessed - by `popper', and the mail check in `login'. - -`--with-hesiod='DIR - Enable the Hesiod support in `push'. With this option, it will try - to use the hesiod library to locate the mail post-office for the - user. - -`--with-mkey='FILE - Put the master key here, the default is `/.k'. - -`--with-db-dir='DIR - Where the kerberos database should be stored. The default is - `/var/kerberos'. - -`--without-berkeley-db' - If you have Berkeley DB installed, it is preferred over dbm. If - you already are running Kerberos this option might be useful, - since there currently isn't an easy way to convert a dbm database - to a db one (you have to dump the old database and then load it - with the new binaries). - -`--without-afs-support' - Do not include AFS support. - -`--with-afsws='DIR - Where your AFS client installation resides. The default is - `/usr/afsws'. - -`--enable-rxkad' - Build the rxkad library. Normally automatically included if there - is AFS. - -`--disable-dynamic-afs' - The AFS support in AIX consists of a shared library that is loaded - at runtime. This option disables this, and links with static system - calls. Doing this will make the built binaries crash on a machine - that doesn't have AFS in the kernel (for instance if the AFS - module fails to load at boot). - -`--with-mips-api='API - This option enables creation of different types of binaries on - Irix. The allowed values are `32', `n32', and `64'. - -`--enable-legacy-kdestroy' - This compile-time option creates a `kdestroy' that does not destroy - any AFS tokens. - -`--disable-otp' - Do not build the OTP (*note One-Time Passwords::) library and - programs, and do not include OTP support in the application - programs. - -`--enable-match-subdomains' - Normally, the host `host.domain' will be considered to be part of - the realm `DOMAIN'. With this option will also enable hosts of the - form `host.sub.domain', `host.sub1.sub2.domain', and so on to be - considered part of the realm `DOMAIN'. - -`--enable-osfc2' - Enable the use of enhanced C2 security on OSF/1. *Note Digital - SIA::. - -`--disable-mmap' - Do not use the mmap system call. Normally, configure detects if - there is a working mmap and it is only used if there is one. Only - try this option if it fails to work anyhow. - -`--disable-cat-manpages' - Do not install preformatted man pages. - - -File: kth-krb.info, Node: Installing a binary distribution, Next: Finishing the installation, Prev: Installing from source, Up: Installing programs - -Installing a binary distribution -================================ - -The binary distribution is supposed to be installed in `/usr/athena', -installing in some other place may work but is not recommended. A -symlink from `/usr/athena' to the install directory should be fine. - - -File: kth-krb.info, Node: Finishing the installation, Next: .klogin, Prev: Installing a binary distribution, Up: Installing programs - -Finishing the installation -========================== - -The only program that needs to be installed setuid to root is `su'. - -If `rlogin' and `rsh' are setuid to root they will fall back to -non-kerberised protocols if the kerberised ones fail for some reason. -The old protocols use reserved ports as security, and therefore the -programs have to be setuid to root. If you don't need this -functionality consider turning off the setuid bit. - -`login' does not have to be setuid, as it is always run by root (users -should use `su' rather than `login'). It will print a helpful message -when not setuid to root and run by a user. - -The programs intended to be run by users are located in -`/usr/athena/bin'. Inform your users to include `/usr/athena/bin' in -their paths, or copy or symlink the binaries to some good place. The -programs that you will want to use are: `kauth'/`kinit', `klist', -`kdestroy', `kpasswd', `ftp', `telnet', `rcp', `rsh', `rlogin', `su', -`rxtelnet', `tenletxr', `rxterm', and `xnlock'. If you are using AFS, -`afslog' and `pagsh' might also be useful. Administrators will want to -use `kadmin' and `ksrvutil', which are located in `/usr/athena/sbin'. - -`telnetd' and `rlogind' assume that `login' is located in -`/usr/athena/bin' (or whatever path you used as `--prefix'). If for -some reason you want to move `login', you will have to specify the new -location with the `-L' switch when configuring telnetd and rlogind in -`inetd.conf'. - -It should be possible to replace the system's default `login' with the -kerberised `login'. However some systems assume that login performs -some serious amount of magic that our login might not do (although -we've tried to do our best). So before replacing it on every machine, -try and see what happens. Another thing to try is to use one of the -authentication modules (*note Authentication modules::) supplied. - -The `login' program that we use was in an earlier life the standard -login program from NetBSD. In order to use it with a lot of weird -systems, it has been "enhanced" with features from many other logins -(Solaris, SunOS, IRIX, AIX, and others). Some of these features are -actually useful and you might want to use them even on other systems. - -`/etc/fbtab' -`/etc/logindevperm' - Allows you to chown some devices when a user logs in on a certain - terminal. Commonly used to change the ownership of `/dev/mouse', - `/dev/kbd', and other devices when someone logs in on - `/dev/console'. - - `/etc/fbtab' is the SunOS file name and it is tried first. If - there is no such file then the Solaris file name - `/etc/logindevperm' is tried. - -`/etc/environment' - This file specifies what environment variables should be set when - a user logs in. (AIX-style) - -`/etc/default/login' - Almost the same as `/etc/environment', but the System V style. - -`/etc/login.access' - Can be used to control who is allowed to login from where and on - what ttys. (From Wietse Venema) - -* Menu: - -* .klogin:: -* Authentication modules:: - - -File: kth-krb.info, Node: .klogin, Next: Authentication modules, Prev: Finishing the installation, Up: Installing programs - -Each user can have an authorization file `~USER/.klogin' that -determines what principals can login as that user. It is similar to the -`~user/.rhosts' except that it does not use IP and privileged-port -based authentication. If this file does not exist, the user herself -`user@LOCALREALM' will be allowed to login. Supplementary local realms -(*note Install the configuration files::) also apply here. If the file -exists, it should contain the additional principals that are to be -allowed to login as the local user USER. - -This file is consulted by most of the daemons (`rlogind', `rshd', -`ftpd', `telnetd', `popper', `kauthd', and `kxd') to determine if the -principal requesting a service is allowed to receive it. It is also -used by `su', which is a good way of keeping an access control list -(ACL) on who is allowed to become root. Assuming that `~root/.klogin' -contains: - - nisse.root@FOO.SE - lisa.root@FOO.SE - -both nisse and lisa will be able to su to root by entering the password -of their root instance. If that fails or if the user is not listed in -`~root/.klogin', `su' falls back to the normal policy of who is -permitted to su. Also note that that nisse and lisa can login with -e.g. `telnet' as root provided that they have tickets for their root -instance. - - -File: kth-krb.info, Node: Authentication modules, Prev: .klogin, Up: Installing programs - -Authentication modules -====================== - -The problem of having different authentication mechanisms has been -recognised by several vendors, and several solutions has appeared. In -most cases these solutions involve some kind of shared modules that are -loaded at run-time. Modules for some of these systems can be found in -`lib/auth'. Presently there are modules for Digital's SIA, Solaris' -and Linux' PAM, and IRIX' `login' and `xdm' (in `lib/auth/afskauthlib'). - -* Menu: - -* Digital SIA:: -* IRIX:: -* PAM:: - - -File: kth-krb.info, Node: Digital SIA, Next: IRIX, Prev: Authentication modules, Up: Authentication modules - -Digital SIA ------------ - -To install the SIA module you will have to do the following: - - * Make sure `libsia_krb4.so' is available in `/usr/athena/lib'. If - `/usr/athena' is not on local disk, you might want to put it in - `/usr/shlib' or someplace else. If you do, you'll have to edit - `krb4_matrix.conf' to reflect the new location (you will also have - to do this if you installed in some other directory than - `/usr/athena'). If you built with shared libraries, you will have - to copy the shared `libkrb.so', `libdes.so', `libkadm.so', and - `libkafs.so' to a place where the loader can find them (such as - `/usr/shlib'). - - * Copy (your possibly edited) `krb4_matrix.conf' to `/etc/sia'. - - * Apply `security.patch' to `/sbin/init.d/security'. - - * Turn on KRB4 security by issuing `rcmgr set SECURITY KRB4' and - `rcmgr set KRB4_MATRIX_CONF krb4_matrix.conf'. - - * Digital thinks you should reboot your machine, but that really - shouldn't be necessary. It's usually sufficient just to run - `/sbin/init.d/security start' (and restart any applications that - use SIA, like `xdm'.) - -Users with local passwords (like `root') should be able to login safely. - -When using Digital's xdm the `KRBTKFILE' environment variable isn't -passed along as it should (since xdm zaps the environment). Instead you -have to set `KRBTKFILE' to the correct value in -`/usr/lib/X11/xdm/Xsession'. Add a line similar to - KRBTKFILE=/tmp/tkt`id -u`_`ps -o ppid= -p $$`; export KRBTKFILE -If you use CDE, `dtlogin' allows you to specify which additional -environment variables it should export. To add `KRBTKFILE' to this -list, edit `/usr/dt/config/Xconfig', and look for the definition of -`exportList'. You want to add something like: - Dtlogin.exportList: KRBTKFILE - -Notes to users with Enhanced security -..................................... - -Digital's `ENHANCED' (C2) security, and Kerberos solves two different -problems. C2 deals with local security, adds better control of who can -do what, auditing, and similar things. Kerberos deals with network -security. - -To make C2 security work with Kerberos you will have to do the -following. - - * Replace all occurencies of `krb4_matrix.conf' with - `krb4+c2_matrix.conf' in the directions above. - - * You must enable "vouching" in the `default' database. This will - make the OSFC2 module trust other SIA modules, so you can login - without giving your C2 password. To do this use `edauth' to edit - the default entry `/usr/tcb/bin/edauth -dd default', and add a - `d_accept_alternate_vouching' capability, if not already present. - - * For each user that does _not_ have a local C2 password, you should - set the password expiration field to zero. You can do this for each - user, or in the `default' table. To do this use `edauth' to set - (or change) the `u_exp' capability to `u_exp#0'. - - * You also need to be aware that the shipped `login', `rcp', and - `rshd', doesn't do any particular C2 magic (such as checking to - various forms of disabled accounts), so if you rely on those - features, you shouldn't use those programs. If you configure with - `--enable-osfc2', these programs will, however, set the login UID. - Still: use at your own risk. - -At present `su' does not accept the vouching flag, so it will not work -as expected. - -Also, kerberised ftp will not work with C2 passwords. You can solve this -by using both Digital's ftpd and our on different ports. - -*Remember*, if you do these changes you will get a system that most -certainly does _not_ fulfill the requirements of a C2 system. If C2 is -what you want, for instance if someone else is forcing you to use it, -you're out of luck. If you use enhanced security because you want a -system that is more secure than it would otherwise be, you probably got -an even more secure system. Passwords will not be sent in the clear, -for instance. - - -File: kth-krb.info, Node: IRIX, Next: PAM, Prev: Digital SIA, Up: Authentication modules - -IRIX ----- - -The IRIX support is a module that is compatible with Transarc's -`afskauthlib.so'. It should work with all programs that use this -library, this should include `login' and `xdm'. - -The interface is not very documented but it seems that you have to copy -`libkafs.so', `libkrb.so', and `libdes.so' to `/usr/lib', or build your -`afskauthlib.so' statically. - -The `afskauthlib.so' itself is able to reside in `/usr/vice/etc', -`/usr/afsws/lib', or the current directory (wherever that is). - -IRIX 6.4 and newer seems to have all programs (including `xdm' and -`login') in the N32 object format, whereas in older versions they were -O32. For it to work, the `afskauthlib.so' library has to be in the same -object format as the program that tries to load it. This might require -that you have to configure and build for O32 in addition to the default -N32. - -Appart from this it should "just work", there are no configuration -files. - - -File: kth-krb.info, Node: PAM, Prev: IRIX, Up: Authentication modules - -PAM ---- - -The PAM module was written more out of curiosity that anything else. It -has not been updated for quite a while, but it seems to mostly work on -both Linux and Solaris. - -To use this module you should: - - * Make sure `pam_krb4.so' is available in `/usr/athena/lib'. You - might actually want it on local disk, so `/lib/security' might be a - better place if `/usr/athena' is not local. - - * Look at `pam.conf.add' for examples of what to add to - `/etc/pam.conf'. - -There is currently no support for changing kerberos passwords. Use -kpasswd instead. - -See also Derrick J Brashear's `<shadow@dementia.org>' Kerberos PAM -module at -<ftp://ftp.dementia.org/pub/pam>. It has a lot more features, and it is -also more in line with other PAM modules. - - -File: kth-krb.info, Node: How to set up a realm, Next: One-Time Passwords, Prev: Installing programs, Up: Top - -How to set up a realm -********************* - - 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 - -* Menu: - -* How to set up the kerberos server:: -* Install the client programs:: -* Install the kerberised services:: -* Install a slave kerberos server:: -* Cross-realm functionality :: - - -File: kth-krb.info, Node: How to set up the kerberos server, Next: Install the client programs, Prev: How to set up a realm, Up: How to set up a realm - -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:: - - -File: kth-krb.info, Node: Choose a realm name, Next: Choose a kerberos server, Prev: How to set up the kerberos server, Up: How to set up the kerberos server - -Choose a realm name -------------------- - -A realm is an administrative domain. Kerberos realms are usually -written in uppercase and consist of a Internet domain name(1). 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. - ----------- Footnotes ---------- - -(1) Using lowercase characters in the realm name might break in -mysterious ways. This really should have been fixed, but has not. - - -File: kth-krb.info, Node: Choose a kerberos server, Next: Install the configuration files, Prev: Choose a realm name, Up: How to set up the kerberos server - -Choose a kerberos server ------------------------- - -You need to choose a machine to run the 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 (*note 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. - - -File: kth-krb.info, Node: Install the configuration files, Next: Install the /etc/services, Prev: Choose a kerberos server, Up: How to set up the kerberos server - -Install the configuration files -------------------------------- - -There are two important configuration files: `/etc/krb.conf' and -`/etc/krb.realms'. - -The `krb.conf' file determines which machines are servers for different -realms. The format of this file is: - - THIS.REALM - SUPP.LOCAL.REALM - THIS.REALM kerberos.this.realm admin server - THIS.REALM kerberos-1.this.realm - SUPP.LOCAL.REALM kerberos.supp.local.realm admin server - ANOTHER.REALM kerberos.another.realm - -The first line defines the name of the local realm. The next few lines -optionally defines 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 four. -Clients will try to contact servers in listed order. - -The `admin server' clause at the first entry states that this is the -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 `[PROTO/]HOST[:PORT]'. PROTO is -either `UDP', `TCP', or `HTTP', and PORT is the port to talk to. -Default value for PROTO is `UDP' and for PORT whatever `kerberos-iv' is -defined to be in `/etc/services' or 750 if undefined. If PROTO is -`HTTP', the default port is 80. An `http' entry may also be specified -in URL format. - -If the information about a realm is missing from the `krb.conf' file, -or if the information is wrong, the following methods will be tried in -order. - - 1. If you have an SRV-record (`RFC 2052') for your realm it will be - used. This record should be of the form - `kerberos-iv.PROTOCOL.REALM', where PROTO is either `UDP', `TCP', - or `HTTP'. (Note: the current implementation does not look at - priority or weight when deciding which server to talk to.) - - 2. 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 `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.) - - 3. If no valid kerberos server is found, it will try to talk UDP to - the service `kerberos-iv' with fall-back to port 750 with - `kerberos.REALM' (which is also assumed to be the master server), - and then `kerberos-1.REALM', `kerberos-2.REALM', and so on. - -SRV records have been supported in BIND since 4.9.5T2A. An example -would look like the following in the zone file: - - 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. - -We strongly recommend that you add a CNAME `kerberos.REALM' pointing to -your kerberos master server. - -The `krb.realms' file is used to find out what realm a particular host -belongs to. An example of this file could look like: - - this.realm THIS.REALM - .this.realm THIS.REALM - foo.com SOME.OTHER.REALM - www.foo.com A.STRANGE.REALM - .foo.com FOO.REALM - -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 `this.realm' is only necessary if there -is a host named `this.realm'. - -If no matching realm is found in `krb.realms', DNS is searched for the -correct realm. For example, if we are looking for host `a.b.c', -`krb4-realm.a.b.c' is first tried and then `krb4-realm.b.c' and so on. -The entry should be a TXT record containing the name of the realm, such -as: - - krb4-realm.pdc.kth.se. 7200 TXT "NADA.KTH.SE" - -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 -`krb.conf' and `krb.realms' up to date. - -In addition to these commonly used files, `/etc/krb.extra' holds some -things that are not normally used. It consists of a number of `VARIABLE -= VALUE' pairs, blank lines and lines beginning with a hash (#) are -ignored. - -The currently defined variables are: - -`kdc_timeout' - The time in seconds to wait for an answer from the KDC (the - default is 4 seconds). - -`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. - -`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 `reverse_lsb_test'. - -`krb4_proxy' - When getting tickets via HTTP, this specifies the proxy to use. The - default is to speak directly to the KDC. - -`krb_default_tkt_root' - The default prefix for ticket files. The default is `/tmp/tkt'. - Normally the uid or tty is appended to this prefix. - -`krb_default_keyfile' - The file where the server keys are stored, the default is - `/etc/srvtab'. - -`nat_in_use' - If the client is behind a Network Address Translator (NAT). - -`reverse_lsb_test' - Reverses the test used by `krb_mk_safe', `krb_rd_safe', - `krb_mk_priv', and `krb_rd_priv' to compute the ordering of the - communicating hosts. This test can cause truble when using - firewalls. - - -File: kth-krb.info, Node: Install the /etc/services, Next: Install the kerberos server, Prev: Install the configuration files, Up: How to set up the kerberos server - -Updating /etc/services ----------------------- - -You should append or merge the contents of `services.append' to your -`/etc/services' files or NIS-map. Remove any unused factory installed -kerberos port definitions to avoid possible conflicts. - -Most of the programs will fall back to the default ports if the port -numbers are not found in `/etc/services', but it is convenient to have -them there anyway. - - -File: kth-krb.info, Node: Install the kerberos server, Next: Set up the server, Prev: Install the /etc/services, Up: How to set up the kerberos server - -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 (*note Choose a kerberos server::) before installing -the kerberos server. In this example, we will install a kerberos server -for the realm `FOO.SE' on a machine called `hemlig.foo.se'. - - -File: kth-krb.info, Node: Set up the server, Next: Add a few important principals, Prev: Install the kerberos server, Up: How to set up the kerberos server - -Setup the server ----------------- - -Login as root on the console of the kerberos server. Add -`/usr/athena/bin' and `/usr/athena/sbin' to your path. Create the -directory `/var/kerberos' (`mkdir /var/kerberos'), which is where the -database will be stored. Then, to create the database, run `kdb_init': - - hemlig# mkdir /var/kerberos - 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: - -If you have set up the configuration files correctly, `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 `kstash'. Choose something long -and random. Now run `kstash' using the same password: - - hemlig# kstash - - Enter Kerberos master password: - - Current Kerberos master key version is 1. - - Master key entered. BEWARE! - Wrote master key to /.k - -After entering the same master password it will be saved in the file -`/.k' 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. - -`kdb_init' initializes the database with a few entries: - -`krbtgt.REALM' - The key used for authenticating to the kerberos server. - -`changepw.kerberos' - The key used for authenticating to the administrative server, i.e. - when adding users, changing passwords, and so on. - -`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. - -`K.M' - This is the master key and it is only used to verify that the - master key that is saved un-encrypted in `/.k' is correct and - corresponds to this database. - -`kstash' only reads the master password and writes it to `/.k'. This -enables the kerberos server to start without you having to enter the -master password. This file (`/.k') is only readable by root and -resides on a "secure" machine. - - -File: kth-krb.info, Node: Add a few important principals, Next: Start the server, Prev: Set up the server, Up: How to set up the kerberos server - -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 `kdb_edit' to -edit the kerberos database directly on the server. - -`kdb_edit' is intended as a bootstrapping and fall-back mechanism for -editing the database. For normal purposes, use the `kadmin' program -(*note Add users to the database::). - -The following example shows the adding of the principal `nisse.admin' -into the kerberos database. This principal is used by `nisse' when -administrating the kerberos database. Later on the normal principal -for `nisse' will be created. Replace `nisse' and `password' with your -own username and password. - - 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: <> - -`kdb_edit' will loop until you hit the `return' key at the "Principal -name" prompt. Now you have added nisse as an administrator. - - -File: kth-krb.info, Node: Start the server, Next: Try to get tickets, Prev: Add a few important principals, Up: How to set up the kerberos server - -Start the server ----------------- - - hemlig# /usr/athena/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 - - -File: kth-krb.info, Node: Try to get tickets, Next: Create initial ACL for the admin server, Prev: Start the server, Up: How to set up the kerberos server - -Try to get tickets ------------------- - -You can now verify that these principals have been added and that the -server is working correctly. - - hemlig# kinit - eBones International (hemlig.foo.se) - Kerberos Initialization - Kerberos name: <nisse.admin> - Password: <password> - -If you do not get any error message from `kinit', then everything is -working (otherwise, see *Note Common error messages::). Use `klist' to -verify the tickets you acquired with `kinit': - - 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 - - -File: kth-krb.info, Node: Create initial ACL for the admin server, Next: Start the admin server, Prev: Try to get tickets, Up: How to set up the kerberos server - -Create initial ACL for the admin server ---------------------------------------- - -The admin server, `kadmind', uses a series of files to determine who has -the right to perform certain operations. The files are: -`admin_acl.add', `admin_acl.get', `admin_acl.del', and `admin_acl.mod'. -Create these with `nisse.admin@FOO.SE' as the contents. - - hemlig# echo "nisse.admin@FOO.SE" >> /var/kerberos/admin_acl.add - hemlig# echo "nisse.admin@FOO.SE" >> /var/kerberos/admin_acl.get - hemlig# echo "nisse.admin@FOO.SE" >> /var/kerberos/admin_acl.mod - hemlig# echo "nisse.admin@FOO.SE" >> /var/kerberos/admin_acl.del - -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. - - -File: kth-krb.info, Node: Start the admin server, Next: Add users to the database, Prev: Create initial ACL for the admin server, Up: How to set up the kerberos server - -Start the admin server ----------------------- - - hemlig# /usr/athena/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! - - -File: kth-krb.info, Node: Add users to the database, Next: Automate the startup of the servers, Prev: Start the admin server, Up: How to set up the kerberos server - -Add users to the database -------------------------- - -Use the `kadmin' client to add users to the database: - - hemlig# kadmin -p 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. - -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: - - 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. - - -File: kth-krb.info, Node: Automate the startup of the servers, Prev: Add users to the database, Up: How to set up the kerberos server - -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 (`/etc/rc' or similar). - - -File: kth-krb.info, Node: Install the client programs, Next: Install the kerberised services, Prev: How to set up the kerberos server, Up: How to set up a realm - -Install the client programs -=========================== - -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. (*note Install the configuration files:: and *note Install the -/etc/services::.) Also you need to make the programs in -`/usr/athena/bin' available. This can be done by adding the -`/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. One good way to synchronize the time is NTP (Network Time -Protocol), see <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 *Note Install the configuration files::). If this is not the case -and you need to have `krb.conf' and/or `krb.realms', you can copy them -into a directory of your choice and set the environment variable -KRBCONFDIR to point at this directory. - -To test the client functionality, run the `kinit' program: - - 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 - - -File: kth-krb.info, Node: Install the kerberised services, Next: Install a slave kerberos server, Prev: Install the client programs, Up: How to set up a realm - -Install the kerberised services -=============================== - -These includes `rsh', `rlogin', `telnet', `ftp', `rxtelnet', and so on. - -First follow the steps mentioned in the prior section to make it a -client and verify its operation. Change `inetd.conf' next to use the -new daemons. Look at the file `etc/inetd.conf.changes' to see the -changes that we recommend you perform on `inetd.conf'. - -You should at this point decide what services you want to run on each -machine. - -rsh, rlogin, and 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 `-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 `-x' as an option -indicating encryption. - -Our recommendation is to only use the kerberised services and give -explanation messages for the old ports. - -telnet ------- - -The telnet service always uses the same port and negotiates as to which -authentication method should be used. The `telnetd' program has 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 (*note One-Time -Passwords::) you can use the "-a otp" option which will allow OTPs or -kerberised connections. - -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: - -`-a otp' - Allow one-time passwords (*note One-Time Passwords::). - -`-a ftp' - Allow anonymous login (as user "ftp" or "anonymous"). - -`-a safe' - The same as `-a ftp', for backwards compatibility. - -`-a plain' - Allow clear-text passwords. - -`-a none' - The same as `-a ftp -a plain'. - -`-a user' - A no-op, also there for backwards compatibility reasons. - -When running anonymous ftp you should read the man page on `ftpd' which -explains how to set it up. - -pop ---- - -The Post Office Protocol (POP) is used to retrieve mail from the mail -hub. The `popper' program implements the standard POP3 protocol and -the kerberised KPOP. Use the `-k' option to run the kerberos version -of the protocol. This service should only be run on your mail hub. - -kx --- - -`kx' allows you to run X over a kerberos-authenticated and encrypted -connection. This program is used by `rxtelnet', `tenletxr', and -`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 `-t' -option to `kxd'. Otherwise it should be sufficient by adding the -daemon in `inetd.conf'. - -kauth ------ - -This service allows you to create tickets on a remote host. To enable -it just insert the corresponding line in `inetd.conf'. - -srvtabs -======= - -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 -`/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 name and the hostname. -Examples of such principals are `pop.HOSTNAME' and `rcmd.HOSTNAME'. -(rcmd comes from "remote command".) Here is a list of the most -commonly used srvtab types and what programs use them. - -rcmd.HOSTNAME - rsh, rcp, rlogin, telnet, kauth, su, kx - -rcmd.kerberos - kprop - -pop.HOSTNAME - popper, movemail, push - -sample.HOSTNAME - sample_server, simple_server - -changepw.kerberos - kadmin, kpasswd - -krbtgt.REALM - kerberos (not stored in any srvtab) - -ftp.HOSTNAME - ftp (also tries with rcmd.HOSTNAME) - -zephyr.zephyr - Zephyr - -afs or afs.CELLNAME - Andrew File System - -To create these keys you will use the the `ksrvutil' program. Perform -the following: - - 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. - -Complete test of the kerberised services ----------------------------------------- - -Obtain a ticket on one machine (`foo') and use it to login with a -kerberised service to a second machine (`bar'). The test should look -like this if successful: - - 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$ - -You can also try with `rsh', `rcp', `rlogin', `rlogin -x', and some -other commands to see that everything is working all right. - - -File: kth-krb.info, Node: Install a slave kerberos server, Next: Cross-realm functionality, Prev: Install the kerberised services, Up: How to set up a realm - -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. (*note Choose a kerberos server::). - -On the master, add a `rcmd.kerberos' (note, it should be literally -"kerberos") principal (using `ksrvutil get'). The `kprop' program, -running on the master, will use this when authenticating to the -`kpropd' daemons running on the slave servers. The `kpropd' on the -slave will use its `rcmd.hostname' key for authenticating the -connection from the master. Therefore, the slave needs to have this -key in its srvtab, and it of course also needs to have enough of the -configuration files to act as a server. See *Note Install the -kerberised services:: for information on how to do this. - -To summarize, the master should have a key for `rcmd.kerberos' and the -slave one for `rcmd.hostname'. - -The slave will need the same master key as you used at the master. - -On your master server, create a file, e.g. `/var/kerberos/slaves', that -contains the hostnames of your kerberos slave servers. - -Start `kpropd' with `kpropd -i' on your slave servers. - -On your master server, create a dump of the database and then propagate -it. - - foo# kdb_util slave_dump /var/kerberos/slave_dump - foo# kprop - -You should now have copies of the database on your slave servers. You -can verify this by issuing `kdb_util dump 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. - -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 `kstash'. (*note 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 `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 `-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 `kadmind' at the master, and -then propagated to the slaves, so you should *not* run `kadmind' on the -slaves. - -Finally add the slave servers to `/etc/krb.conf'. The clients will ask -the servers in the order specified by that file. - -Consider adding CNAMEs to your slave servers, see *Note Install the -configuration files::. - - -File: kth-krb.info, Node: Cross-realm functionality, Prev: Install a slave kerberos server, Up: How to set up a realm - -Cross-realm functionality -========================= - -Suppose you are residing in the realm `MY.REALM', how do you -authenticate to a server in `OTHER.REALM'? Having valid tickets in -`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 `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 `krbtgt.OTHER.REALM' in `MY.REALM', and -`krbtgt.MY.REALM' in `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. - - 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 - - -File: kth-krb.info, Node: One-Time Passwords, Next: Resolving frequent problems, Prev: How to set up a realm, Up: Top - -One-Time Passwords -****************** - -There is also support for using "one time passwords" (OTP) in this -package. Specifically `login', `ftpd', and `popper' have support for -using them. - -* Menu: - -* What are one time passwords?:: -* When to use one time passwords?:: -* Configuring OTPs:: - - -File: kth-krb.info, Node: What are one time passwords?, Next: When to use one time passwords?, Prev: One-Time Passwords, Up: One-Time Passwords - -What are one time passwords? -============================ - -One time passwords are, as the name implies, passwords that can only be -used once. This means that even if someone is eavesdropping on the -network, they will not be able to make use of the passwords they steal. - -The OTPs used in this package support `RFC 1938'. This standard is -also backwards compatible with the well-known S/Key. There are lots of -programs for generating these on everything from HP 48's to Crays. - - -File: kth-krb.info, Node: When to use one time passwords?, Next: Configuring OTPs, Prev: What are one time passwords?, Up: One-Time Passwords - -When to use one time passwords? -=============================== - -Why would you want to use OTPs instead of Kerberos? The advantage of -OTPs is that they don't require a computer to operate. You can print -out a list of passwords and take with you, or you could use your -calculator or hand-held computer to generate them. - -The downside is that they only protect you against passive attacks. -Only the initial connection is authenticated. After that, anyone can -eavesdrop on your session, so you should not send or view any sensitive -data (e.g. passwords) over a OTP-initiated link. You are also -vulnerable to active attacks where intruders try to take over your -TCP-session and/or introduce data in the middle of it. In other words, -they provide initial authentication, but neither integrity nor -confidentiality. - -The OTPs are generated from the tuple (SEED, SEQUENCE NUMBER, -PASS-PHRASE). The seed and the sequence number will be printed as part -of the "challenge" and you will have to generate the corresponding -password or pick it from a list. - -In conclusion, they are simple and can be used everywhere but don't -protect against all threats that Kerberos does. Use them when you can't -use Kerberos. - - -File: kth-krb.info, Node: Configuring OTPs, Prev: When to use one time passwords?, Up: One-Time Passwords - -Configuring OTPs -================ - -Initializing -============ - -To initialize your OTPs use the `otp' program. This program will write -an entry in a local file on this host with your current password (in -this case the 100th) and the corresponding seed (`foobar'). - - datan:>otp 100 foobar - Pass-phrase: <pass-phrase> - Verifying password Pass-phrase: <pass-phrase> - -Generating -========== - -To print out a list of them there is a program called `otpprint'. - - datan:>otpprint 100 foobar - Pass-phrase: <pass-phrase> - 91: SLAM BUY SUP DUSK SKY BEST - 92: DEEM SIGH ROB RASH JUG MAT - 93: DUET FISK HERS AREA TOLL SUP - 94: WOW RAIN LEAK SARA MARK WING - 95: COG YELL MILK CART ABE BAWL - 96: GROW SILK GIST OMEN CAM ANNE - 97: JAG QUAD NUT BEAT BHOY MAGI - 98: ADAM USED GENE NIP EYE SIS - 99: MY SUNG HERO AT DASH RAKE - 100: CORN KNIT BOTH TOGO SOUL BOG - -Using the OTPs -============== - -When you try to use one and have initialized a series of one-time -passwords for yourself you will get a challenge with the algorithm -being used, the sequence number, and the seed. Enter those in your -generator or find the corresponding password in your list. - - login: assar - assar's [ otp-md5 99 foobar ] Password: <MY SUNG HERO AT DASH RAKE> - -The sequence number of the password will start at one less that the -number you gave to `otp' and decrease by one every time you use it. -You should try to keep track of which should be the current one so that -you can be assured that nobody has stolen some of your passwords and -used them. When the number has reached zero you need to acquire a new -series of passwords. - -Once you have initialized your series of passwords, you can always use -them at any password prompt where you get the challenge as shown above. - -Configuring servers -=================== - -`ftpd', `telnetd', and `popper' can be configured to require one-time -passwords when the connection has not been kerberos authenticated. -Check the man pages for these programs for the correct options. - - -File: kth-krb.info, Node: Resolving frequent problems, Next: Acknowledgments, Prev: One-Time Passwords, Up: Top - -Resolving frequent problems -*************************** - -* Menu: - -* Problems compiling Kerberos:: -* Problems with firewalls:: -* Common error messages:: -* Is Kerberos year 2000 safe?:: - - -File: kth-krb.info, Node: Problems compiling Kerberos, Next: Problems with firewalls, Prev: Resolving frequent problems, Up: Resolving frequent problems - -Problems compiling Kerberos -=========================== - -Many compilers require a switch to become ANSI compliant. Since krb4 is -written in ANSI C it is necessary to specify the name of the compiler -to be used and the required switch to make it ANSI compliant. This is -most easily done when running configure using the `env' command. For -instance to build under HP-UX using the native compiler do: - - datan$ env CC="cc -Ae" ./configure - -In general `gcc' works. The following combinations have also been -verified to successfully compile the distribution: - -`HP-UX' - `cc -Ae' - -`Digital UNIX' - `cc -std1' - -`AIX' - `xlc' - -`Solaris 2.x' - `cc' (unbundled one) - -`IRIX' - `cc' - -Linux problems --------------- - -The libc functions gethostby*() under RedHat4.2 can sometimes cause -core dumps. If you experience these problems make sure that the file -`/etc/nsswitch.conf' contains a hosts entry no more complex than the -line - -hosts: files dns - -Some systems have lost `/usr/include/ndbm.h' which is necessary to -build krb4 correctly. There is a `ndbm.h.Linux' right next to the -source distribution. - -There has been reports of non-working `libdb' on some Linux -distributions. If that happens, use the `--without-berkeley-db' when -configuring. - -SunOS 5 (aka Solaris 2) problems --------------------------------- - -When building shared libraries and using some combinations of GNU gcc/ld -you better set the environment variable RUN_PATH to /usr/athena/lib -(your target libdir). If you don't, then you will have to set -LD_LIBRARY_PATH during runtime and the PAM module will not work. - -HP-UX problems --------------- - -The shared library `/usr/lib/libndbm.sl' doesn't exist on all systems. -To make problems even worse, there is never an archive version for -static linking either. Therefore, when building "truly portable" -binaries first install GNU gdbm or Berkeley DB, and make sure that you -are linking against that library. - -Cray problems -------------- - -`rlogind' won't work on Crays until `forkpty()' has been ported, in the -mean time use `telnetd'. - -IRIX problems -------------- - -IRIX has three different ABI:s (Application Binary Interface), there's -an old 32 bit interface (known as O32, or just 32), a new 32 bit -interface (N32), and a 64 bit interface (64). O32 and N32 are both 32 -bits, but they have different calling conventions, and alignment -constraints, and similar. The N32 format is the default format from IRIX -6.4. - -You select ABI at compile time, and you can do this with the -`--with-mips-abi' configure option. The valid arguments are `o32', -`n32', and `64', N32 is the default. Libraries for the three different -ABI:s are normally installed installed in different directories (`lib', -`lib32', and `lib64'). If you want more than one set of libraries you -have to reconfigure and recompile for each ABI, but you should probably -install only N32 binaries. - -GCC had had some known problems with the different ABI:s. Old GCC could -only handle O32, newer GCC can handle N32, and 64, but not O32, but in -some versions of GCC the structure alignment was broken in N32. - -This confusion with different ABI:s can cause some trouble. For -instance, the `afskauthlib.so' library has to use the same ABI as -`xdm', and `login'. The easiest way to check what ABI to use is to run -`file' on `/usr/bin/X11/xdm'. - -Another problem that you might encounter if you run AFS is that Transarc -apparently doesn't support the 64-bit ABI, and because of this you can't -get tokens with a 64 bit application. If you really need to do this, -there is a kernel module that provides this functionality at -<ftp://ftp.pdc.kth.se/home/joda/irix-afs64.tar.gz>. - -AIX problems ------------- - -`gcc' version 2.7.2.* has a bug which makes it miscompile -`appl/telnet/telnetd/sys_term.c' (and possibily `appl/bsd/forkpty.c'), -if used with too much optimization. - -Some versions of the `xlc' preprocessor doesn't recognise the -(undocumented) `-qnolm' option. If this option is passed to the -preprocessor (like via the configuration file `/etc/ibmcxx.cfg', -configure will fail. - -The solution is to remove this option from the configuration file, -either globally, or for just the preprocessor: - - $ cp /etc/ibmcxx.cfg /tmp - $ed /tmp/ibmcxx.cfg - 8328 - /nolm - options = -D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_IBMR2,-D_POWER,-bpT:0x10000000,-bpD:0x20000000,-qnolm - s/,-qnolm//p - options = -D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_IBMR2,-D_POWER,-bpT:0x10000000,-bpD:0x20000000 - w - 8321 - q - $ env CC=xlc CPP="xlc -E -F/tmp/ibmcxx.cfg" configure - -There is a bug in AFS 3.4 version 5.38 for AIX 4.3 that causes the -kernel to panic in some cases. There is a hack for this in `login', but -other programs could be affected also. This seems to be fixed in -version 5.55. - -C2 problems ------------ - -The programs that checks passwords works with `passwd', OTP, and -Kerberos paswords. This is problem if you use C2 security (or use some -other password database), that normally keeps passwords in some obscure -place. If you want to use Kerberos with C2 security you will have to -think about what kind of changes are necessary. See also the discussion -about Digital's SIA and C2 security, see *Note Digital SIA::. - - -File: kth-krb.info, Node: Problems with firewalls, Next: Common error messages, Prev: Problems compiling Kerberos, Up: Resolving frequent problems - -Problems with firewalls -======================= - -A firewall is a network device that filters out certain types of packets -going from one side of the firewall to the other. A firewall is supposed -to solve the same kinds of problems as Kerberos (basically hindering -unauthorised network use). The difference is that Kerberos tries to -authenticate users, while firewall splits the network in a `secure' -inside, and an `insecure' outside. - -Firewall people usually think that UDP is insecure, partly because many -`insecure' protocols use UDP. Since Kerberos by default uses UDP to send -and recieve packets, Kerberos and firewalls doesn't work very well -together. - -The symptoms of trying to use Kerberos behind a firewall is that you -can't get any tickets (`kinit' exits with the infamous `Can't send -request' error message). - -There are a few ways to solve these problems: - - * Convince your firewall administrator to open UDP port 750 or 88 for - incoming packets. This usually turns out to be difficult. - - * Convince your firewall administrator to open TCP port 750 or 88 for - outgoing connections. This can be a lot easier, and might already - be enabled. - - * Use TCP connections over some non-standard port. This requires - that you have to convince the administrator of the kerberos server - to allow connections on this port. - - * Use HTTP to get tickets. Since web-stuff has become almost - infinitely popular, many firewalls either has the HTTP port open, - or has a HTTP proxy. - -The last two methods might be considered to be offensive (since you are -not sending the `right' type of data in each port). You probably do best -in discussuing this with firewall administrator. - -For information on how to use other protocols when communication with -KDC, see *Note Install the configuration files::. - -It is often the case that the firewall hides addresses on the `inside', -so it looks like all packets are coming from the firewall. Since address -of the client host is encoded in the ticket, this can cause trouble. If -you get errors like `Incorrect network address', when trying to use the -ticket, the problem is usually becuase the server you are trying to -talk to sees a different address than the KDC did. If you experience -this kind of trouble, the easiest way to solve them is probably to try -some other mechanism to fetch tickets. You might also be able to -convince the administrator of the server that the two different -addresses should be added to the `/etc/krb.equiv' file. - - -File: kth-krb.info, Node: Common error messages, Next: Is Kerberos year 2000 safe?, Prev: Problems with firewalls, Up: Resolving frequent problems - -Common error messages -===================== - -These are some of the more obscure error messages you might encounter: - -`Time is out of bounds' - The time on your machine differs from the time on either the - kerberos server or the machine you are trying to login to. If it - isn't obvious that this is the case, remember that all times are - compared in UTC. - - On unix systems you usually can find out what the local time is by - doing `telnet machine daytime'. This time (again, usually is the - keyword) is with correction for time-zone and daylight savings. - - If you have problem keeping your clocks synchronized, consider - using a time keeping system such as NTP (see also the discussion in - *Note Install the client programs::). - -`Ticket issue date too far in the future' - The time on the kerberos server is more than five minutes ahead of - the time on the server. - -`Can't decode authenticator' - This means that there is a mismatch between the service key in the - kerberos server and the service key file on the specific machine. - Either: - * the server couldn't find a service key matching the request - - * the service key (or version number) does not match the key - the packet was encrypted with - -`Incorrect network address' - The address in the ticket does not match the address you sent the - request from. This happens on systems with more than one network - address, either physically or logically. You can list addresses - which should be considered equal in `/etc/krb.equiv' on your - servers. - - A note to programmers: a server should not pass `*' as the instance - to `krb_rd_req'. It should try to figure out on which interface the - request was received, for instance by using `k_getsockinst'. - - If you change addresses on your computer you invalidate any - tickets you might have. The easiest way to fix this is to get new - tickets with the new address. - -`Message integrity error' - The packet is broken in some way: - * the lengths does not match the size of the packet, or - - * the checksum does not match the contents of the packet - -`Can't send request' - There is some problem contacting the kerberos server. Either the - server is down, or it is using the wrong port (compare the entries - for `kerberos-iv' in `/etc/services'). The client might also have - failed to guess what kerberos server to talk to (check - `/etc/krb.conf' and `/etc/krb.realms'). - - One reason you can't contact the kerberos server might be because - you're behind a firewall that doesn't allow kerberos packets to - pass. For possible solutions to this see the firewall section - above. - -`kerberos: socket: Unable to open socket...' - The kerberos server has to open four sockets for each interface. - If you have a machine with lots of virtual interfaces, you run the - risk of running out of file descriptors. If that happens you will - get this error message. - -`ftp: User foo access denied' - This usually happens because the user's shell is not listed in - `/etc/shells'. Note that `ftpd' checks this file even on systems - where the system version does not and there is no `/etc/shells'. - -`Generic kerberos error' - This is a generic catch-all error message. - - -File: kth-krb.info, Node: Is Kerberos year 2000 safe?, Prev: Common error messages, Up: Resolving frequent problems - -Is Kerberos year 2000 safe? -=========================== - -Yes. - -A somewhat longer answer is that we can't think of anything that can -break. The protocol itself doesn't use time stamps in textual form, the -two-digit year problems in the original MIT code has been fixed (this -was a problem mostly with log files). The FTP client had a bug in the -command `newer' (which fetches a file if it's newer than what you -already got). - -Another thing to look out for, but that isn't a Y2K problem per se, is -the expiration date of old principals. The MIT code set the default -expiration date for some new principals to 1999-12-31, so you might want -to check your database for things like this. - -Now, the Y2038 problem is something completely different (but the -authors should have retired by then, presumably growing rowanberrys in -some nice and warm place). - - -File: kth-krb.info, Node: Acknowledgments, Next: Index, Prev: Resolving frequent problems, Up: Top - -Acknowledgments -*************** - -People from the MIT Athena project wrote the original code that this is -based on. Kerberos 4 patch-level 9 was stripped of both the encryption -functions and the calls to them. This was exported from the US as the -"Bones" release. Eric Young put back the calls and hooked in his -libdes, thereby creating the "eBones" release. - -The "rcmd" programs where initially developed at the University of -California at Berkeley and then hacked on by the FreeBSD and NetBSD -projects. - -Berkeley also wrote `ftp', `ftpd', `telnet', and `telnetd'. The -authentication and encryption code of `telnet' and `telnetd' was added -by David Borman (then of Cray Research, Inc). The encryption code was -removed when this was exported and then added back by Juha Eskelinen, -`<esc@magic.fi>'. - -The `popper' was also a Berkeley program initially. - -The `login' has the same origins but has received code written by -Wietse Venema at Eindhoven University of Technology, The Netherlands. - -`movemail' was (at least partially) written by Jonathan Kamens, -`<jik@security.ov.com>', and is Copyright (C) 1986, 1991, 1992, 1993, -1994 Free Software Foundation, Inc. - -`xnlock' was originally written by Dan Heller in 1985 for sunview. The -X version was written by him in 1990. - -Some of the functions in `libroken' also come from Berkeley by the way -of NetBSD/FreeBSD. - -The code to handle the dynamic loading of the AFS module for AIX is -copyright (C) 1992 HELIOS Software GmbH 30159 Hannover, Germany. - -`editline' was written by Simmule Turner and Rich Salz. - -Bugfixes and code has been contributed by: -Derrick J Brashear - `<shadow@dementia.org>' - -Anders Gertz - `<gertz@lysator.liu.se>' - -Dejan Ilic - `<svedja@lysator.liu.se>' - -Kent Engström - `<kent@lysator.liu.se>' - -Simon Josefsson - `<jas@pdc.kth.se>' - -Robert Malmgren - `<rom@incolumitas.se>' - -Fredrik Ljungberg - `<flag@astrogator.se>' - -Joakim Fallsjö - `jfa@pobox.se' - -Lars Malinowsky - `<lama@pdc.kth.se>' - -Fabien Coelho - `<coelho@cri.ensmp.fr>' - -Chris Chiappa - `<griffon+@cmu.edu>' - -Gregory S. Stark - `<gsstark@mit.edu>' - -Love Hörnquist-Åstrand - `<lha@stacken.kth.se>' - -Daniel Staaf - `<d96-dst@nada.kth.se>' - -Magnus Ahltorp - `<map@stacken.kth.se>' - -Robert Burgess - `<rb@stacken.kth.se>' - -Lars Arvestad - `<arve@nada.kth.se>' - -Jörgen Wahlsten - `<wahlsten@pathfinder.com>' - -Daniel Staaf - `<d96-dst@nada.kth.se>' - -R Lindsay Todd - `<toddr@rpi.edu>' - -Åke Sandgren - `<ake@cs.umu.se>' - -Thomas Nyström - `<thn@stacken.kth.se>' - -and we hope that those not mentioned here will forgive us. -Ian Marsh `<ianm@sics.se>' removed the worst abuses of the English -language from this text. - -Ilja Hallberg `<iha@incolumitas.se>' is still promising to help us -finish the documentation. - -This work was supported in part by SUNET and the Centre for Parallel -Computers at KTH. - -The port to Windows 95/NT was supported by the Computer Council at KTH -and done by Jörgen Karlsson `<d93-jka@nada.kth.se>'. - -All the bugs were introduced by ourselves. - - -File: kth-krb.info, Node: Index, Prev: Acknowledgments, Up: Top - -Index -***** - -* Menu: - -* .klogin: .klogin. -* admin_acl.add: Create initial ACL for the admin server. -* admin_acl.del: Create initial ACL for the admin server. -* admin_acl.get: Create initial ACL for the admin server. -* admin_acl.mod: Create initial ACL for the admin server. -* AFS: Problems compiling Kerberos. -* afslog: Finishing the installation. -* authentication: What is Kerberos?. -* Berkeley DB: Installing from source. -* Bones: Acknowledgments. -* C2: Problems compiling Kerberos. -* confidentiality: What is Kerberos?. -* cracklib: Installing from source. -* default/login: Finishing the installation. -* eBones: Acknowledgments. -* environment: Finishing the installation. -* fbtab: Finishing the installation. -* firewall <1>: Problems with firewalls. -* firewall: Installing from source. -* firewall_address: Install the configuration files. -* ftp <1>: Install the kerberised services. -* ftp <2>: Finishing the installation. -* ftp: Install the kerberised services. -* ftpd: .klogin. -* GCC: Problems compiling Kerberos. -* Hesiod: Installing from source. -* HP-UX: Problems compiling Kerberos. -* HTTP: Problems with firewalls. -* inetd.conf: Install the kerberised services. -* integrity: What is Kerberos?. -* IRIX: Problems compiling Kerberos. -* kadmin <1>: Add users to the database. -* kadmin: Finishing the installation. -* kadmind <1>: Installing from source. -* kadmind <2>: Create initial ACL for the admin server. -* kadmind: Start the admin server. -* kauth <1>: Finishing the installation. -* kauth: Install the kerberised services. -* kauthd: .klogin. -* kdb_edit: Add a few important principals. -* kdb_init: Set up the server. -* kdc_timeout: Install the configuration files. -* kdc_timesync: Install the configuration files. -* kdestroy: Finishing the installation. -* kerberos <1>: Choose a kerberos server. -* kerberos: Start the server. -* kinit <1>: Try to get tickets. -* kinit: Finishing the installation. -* klist <1>: Finishing the installation. -* klist: Try to get tickets. -* kpasswd: Finishing the installation. -* kprop: Install a slave kerberos server. -* kpropd: Install a slave kerberos server. -* krb.conf <1>: Install the configuration files. -* krb.conf: Install the client programs. -* krb.extra: Install the configuration files. -* krb.realms <1>: Install the client programs. -* krb.realms: Install the configuration files. -* krb4_proxy: Install the configuration files. -* krb_default_keyfile: Install the configuration files. -* krb_default_tkt_root: Install the configuration files. -* KRBCONFDIR: Install the client programs. -* ksrvutil <1>: Install the kerberised services. -* ksrvutil: Finishing the installation. -* kstash: Set up the server. -* kx: Install the kerberised services. -* kxd <1>: Install the kerberised services. -* kxd: .klogin. -* Linux: Problems compiling Kerberos. -* login <1>: Installing from source. -* login: Finishing the installation. -* login.access: Finishing the installation. -* logindevperm: Finishing the installation. -* master server: Install the configuration files. -* NAT: Install the configuration files. -* nat_in_use: Install the configuration files. -* Network Address Translator: Install the configuration files. -* NTP.: Install the client programs. -* One time passwords: One-Time Passwords. -* OTP: One-Time Passwords. -* otp: Configuring OTPs. -* otpprint: Configuring OTPs. -* pagsh: Finishing the installation. -* popper <1>: Installing from source. -* popper <2>: Install the kerberised services. -* popper: .klogin. -* push: Installing from source. -* rc: Automate the startup of the servers. -* rcp <1>: Install the kerberised services. -* rcp: Finishing the installation. -* readline: Installing from source. -* realm: Choose a realm name. -* replay cache: What is Kerberos?. -* reverse_lsb_test: Install the configuration files. -* rlogin <1>: Finishing the installation. -* rlogin <2>: Install the kerberised services. -* rlogin <3>: Finishing the installation. -* rlogin: Install the kerberised services. -* rlogind <1>: .klogin. -* rlogind: Finishing the installation. -* rsh <1>: Install the kerberised services. -* rsh <2>: Finishing the installation. -* rsh: Install the kerberised services. -* rshd: .klogin. -* rxtelnet <1>: Finishing the installation. -* rxtelnet: Install the kerberised services. -* rxterm: Finishing the installation. -* S/Key: What are one time passwords?. -* services: Install the /etc/services. -* session key: What is Kerberos?. -* socks: Installing from source. -* srvtab: Install the kerberised services. -* su <1>: Finishing the installation. -* su: .klogin. -* SunOS 5: Problems compiling Kerberos. -* supplementary local realms: Install the configuration files. -* telnet <1>: Install the kerberised services. -* telnet <2>: Finishing the installation. -* telnet: Install the kerberised services. -* telnetd <1>: .klogin. -* telnetd <2>: Finishing the installation. -* telnetd: Install the kerberised services. -* tenletxr: Finishing the installation. -* xnlock: Finishing the installation. -* Year 2000: Is Kerberos year 2000 safe?. - - - -Tag Table: -Node: Top212 -Node: Introduction1673 -Node: What is Kerberos?3278 -Node: Installing programs8218 -Node: Installing from source8876 -Node: Installing a binary distribution14070 -Node: Finishing the installation14498 -Node: .klogin17649 -Node: Authentication modules19059 -Node: Digital SIA19667 -Node: IRIX23714 -Node: PAM24738 -Node: How to set up a realm25573 -Node: How to set up the kerberos server26157 -Node: Choose a realm name26787 -Ref: Choose a realm name-Footnote-127316 -Node: Choose a kerberos server27447 -Node: Install the configuration files28439 -Node: Install the /etc/services34598 -Node: Install the kerberos server35172 -Node: Set up the server35729 -Node: Add a few important principals38284 -Node: Start the server40146 -Node: Try to get tickets40640 -Node: Create initial ACL for the admin server41486 -Node: Start the admin server42447 -Node: Add users to the database42928 -Node: Automate the startup of the servers44005 -Node: Install the client programs44346 -Node: Install the kerberised services46197 -Node: Install a slave kerberos server51959 -Node: Cross-realm functionality55030 -Node: One-Time Passwords57167 -Node: What are one time passwords?57581 -Node: When to use one time passwords?58212 -Node: Configuring OTPs59567 -Node: Resolving frequent problems61720 -Node: Problems compiling Kerberos62024 -Node: Problems with firewalls67407 -Node: Common error messages70070 -Node: Is Kerberos year 2000 safe?73564 -Node: Acknowledgments74534 -Node: Index77697 - -End Tag Table |