svn rev #25652: trunk/doc/rst_source/ krb_admins/install_kdc/ krb_users/user_commands/

tsitkova@MIT.EDU tsitkova at MIT.EDU
Fri Jan 13 13:39:36 EST 2012


http://src.mit.edu/fisheye/changelog/krb5/?cs=25652
Commit By: tsitkova
Log Message:
Reverted reference to klogind. Minor reformating.



Changed Files:
U   trunk/doc/rst_source/krb_admins/install_kdc/slave_install.rst
U   trunk/doc/rst_source/krb_users/user_commands/k5identity.rst
U   trunk/doc/rst_source/krb_users/user_commands/k5login.rst
Modified: trunk/doc/rst_source/krb_admins/install_kdc/slave_install.rst
===================================================================
--- trunk/doc/rst_source/krb_admins/install_kdc/slave_install.rst	2012-01-13 17:35:30 UTC (rev 25651)
+++ trunk/doc/rst_source/krb_admins/install_kdc/slave_install.rst	2012-01-13 18:39:36 UTC (rev 25652)
@@ -1,20 +1,19 @@
 .. _slave_host_key_label:
 
-
-
 Setting up slave KDCs
 ========================================
 
 Prep work on the master side.
 -------------------------------------------
 
-Each KDC needs a *host* keys in the Kerberos database. 
-These keys are used for mutual authentication when propagating the database *dump* file 
-from the master KDC to the secondary KDC servers.
+Each KDC needs a *host* keys in the Kerberos database.
+These keys are used for mutual authentication when propagating the database
+*dump* file from the master KDC to the secondary KDC servers.
 
-On the master KDC connect to administrative interface and create the  new principals for each of the KDCs *host* service.
-For example, if the master KDC were called *kerberos.mit.edu*, and you had slave KDC named *kerberos-1.mit.edu*, 
-you would type the following::
+On the master KDC connect to administrative interface and create
+the new principals for each of the KDCs *host* service.
+For example, if the master KDC were called *kerberos.mit.edu*, and you had
+slave KDC named *kerberos-1.mit.edu*, you would type the following::
 
      shell% /usr/local/bin/kadmin
      kadmin: addprinc -randkey host/kerberos.mit.edu
@@ -26,14 +25,16 @@
      Principal "host/kerberos-1.mit.edu at ATHENA.MIT.EDU" created.
 
 
-It is not actually necessary to have the master KDC server in the Kerberos database, but it can be handy if:
+It is not actually necessary to have the master KDC server in the Kerberos
+database, but it can be handy if:
 
    - anyone will be logging into the machine as something other than *root*
-   - you want to be able to swap the master KDC with one of the slaves if necessary. 
+   - you want to be able to swap the master KDC with one of the slaves if necessary.
 
-Next, extract *host* random keys for all participating KDCs and store them in the default keytab file 
-which is needed to decrypt tickets. Ideally, you should extract each keytab locally on its own KDC. 
-If this is not feasible, you should use an encrypted session to send them across the network. 
+Next, extract *host* random keys for all participating KDCs and store them
+in the default keytab file which is needed to decrypt tickets.
+Ideally, you should extract each keytab locally on its own KDC.
+If this is not feasible, you should use an encrypted session to send them across the network.
 To extract a keytab on a KDC called *kerberos.mit.edu*, you would execute the following command::
 
      kadmin: ktadd host/kerberos.mit.edu
@@ -46,30 +47,34 @@
 
      kadmin:
      
-Move the file /tmp/krb5.keytab (via scp) onto the slave KDC (*kerberos-1.mit.edu*) 
-into exactly the same location as on the master (default is */etc/krb5.keytab*). 
-Remove the temporary copy /tmp/krb5.keytab from the master. 
+Move the file /tmp/krb5.keytab (via scp) onto the slave KDC (*kerberos-1.mit.edu*)
+into exactly the same location as on the master (default is */etc/krb5.keytab*).
+Remove the temporary copy /tmp/krb5.keytab from the master.
 
 
 Configuring the slave
 -------------------------
 
