diff options
Diffstat (limited to 'share/doc/handbook/kerberos.sgml')
| -rw-r--r-- | share/doc/handbook/kerberos.sgml | 480 |
1 files changed, 0 insertions, 480 deletions
diff --git a/share/doc/handbook/kerberos.sgml b/share/doc/handbook/kerberos.sgml deleted file mode 100644 index e2c264e..0000000 --- a/share/doc/handbook/kerberos.sgml +++ /dev/null @@ -1,480 +0,0 @@ -<!-- $Id$ --> -<!-- The FreeBSD Documentation Project --> - -<sect><heading>Kerberos<label id="kerberos"></heading> - -<p><em>Contributed by &a.markm; (based on contribution by &a.md;).</em> - - Kerberos is a network add-on system/protocol that allows users to - authenticate themselves through the services of a secure server. - Services such as remote login, remote copy, secure inter-system - file copying and other high-risk tasks are made considerably safer - and more controllable. - - The following instructions can be used as a guide on how to - set up Kerberos as distributed for FreeBSD. However, you should refer - to the relevant manual pages for a complete description. - - In FreeBSD, the Kerberos is not that from the original 4.4BSD-Lite, - distribution, but eBones, which had been previously ported to - FreeBSD 1.1.5.1, and was sourced from outside the USA/Canada, - and is thus available to system owners outside those countries. - - For those needing to get a legal foreign distribution of this - software, please <em>DO NOT</em> get it from a USA or Canada site. - You will get that site in <em>big</em> trouble! A legal copy of this is - available from <tt>skeleton.mikom.csir.co.za</tt>, which is in South - Africa. - - <sect1> - <heading>Creating the initial database</heading> - - <p>This is done on the Kerberos server only. First make sure that your - do not have any old Kerberos databases around. You should change to the - directory <tt>/etc/kerberosIV</tt> and check that only the following - files are present: - -<tscreen><verb> -grunt# cd /etc/kerberosIV -grunt# ls -README krb.conf krb.realms -</verb></tscreen> - - <p>If any additional files (such as <tt>principal.*</tt> or - <tt>master_key</tt>) exist, then use the <tt>kdb_destroy</tt> - command to destroy the old Kerberos database, of if Kerberos - is not running, simply delete the extra files with <tt>rm</tt>. - - You should now edit the <tt>krb.conf</tt> and <tt>krb.realms</tt> - files to define your Kerberos realm. In this case the realm will - be <it>GRONDAR.ZA</it> and the server is <it>grunt.grondar.za</it>. - We edit or create the <tt>krb.conf</tt> file: - -<tscreen><verb> -grunt# cat krb.conf -GRONDAR.ZA -GRONDAR.ZA grunt.grondar.za admin server -CS.BERKELEY.EDU okeeffe.berkeley.edu -ATHENA.MIT.EDU kerberos.mit.edu -ATHENA.MIT.EDU kerberos-1.mit.edu -ATHENA.MIT.EDU kerberos-2.mit.edu -ATHENA.MIT.EDU kerberos-3.mit.edu -LCS.MIT.EDU kerberos.lcs.mit.edu -TELECOM.MIT.EDU bitsy.mit.edu -ARC.NASA.GOV trident.arc.nasa.gov -</verb></tscreen> - - <p>In this case, the other realms do not need to be there. - They are here as an example of how a machine may be made aware - of multiple realms. You may wish to not include them for simplicity. - - The first line names the realm in which this system works. The other - lines contain realm/host entries. The first item on a line is a realm, - and the second is a host in that realm that is acting as a ``key - distribution centre''. The words ``admin server'' following a hosts - name means that host also provides an administrative database server. - For further explanation of these terms, please consult the Kerberos - man pages. - - Now we have to add <it>grunt.grondar.za</it> to the <it>GRONDAR.ZA</it> - realm and also add an entry to put all hosts in the <it>.grondar.za</it> - domain in the <it>GRONDAR.ZA</it> realm. The <tt>krb.realms</tt> file - would be updated as follows: - -<tscreen><verb> - grunt# cat krb.realms - grunt.grondar.za GRONDAR.ZA - .grondar.za GRONDAR.ZA - .berkeley.edu CS.BERKELEY.EDU - .MIT.EDU ATHENA.MIT.EDU - .mit.edu ATHENA.MIT.EDU -</verb></tscreen> - - <p>Again, the other realms do not need to be there. - They are here as an example of how a machine may be made aware - of multiple realms. You may wish to remove them to simplify things. - - The first line puts the <it>specific</it> system into the named - realm. The rest of the lines show how to default systems of a - particular subdomain to a named realm. - - Now we are ready to create the database. This only needs to run on - the Kerberos server (or Key Distribution Centre). Issue the - <tt>kdb_init</tt> command to do this: - -<tscreen><verb> -grunt# kdb_init -Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA -You will be prompted for the database Master Password. -It is important that you NOT FORGET this password. - -Enter Kerberos master key: -</verb></tscreen> - - <p>Now we have to save the key so that servers on the local - machine can pick it up. Use the <tt>kstash</tt> command to - do this. - -<tscreen><verb> -grunt# kstash - -Enter Kerberos master key: - -Current Kerberos master key version is 1. - -Master key entered. BEWARE! -</verb></tscreen> - - <p>This saves the encrypted master password in - <tt>/etc/kerberosIV/master_key</tt>. - - <sect1> - <heading>Making it all run</heading> - - <p>Two principals need to be added to the database for <it>each</it> - system that will be secured with Kerberos. Their names are - <tt>kpasswd</tt> and <tt>rcmd</tt> These two principals are - made for each system, with the instance being the name of the - individual system. - - These daemons, <tt>kpasswd</tt> and <tt>rcmd</tt> allow other systems - to change Kerberos passwords and run commands like <tt>rcp</tt>, - <tt>rlogin</tt> and <tt>rsh</tt>. - - Now lets add these entries: - -<tscreen><verb> -grunt# kdb_edit -Opening database... - -Enter Kerberos master key: - -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: passwd -Instance: grunt - -<Not found>, Create [y] ? y - -Principal: passwd, Instance: grunt, kdc_key_ver: 1 -New Password: <---- enter RANDOM here -Verifying password - -New Password: <---- enter RANDOM here - -Random password [y] ? y - -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: rcmd -Instance: grunt - -<Not found>, Create [y] ? - -Principal: rcmd, Instance: grunt, kdc_key_ver: 1 -New Password: <---- enter RANDOM here -Verifying password - -New Password: <---- enter RANDOM here - -Random password [y] ? - -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: <---- null entry here will cause an exit -</verb></tscreen> - - <sect1> - <heading>Creating the server file</heading> - - <p>We now have to extract all the instances which define the services - on each machine. For this we use the <tt>ext_srvtab</tt> command. - This will create a file which must be copied or moved <it>by secure - means</it> to each Kerberos client's /etc/kerberosIV directory. This - file must be present on each server and client, and is crucial to the - operation of Kerberos. - -<tscreen><verb> -grunt# ext_srvtab grunt - -Enter Kerberos master key: - -Current Kerberos master key version is 1. - -Master key entered. BEWARE! -Generating 'grunt-new-srvtab'.... -</verb></tscreen> - - <p>Now, this command only generates a temporary file - which must be renamed to <tt>srvtab</tt> so that all the - server can pick it up. Use the <tt>mv</tt> command to move it - into place on the original system: - -<tscreen><verb> -grunt# mv grunt-new-srvtab srvtab -</verb></tscreen> - - <p>If the file is for a client system, and the network is not - deemed safe, then copy the <tt><client>-new-srvtab</tt> to - removable media and transport it by secure physical means. Be - sure to rename it to <tt>srvtab</tt> in the client's - <tt>/etc/kerberosIV</tt> directory, and make sure it is mode 600: - -<tscreen><verb> -grumble# mv grumble-new-srvtab srvtab -grumble# chmod 600 srvtab -</verb></tscreen> - - <sect1> - <heading>Populating the database</heading> - - <p>We now have to add some user entries into the database. - First lets create an entry for the user <it>jane</it>. Use - the <tt>kdb_edit</tt> command to do this: - -<tscreen><verb> -grunt# kdb_edit -Opening database... - -Enter Kerberos master key: - -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: jane -Instance: - -<Not found>, Create [y] ? y - -Principal: jane, Instance: , kdc_key_ver: 1 -New Password: <---- enter a secure password here -Verifying password - -New Password: <---- re-enter the password here - -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: <---- null entry here will cause an exit -</verb></tscreen> - - <sect1> - <heading>Testing it all out</heading> - - <p>First we have to start the Kerberos daemons. NOTE that if you have - correctly edited your <tt>/etc/sysconfig</tt> then this will happen - automatically when you reboot. This is only necessary on the Kerberos - server. Kerberos clients will automagically get what they need from - the <tt>/etc/kerberosIV</tt> directory. - -<tscreen><verb> -grunt# kerberos & -grunt# 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: GRONDAR.ZA -grunt# kadmind -n & -grunt# 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! -</verb></tscreen> - - <p>Now we can try using the <tt>kinit</tt> command to get a ticket for - the id <it>jane</it> that we created above: - -<tscreen><verb> -grunt$ kinit jane -MIT Project Athena (grunt.grondar.za) -Kerberos Initialization for "jane" -Password: -</verb></tscreen> - - <p>Try listing the tokens using <tt>klist</tt> to see if we really have them: - -<tscreen><verb> -grunt$ klist -Ticket file: /tmp/tkt245 -Principal: jane@GRONDAR.ZA - - Issued Expires Principal -Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA -</verb></tscreen> - - <p>Now try changing the password using <tt>passwd</tt> to check if the - kpasswd daemon can get authorization to the Kerberos database: - -<tscreen><verb> -grunt$ passwd -realm GRONDAR.ZA -Old password for jane: -New Password for jane: -Verifying password -New Password for jane: -Password changed. -</verb></tscreen> - - <sect1> - <heading>Adding <tt>su</tt> privileges</heading> - - <p>Kerberos allows us to give <it>each</it> user who needs root - privileges their own <it>separate</it> <tt>su</tt>password. We - could now add an id which is authorized to <tt>su</tt> to <it>root</it>. - This is controlled by having an instance of <it>root</it> associated - with a principal. Using <tt>kdb_edit</tt> we can create the entry - <it>jane.root</it> in the Kerberos database: - -<tscreen><verb> -grunt# kdb_edit -Opening database... - -Enter Kerberos master key: - -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: jane -Instance: root - -<Not found>, Create [y] ? y - -Principal: jane, Instance: root, kdc_key_ver: 1 -New Password: <---- enter a SECURE password here -Verifying password - -New Password: <---- re-enter the password here - -Principal's new key version = 1 -Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? -Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! -Attributes [ 0 ] ? -Edit O.K. -Principal name: <---- null entry here will cause an exit -</verb></tscreen> - - <p>Now try getting tokens for it to make sure it works: - -<tscreen><verb> -grunt# kinit jane.root -MIT Project Athena (grunt.grondar.za) -Kerberos Initialization for "jane.root" -Password: - </verb></tscreen> - - <p>Now we need to add the user to root's <tt>.klogin</tt> file: - -<tscreen><verb> -grunt# cat /root/.klogin -jane.root@GRONDAR.ZA -</verb></tscreen> - - <p>Now try doing the <tt>su</tt>: - -<tscreen><verb> -[jane@grunt 10407] su -Password: -grunt# - </verb></tscreen> - - and take a look at what tokens we have: - -<tscreen><verb> -grunt# klist -Ticket file: /tmp/tkt_root_245 -Principal: jane.root@GRONDAR.ZA - - Issued Expires Principal -May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA -</verb></tscreen> - - <sect1> - <heading>Using other commands</heading> - - <p>In an earlier example, we created a principal called <tt>jane</tt> - with an instance <tt>root</tt>. This was based on a user with the - same name as the principal, and this is a Kerberos default; that a - <em><principal>.<instance></em> of the form - <em><username>.</em><tt>root</tt> will allow that - <em><username></em> to <tt>su</tt> to root if the necessary - entries are in the <tt>.klogin</tt> file in <tt>root</tt>'s home - directory: - -<tscreen><verb> -grunt# cat /root/.klogin -jane.root@GRONDAR.ZA -</verb></tscreen> - - <p>Likewise, if a user has in their own home directory lines of the - form: - -<tscreen><verb> -[jane@grunt 10543] cat ~/.klogin -jane@GRONDAR.ZA -jack@GRONDAR.ZA -</verb></tscreen> - - <p>This allows anyone in the <em>GRONDAR.ZA</em> realm who has - authenticated themselves to <em>jane</em> or <em>jack</em> (via - <tt>kinit</tt>, see above) access to <tt>rlogin</tt> to <em>jane</em>'s - account or files on this system (<em>grunt</em>) via <tt>rlogin</tt>, - <tt>rsh</tt> or <tt>rcp</tt>. - - For example, Jane now logs into another system, using Kerberos: - -<tscreen><verb> -[jane@grumble 573] kinit -MIT Project Athena (grunt.grondar.za) -Password: -[jane@grumble 574] rlogin grunt -Last login: Mon May 1 21:14:47 from grumble -Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 - The Regents of the University of California. All rights reserved. - -FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 - -[jane@grunt 10567] -</verb></tscreen> - - <p>Or Jack logs into Jane's account on the same machine (Jane having set up - the <tt>.klogin</tt> file as above, and the person in charge of Kerberos - having set up principal <em>jack</em> with a null instance: - -<tscreen><verb> -[jack@grumble 573] kinit -[jack@grumble 574] rlogin grunt -l jane -MIT Project Athena (grunt.grondar.za) -Password: -Last login: Mon May 1 21:16:55 from grumble -Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 - The Regents of the University of California. All rights reserved. - -FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 - -[jane@grunt 10578] -</verb></tscreen> |
