krb5: Import MIT 1.21.3 - src - FreeBSD source tree

diff options


context:
space:
mode:

author	Cy Schubert <cy@FreeBSD.org>	2025-03-19 22:12:25 +0000
committer	Cy Schubert <cy@FreeBSD.org>	2025-03-19 22:12:25 +0000
commit	8f7d3ef26dec89a92ec0665de84a5936310a5574 (patch)
tree	9a465418bd4056bf0d369751320a414eaed29fa4 /doc/html/admin/database.html
parent	1a79b20663ca26acc2998b90ea2ff2aefd8af5b1 (diff)

Diffstat (limited to 'doc/html/admin/database.html')

-rw-r--r--

doc/html/admin/database.html

336

1 files changed, 162 insertions, 174 deletions

diff --git a/doc/html/admin/database.html b/doc/html/admin/database.html
index 6f66dcfb4c45..2c668f64551d 100644
--- a/doc/html/admin/database.html
+++ b/doc/html/admin/database.html

@@ -1,35 +1,26 @@

-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

+<!DOCTYPE html>

-<html xmlns="http://www.w3.org/1999/xhtml">

+<html>

<head>

- <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

+ <meta charset="utf-8" />

+ <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.17.1: http://docutils.sourceforge.net/" />

<title>Database administration — MIT Kerberos Documentation</title>

- <link rel="stylesheet" href="../_static/agogo.css" type="text/css" />

- <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />

- <link rel="stylesheet" href="../_static/kerb.css" type="text/css" />

- <script type="text/javascript">

- var DOCUMENTATION_OPTIONS = {

- URL_ROOT: '../',

- VERSION: '1.21.2',

- COLLAPSE_INDEX: false,

- FILE_SUFFIX: '.html',

- HAS_SOURCE: true,

- SOURCELINK_SUFFIX: '.txt'

- };

- </script>

- <script type="text/javascript" src="../_static/jquery.js"></script>

- <script type="text/javascript" src="../_static/underscore.js"></script>

- <script type="text/javascript" src="../_static/doctools.js"></script>

+ <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />

+ <link rel="stylesheet" type="text/css" href="../_static/agogo.css" />

+ <link rel="stylesheet" type="text/css" href="../_static/kerb.css" />

+ <script data-url_root="../" id="documentation_options" src="../_static/documentation_options.js"></script>

+ <script src="../_static/jquery.js"></script>

+ <script src="../_static/underscore.js"></script>

+ <script src="../_static/doctools.js"></script>

- </head>

- <body>

+ </head><body>

@@ -61,7 +52,7 @@

- <div class="section" id="database-administration">

+ <section id="database-administration">

<h1>Database administration<a class="headerlink" href="#database-administration" title="Permalink to this headline">¶</a></h1>

<p>A Kerberos database contains all of a realm’s Kerberos principals,

their passwords, and other administrative information about each

@@ -85,36 +76,37 @@ kadmin.local, which directly accesses the Kerberos database on the

local filesystem (or through LDAP). kadmin.local is necessary to set

up enough of the database to be able to use the remote version.</p>

<p>kadmin can authenticate to the admin server using the service