-By default, the propagation is done on the entire content of the master's database. 
-That is, even special principals (like *K/M\@FOOBAR.COM*) will be dumped and copied to the slave KDCs. 
-Pay attention there: it means that configuration files, as also specific files 
+By default, the propagation is done on the entire content of the master's database.
+That is, even special principals (like *K/M\@FOOBAR.COM*) will be dumped and
+copied to the slave KDCs.
+Pay attention there: it means that configuration files, as also specific files
 (like ACLs and :ref:`stash_definition`) must be copied to the slave hosts too.
-Copying only a part of it will result in a bulky situation. If you forget to copy the stash file for example, 
-the KDC daemon on the slave host will not be able to access the propagated database because of missing master key.
-Before connecting to the slave, you will copy all minimum required files from the master for the slave system to work. 
-Initially, it concerns ( See :ref:`mitK5defaults` for the recommended default locations for these files):
+Copying only a part of it will result in a bulky situation.
+If you forget to copy the stash file for example,
+the KDC daemon on the slave host will not be able to access the propagated
+database because of missing master key.
+Before connecting to the slave, you will copy all minimum required files
+from the master for the slave system to work.  Initially, it concerns
+(See :ref:`mitK5defaults` for the recommended default locations for these files):
 
    • krb5.conf 
    • kdc.conf 
    • kadm5.acl 
    • master key stash file 
 
-Connect to the slave, *kerberos-1.mit.edu*. Move the copied files into their appropriate directories 
-(exactly like on the master KDC).
+Connect to the slave, *kerberos-1.mit.edu*. Move the copied files into their
+appropriate directories (exactly like on the master KDC).
 
 You will now initialize the slave database::
 
@@ -78,14 +83,17 @@
 .. caution:: You will use :ref:`kdb5_util(8)` but without exporting the stash file (-s argument), i
              thus avoiding the obliteration of the one you just copied from the master.
 
-When asking for the database Master Password, type in anything you want. 
+When asking for the database Master Password, type in anything you want.
 The whole dummy database will be erased upon the first propagation from master.
 
-The database is propagated from the master KDC to the slave KDCs via the :ref:`kpropd(8)` daemon. 
-You must explicitly specify the clients that are allowed to provide Kerberos dump updates on the slave machine with a new database. 
+The database is propagated from the master KDC to the slave KDCs via
+the :ref:`kpropd(8)` daemon.
+You must explicitly specify the clients that are allowed to provide Kerberos
+dump updates on the slave machine with a new database.
 The *kpropd.acl* file serves as the access control list for the *kpropd* service.
-This file is typically resides in *krb5kdc* local directory. 
-Since in our case the updates should only come from *kerberos.mit.edu* server,  then the file's contents would be::
+This file is typically resides in *krb5kdc* local directory.
+Since in our case the updates should only come from *kerberos.mit.edu* server,
+then the file's contents would be::
 
      host/kerberos.mit.edu at ATHENA.MIT.EDU
 
@@ -94,11 +102,14 @@
           *kpropd.acl* files on *all* of these servers.  
 
 
-Then, add the following line to */etc/inetd.conf* file on each KDC (Adjust the path to *kpropd*)::
+Then, add the following line to */etc/inetd.conf* file on each KDC
+(Adjust the path to *kpropd*)::
 
      krb5_prop stream tcp nowait root /usr/local/sbin/kpropd kpropd
+     eklogin stream tcp nowait root  /usr/local/sbin/klogind klogind -5 -c -e
 
-You also need to add the following lines to */etc/services* on each KDC (assuming that default ports are used)::
+You also need to add the following lines to */etc/services* on each KDC
+(assuming that default ports are used)::
 
      kerberos        88/udp      kdc       # Kerberos authentication (udp)
      kerberos        88/tcp      kdc       # Kerberos authentication (tcp)
@@ -116,17 +127,14 @@
 
     waiting for a kprop connection
 
-Now that the slave KDC is able to accept database propagation, you’ll need to propagate the database from the master server.
+Now that the slave KDC is able to accept database propagation,
+you’ll need to propagate the database from the master server.
 
 NOTE: Do not start slave KDC -  you still do not have a copy of the master's database.
 
