From 4133ea006c282b31d421de5ed844f62f75ab8ba5 Mon Sep 17 00:00:00 2001 From: Zhanna Tsitkov Date: Fri, 13 Jan 2012 18:39:36 +0000 Subject: [PATCH] Reverted reference to klogind. Minor reformating git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@25652 dc483132-0cff-0310-8789-dd5450dbe970 --- .../krb_admins/install_kdc/slave_install.rst | 82 ++++++++++--------- .../krb_users/user_commands/k5identity.rst | 10 +-- .../krb_users/user_commands/k5login.rst | 22 ++--- 3 files changed, 61 insertions(+), 53 deletions(-) diff --git a/doc/rst_source/krb_admins/install_kdc/slave_install.rst b/doc/rst_source/krb_admins/install_kdc/slave_install.rst index 6471ec9ec..87f426ca2 100644 --- a/doc/rst_source/krb_admins/install_kdc/slave_install.rst +++ b/doc/rst_source/krb_admins/install_kdc/slave_install.rst @@ -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 @@ you would type the following:: Principal "host/kerberos-1.mit.edu@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 @@ To extract a keytab on a KDC called *kerberos.mit.edu*, you would execute the fo 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 @@ You will now initialize the slave database:: .. 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@ATHENA.MIT.EDU @@ -94,11 +102,14 @@ Since in our case the updates should only come from *kerberos.mit.edu* server, *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 @@ if the default locations must be overridden,:: 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@mit.edu?subject=Documentation___install_kdc - - - diff --git a/doc/rst_source/krb_users/user_commands/k5identity.rst b/doc/rst_source/krb_users/user_commands/k5identity.rst index e728c78f7..f6cdda352 100644 --- a/doc/rst_source/krb_users/user_commands/k5identity.rst +++ b/doc/rst_source/krb_users/user_commands/k5identity.rst @@ -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 diff --git a/doc/rst_source/krb_users/user_commands/k5login.rst b/doc/rst_source/krb_users/user_commands/k5login.rst index eb76f0501..4e4764443 100644 --- a/doc/rst_source/krb_users/user_commands/k5login.rst +++ b/doc/rst_source/krb_users/user_commands/k5login.rst @@ -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 @@ Suppose the user *alice* had a *.k5login* file in her home directory containing 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 @@ in root's *.k5login* file on each host: 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) -- 2.26.2