-principal <code class="docutils literal"><span class="pre">kadmin/admin</span></code> or <code class="docutils literal"><span class="pre">kadmin/HOST</span></code> (where <em>HOST</em> is the

+principal <code class="docutils literal notranslate"><span class="pre">kadmin/admin</span></code> or <code class="docutils literal notranslate"><span class="pre">kadmin/HOST</span></code> (where <em>HOST</em> is the

hostname of the admin server). If the credentials cache contains a

ticket for either service principal and the <strong>-c</strong> ccache option is

specified, that ticket is used to authenticate to KADM5. Otherwise,

the <strong>-p</strong> and <strong>-k</strong> options are used to specify the client Kerberos

principal name used to authenticate. Once kadmin has determined the

-principal name, it requests a <code class="docutils literal"><span class="pre">kadmin/admin</span></code> Kerberos service ticket

+principal name, it requests a <code class="docutils literal notranslate"><span class="pre">kadmin/admin</span></code> Kerberos service ticket

from the KDC, and uses that service ticket to authenticate to KADM5.</p>

<p>See <a class="reference internal" href="admin_commands/kadmin_local.html#kadmin-1"><span class="std std-ref">kadmin</span></a> for the available kadmin and kadmin.local

commands and options.</p>

-<div class="section" id="principals">

+<section id="principals">

<span id="id1"></span><h2>Principals<a class="headerlink" href="#principals" title="Permalink to this headline">¶</a></h2>

<p>Each entry in the Kerberos database contains a Kerberos principal and

the attributes and policies associated with that principal.</p>

<p>To add a principal to the database, use the <a class="reference internal" href="admin_commands/kadmin_local.html#kadmin-1"><span class="std std-ref">kadmin</span></a>

<strong>add_principal</strong> command. User principals should usually be created

-with the <code class="docutils literal"><span class="pre">+requires_preauth</span> <span class="pre">-allow_svr</span></code> options to help mitigate

+with the <code class="docutils literal notranslate"><span class="pre">+requires_preauth</span> <span class="pre">-allow_svr</span></code> options to help mitigate

dictionary attacks (see <a class="reference internal" href="dictionary.html#dictionary"><span class="std std-ref">Addressing dictionary attack risks</span></a>):</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">kadmin</span><span class="p">:</span> <span class="n">addprinc</span> <span class="o">+</span><span class="n">requires_preauth</span> <span class="o">-</span><span class="n">allow_svr</span> <span class="n">alice</span>

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">kadmin</span><span class="p">:</span> <span class="n">addprinc</span> <span class="o">+</span><span class="n">requires_preauth</span> <span class="o">-</span><span class="n">allow_svr</span> <span class="n">alice</span>

<span class="n">Enter</span> <span class="n">password</span> <span class="k">for</span> <span class="n">principal</span> <span class="s2">"alice@KRBTEST.COM"</span><span class="p">:</span>

</pre></div>

</div>

<p>User principals which will authenticate with <a class="reference internal" href="pkinit.html#pkinit"><span class="std std-ref">PKINIT configuration</span></a> should

-instead by created with the <code class="docutils literal"><span class="pre">-nokey</span></code> option:</p>

+instead by created with the <code class="docutils literal notranslate"><span class="pre">-nokey</span></code> option:</p>

-<div>kadmin: addprinc -nokey alice</div></blockquote>

-<p>Service principals can be created with the <code class="docutils literal"><span class="pre">-nokey</span></code> option;

+<div><p>kadmin: addprinc -nokey alice</p>

+</div></blockquote>

+<p>Service principals can be created with the <code class="docutils literal notranslate"><span class="pre">-nokey</span></code> option;

long-term keys will be added when a keytab is generated:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">kadmin</span><span class="p">:</span> <span class="n">addprinc</span> <span class="o">-</span><span class="n">nokey</span> <span class="n">host</span><span class="o">/</span><span class="n">foo</span><span class="o">.</span><span class="n">mit</span><span class="o">.</span><span class="n">edu</span>

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">kadmin</span><span class="p">:</span> <span class="n">addprinc</span> <span class="o">-</span><span class="n">nokey</span> <span class="n">host</span><span class="o">/</span><span class="n">foo</span><span class="o">.</span><span class="n">mit</span><span class="o">.</span><span class="n">edu</span>

<span class="n">kadmin</span><span class="p">:</span> <span class="n">ktadd</span> <span class="o">-</span><span class="n">k</span> <span class="n">foo</span><span class="o">.</span><span class="n">keytab</span> <span class="n">host</span><span class="o">/</span><span class="n">foo</span><span class="o">.</span><span class="n">mit</span><span class="o">.</span><span class="n">edu</span>

<span class="n">Entry</span> <span class="k">for</span> <span class="n">principal</span> <span class="n">host</span><span class="o">/</span><span class="n">foo</span><span class="o">.</span><span class="n">mit</span><span class="o">.</span><span class="n">edu</span> <span class="k">with</span> <span class="n">kvno</span> <span class="mi">1</span><span class="p">,</span> <span class="n">encryption</span> <span class="nb">type</span> <span class="n">aes256</span><span class="o">-</span><span class="n">cts</span><span class="o">-</span><span class="n">hmac</span><span class="o">-</span><span class="n">sha1</span><span class="o">-</span><span class="mi">96</span> <span class="n">added</span> <span class="n">to</span> <span class="n">keytab</span> <span class="n">WRFILE</span><span class="p">:</span><span class="n">foo</span><span class="o">.</span><span class="n">keytab</span><span class="o">.</span>

<span class="n">Entry</span> <span class="k">for</span> <span class="n">principal</span> <span class="n">host</span><span class="o">/</span><span class="n">foo</span><span class="o">.</span><span class="n">mit</span><span class="o">.</span><span class="n">edu</span> <span class="k">with</span> <span class="n">kvno</span> <span class="mi">1</span><span class="p">,</span> <span class="n">encryption</span> <span class="nb">type</span> <span class="n">aes128</span><span class="o">-</span><span class="n">cts</span><span class="o">-</span><span class="n">hmac</span><span class="o">-</span><span class="n">sha1</span><span class="o">-</span><span class="mi">96</span> <span class="n">added</span> <span class="n">to</span> <span class="n">keytab</span> <span class="n">WRFILE</span><span class="p">:</span><span class="n">foo</span><span class="o">.</span><span class="n">keytab</span><span class="o">.</span>

@@ -122,12 +114,12 @@ long-term keys will be added when a keytab is generated:</p>

</div>

<p>To modify attributes of an existing principal, use the kadmin

<strong>modify_principal</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">kadmin</span><span class="p">:</span> <span class="n">modprinc</span> <span class="o">-</span><span class="n">expire</span> <span class="n">tomorrow</span> <span class="n">alice</span>

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">kadmin</span><span class="p">:</span> <span class="n">modprinc</span> <span class="o">-</span><span class="n">expire</span> <span class="n">tomorrow</span> <span class="n">alice</span>

<span class="n">Principal</span> <span class="s2">"alice@KRBTEST.COM"</span> <span class="n">modified</span><span class="o">.</span>

</pre></div>

</div>

<p>To delete a principal, use the kadmin <strong>delete_principal</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>kadmin: delprinc alice

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>kadmin: delprinc alice

Are you sure you want to delete the principal "alice@KRBTEST.COM"? (yes/no): yes

Principal "alice@KRBTEST.COM" deleted.

Make sure that you have removed this principal from all ACLs before reusing.

@@ -141,15 +133,15 @@ password policies as would apply to password changes made through

<strong>get_principal</strong> command.</p>

<p>To generate a listing of principals, use the kadmin

<strong>list_principals</strong> command.</p>

-</div>

-<div class="section" id="policies">

+</section>

+<section id="policies">

<span id="id2"></span><h2>Policies<a class="headerlink" href="#policies" title="Permalink to this headline">¶</a></h2>

<p>A policy is a set of rules governing passwords. Policies can dictate

minimum and maximum password lifetimes, minimum number of characters

and character classes a password must contain, and the number of old

passwords kept in the database.</p>

<p>To add a new policy, use the <a class="reference internal" href="admin_commands/kadmin_local.html#kadmin-1"><span class="std std-ref">kadmin</span></a> <strong>add_policy</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">kadmin</span><span class="p">:</span> <span class="n">addpol</span> <span class="o">-</span><span class="n">maxlife</span> <span class="s2">"1 year"</span> <span class="o">-</span><span class="n">history</span> <span class="mi">3</span> <span class="n">stduser</span>

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">kadmin</span><span class="p">:</span> <span class="n">addpol</span> <span class="o">-</span><span class="n">maxlife</span> <span class="s2">"1 year"</span> <span class="o">-</span><span class="n">history</span> <span class="mi">3</span> <span class="n">stduser</span>

</pre></div>

</div>

<p>To modify attributes of a principal, use the kadmin <strong>modify_policy</strong>

@@ -158,23 +150,24 @@ command.</p>

<p>To associate a policy with a principal, use the kadmin

<strong>modify_principal</strong> command with the <strong>-policy</strong> option:</p>

-<div>kadmin: modprinc -policy stduser alice

-Principal “<a class="reference external" href="mailto:alice%40KRBTEST.COM">alice<span>@</span>KRBTEST<span>.</span>COM</a>” modified.</div></blockquote>

+<div><p>kadmin: modprinc -policy stduser alice

+Principal “<a class="reference external" href="mailto:alice%40KRBTEST.COM">alice<span>@</span>KRBTEST<span>.</span>COM</a>” modified.</p>

+</div></blockquote>

<p>A principal entry may be associated with a nonexistent policy, either

because the policy did not exist at the time of associated or was

deleted afterwards. kadmin will warn when associated a principal with

a nonexistent policy, and will annotate the policy name with “[does

not exist]” in the <strong>get_principal</strong> output.</p>

-<div class="section" id="updating-the-history-key">

+<section id="updating-the-history-key">

<span id="updating-history-key"></span><h3>Updating the history key<a class="headerlink" href="#updating-the-history-key" title="Permalink to this headline">¶</a></h3>

<p>If a policy specifies a number of old keys kept of two or more, the

stored old keys are encrypted in a history key, which is found in the

-key data of the <code class="docutils literal"><span class="pre">kadmin/history</span></code> principal.</p>

+key data of the <code class="docutils literal notranslate"><span class="pre">kadmin/history</span></code> principal.</p>

<p>Currently there is no support for proper rollover of the history key,

but you can change the history key (for example, to use a better

encryption type) at the cost of invalidating currently stored old

keys. To change the history key, run:</p>

</pre></div>

</div>

<p>This command will fail if you specify the <strong>-keepold</strong> flag. Only one

@@ -183,53 +176,53 @@ combinations.</p>

<p>In the future, we plan to migrate towards encrypting old keys in the

master key instead of the history key, and implementing proper

rollover support for stored old keys.</p>

-</div>

-<div class="section" id="privileges">

+</section>

+<section id="privileges">

<span id="id3"></span><h2>Privileges<a class="headerlink" href="#privileges" title="Permalink to this headline">¶</a></h2>

<p>Administrative privileges for the Kerberos database are stored in the

file <a class="reference internal" href="conf_files/kadm5_acl.html#kadm5-acl-5"><span class="std std-ref">kadm5.acl</span></a>.</p>

-<p class="first admonition-title">Note</p>

-<p class="last">A common use of an admin instance is so you can grant

+<p class="admonition-title">Note</p>

+<p>A common use of an admin instance is so you can grant

separate permissions (such as administrator access to the

Kerberos database) to a separate Kerberos principal. For

-example, the user <code class="docutils literal"><span class="pre">joeadmin</span></code> might have a principal for

-his administrative use, called <code class="docutils literal"><span class="pre">joeadmin/admin</span></code>. This

-way, <code class="docutils literal"><span class="pre">joeadmin</span></code> would obtain <code class="docutils literal"><span class="pre">joeadmin/admin</span></code> tickets

+example, the user <code class="docutils literal notranslate"><span class="pre">joeadmin</span></code> might have a principal for

+his administrative use, called <code class="docutils literal notranslate"><span class="pre">joeadmin/admin</span></code>. This

+way, <code class="docutils literal notranslate"><span class="pre">joeadmin</span></code> would obtain <code class="docutils literal notranslate"><span class="pre">joeadmin/admin</span></code> tickets

only when he actually needs to use those permissions.</p>

</div>

-</div>

-<div class="section" id="operations-on-the-kerberos-database">

+</section>

+<section id="operations-on-the-kerberos-database">

<span id="db-operations"></span><h2>Operations on the Kerberos database<a class="headerlink" href="#operations-on-the-kerberos-database" title="Permalink to this headline">¶</a></h2>

<p>The <a class="reference internal" href="admin_commands/kdb5_util.html#kdb5-util-8"><span class="std std-ref">kdb5_util</span></a> command is the primary tool for administrating

the Kerberos database when using the DB2 or LMDB modules (see

<a class="reference internal" href="dbtypes.html#dbtypes"><span class="std std-ref">Database types</span></a>). Creating a database is described in

<a class="reference internal" href="install_kdc.html#create-db"><span class="std std-ref">Create the KDC database</span></a>.</p>

<p>To create a stash file using the master password (because the database

-was not created with one using the <code class="docutils literal"><span class="pre">create</span> <span class="pre">-s</span></code> flag, or after

+was not created with one using the <code class="docutils literal notranslate"><span class="pre">create</span> <span class="pre">-s</span></code> flag, or after

restoring from a backup which did not contain the stash file), use the

kdb5_util <strong>stash</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_util stash

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_util stash

kdb5_util: Cannot find/read stored master key while reading master key

kdb5_util: Warning: proceeding without master key

Enter KDC database master key: <= Type the KDC database master password.

</pre></div>

</div>

<p>To destroy a database, use the kdb5_util destroy command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_util destroy

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_util destroy

Deleting KDC database stored in '/var/krb5kdc/principal', are you sure?

(type 'yes' to confirm)? yes

OK, deleting database '/var/krb5kdc/principal'...

** Database '/var/krb5kdc/principal' destroyed.

</pre></div>

</div>

-<div class="section" id="dumping-and-loading-a-kerberos-database">

+<section id="dumping-and-loading-a-kerberos-database">

<span id="restore-from-dump"></span><h3>Dumping and loading a Kerberos database<a class="headerlink" href="#dumping-and-loading-a-kerberos-database" title="Permalink to this headline">¶</a></h3>

<p>To dump a Kerberos database into a text file for backup or transfer

purposes, use the <a class="reference internal" href="admin_commands/kdb5_util.html#kdb5-util-8"><span class="std std-ref">kdb5_util</span></a> <strong>dump</strong> command on one of the

KDCs:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_util dump dumpfile

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_util dump dumpfile

$ kbd5_util dump -verbose dumpfile

kadmin/admin@ATHENA.MIT.EDU

@@ -241,122 +234,114 @@ kadmin/changepw@ATHENA.MIT.EDU

</div>

<p>You may specify which principals to dump, using full principal names

including realm:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_util dump -verbose someprincs K/M@ATHENA.MIT.EDU kadmin/admin@ATHENA.MIT.EDU

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_util dump -verbose someprincs K/M@ATHENA.MIT.EDU kadmin/admin@ATHENA.MIT.EDU

kadmin/admin@ATHENA.MIT.EDU

K/M@ATHENA.MIT.EDU

</pre></div>

</div>

<p>To restore a Kerberos database dump from a file, use the

<a class="reference internal" href="admin_commands/kdb5_util.html#kdb5-util-8"><span class="std std-ref">kdb5_util</span></a> <strong>load</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_util load dumpfile

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_util load dumpfile

</pre></div>

</div>

<p>To update an existing database with a partial dump file containing

-only some principals, use the <code class="docutils literal"><span class="pre">-update</span></code> flag:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_util load -update someprincs

+only some principals, use the <code class="docutils literal notranslate"><span class="pre">-update</span></code> flag:</p>

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_util load -update someprincs

</pre></div>

</div>

-<p class="first admonition-title">Note</p>

-<p class="last">If the database file exists, and the <em>-update</em> flag was not

+<p class="admonition-title">Note</p>

+<p>If the database file exists, and the <em>-update</em> flag was not

given, <em>kdb5_util</em> will overwrite the existing database.</p>

</div>

-</div>

-<div class="section" id="updating-the-master-key">

+</section>

+<section id="updating-the-master-key">

<span id="updating-master-key"></span><h3>Updating the master key<a class="headerlink" href="#updating-the-master-key" title="Permalink to this headline">¶</a></h3>

<p>Starting with release 1.7, <a class="reference internal" href="admin_commands/kdb5_util.html#kdb5-util-8"><span class="std std-ref">kdb5_util</span></a> allows the master key

to be changed using a rollover process, with minimal loss of

availability. To roll over the master key, follow these steps:</p>

-<li><p class="first">On the primary KDC, run <code class="docutils literal"><span class="pre">kdb5_util</span> <span class="pre">list_mkeys</span></code> to view the

+<li><p>On the primary KDC, run <code class="docutils literal notranslate"><span class="pre">kdb5_util</span> <span class="pre">list_mkeys</span></code> to view the

current master key version number (KVNO). If you have never rolled

over the master key before, this will likely be version 1:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_util list_mkeys

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_util list_mkeys

Master keys for Principal: K/M@KRBTEST.COM

KVNO: 1, Enctype: aes256-cts-hmac-sha384-192, Active on: Thu Jan 01 00:00:00 UTC 1970 *

</pre></div>

</div>

</li>

-<li><p class="first">On the primary KDC, run <code class="docutils literal"><span class="pre">kdb5_util</span> <span class="pre">use_mkey</span> <span class="pre">1</span></code> to ensure that a

+<li><p>On the primary KDC, run <code class="docutils literal notranslate"><span class="pre">kdb5_util</span> <span class="pre">use_mkey</span> <span class="pre">1</span></code> to ensure that a

master key activation list is present in the database. This step

is unnecessary in release 1.11.4 or later, or if the database was

-initially created with release 1.7 or later.</p>

-</li>

-<li><p class="first">On the primary KDC, run <code class="docutils literal"><span class="pre">kdb5_util</span> <span class="pre">add_mkey</span> <span class="pre">-s</span></code> to create a new

+initially created with release 1.7 or later.</p></li>

+<li><p>On the primary KDC, run <code class="docutils literal notranslate"><span class="pre">kdb5_util</span> <span class="pre">add_mkey</span> <span class="pre">-s</span></code> to create a new

master key and write it to the stash file. Enter a secure password

when prompted. If this is the first time you are changing the

master key, the new key will have version 2. The new master key

-will not be used until you make it active.</p>

-</li>

-<li><p class="first">Propagate the database to all replica KDCs, either manually or by

+will not be used until you make it active.</p></li>

+<li><p>Propagate the database to all replica KDCs, either manually or by

waiting until the next scheduled propagation. If you do not have

-any replica KDCs, you can skip this and the next step.</p>

-</li>

-<li><p class="first">On each replica KDC, run <code class="docutils literal"><span class="pre">kdb5_util</span> <span class="pre">list_mkeys</span></code> to verify that

-the new master key is present, and then <code class="docutils literal"><span class="pre">kdb5_util</span> <span class="pre">stash</span></code> to

-write the new master key to the replica KDC’s stash file.</p>

-</li>

-<li><p class="first">On the primary KDC, run <code class="docutils literal"><span class="pre">kdb5_util</span> <span class="pre">use_mkey</span> <span class="pre">2</span></code> to begin using the

-new master key. Replace <code class="docutils literal"><span class="pre">2</span></code> with the version of the new master

+any replica KDCs, you can skip this and the next step.</p></li>

+<li><p>On each replica KDC, run <code class="docutils literal notranslate"><span class="pre">kdb5_util</span> <span class="pre">list_mkeys</span></code> to verify that

+the new master key is present, and then <code class="docutils literal notranslate"><span class="pre">kdb5_util</span> <span class="pre">stash</span></code> to

+write the new master key to the replica KDC’s stash file.</p></li>

+<li><p>On the primary KDC, run <code class="docutils literal notranslate"><span class="pre">kdb5_util</span> <span class="pre">use_mkey</span> <span class="pre">2</span></code> to begin using the

+new master key. Replace <code class="docutils literal notranslate"><span class="pre">2</span></code> with the version of the new master

key, as appropriate. You can optionally specify a date for the new

master key to become active; by default, it will become active

immediately. Prior to release 1.12, <a class="reference internal" href="admin_commands/kadmind.html#kadmind-8"><span class="std std-ref">kadmind</span></a> must be

-restarted for this change to take full effect.</p>

-</li>

-<li><p class="first">On the primary KDC, run <code class="docutils literal"><span class="pre">kdb5_util</span> <span class="pre">update_princ_encryption</span></code>.

+restarted for this change to take full effect.</p></li>

+<li><p>On the primary KDC, run <code class="docutils literal notranslate"><span class="pre">kdb5_util</span> <span class="pre">update_princ_encryption</span></code>.

This command will iterate over the database and re-encrypt all keys

in the new master key. If the database is large and uses DB2, the

primary KDC will become unavailable while this command runs, but

clients should fail over to replica KDCs (if any are present)

during this time period. In release 1.13 and later, you can

-instead run <code class="docutils literal"><span class="pre">kdb5_util</span> <span class="pre">-x</span> <span class="pre">unlockiter</span> <span class="pre">update_princ_encryption</span></code> to

+instead run <code class="docutils literal notranslate"><span class="pre">kdb5_util</span> <span class="pre">-x</span> <span class="pre">unlockiter</span> <span class="pre">update_princ_encryption</span></code> to

use unlocked iteration; this variant will take longer, but will

-keep the database available to the KDC and kadmind while it runs.</p>

-</li>

-<li><p class="first">Wait until the above changes have propagated to all replica KDCs

+keep the database available to the KDC and kadmind while it runs.</p></li>

+<li><p>Wait until the above changes have propagated to all replica KDCs

and until all running KDC and kadmind processes have serviced

-requests using updated principal entries.</p>

-</li>

-<li><p class="first">On the primary KDC, run <code class="docutils literal"><span class="pre">kdb5_util</span> <span class="pre">purge_mkeys</span></code> to clean up the

-old master key.</p>

-</li>

+requests using updated principal entries.</p></li>

+<li><p>On the primary KDC, run <code class="docutils literal notranslate"><span class="pre">kdb5_util</span> <span class="pre">purge_mkeys</span></code> to clean up the

+old master key.</p></li>

</ol>

-</div>

-<div class="section" id="operations-on-the-ldap-database">

+</section>

+<section id="operations-on-the-ldap-database">

<span id="ops-on-ldap"></span><h2>Operations on the LDAP database<a class="headerlink" href="#operations-on-the-ldap-database" title="Permalink to this headline">¶</a></h2>

<p>The <a class="reference internal" href="admin_commands/kdb5_ldap_util.html#kdb5-ldap-util-8"><span class="std std-ref">kdb5_ldap_util</span></a> command is the primary tool for

administrating the Kerberos database when using the LDAP module.

Creating an LDAP Kerberos database is describe in <a class="reference internal" href="conf_ldap.html#conf-ldap"><span class="std std-ref">Configuring Kerberos with OpenLDAP back-end</span></a>.</p>

<p>To view a list of realms in the LDAP database, use the kdb5_ldap_util

<strong>list</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_ldap_util list

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_ldap_util list

KRBTEST.COM

</pre></div>

</div>

<p>To modify the attributes of a realm, use the kdb5_ldap_util <strong>modify</strong>

command. For example, to change the default realm’s maximum ticket

life:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_ldap_util modify -maxtktlife "10 hours"

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_ldap_util modify -maxtktlife "10 hours"

</pre></div>

</div>

<p>To display the attributes of a realm, use the kdb5_ldap_util <strong>view</strong>

command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_ldap_util view

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_ldap_util view

Realm Name: KRBTEST.COM

Maximum Ticket Life: 0 days 00:10:00

</pre></div>

</div>

<p>To remove a realm from the LDAP database, destroying its contents, use

the kdb5_ldap_util <strong>destroy</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_ldap_util destroy

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_ldap_util destroy

Deleting KDC database of 'KRBTEST.COM', are you sure?

(type 'yes' to confirm)? yes

OK, deleting database of 'KRBTEST.COM'...

** Database of 'KRBTEST.COM' destroyed.

</pre></div>

</div>

-<div class="section" id="ticket-policy-operations">

+<section id="ticket-policy-operations">

<h3>Ticket Policy operations<a class="headerlink" href="#ticket-policy-operations" title="Permalink to this headline">¶</a></h3>

<p>Unlike the DB2 and LMDB modules, the LDAP module supports ticket

policy objects, which can be associated with principals to restrict

@@ -365,34 +350,34 @@ policy objects are distinct from the password policies described

earlier on this page, and are chiefly managed through kdb5_ldap_util

rather than kadmin. To create a new ticket policy, use the

kdb5_ldap_util <strong>create_policy</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_ldap_util create_policy -maxrenewlife "2 days" users

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_ldap_util create_policy -maxrenewlife "2 days" users

</pre></div>

</div>

<p>To associate a ticket policy with a principal, use the

<a class="reference internal" href="admin_commands/kadmin_local.html#kadmin-1"><span class="std std-ref">kadmin</span></a> <strong>modify_principal</strong> (or <strong>add_principal</strong>) command

with the <strong>-x tktpolicy=</strong><em>policy</em> option:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kadmin.local modprinc -x tktpolicy=users alice

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kadmin.local modprinc -x tktpolicy=users alice

</pre></div>

</div>

<p>To remove a ticket policy reference from a principal, use the same

command with an empty <em>policy</em>:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kadmin.local modprinc -x tktpolicy= alice

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kadmin.local modprinc -x tktpolicy= alice

</pre></div>

</div>

<p>To list the existing ticket policy objects, use the kdb5_ldap_util

<strong>list_policy</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_ldap_util list_policy

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_ldap_util list_policy

users

</pre></div>

</div>

<p>To modify the attributes of a ticket policy object, use the

kdb5_ldap_util <strong>modify_policy</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_ldap_util modify_policy -allow_svr +requires_preauth users

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_ldap_util modify_policy -allow_svr +requires_preauth users

</pre></div>

</div>

<p>To view the attributes of a ticket policy object, use the

kdb5_ldap_util <strong>view_policy</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_ldap_util view_policy users

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_ldap_util view_policy users

Ticket policy: users

Maximum renewable life: 2 days 00:00:00

Ticket flags: REQUIRES_PRE_AUTH DISALLOW_SVR

@@ -400,29 +385,29 @@ kdb5_ldap_util <strong>view_policy</strong> command:</p>

</div>

<p>To destroy an ticket policy object, use the kdb5_ldap_util

<strong>destroy_policy</strong> command:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span>$ kdb5_ldap_util destroy_policy users

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ kdb5_ldap_util destroy_policy users

This will delete the policy object 'users', are you sure?

(type 'yes' to confirm)? yes

** policy object 'users' deleted.

</pre></div>

</div>

-</div>

-<div class="section" id="cross-realm-authentication">

+</section>

+<section id="cross-realm-authentication">

<span id="xrealm-authn"></span><h2>Cross-realm authentication<a class="headerlink" href="#cross-realm-authentication" title="Permalink to this headline">¶</a></h2>

<p>In order for a KDC in one realm to authenticate Kerberos users in a

different realm, it must share a key with the KDC in the other realm.

In both databases, there must be krbtgt service principals for both realms.

For example, if you need to do cross-realm authentication between the realms

-<code class="docutils literal"><span class="pre">ATHENA.MIT.EDU</span></code> and <code class="docutils literal"><span class="pre">EXAMPLE.COM</span></code>, you would need to add the

-principals <code class="docutils literal"><span class="pre">krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU</span></code> and

-<code class="docutils literal"><span class="pre">krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM</span></code> to both databases.

+<code class="docutils literal notranslate"><span class="pre">ATHENA.MIT.EDU</span></code> and <code class="docutils literal notranslate"><span class="pre">EXAMPLE.COM</span></code>, you would need to add the

+principals <code class="docutils literal notranslate"><span class="pre">krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU</span></code> and

+<code class="docutils literal notranslate"><span class="pre">krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM</span></code> to both databases.

These principals must all have the same passwords, key version

numbers, and encryption types; this may require explicitly setting

the key version number with the <strong>-kvno</strong> option.</p>

<p>In the ATHENA.MIT.EDU and EXAMPLE.COM cross-realm case, the administrators

would run the following commands on the KDCs in both realms:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">shell</span><span class="o">%</span><span class="p">:</span> <span class="n">kadmin</span><span class="o">.</span><span class="n">local</span> <span class="o">-</span><span class="n">e</span> <span class="s2">"aes256-cts:normal"</span>

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">shell</span><span class="o">%</span><span class="p">:</span> <span class="n">kadmin</span><span class="o">.</span><span class="n">local</span> <span class="o">-</span><span class="n">e</span> <span class="s2">"aes256-cts:normal"</span>

<span class="n">kadmin</span><span class="p">:</span> <span class="n">addprinc</span> <span class="o">-</span><span class="n">requires_preauth</span> <span class="n">krbtgt</span><span class="o">/</span><span class="n">ATHENA</span><span class="o">.</span><span class="n">MIT</span><span class="o">.</span><span class="n">EDU</span><span class="nd">@EXAMPLE</span><span class="o">.</span><span class="n">COM</span>

<span class="n">Enter</span> <span class="n">password</span> <span class="k">for</span> <span class="n">principal</span> <span class="n">krbtgt</span><span class="o">/</span><span class="n">ATHENA</span><span class="o">.</span><span class="n">MIT</span><span class="o">.</span><span class="n">EDU</span><span class="nd">@EXAMPLE</span><span class="o">.</span><span class="n">COM</span><span class="p">:</span>

<span class="n">Re</span><span class="o">-</span><span class="n">enter</span> <span class="n">password</span> <span class="k">for</span> <span class="n">principal</span> <span class="n">krbtgt</span><span class="o">/</span><span class="n">ATHENA</span><span class="o">.</span><span class="n">MIT</span><span class="o">.</span><span class="n">EDU</span><span class="nd">@EXAMPLE</span><span class="o">.</span><span class="n">COM</span><span class="p">:</span>

@@ -433,8 +418,8 @@ would run the following commands on the KDCs in both realms:</p>

</pre></div>

</div>

-<p class="first admonition-title">Note</p>

-<p class="last">Even if most principals in a realm are generally created

+<p class="admonition-title">Note</p>

+<p>Even if most principals in a realm are generally created

with the <strong>requires_preauth</strong> flag enabled, this flag is not

desirable on cross-realm authentication keys because doing

so makes it impossible to disable preauthentication on a

@@ -442,16 +427,16 @@ service-by-service basis. Disabling it as in the example

above is recommended.</p>

</div>

-<p class="first admonition-title">Note</p>

-<p class="last">It is very important that these principals have good

+<p class="admonition-title">Note</p>

+<p>It is very important that these principals have good

passwords. MIT recommends that TGT principal passwords be

at least 26 characters of random ASCII text.</p>

</div>

-</div>

-<div class="section" id="changing-the-krbtgt-key">

+</section>

+<section id="changing-the-krbtgt-key">

<span id="changing-krbtgt-key"></span><h2>Changing the krbtgt key<a class="headerlink" href="#changing-the-krbtgt-key" title="Permalink to this headline">¶</a></h2>

<p>A Kerberos Ticket Granting Ticket (TGT) is a service ticket for the

-principal <code class="docutils literal"><span class="pre">krbtgt/REALM</span></code>. The key for this principal is created

+principal <code class="docutils literal notranslate"><span class="pre">krbtgt/REALM</span></code>. The key for this principal is created

when the Kerberos database is initialized and need not be changed.

However, it will only have the encryption types supported by the KDC

at the time of the initial database creation. To allow use of newer

@@ -461,12 +446,12 @@ encryption types for the TGT, this key has to be changed.</p>

TGTs. Therefore, when changing this key, normally one should use the

<strong>-keepold</strong> flag to change_password to retain the previous key in the

database as well as the new key. For example:</p>

-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">kadmin</span><span class="p">:</span> <span class="n">change_password</span> <span class="o">-</span><span class="n">randkey</span> <span class="o">-</span><span class="n">keepold</span> <span class="n">krbtgt</span><span class="o">/</span><span class="n">ATHENA</span><span class="o">.</span><span class="n">MIT</span><span class="o">.</span><span class="n">EDU</span><span class="nd">@ATHENA</span><span class="o">.</span><span class="n">MIT</span><span class="o">.</span><span class="n">EDU</span>

+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">kadmin</span><span class="p">:</span> <span class="n">change_password</span> <span class="o">-</span><span class="n">randkey</span> <span class="o">-</span><span class="n">keepold</span> <span class="n">krbtgt</span><span class="o">/</span><span class="n">ATHENA</span><span class="o">.</span><span class="n">MIT</span><span class="o">.</span><span class="n">EDU</span><span class="nd">@ATHENA</span><span class="o">.</span><span class="n">MIT</span><span class="o">.</span><span class="n">EDU</span>

</pre></div>

</div>

-<p class="first admonition-title">Warning</p>

-<p class="last">After issuing this command, the old key is still valid

+<p class="admonition-title">Warning</p>

+<p>After issuing this command, the old key is still valid

and is still vulnerable to (for instance) brute force

attacks. To completely retire an old key or encryption

type, run the kadmin <strong>purgekeys</strong> command to delete keys

@@ -489,10 +474,10 @@ principal (see <a class="reference internal" href="admin_commands/kadmin_local.h

tickets may not work if the original ticket was obtained prior to a

krbtgt key change and the modified ticket is obtained afterwards.

Upgrading the KDC to release 1.14 or later will correct this bug.</p>

-</div>

-<div class="section" id="incremental-database-propagation">

+</section>

+<section id="incremental-database-propagation">

<span id="incr-db-prop"></span><h2>Incremental database propagation<a class="headerlink" href="#incremental-database-propagation" title="Permalink to this headline">¶</a></h2>

-<div class="section" id="overview">

+<section id="overview">

<h3>Overview<a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h3>

<p>At some very large sites, dumping and transmitting the database can

take more time than is desirable for changes to propagate from the

@@ -507,47 +492,47 @@ periodically requests the changes that have been made since the last

check. By default, this check is done every two minutes.</p>

<p>Incremental propagation uses the following entries in the per-realm

data in the KDC config file (See <a class="reference internal" href="conf_files/kdc_conf.html#kdc-conf-5"><span class="std std-ref">kdc.conf</span></a>):</p>

-<table border="1" class="docutils">

+<table class="docutils align-default">

-<col width="4%" />

-<col width="3%" />

-<col width="94%" />

+<col style="width: 4%" />

+<col style="width: 3%" />

+<col style="width: 94%" />

</colgroup>

-<tbody valign="top">

-<tr class="row-odd"><td>iprop_enable</td>

-<td><em>boolean</em></td>

-<td>If <em>true</em>, then incremental propagation is enabled, and (as noted below) normal kprop propagation is disabled. The default is <em>false</em>.</td>

+<tbody>

+<tr class="row-odd"><td><p>iprop_enable</p></td>

+<td><p><em>boolean</em></p></td>

+<td><p>If <em>true</em>, then incremental propagation is enabled, and (as noted below) normal kprop propagation is disabled. The default is <em>false</em>.</p></td>

</tr>

-<tr class="row-even"><td>iprop_master_ulogsize</td>

-<td><em>integer</em></td>

-<td>Indicates the number of entries that should be retained in the update log. The default is 1000; the maximum number is 2500.</td>

+<tr class="row-even"><td><p>iprop_master_ulogsize</p></td>

+<td><p><em>integer</em></p></td>

+<td><p>Indicates the number of entries that should be retained in the update log. The default is 1000; the maximum number is 2500.</p></td>

</tr>

-<tr class="row-odd"><td>iprop_replica_poll</td>

-<td><em>time interval</em></td>

-<td>Indicates how often the replica should poll the primary KDC for changes to the database. The default is two minutes.</td>

+<tr class="row-odd"><td><p>iprop_replica_poll</p></td>

+<td><p><em>time interval</em></p></td>

+<td><p>Indicates how often the replica should poll the primary KDC for changes to the database. The default is two minutes.</p></td>

</tr>

-<tr class="row-even"><td>iprop_port</td>

-<td><em>integer</em></td>

-<td>Specifies the port number to be used for incremental propagation. This is required in both primary and replica configuration files.</td>

+<tr class="row-even"><td><p>iprop_port</p></td>

+<td><p><em>integer</em></p></td>

+<td><p>Specifies the port number to be used for incremental propagation. This is required in both primary and replica configuration files.</p></td>

</tr>

-<tr class="row-odd"><td>iprop_resync_timeout</td>

-<td><em>integer</em></td>

-<td>Specifies the number of seconds to wait for a full propagation to complete. This is optional on replica configurations. Defaults to 300 seconds (5 minutes).</td>

+<tr class="row-odd"><td><p>iprop_resync_timeout</p></td>

+<td><p><em>integer</em></p></td>

+<td><p>Specifies the number of seconds to wait for a full propagation to complete. This is optional on replica configurations. Defaults to 300 seconds (5 minutes).</p></td>

</tr>

-<tr class="row-even"><td>iprop_logfile</td>

-<td><em>file name</em></td>

-<td>Specifies where the update log file for the realm database is to be stored. The default is to use the <em>database_name</em> entry from the realms section of the config file <a class="reference internal" href="conf_files/kdc_conf.html#kdc-conf-5"><span class="std std-ref">kdc.conf</span></a>, with <em>.ulog</em> appended. (NOTE: If database_name isn’t specified in the realms section, perhaps because the LDAP database back end is being used, or the file name is specified in the <em>dbmodules</em> section, then the hard-coded default for <em>database_name</em> is used. Determination of the <em>iprop_logfile</em> default value will not use values from the <em>dbmodules</em> section.)</td>

+<tr class="row-even"><td><p>iprop_logfile</p></td>

+<td><p><em>file name</em></p></td>

+<td><p>Specifies where the update log file for the realm database is to be stored. The default is to use the <em>database_name</em> entry from the realms section of the config file <a class="reference internal" href="conf_files/kdc_conf.html#kdc-conf-5"><span class="std std-ref">kdc.conf</span></a>, with <em>.ulog</em> appended. (NOTE: If database_name isn’t specified in the realms section, perhaps because the LDAP database back end is being used, or the file name is specified in the <em>dbmodules</em> section, then the hard-coded default for <em>database_name</em> is used. Determination of the <em>iprop_logfile</em> default value will not use values from the <em>dbmodules</em> section.)</p></td>

</tr>

</tbody>

</table>

<p>Both primary and replica sides must have a principal named

-<code class="docutils literal"><span class="pre">kiprop/hostname</span></code> (where <em>hostname</em> is the lowercase,

+<code class="docutils literal notranslate"><span class="pre">kiprop/hostname</span></code> (where <em>hostname</em> is the lowercase,

fully-qualified, canonical name for the host) registered in the

Kerberos database, and have keys for that principal stored in the

-default keytab file (<a class="reference internal" href="../mitK5defaults.html#paths"><span class="std std-ref">DEFKTNAME</span></a>). The <code class="docutils literal"><span class="pre">kiprop/hostname</span></code> principal may

+default keytab file (<a class="reference internal" href="../mitK5defaults.html#paths"><span class="std std-ref">DEFKTNAME</span></a>). The <code class="docutils literal notranslate"><span class="pre">kiprop/hostname</span></code> principal may

have been created automatically for the primary KDC, but it must

always be created for replica KDCs.</p>

-<p>On the primary KDC side, the <code class="docutils literal"><span class="pre">kiprop/hostname</span></code> principal must be

+<p>On the primary KDC side, the <code class="docutils literal notranslate"><span class="pre">kiprop/hostname</span></code> principal must be

listed in the kadmind ACL file <a class="reference internal" href="conf_files/kadm5_acl.html#kadm5-acl-5"><span class="std std-ref">kadm5.acl</span></a>, and given the

<strong>p</strong> privilege (see <a class="reference internal" href="#privileges"><span class="std std-ref">Privileges</span></a>).</p>

<p>On the replica KDC side, <a class="reference internal" href="admin_commands/kpropd.html#kpropd-8"><span class="std std-ref">kpropd</span></a> should be run. When

@@ -565,30 +550,30 @@ fetching incremental updates. Thus, all the keytab and ACL setup

previously described for kprop propagation is still needed.</p>

<p>If an environment has a large number of replicas, it may be desirable

to arrange them in a hierarchy instead of having the primary serve

-updates to every replica. To do this, run <code class="docutils literal"><span class="pre">kadmind</span> <span class="pre">-proponly</span></code> on

-each intermediate replica, and <code class="docutils literal"><span class="pre">kpropd</span> <span class="pre">-A</span> <span class="pre">upstreamhostname</span></code> on

+updates to every replica. To do this, run <code class="docutils literal notranslate"><span class="pre">kadmind</span> <span class="pre">-proponly</span></code> on

+each intermediate replica, and <code class="docutils literal notranslate"><span class="pre">kpropd</span> <span class="pre">-A</span> <span class="pre">upstreamhostname</span></code> on

downstream replicas to direct each one to the appropriate upstream

replica.</p>

<p>There are several known restrictions in the current implementation:</p>

-<li>The incremental update protocol does not transport changes to policy

+<li><p>The incremental update protocol does not transport changes to policy

objects. Any policy changes on the primary will result in full

-resyncs to all replicas.</li>

-<li>The replica’s KDB module must support locking; it cannot be using the

-LDAP KDB module.</li>

-<li>The primary and replica must be able to initiate TCP connections in

-both directions, without an intervening NAT.</li>

+resyncs to all replicas.</p></li>

+<li><p>The replica’s KDB module must support locking; it cannot be using the

+LDAP KDB module.</p></li>

+<li><p>The primary and replica must be able to initiate TCP connections in

+both directions, without an intervening NAT.</p></li>

</ul>

-</div>

-<div class="section" id="sun-mit-incremental-propagation-differences">

+</section>

+<section id="sun-mit-incremental-propagation-differences">

<h3>Sun/MIT incremental propagation differences<a class="headerlink" href="#sun-mit-incremental-propagation-differences" title="Permalink to this headline">¶</a></h3>

<p>Sun donated the original code for supporting incremental database

propagation to MIT. Some changes have been made in the MIT source

tree that will be visible to administrators. (These notes are based

on Sun’s patches. Changes to Sun’s implementation since then may not

be reflected here.)</p>

-<p>The Sun config file support looks for <code class="docutils literal"><span class="pre">sunw_dbprop_enable</span></code>,

-<code class="docutils literal"><span class="pre">sunw_dbprop_master_ulogsize</span></code>, and <code class="docutils literal"><span class="pre">sunw_dbprop_slave_poll</span></code>.</p>

+<p>The Sun config file support looks for <code class="docutils literal notranslate"><span class="pre">sunw_dbprop_enable</span></code>,

+<code class="docutils literal notranslate"><span class="pre">sunw_dbprop_master_ulogsize</span></code>, and <code class="docutils literal notranslate"><span class="pre">sunw_dbprop_slave_poll</span></code>.</p>

<p>The incremental propagation service is implemented as an ONC RPC

service. In the Sun implementation, the service is registered with

rpcbind (also known as portmapper) and the client looks up the port

@@ -596,21 +581,23 @@ number to contact. In the MIT implementation, where interaction with

some modern versions of rpcbind doesn’t always work well, the port

number must be specified in the config file on both the primary and

replica sides.</p>

-<p>The Sun implementation hard-codes pathnames in <code class="docutils literal"><span class="pre">/var/krb5</span></code> for the

+<p>The Sun implementation hard-codes pathnames in <code class="docutils literal notranslate"><span class="pre">/var/krb5</span></code> for the

update log and the per-replica kprop dump files. In the MIT

implementation, the pathname for the update log is specified in the

config file, and the per-replica dump files are stored in

-<a class="reference internal" href="../mitK5defaults.html#paths"><span class="std std-ref">LOCALSTATEDIR</span></a><code class="docutils literal"><span class="pre">/krb5kdc</span></code><code class="docutils literal"><span class="pre">/replica_datatrans_hostname</span></code>.</p>

-</div>

+<a class="reference internal" href="../mitK5defaults.html#paths"><span class="std std-ref">LOCALSTATEDIR</span></a><code class="docutils literal notranslate"><span class="pre">/krb5kdc</span></code><code class="docutils literal notranslate"><span class="pre">/replica_datatrans_hostname</span></code>.</p>

+</section>

+ <div class="clearer"></div>

</div>

<ul>

<li><a class="reference internal" href="#">Database administration</a><ul>

@@ -691,6 +678,7 @@ config file, and the per-replica dump files are stored in

</form>

</div>

</div>

@@ -698,8 +686,8 @@ config file, and the per-replica dump files are stored in

- <div class="right" ><i>Release: 1.21.2</i><br />

+ <div class="right" ><i>Release: 1.21.3</i><br />

</div>