-
 ------------
 
 Feedback:
 
 Please, provide your feedback or suggest a new topic at krb5-bugs at mit.edu?subject=Documentation___install_kdc
 
-
-
-

Modified: trunk/doc/rst_source/krb_users/user_commands/k5identity.rst
===================================================================
--- trunk/doc/rst_source/krb_users/user_commands/k5identity.rst	2012-01-13 17:35:30 UTC (rev 25651)
+++ trunk/doc/rst_source/krb_users/user_commands/k5identity.rst	2012-01-13 18:39:36 UTC (rev 25652)
@@ -4,19 +4,19 @@
 DESCRIPTION
 -------------
 
-The *.k5identity*  file, which resides in a user's home directory, 
-contains a list of rules for selecting a client principals based on 
-the server being accessed. These rules are used to choose a credential 
+The *.k5identity*  file, which resides in a user's home directory,
+contains a list of rules for selecting a client principals based on
+the server being accessed. These rules are used to choose a credential
 cache within the cache collection when possible.
 
 Blank lines and lines beginning with '#' are ignored.  Each line has the form:
 
         principal field=value ...
 
-If the server principal meets all of the field constraints, then principal 
+If the server principal meets all of the field constraints, then principal
 is chosen as the client principal.  The following fields are recognized:
 
-**realm**  
+**realm** 
         If the realm of the server principal is known, it is matched
         against *value*, which may be a pattern using shell wildcards.
         For host-based server principals, the realm will generally only

Modified: trunk/doc/rst_source/krb_users/user_commands/k5login.rst
===================================================================
--- trunk/doc/rst_source/krb_users/user_commands/k5login.rst	2012-01-13 17:35:30 UTC (rev 25651)
+++ trunk/doc/rst_source/krb_users/user_commands/k5login.rst	2012-01-13 18:39:36 UTC (rev 25652)
@@ -4,11 +4,11 @@
 DESCRIPTION
 --------------
 
-The *.k5login* file, which resides in a user's home directory, 
+The *.k5login* file, which resides in a user's home directory,
 contains a list of the Kerberos principals.
-Anyone with valid tickets for a principal in the file is allowed host access 
-with the UID of the user in whose home directory the file resides.  
-One common use is to place a *.k5login* file in root's home directory, 
+Anyone with valid tickets for a principal in the file is allowed host access
+with the UID of the user in whose home directory the file resides.
+One common use is to place a *.k5login* file in root's home directory,
 thereby granting system administrators remote root access to the host via Kerberos.
 
 EXAMPLES
@@ -18,8 +18,8 @@
 
         bob\@FOOBAR.ORG
 
-This would allow *bob* to use any of the Kerberos network applications, 
-such as telnet(1), rlogin(1), rsh(1), and rcp(1), 
+This would allow *bob* to use any of the Kerberos network applications,
+such as telnet(1), rlogin(1), rsh(1), and rcp(1),
 to access *alice*'s account, using *bob*'s Kerberos tickets.
 
 Let us further suppose that *alice* is a system administrator.
@@ -31,14 +31,14 @@
         joeadmin/root\@BLEEP.COM
 
 This would allow either system administrator to log in to these hosts 
-using their Kerberos tickets instead of having to type the root password.  
-Note that because *bob* retains the Kerberos tickets for his own principal, 
-"bob\@FOOBAR.ORG", he would not have any of the privileges that require *alice*'s tickets, 
-such as root access to any of the site's hosts, 
+using their Kerberos tickets instead of having to type the root password.
+Note that because *bob* retains the Kerberos tickets for his own principal,
+"bob\@FOOBAR.ORG", he would not have any of the privileges that require *alice*'s tickets,
+such as root access to any of the site's hosts,
 or the ability to change *alice*'s password.
 
 SEE ALSO
 -----------
 
-telnet(1), rlogin(1), rsh(1), rcp(1), ksu(1), telnetd(8)
+telnet(1), rlogin(1), rsh(1), rcp(1), ksu(1), telnetd(8), klogind(8)
 



More information about the cvs-krb5 mailing list