%% Generated by Sphinx.
\def\sphinxdocclass{report}
\documentclass[letterpaper,10pt,english]{sphinxmanual}
\ifdefined\pdfpxdimen
   \let\sphinxpxdimen\pdfpxdimen\else\newdimen\sphinxpxdimen
\fi \sphinxpxdimen=.75bp\relax

\usepackage[utf8]{inputenc}
\ifdefined\DeclareUnicodeCharacter
 \ifdefined\DeclareUnicodeCharacterAsOptional
  \DeclareUnicodeCharacter{"00A0}{\nobreakspace}
  \DeclareUnicodeCharacter{"2500}{\sphinxunichar{2500}}
  \DeclareUnicodeCharacter{"2502}{\sphinxunichar{2502}}
  \DeclareUnicodeCharacter{"2514}{\sphinxunichar{2514}}
  \DeclareUnicodeCharacter{"251C}{\sphinxunichar{251C}}
  \DeclareUnicodeCharacter{"2572}{\textbackslash}
 \else
  \DeclareUnicodeCharacter{00A0}{\nobreakspace}
  \DeclareUnicodeCharacter{2500}{\sphinxunichar{2500}}
  \DeclareUnicodeCharacter{2502}{\sphinxunichar{2502}}
  \DeclareUnicodeCharacter{2514}{\sphinxunichar{2514}}
  \DeclareUnicodeCharacter{251C}{\sphinxunichar{251C}}
  \DeclareUnicodeCharacter{2572}{\textbackslash}
 \fi
\fi
\usepackage{cmap}
\usepackage[T1]{fontenc}
\usepackage{amsmath,amssymb,amstext}
\usepackage{babel}
\usepackage{times}
\usepackage[Bjarne]{fncychap}
\usepackage[dontkeepoldnames]{sphinx}

\usepackage{geometry}

% Include hyperref last.
\usepackage{hyperref}
% Fix anchor placement for figures with captions.
\usepackage{hypcap}% it must be loaded after hyperref.
% Set up styles of URL: it should be placed after hyperref.
\urlstyle{same}

\addto\captionsenglish{\renewcommand{\figurename}{Fig.}}
\addto\captionsenglish{\renewcommand{\tablename}{Table}}
\addto\captionsenglish{\renewcommand{\literalblockname}{Listing}}

\addto\captionsenglish{\renewcommand{\literalblockcontinuedname}{continued from previous page}}
\addto\captionsenglish{\renewcommand{\literalblockcontinuesname}{continues on next page}}

\addto\extrasenglish{\def\pageautorefname{page}}

\setcounter{tocdepth}{0}



\title{Kerberos Administration Guide}
\date{ }
\release{1.21.2}
\author{MIT}
\newcommand{\sphinxlogo}{\vbox{}}
\renewcommand{\releasename}{Release}
\makeindex

\begin{document}

\maketitle
\sphinxtableofcontents
\phantomsection\label{\detokenize{admin/index::doc}}



\chapter{Installation guide}
\label{\detokenize{admin/install:for-administrators}}\label{\detokenize{admin/install::doc}}\label{\detokenize{admin/install:installation-guide}}

\section{Contents}
\label{\detokenize{admin/install:contents}}

\subsection{Installing KDCs}
\label{\detokenize{admin/install_kdc:installing-kdcs}}\label{\detokenize{admin/install_kdc::doc}}
When setting up Kerberos in a production environment, it is best to
have multiple replica KDCs alongside with a primary KDC to ensure the
continued availability of the Kerberized services.  Each KDC contains
a copy of the Kerberos database.  The primary KDC contains the
writable copy of the realm database, which it replicates to the
replica KDCs at regular intervals.  All database changes (such as
password changes) are made on the primary KDC.  Replica KDCs provide
Kerberos ticket-granting services, but not database administration,
when the primary KDC is unavailable.  MIT recommends that you install
all of your KDCs to be able to function as either the primary or one
of the replicas.  This will enable you to easily switch your primary
KDC with one of the replicas if necessary (see
{\hyperref[\detokenize{admin/install_kdc:switch-primary-replica}]{\sphinxcrossref{\DUrole{std,std-ref}{Switching primary and replica KDCs}}}}).  This installation procedure is based
on that recommendation.

\begin{sphinxadmonition}{warning}{Warning:}\begin{itemize}
\item {} 
The Kerberos system relies on the availability of correct time
information.  Ensure that the primary and all replica KDCs have
properly synchronized clocks.

\item {} 
It is best to install and run KDCs on secured and dedicated
hardware with limited access.  If your KDC is also a file
server, FTP server, Web server, or even just a client machine,
someone who obtained root access through a security hole in any
of those areas could potentially gain access to the Kerberos
database.

\end{itemize}
\end{sphinxadmonition}


\subsubsection{Install and configure the primary KDC}
\label{\detokenize{admin/install_kdc:install-and-configure-the-primary-kdc}}
Install Kerberos either from the OS-provided packages or from the
source (See \DUrole{xref,std,std-ref}{do\_build}).

\begin{sphinxadmonition}{note}{Note:}
For the purpose of this document we will use the following
names:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}    \PYG{o}{\PYGZhy{}} \PYG{n}{primary} \PYG{n}{KDC}
\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}  \PYG{o}{\PYGZhy{}} \PYG{n}{replica} \PYG{n}{KDC}
\PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}      \PYG{o}{\PYGZhy{}} \PYG{n}{realm} \PYG{n}{name}
\PYG{o}{.}\PYG{n}{k5}\PYG{o}{.}\PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}  \PYG{o}{\PYGZhy{}} \PYG{n}{stash} \PYG{n}{file}
\PYG{n}{admin}\PYG{o}{/}\PYG{n}{admin}         \PYG{o}{\PYGZhy{}} \PYG{n}{admin} \PYG{n}{principal}
\end{sphinxVerbatim}

See {\hyperref[\detokenize{mitK5defaults:mitk5defaults}]{\sphinxcrossref{\DUrole{std,std-ref}{MIT Kerberos defaults}}}} for the default names and locations
of the relevant to this topic files.  Adjust the names and
paths to your system environment.
\end{sphinxadmonition}


\subsubsection{Edit KDC configuration files}
\label{\detokenize{admin/install_kdc:edit-kdc-configuration-files}}
Modify the configuration files, {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} and
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}, to reflect the correct information (such as
domain-realm mappings and Kerberos servers names) for your realm.
(See {\hyperref[\detokenize{mitK5defaults:mitk5defaults}]{\sphinxcrossref{\DUrole{std,std-ref}{MIT Kerberos defaults}}}} for the recommended default locations for
these files).

Most of the tags in the configuration have default values that will
work well for most sites.  There are some tags in the
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} file whose values must be specified, and this
section will explain those.

If the locations for these configuration files differs from the
default ones, set \sphinxstylestrong{KRB5\_CONFIG} and \sphinxstylestrong{KRB5\_KDC\_PROFILE} environment
variables to point to the krb5.conf and kdc.conf respectively.  For
example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{export} \PYG{n}{KRB5\PYGZus{}CONFIG}\PYG{o}{=}\PYG{o}{/}\PYG{n}{yourdir}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{conf}
\PYG{n}{export} \PYG{n}{KRB5\PYGZus{}KDC\PYGZus{}PROFILE}\PYG{o}{=}\PYG{o}{/}\PYG{n}{yourdir}\PYG{o}{/}\PYG{n}{kdc}\PYG{o}{.}\PYG{n}{conf}
\end{sphinxVerbatim}


\paragraph{krb5.conf}
\label{\detokenize{admin/install_kdc:krb5-conf}}
If you are not using DNS TXT records (see {\hyperref[\detokenize{admin/realm_config:mapping-hostnames}]{\sphinxcrossref{\DUrole{std,std-ref}{Mapping hostnames onto Kerberos realms}}}}),
you must specify the \sphinxstylestrong{default\_realm} in the {\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}}
section.  If you are not using DNS URI or SRV records (see
{\hyperref[\detokenize{admin/realm_config:kdc-hostnames}]{\sphinxcrossref{\DUrole{std,std-ref}{Hostnames for KDCs}}}} and {\hyperref[\detokenize{admin/realm_config:kdc-discovery}]{\sphinxcrossref{\DUrole{std,std-ref}{KDC Discovery}}}}), you must include the
\sphinxstylestrong{kdc} tag for each \sphinxstyleemphasis{realm} in the {\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} section.  To
communicate with the kadmin server in each realm, the \sphinxstylestrong{admin\_server}
tag must be set in the
{\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} section.

An example krb5.conf file:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{libdefaults}\PYG{p}{]}
    \PYG{n}{default\PYGZus{}realm} \PYG{o}{=} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}

\PYG{p}{[}\PYG{n}{realms}\PYG{p}{]}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{kdc} \PYG{o}{=} \PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
        \PYG{n}{kdc} \PYG{o}{=} \PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
        \PYG{n}{admin\PYGZus{}server} \PYG{o}{=} \PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}


\paragraph{kdc.conf}
\label{\detokenize{admin/install_kdc:kdc-conf}}
The kdc.conf file can be used to control the listening ports of the
KDC and kadmind, as well as realm-specific defaults, the database type
and location, and logging.

An example kdc.conf file:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{kdcdefaults}\PYG{p}{]}
    \PYG{n}{kdc\PYGZus{}listen} \PYG{o}{=} \PYG{l+m+mi}{88}
    \PYG{n}{kdc\PYGZus{}tcp\PYGZus{}listen} \PYG{o}{=} \PYG{l+m+mi}{88}

\PYG{p}{[}\PYG{n}{realms}\PYG{p}{]}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{kadmind\PYGZus{}port} \PYG{o}{=} \PYG{l+m+mi}{749}
        \PYG{n}{max\PYGZus{}life} \PYG{o}{=} \PYG{l+m+mi}{12}\PYG{n}{h} \PYG{l+m+mi}{0}\PYG{n}{m} \PYG{l+m+mi}{0}\PYG{n}{s}
        \PYG{n}{max\PYGZus{}renewable\PYGZus{}life} \PYG{o}{=} \PYG{l+m+mi}{7}\PYG{n}{d} \PYG{l+m+mi}{0}\PYG{n}{h} \PYG{l+m+mi}{0}\PYG{n}{m} \PYG{l+m+mi}{0}\PYG{n}{s}
        \PYG{n}{master\PYGZus{}key\PYGZus{}type} \PYG{o}{=} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}
        \PYG{n}{supported\PYGZus{}enctypes} \PYG{o}{=} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{p}{:}\PYG{n}{normal} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{p}{:}\PYG{n}{normal}
        \PYG{c+c1}{\PYGZsh{} If the default location does not suit your setup,}
        \PYG{c+c1}{\PYGZsh{} explicitly configure the following values:}
        \PYG{c+c1}{\PYGZsh{}    database\PYGZus{}name = /var/krb5kdc/principal}
        \PYG{c+c1}{\PYGZsh{}    key\PYGZus{}stash\PYGZus{}file = /var/krb5kdc/.k5.ATHENA.MIT.EDU}
        \PYG{c+c1}{\PYGZsh{}    acl\PYGZus{}file = /var/krb5kdc/kadm5.acl}
    \PYG{p}{\PYGZcb{}}

\PYG{p}{[}\PYG{n}{logging}\PYG{p}{]}
    \PYG{c+c1}{\PYGZsh{} By default, the KDC and kadmind will log output using}
    \PYG{c+c1}{\PYGZsh{} syslog.  You can instead send log output to files like this:}
    \PYG{n}{kdc} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{log}\PYG{o}{/}\PYG{n}{krb5kdc}\PYG{o}{.}\PYG{n}{log}
    \PYG{n}{admin\PYGZus{}server} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{log}\PYG{o}{/}\PYG{n}{kadmin}\PYG{o}{.}\PYG{n}{log}
    \PYG{n}{default} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{log}\PYG{o}{/}\PYG{n}{krb5lib}\PYG{o}{.}\PYG{n}{log}
\end{sphinxVerbatim}

Replace \sphinxcode{ATHENA.MIT.EDU} and \sphinxcode{kerberos.mit.edu} with the name of
your Kerberos realm and server respectively.

\begin{sphinxadmonition}{note}{Note:}
You have to have write permission on the target directories
(these directories must exist) used by \sphinxstylestrong{database\_name},
\sphinxstylestrong{key\_stash\_file}, and \sphinxstylestrong{acl\_file}.
\end{sphinxadmonition}


\subsubsection{Create the KDC database}
\label{\detokenize{admin/install_kdc:create-the-kdc-database}}\label{\detokenize{admin/install_kdc:create-db}}
You will use the {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} command on the primary KDC to
create the Kerberos database and the optional \DUrole{xref,std,std-ref}{stash\_definition}.

\begin{sphinxadmonition}{note}{Note:}
If you choose not to install a stash file, the KDC will
prompt you for the master key each time it starts up.  This
means that the KDC will not be able to start automatically,
such as after a system reboot.
\end{sphinxadmonition}

{\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} will prompt you for the master password for the
Kerberos database.  This password can be any string.  A good password
is one you can remember, but that no one else can guess.  Examples of
bad passwords are words that can be found in a dictionary, any common
or popular name, especially a famous person (or cartoon character),
your username in any form (e.g., forward, backward, repeated twice,
etc.), and any of the sample passwords that appear in this manual.
One example of a password which might be good if it did not appear in
this manual is “MITiys4K5!”, which represents the sentence “MIT is
your source for Kerberos 5!”  (It’s the first letter of each word,
substituting the numeral “4” for the word “for”, and includes the
punctuation mark at the end.)

The following is an example of how to create a Kerberos database and
stash file on the primary KDC, using the {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} command.
Replace \sphinxcode{ATHENA.MIT.EDU} with the name of your Kerberos realm:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{kdb5\PYGZus{}util} \PYG{n}{create} \PYG{o}{\PYGZhy{}}\PYG{n}{r} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{\PYGZhy{}}\PYG{n}{s}

\PYG{n}{Initializing} \PYG{n}{database} \PYG{l+s+s1}{\PYGZsq{}}\PYG{l+s+s1}{/usr/local/var/krb5kdc/principal}\PYG{l+s+s1}{\PYGZsq{}} \PYG{k}{for} \PYG{n}{realm} \PYG{l+s+s1}{\PYGZsq{}}\PYG{l+s+s1}{ATHENA.MIT.EDU}\PYG{l+s+s1}{\PYGZsq{}}\PYG{p}{,}
\PYG{n}{master} \PYG{n}{key} \PYG{n}{name} \PYG{l+s+s1}{\PYGZsq{}}\PYG{l+s+s1}{K/M@ATHENA.MIT.EDU}\PYG{l+s+s1}{\PYGZsq{}}
\PYG{n}{You} \PYG{n}{will} \PYG{n}{be} \PYG{n}{prompted} \PYG{k}{for} \PYG{n}{the} \PYG{n}{database} \PYG{n}{Master} \PYG{n}{Password}\PYG{o}{.}
\PYG{n}{It} \PYG{o+ow}{is} \PYG{n}{important} \PYG{n}{that} \PYG{n}{you} \PYG{n}{NOT} \PYG{n}{FORGET} \PYG{n}{this} \PYG{n}{password}\PYG{o}{.}
\PYG{n}{Enter} \PYG{n}{KDC} \PYG{n}{database} \PYG{n}{master} \PYG{n}{key}\PYG{p}{:}  \PYG{o}{\PYGZlt{}}\PYG{o}{=} \PYG{n}{Type} \PYG{n}{the} \PYG{n}{master} \PYG{n}{password}\PYG{o}{.}
\PYG{n}{Re}\PYG{o}{\PYGZhy{}}\PYG{n}{enter} \PYG{n}{KDC} \PYG{n}{database} \PYG{n}{master} \PYG{n}{key} \PYG{n}{to} \PYG{n}{verify}\PYG{p}{:}  \PYG{o}{\PYGZlt{}}\PYG{o}{=} \PYG{n}{Type} \PYG{n}{it} \PYG{n}{again}\PYG{o}{.}
\PYG{n}{shell}\PYG{o}{\PYGZpc{}}
\end{sphinxVerbatim}

This will create five files in {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc} (or at the locations specified
in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}):
\begin{itemize}
\item {} 
two Kerberos database files, \sphinxcode{principal}, and \sphinxcode{principal.ok}

\item {} 
the Kerberos administrative database file, \sphinxcode{principal.kadm5}

\item {} 
the administrative database lock file, \sphinxcode{principal.kadm5.lock}

\item {} 
the stash file, in this example \sphinxcode{.k5.ATHENA.MIT.EDU}.  If you do
not want a stash file, run the above command without the \sphinxstylestrong{-s}
option.

\end{itemize}

For more information on administrating Kerberos database see
{\hyperref[\detokenize{admin/database:db-operations}]{\sphinxcrossref{\DUrole{std,std-ref}{Operations on the Kerberos database}}}}.


\subsubsection{Add administrators to the ACL file}
\label{\detokenize{admin/install_kdc:add-administrators-to-the-acl-file}}\label{\detokenize{admin/install_kdc:admin-acl}}
Next, you need create an Access Control List (ACL) file and put the
Kerberos principal of at least one of the administrators into it.
This file is used by the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} daemon to control which
principals may view and make privileged modifications to the Kerberos
database files.  The ACL filename is determined by the \sphinxstylestrong{acl\_file}
variable in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}; the default is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/kadm5.acl}.

For more information on Kerberos ACL file see {\hyperref[\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5.acl}}}}.


\subsubsection{Add administrators to the Kerberos database}
\label{\detokenize{admin/install_kdc:add-administrators-to-the-kerberos-database}}\label{\detokenize{admin/install_kdc:addadmin-kdb}}
Next you need to add administrative principals (i.e., principals who
are allowed to administer Kerberos database) to the Kerberos database.
You \sphinxstyleemphasis{must} add at least one principal now to allow communication
between the Kerberos administration daemon kadmind and the kadmin
program over the network for further administration.  To do this, use
the kadmin.local utility on the primary KDC.  kadmin.local is designed
to be run on the primary KDC host without using Kerberos
authentication to an admin server; instead, it must have read and
write access to the Kerberos database on the local filesystem.

The administrative principals you create should be the ones you added
to the ACL file (see {\hyperref[\detokenize{admin/install_kdc:admin-acl}]{\sphinxcrossref{\DUrole{std,std-ref}{Add administrators to the ACL file}}}}).

In the following example, the administrative principal \sphinxcode{admin/admin}
is created:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{kadmin}\PYG{o}{.}\PYG{n}{local}

\PYG{n}{kadmin}\PYG{o}{.}\PYG{n}{local}\PYG{p}{:} \PYG{n}{addprinc} \PYG{n}{admin}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}

\PYG{n}{No} \PYG{n}{policy} \PYG{n}{specified} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{admin/admin@ATHENA.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{;}
\PYG{n}{assigning} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{default}\PYG{l+s+s2}{\PYGZdq{}}\PYG{o}{.}
\PYG{n}{Enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{admin}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{p}{:}  \PYG{o}{\PYGZlt{}}\PYG{o}{=} \PYG{n}{Enter} \PYG{n}{a} \PYG{n}{password}\PYG{o}{.}
\PYG{n}{Re}\PYG{o}{\PYGZhy{}}\PYG{n}{enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{admin}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{p}{:}  \PYG{o}{\PYGZlt{}}\PYG{o}{=} \PYG{n}{Type} \PYG{n}{it} \PYG{n}{again}\PYG{o}{.}
\PYG{n}{Principal} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{admin/admin@ATHENA.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{created}\PYG{o}{.}
\PYG{n}{kadmin}\PYG{o}{.}\PYG{n}{local}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{Start the Kerberos daemons on the primary KDC}
\label{\detokenize{admin/install_kdc:start-the-kerberos-daemons-on-the-primary-kdc}}\label{\detokenize{admin/install_kdc:start-kdc-daemons}}
At this point, you are ready to start the Kerberos KDC
({\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}}) and administrative daemons on the primary KDC.  To
do so, type:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{krb5kdc}
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{kadmind}
\end{sphinxVerbatim}

Each server daemon will fork and run in the background.

\begin{sphinxadmonition}{note}{Note:}
Assuming you want these daemons to start up automatically at
boot time, you can add them to the KDC’s \sphinxcode{/etc/rc} or
\sphinxcode{/etc/inittab} file.  You need to have a
\DUrole{xref,std,std-ref}{stash\_definition} in order to do this.
\end{sphinxadmonition}

You can verify that they started properly by checking for their
startup messages in the logging locations you defined in
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} (see {\hyperref[\detokenize{admin/conf_files/kdc_conf:logging}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}logging{]}}}}}).  For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{tail} \PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{log}\PYG{o}{/}\PYG{n}{krb5kdc}\PYG{o}{.}\PYG{n}{log}
\PYG{n}{Dec} \PYG{l+m+mi}{02} \PYG{l+m+mi}{12}\PYG{p}{:}\PYG{l+m+mi}{35}\PYG{p}{:}\PYG{l+m+mi}{47} \PYG{n}{beeblebrox} \PYG{n}{krb5kdc}\PYG{p}{[}\PYG{l+m+mi}{3187}\PYG{p}{]}\PYG{p}{(}\PYG{n}{info}\PYG{p}{)}\PYG{p}{:} \PYG{n}{commencing} \PYG{n}{operation}
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{tail} \PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{log}\PYG{o}{/}\PYG{n}{kadmin}\PYG{o}{.}\PYG{n}{log}
\PYG{n}{Dec} \PYG{l+m+mi}{02} \PYG{l+m+mi}{12}\PYG{p}{:}\PYG{l+m+mi}{35}\PYG{p}{:}\PYG{l+m+mi}{52} \PYG{n}{beeblebrox} \PYG{n}{kadmind}\PYG{p}{[}\PYG{l+m+mi}{3189}\PYG{p}{]}\PYG{p}{(}\PYG{n}{info}\PYG{p}{)}\PYG{p}{:} \PYG{n}{starting}
\end{sphinxVerbatim}

Any errors the daemons encounter while starting will also be listed in
the logging output.

As an additional verification, check if \DUrole{xref,std,std-ref}{kinit(1)} succeeds
against the principals that you have created on the previous step
({\hyperref[\detokenize{admin/install_kdc:addadmin-kdb}]{\sphinxcrossref{\DUrole{std,std-ref}{Add administrators to the Kerberos database}}}}).  Run:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{kinit} \PYG{n}{admin}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\end{sphinxVerbatim}


\subsubsection{Install the replica KDCs}
\label{\detokenize{admin/install_kdc:install-the-replica-kdcs}}
You are now ready to start configuring the replica KDCs.

\begin{sphinxadmonition}{note}{Note:}
Assuming you are setting the KDCs up so that you can easily
switch the primary KDC with one of the replicas, you should
perform each of these steps on the primary KDC as well as
the replica KDCs, unless these instructions specify
otherwise.
\end{sphinxadmonition}


\paragraph{Create host keytabs for replica KDCs}
\label{\detokenize{admin/install_kdc:create-host-keytabs-for-replica-kdcs}}\label{\detokenize{admin/install_kdc:replica-host-key}}
Each KDC needs a \sphinxcode{host} key in the Kerberos database.  These keys
are used for mutual authentication when propagating the database dump
file from the primary KDC to the secondary KDC servers.

On the primary KDC, connect to administrative interface and create the
host principal for each of the KDCs’ \sphinxcode{host} services.  For example,
if the primary KDC were called \sphinxcode{kerberos.mit.edu}, and you had a
replica KDC named \sphinxcode{kerberos-1.mit.edu}, you would type the
following:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{kadmin}
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{addprinc} \PYG{o}{\PYGZhy{}}\PYG{n}{randkey} \PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
\PYG{n}{No} \PYG{n}{policy} \PYG{n}{specified} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{host/kerberos.mit.edu@ATHENA.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{;} \PYG{n}{assigning} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{default}\PYG{l+s+s2}{\PYGZdq{}}
\PYG{n}{Principal} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{host/kerberos.mit.edu@ATHENA.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{created}\PYG{o}{.}

\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{addprinc} \PYG{o}{\PYGZhy{}}\PYG{n}{randkey} \PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
\PYG{n}{No} \PYG{n}{policy} \PYG{n}{specified} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{host/kerberos\PYGZhy{}1.mit.edu@ATHENA.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{;} \PYG{n}{assigning} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{default}\PYG{l+s+s2}{\PYGZdq{}}
\PYG{n}{Principal} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{host/kerberos\PYGZhy{}1.mit.edu@ATHENA.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{created}\PYG{o}{.}
\end{sphinxVerbatim}

It is not strictly necessary to have the primary KDC server in the
Kerberos database, but it can be handy if you want to be able to swap
the primary KDC with one of the replicas.

Next, extract \sphinxcode{host} random keys for all participating KDCs and
store them in each host’s default keytab file.  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 directly on a replica KDC called
\sphinxcode{kerberos-1.mit.edu}, you would execute the following command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{ktadd} \PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{encryption}
    \PYG{n+nb}{type} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{encryption}
    \PYG{n+nb}{type} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{encryption}
    \PYG{n+nb}{type} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha384}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{192} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{encryption}
    \PYG{n+nb}{type} \PYG{n}{arcfour}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\end{sphinxVerbatim}

If you are instead extracting a keytab for the replica KDC called
\sphinxcode{kerberos-1.mit.edu} on the primary KDC, you should use a dedicated
temporary keytab file for that machine’s keytab:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{ktadd} \PYG{o}{\PYGZhy{}}\PYG{n}{k} \PYG{o}{/}\PYG{n}{tmp}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{keytab} \PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{encryption}
    \PYG{n+nb}{type} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{encryption}
    \PYG{n+nb}{type} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\end{sphinxVerbatim}

The file \sphinxcode{/tmp/kerberos-1.keytab} can then be installed as
\sphinxcode{/etc/krb5.keytab} on the host \sphinxcode{kerberos-1.mit.edu}.


\paragraph{Configure replica KDCs}
\label{\detokenize{admin/install_kdc:configure-replica-kdcs}}
Database propagation copies the contents of the primary’s database,
but does not propagate configuration files, stash files, or the kadm5
ACL file.  The following files must be copied by hand to each replica
(see {\hyperref[\detokenize{mitK5defaults:mitk5defaults}]{\sphinxcrossref{\DUrole{std,std-ref}{MIT Kerberos defaults}}}} for the default locations for these files):
\begin{itemize}
\item {} 
krb5.conf

\item {} 
kdc.conf

\item {} 
kadm5.acl

\item {} 
master key stash file

\end{itemize}

Move the copied files into their appropriate directories, exactly as
on the primary KDC.  kadm5.acl is only needed to allow a replica to
swap with the primary KDC.

The database is propagated from the primary KDC to the replica KDCs
via the {\hyperref[\detokenize{admin/admin_commands/kpropd:kpropd-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kpropd}}}} daemon.  You must explicitly specify the
principals which are allowed to provide Kerberos dump updates on the
replica machine with a new database.  Create a file named kpropd.acl
in the KDC state directory containing the \sphinxcode{host} principals for each
of the KDCs:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\PYG{n}{host}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\end{sphinxVerbatim}

\begin{sphinxadmonition}{note}{Note:}
If you expect that the primary and replica KDCs will be
switched at some point of time, list the host principals
from all participating KDC servers in kpropd.acl files on
all of the KDCs.  Otherwise, you only need to list the
primary KDC’s host principal in the kpropd.acl files of the
replica KDCs.
\end{sphinxadmonition}

Then, add the following line to \sphinxcode{/etc/inetd.conf} on each KDC
(adjust the path to kpropd):

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{krb5\PYGZus{}prop} \PYG{n}{stream} \PYG{n}{tcp} \PYG{n}{nowait} \PYG{n}{root} \PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{sbin}\PYG{o}{/}\PYG{n}{kpropd} \PYG{n}{kpropd}
\end{sphinxVerbatim}

You also need to add the following line to \sphinxcode{/etc/services} on each
KDC, if it is not already present (assuming that the default port is
used):

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{krb5\PYGZus{}prop}       \PYG{l+m+mi}{754}\PYG{o}{/}\PYG{n}{tcp}               \PYG{c+c1}{\PYGZsh{} Kerberos replica propagation}
\end{sphinxVerbatim}

Restart inetd daemon.

Alternatively, start {\hyperref[\detokenize{admin/admin_commands/kpropd:kpropd-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kpropd}}}} as a stand-alone daemon.  This is
required when incremental propagation is enabled.

Now that the replica KDC is able to accept database propagation,
you’ll need to propagate the database from the primary server.

NOTE: Do not start the replica KDC yet; you still do not have a copy
of the primary’s database.


\paragraph{Propagate the database to each replica KDC}
\label{\detokenize{admin/install_kdc:kprop-to-replicas}}\label{\detokenize{admin/install_kdc:propagate-the-database-to-each-replica-kdc}}
First, create a dump file of the database on the primary KDC, as
follows:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{kdb5\PYGZus{}util} \PYG{n}{dump} \PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{krb5kdc}\PYG{o}{/}\PYG{n}{replica\PYGZus{}datatrans}
\end{sphinxVerbatim}

Then, manually propagate the database to each replica KDC, as in the
following example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{kprop} \PYG{o}{\PYGZhy{}}\PYG{n}{f} \PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{krb5kdc}\PYG{o}{/}\PYG{n}{replica\PYGZus{}datatrans} \PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}

\PYG{n}{Database} \PYG{n}{propagation} \PYG{n}{to} \PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{p}{:} \PYG{n}{SUCCEEDED}
\end{sphinxVerbatim}

You will need a script to dump and propagate the database. The
following is an example of a Bourne shell script that will do this.

\begin{sphinxadmonition}{note}{Note:}
Remember that you need to replace \sphinxcode{/usr/local/var/krb5kdc}
with the name of the KDC state directory.
\end{sphinxadmonition}

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZsh{}!/bin/sh

kdclist = \PYGZdq{}kerberos\PYGZhy{}1.mit.edu kerberos\PYGZhy{}2.mit.edu\PYGZdq{}

kdb5\PYGZus{}util dump /usr/local/var/krb5kdc/replica\PYGZus{}datatrans

for kdc in \PYGZdl{}kdclist
do
    kprop \PYGZhy{}f /usr/local/var/krb5kdc/replica\PYGZus{}datatrans \PYGZdl{}kdc
done
\end{sphinxVerbatim}

You will need to set up a cron job to run this script at the intervals
you decided on earlier (see {\hyperref[\detokenize{admin/realm_config:db-prop}]{\sphinxcrossref{\DUrole{std,std-ref}{Database propagation}}}}).

Now that the replica KDC has a copy of the Kerberos database, you can
start the krb5kdc daemon:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{krb5kdc}
\end{sphinxVerbatim}

As with the primary KDC, you will probably want to add this command to
the KDCs’ \sphinxcode{/etc/rc} or \sphinxcode{/etc/inittab} files, so they will start
the krb5kdc daemon automatically at boot time.


\subparagraph{Propagation failed?}
\label{\detokenize{admin/install_kdc:propagation-failed}}
You may encounter the following error messages. For a more detailed
discussion on possible causes and solutions click on the error link
to be redirected to {\hyperref[\detokenize{admin/troubleshoot:troubleshoot}]{\sphinxcrossref{\DUrole{std,std-ref}{Troubleshooting}}}} section.
\begin{enumerate}
\item {} 
{\hyperref[\detokenize{admin/troubleshoot:kprop-no-route}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop: No route to host while connecting to server}}}}

\item {} 
{\hyperref[\detokenize{admin/troubleshoot:kprop-con-refused}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop: Connection refused while connecting to server}}}}

\item {} 
{\hyperref[\detokenize{admin/troubleshoot:kprop-sendauth-exchange}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop: Server rejected authentication (during sendauth exchange) while authenticating to server}}}}

\end{enumerate}


\subsubsection{Add Kerberos principals to the database}
\label{\detokenize{admin/install_kdc:add-kerberos-principals-to-the-database}}
Once your KDCs are set up and running, you are ready to use
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} to load principals for your users, hosts, and other
services into the Kerberos database.  This procedure is described
fully in {\hyperref[\detokenize{admin/database:principals}]{\sphinxcrossref{\DUrole{std,std-ref}{Principals}}}}.

You may occasionally want to use one of your replica KDCs as the
primary.  This might happen if you are upgrading the primary KDC, or
if your primary KDC has a disk crash.  See the following section for
the instructions.


\subsubsection{Switching primary and replica KDCs}
\label{\detokenize{admin/install_kdc:switch-primary-replica}}\label{\detokenize{admin/install_kdc:switching-primary-and-replica-kdcs}}
You may occasionally want to use one of your replica KDCs as the
primary.  This might happen if you are upgrading the primary KDC, or
if your primary KDC has a disk crash.

Assuming you have configured all of your KDCs to be able to function
as either the primary KDC or a replica KDC (as this document
recommends), all you need to do to make the changeover is:

If the primary KDC is still running, do the following on the \sphinxstyleemphasis{old}
primary KDC:
\begin{enumerate}
\item {} 
Kill the kadmind process.

\item {} 
Disable the cron job that propagates the database.

\item {} 
Run your database propagation script manually, to ensure that the
replicas all have the latest copy of the database (see
{\hyperref[\detokenize{admin/install_kdc:kprop-to-replicas}]{\sphinxcrossref{\DUrole{std,std-ref}{Propagate the database to each replica KDC}}}}).

\end{enumerate}

On the \sphinxstyleemphasis{new} primary KDC:
\begin{enumerate}
\item {} 
Start the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} daemon (see {\hyperref[\detokenize{admin/install_kdc:start-kdc-daemons}]{\sphinxcrossref{\DUrole{std,std-ref}{Start the Kerberos daemons on the primary KDC}}}}).

\item {} 
Set up the cron job to propagate the database (see
{\hyperref[\detokenize{admin/install_kdc:kprop-to-replicas}]{\sphinxcrossref{\DUrole{std,std-ref}{Propagate the database to each replica KDC}}}}).

\item {} 
Switch the CNAMEs of the old and new primary KDCs.  If you can’t do
this, you’ll need to change the {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} file on every
client machine in your Kerberos realm.

\end{enumerate}


\subsubsection{Incremental database propagation}
\label{\detokenize{admin/install_kdc:incremental-database-propagation}}
If you expect your Kerberos database to become large, you may wish to
set up incremental propagation to replica KDCs.  See
{\hyperref[\detokenize{admin/database:incr-db-prop}]{\sphinxcrossref{\DUrole{std,std-ref}{Incremental database propagation}}}} for details.


\subsection{Installing and configuring UNIX client machines}
\label{\detokenize{admin/install_clients:installing-and-configuring-unix-client-machines}}\label{\detokenize{admin/install_clients::doc}}
The Kerberized client programs include \DUrole{xref,std,std-ref}{kinit(1)},
\DUrole{xref,std,std-ref}{klist(1)}, \DUrole{xref,std,std-ref}{kdestroy(1)}, and \DUrole{xref,std,std-ref}{kpasswd(1)}.  All of
these programs are in the directory {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{BINDIR}}}}.

You can often integrate Kerberos with the login system on client
machines, typically through the use of PAM.  The details vary by
operating system, and should be covered in your operating system’s
documentation.  If you do this, you will need to make sure your users
know to use their Kerberos passwords when they log in.

You will also need to educate your users to use the ticket management
programs kinit, klist, and kdestroy.  If you do not have Kerberos
password changing integrated into the native password program (again,
typically through PAM), you will need to educate users to use kpasswd
in place of its non-Kerberos counterparts passwd.


\subsubsection{Client machine configuration files}
\label{\detokenize{admin/install_clients:client-machine-configuration-files}}
Each machine running Kerberos should have a {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} file.
At a minimum, it should define a \sphinxstylestrong{default\_realm} setting in
{\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}}.  If you are not using DNS SRV records
({\hyperref[\detokenize{admin/realm_config:kdc-hostnames}]{\sphinxcrossref{\DUrole{std,std-ref}{Hostnames for KDCs}}}}) or URI records ({\hyperref[\detokenize{admin/realm_config:kdc-discovery}]{\sphinxcrossref{\DUrole{std,std-ref}{KDC Discovery}}}}), it must
also contain a {\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} section containing information for your
realm’s KDCs.

Consider setting \sphinxstylestrong{rdns} to false in order to reduce your dependence
on precisely correct DNS information for service hostnames.  Turning
this flag off means that service hostnames will be canonicalized
through forward name resolution (which adds your domain name to
unqualified hostnames, and resolves CNAME records in DNS), but not
through reverse address lookup.  The default value of this flag is
true for historical reasons only.

If you anticipate users frequently logging into remote hosts
(e.g., using ssh) using forwardable credentials, consider setting
\sphinxstylestrong{forwardable} to true so that users obtain forwardable tickets by
default.  Otherwise users will need to use \sphinxcode{kinit -f} to get
forwardable tickets.

Consider adjusting the \sphinxstylestrong{ticket\_lifetime} setting to match the likely
length of sessions for your users.  For instance, if most of your
users will be logging in for an eight-hour workday, you could set the
default to ten hours so that tickets obtained in the morning expire
shortly after the end of the workday.  Users can still manually
request longer tickets when necessary, up to the maximum allowed by
each user’s principal record on the KDC.

If a client host may access services in different realms, it may be
useful to define a {\hyperref[\detokenize{admin/conf_files/krb5_conf:domain-realm}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}domain\_realm{]}}}}} mapping so that clients know
which hosts belong to which realms.  However, if your clients and KDC
are running release 1.7 or later, it is also reasonable to leave this
section out on client machines and just define it in the KDC’s
krb5.conf.


\subsection{UNIX Application Servers}
\label{\detokenize{admin/install_appl_srv:unix-application-servers}}\label{\detokenize{admin/install_appl_srv::doc}}
An application server is a host that provides one or more services
over the network.  Application servers can be “secure” or “insecure.”
A “secure” host is set up to require authentication from every client
connecting to it.  An “insecure” host will still provide Kerberos
authentication, but will also allow unauthenticated clients to
connect.

If you have Kerberos V5 installed on all of your client machines, MIT
recommends that you make your hosts secure, to take advantage of the
security that Kerberos authentication affords.  However, if you have
some clients that do not have Kerberos V5 installed, you can run an
insecure server, and still take advantage of Kerberos V5’s single
sign-on capability.


\subsubsection{The keytab file}
\label{\detokenize{admin/install_appl_srv:the-keytab-file}}\label{\detokenize{admin/install_appl_srv:keytab-file}}
All Kerberos server machines need a keytab file to authenticate to the
KDC.  By default on UNIX-like systems this file is named {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{DEFKTNAME}}}}.
The keytab file is an local copy of the host’s key.  The keytab file
is a potential point of entry for a break-in, and if compromised,
would allow unrestricted access to its host.  The keytab file should
be readable only by root, and should exist only on the machine’s local
disk.  The file should not be part of any backup of the machine,
unless access to the backup data is secured as tightly as access to
the machine’s root password.

In order to generate a keytab for a host, the host must have a
principal in the Kerberos database.  The procedure for adding hosts to
the database is described fully in {\hyperref[\detokenize{admin/database:principals}]{\sphinxcrossref{\DUrole{std,std-ref}{Principals}}}}.  (See
{\hyperref[\detokenize{admin/install_kdc:replica-host-key}]{\sphinxcrossref{\DUrole{std,std-ref}{Create host keytabs for replica KDCs}}}} for a brief description.)  The keytab is
generated by running {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} and issuing the {\hyperref[\detokenize{admin/admin_commands/kadmin_local:ktadd}]{\sphinxcrossref{\DUrole{std,std-ref}{ktadd}}}}
command.

For example, to generate a keytab file to allow the host
\sphinxcode{trillium.mit.edu} to authenticate for the services host, ftp, and
pop, the administrator \sphinxcode{joeadmin} would issue the command (on
\sphinxcode{trillium.mit.edu}):

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{trillium}\PYG{o}{\PYGZpc{}} \PYG{n}{kadmin}
\PYG{n}{Authenticating} \PYG{k}{as} \PYG{n}{principal} \PYG{n}{root}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{password}\PYG{o}{.}
\PYG{n}{Password} \PYG{k}{for} \PYG{n}{root}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{p}{:}
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{ktadd} \PYG{n}{host}\PYG{o}{/}\PYG{n}{trillium}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{n}{ftp}\PYG{o}{/}\PYG{n}{trillium}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{n}{pop}\PYG{o}{/}\PYG{n}{trillium}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{trillium}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{3}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha384}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{192} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{ftp}\PYG{o}{/}\PYG{n}{trillium}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{3}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha384}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{192} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{pop}\PYG{o}{/}\PYG{n}{trillium}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{3}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha384}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{192} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{quit}
\PYG{n}{trillium}\PYG{o}{\PYGZpc{}}
\end{sphinxVerbatim}

If you generate the keytab file on another host, you need to get a
copy of the keytab file onto the destination host (\sphinxcode{trillium}, in
the above example) without sending it unencrypted over the network.


\subsubsection{Some advice about secure hosts}
\label{\detokenize{admin/install_appl_srv:some-advice-about-secure-hosts}}
Kerberos V5 can protect your host from certain types of break-ins, but
it is possible to install Kerberos V5 and still leave your host
vulnerable to attack.  Obviously an installation guide is not the
place to try to include an exhaustive list of countermeasures for
every possible attack, but it is worth noting some of the larger holes
and how to close them.

We recommend that backups of secure machines exclude the keytab file
({\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{DEFKTNAME}}}}).  If this is not possible, the backups should at least be
done locally, rather than over a network, and the backup tapes should
be physically secured.

The keytab file and any programs run by root, including the Kerberos
V5 binaries, should be kept on local disk.  The keytab file should be
readable only by root.


\section{Additional references}
\label{\detokenize{admin/install:additional-references}}\begin{enumerate}
\item {} 
Debian: \sphinxhref{http://techpubs.spinlocksolutions.com/dklar/kerberos.html}{Setting up MIT Kerberos 5}

\item {} 
Solaris: \sphinxhref{https://docs.oracle.com/cd/E19253-01/816-4557/6maosrjv2/index.html}{Configuring the Kerberos Service}

\end{enumerate}


\chapter{Configuration Files}
\label{\detokenize{admin/conf_files/index:configuration-files}}\label{\detokenize{admin/conf_files/index::doc}}
Kerberos uses configuration files to allow administrators to specify
settings on a per-machine basis.  {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} applies to all
applications using the Kerboros library, on clients and servers.
For KDC-specific applications, additional settings can be specified in
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}; the two files are merged into a configuration profile
used by applications accessing the KDC database directly.  {\hyperref[\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5.acl}}}}
is also only used on the KDC, it controls permissions for modifying the
KDC database.


\section{Contents}
\label{\detokenize{admin/conf_files/index:contents}}

\subsection{krb5.conf}
\label{\detokenize{admin/conf_files/krb5_conf::doc}}\label{\detokenize{admin/conf_files/krb5_conf:krb5-conf}}\label{\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}}
The krb5.conf file contains Kerberos configuration information,
including the locations of KDCs and admin servers for the Kerberos
realms of interest, defaults for the current realm and for Kerberos
applications, and mappings of hostnames onto Kerberos realms.
Normally, you should install your krb5.conf file in the directory
\sphinxcode{/etc}.  You can override the default location by setting the
environment variable \sphinxstylestrong{KRB5\_CONFIG}.  Multiple colon-separated
filenames may be specified in \sphinxstylestrong{KRB5\_CONFIG}; all files which are
present will be read.  Starting in release 1.14, directory names can
also be specified in \sphinxstylestrong{KRB5\_CONFIG}; all files within the directory
whose names consist solely of alphanumeric characters, dashes, or
underscores will be read.


\subsubsection{Structure}
\label{\detokenize{admin/conf_files/krb5_conf:structure}}
The krb5.conf file is set up in the style of a Windows INI file.
Lines beginning with ‘\#’ or ‘;’ (possibly after initial whitespace)
are ignored as comments.  Sections are headed by the section name, in
square brackets.  Each section may contain zero or more relations, of
the form:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{foo} \PYG{o}{=} \PYG{n}{bar}
\end{sphinxVerbatim}

or:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{fubar} \PYG{o}{=} \PYG{p}{\PYGZob{}}
    \PYG{n}{foo} \PYG{o}{=} \PYG{n}{bar}
    \PYG{n}{baz} \PYG{o}{=} \PYG{n}{quux}
\PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

Placing a ‘*’ after the closing bracket of a section name indicates
that the section is \sphinxstyleemphasis{final}, meaning that if the same section appears
within a later file specified in \sphinxstylestrong{KRB5\_CONFIG}, it will be ignored.
A subsection can be marked as final by placing a ‘*’ after either the
tag name or the closing brace.

The krb5.conf file can include other files using either of the
following directives at the beginning of a line:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{include} \PYG{n}{FILENAME}
\PYG{n}{includedir} \PYG{n}{DIRNAME}
\end{sphinxVerbatim}

\sphinxstyleemphasis{FILENAME} or \sphinxstyleemphasis{DIRNAME} should be an absolute path. The named file or
directory must exist and be readable.  Including a directory includes
all files within the directory whose names consist solely of
alphanumeric characters, dashes, or underscores.  Starting in release
1.15, files with names ending in “.conf” are also included, unless the
name begins with “.”.  Included profile files are syntactically
independent of their parents, so each included file must begin with a
section header.  Starting in release 1.17, files are read in
alphanumeric order; in previous releases, they may be read in any
order.

The krb5.conf file can specify that configuration should be obtained
from a loadable module, rather than the file itself, using the
following directive at the beginning of a line before any section
headers:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{module} \PYG{n}{MODULEPATH}\PYG{p}{:}\PYG{n}{RESIDUAL}
\end{sphinxVerbatim}

\sphinxstyleemphasis{MODULEPATH} may be relative to the library path of the krb5
installation, or it may be an absolute path.  \sphinxstyleemphasis{RESIDUAL} is provided
to the module at initialization time.  If krb5.conf uses a module
directive, {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} should also use one if it exists.


\subsubsection{Sections}
\label{\detokenize{admin/conf_files/krb5_conf:sections}}
The krb5.conf file may contain the following sections:


\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|}
\hline

{\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}}
&
Settings used by the Kerberos V5 library
\\
\hline
{\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}}
&
Realm-specific contact information and settings
\\
\hline
{\hyperref[\detokenize{admin/conf_files/krb5_conf:domain-realm}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}domain\_realm{]}}}}}
&
Maps server hostnames to Kerberos realms
\\
\hline
{\hyperref[\detokenize{admin/conf_files/krb5_conf:capaths}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}capaths{]}}}}}
&
Authentication paths for non-hierarchical cross-realm
\\
\hline
{\hyperref[\detokenize{admin/conf_files/krb5_conf:appdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}appdefaults{]}}}}}
&
Settings used by some Kerberos V5 applications
\\
\hline
{\hyperref[\detokenize{admin/conf_files/krb5_conf:plugins}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}plugins{]}}}}}
&
Controls plugin module registration
\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}

Additionally, krb5.conf may include any of the relations described in
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}, but it is not a recommended practice.


\paragraph{{[}libdefaults{]}}
\label{\detokenize{admin/conf_files/krb5_conf:libdefaults}}\label{\detokenize{admin/conf_files/krb5_conf:id1}}
The libdefaults section may contain any of the following relations:
\begin{description}
\item[{\sphinxstylestrong{allow\_des3}}] \leavevmode
Permit the KDC to issue tickets with des3-cbc-sha1 session keys.
In future releases, this flag will allow des3-cbc-sha1 to be used
at all.  The default value for this tag is false.  (Added in
release 1.21.)

\item[{\sphinxstylestrong{allow\_rc4}}] \leavevmode
Permit the KDC to issue tickets with arcfour-hmac session keys.
In future releases, this flag will allow arcfour-hmac to be used
at all.  The default value for this tag is false.  (Added in
release 1.21.)

\item[{\sphinxstylestrong{allow\_weak\_crypto}}] \leavevmode
If this flag is set to false, then weak encryption types (as noted
in {\hyperref[\detokenize{admin/conf_files/kdc_conf:encryption-types}]{\sphinxcrossref{\DUrole{std,std-ref}{Encryption types}}}} in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}) will be filtered
out of the lists \sphinxstylestrong{default\_tgs\_enctypes},
\sphinxstylestrong{default\_tkt\_enctypes}, and \sphinxstylestrong{permitted\_enctypes}.  The default
value for this tag is false.

\item[{\sphinxstylestrong{canonicalize}}] \leavevmode
If this flag is set to true, initial ticket requests to the KDC
will request canonicalization of the client principal name, and
answers with different client principals than the requested
principal will be accepted.  The default value is false.

\item[{\sphinxstylestrong{ccache\_type}}] \leavevmode
This parameter determines the format of credential cache types
created by \DUrole{xref,std,std-ref}{kinit(1)} or other programs.  The default value
is 4, which represents the most current format.  Smaller values
can be used for compatibility with very old implementations of
Kerberos which interact with credential caches on the same host.

\item[{\sphinxstylestrong{clockskew}}] \leavevmode
Sets the maximum allowable amount of clockskew in seconds that the
library will tolerate before assuming that a Kerberos message is
invalid.  The default value is 300 seconds, or five minutes.

The clockskew setting is also used when evaluating ticket start
and expiration times.  For example, tickets that have reached
their expiration time can still be used (and renewed if they are
renewable tickets) if they have been expired for a shorter
duration than the \sphinxstylestrong{clockskew} setting.

\item[{\sphinxstylestrong{default\_ccache\_name}}] \leavevmode
This relation specifies the name of the default credential cache.
The default is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{DEFCCNAME}}}}.  This relation is subject to parameter
expansion (see below).  New in release 1.11.

\item[{\sphinxstylestrong{default\_client\_keytab\_name}}] \leavevmode
This relation specifies the name of the default keytab for
obtaining client credentials.  The default is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{DEFCKTNAME}}}}.  This
relation is subject to parameter expansion (see below).
New in release 1.11.

\item[{\sphinxstylestrong{default\_keytab\_name}}] \leavevmode
This relation specifies the default keytab name to be used by
application servers such as sshd.  The default is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{DEFKTNAME}}}}.  This
relation is subject to parameter expansion (see below).

\item[{\sphinxstylestrong{default\_rcache\_name}}] \leavevmode
This relation specifies the name of the default replay cache.
The default is \sphinxcode{dfl:}.  This relation is subject to parameter
expansion (see below).  New in release 1.18.

\item[{\sphinxstylestrong{default\_realm}}] \leavevmode
Identifies the default Kerberos realm for the client.  Set its
value to your Kerberos realm.  If this value is not set, then a
realm must be specified with every Kerberos principal when
invoking programs such as \DUrole{xref,std,std-ref}{kinit(1)}.

\item[{\sphinxstylestrong{default\_tgs\_enctypes}}] \leavevmode
Identifies the supported list of session key encryption types that
the client should request when making a TGS-REQ, in order of
preference from highest to lowest.  The list may be delimited with
commas or whitespace.  See {\hyperref[\detokenize{admin/conf_files/kdc_conf:encryption-types}]{\sphinxcrossref{\DUrole{std,std-ref}{Encryption types}}}} in
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} for a list of the accepted values for this tag.
Starting in release 1.18, the default value is the value of
\sphinxstylestrong{permitted\_enctypes}.  For previous releases or if
\sphinxstylestrong{permitted\_enctypes} is not set, the default value is
\sphinxcode{aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac}.

Do not set this unless required for specific backward
compatibility purposes; stale values of this setting can prevent
clients from taking advantage of new stronger enctypes when the
libraries are upgraded.

\item[{\sphinxstylestrong{default\_tkt\_enctypes}}] \leavevmode
Identifies the supported list of session key encryption types that
the client should request when making an AS-REQ, in order of
preference from highest to lowest.  The format is the same as for
default\_tgs\_enctypes.  Starting in release 1.18, the default
value is the value of \sphinxstylestrong{permitted\_enctypes}.  For previous
releases or if \sphinxstylestrong{permitted\_enctypes} is not set, the default
value is \sphinxcode{aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac}.

Do not set this unless required for specific backward
compatibility purposes; stale values of this setting can prevent
clients from taking advantage of new stronger enctypes when the
libraries are upgraded.

\item[{\sphinxstylestrong{dns\_canonicalize\_hostname}}] \leavevmode
Indicate whether name lookups will be used to canonicalize
hostnames for use in service principal names.  Setting this flag
to false can improve security by reducing reliance on DNS, but
means that short hostnames will not be canonicalized to
fully-qualified hostnames.  If this option is set to \sphinxcode{fallback} (new
in release 1.18), DNS canonicalization will only be performed the
server hostname is not found with the original name when
requesting credentials.  The default value is true.

\item[{\sphinxstylestrong{dns\_lookup\_kdc}}] \leavevmode
Indicate whether DNS SRV records should be used to locate the KDCs
and other servers for a realm, if they are not listed in the
krb5.conf information for the realm.  (Note that the admin\_server
entry must be in the krb5.conf realm information in order to
contact kadmind, because the DNS implementation for kadmin is
incomplete.)

Enabling this option does open up a type of denial-of-service
attack, if someone spoofs the DNS records and redirects you to
another server.  However, it’s no worse than a denial of service,
because that fake KDC will be unable to decode anything you send
it (besides the initial ticket request, which has no encrypted
data), and anything the fake KDC sends will not be trusted without
verification using some secret that it won’t know.

\item[{\sphinxstylestrong{dns\_uri\_lookup}}] \leavevmode
Indicate whether DNS URI records should be used to locate the KDCs
and other servers for a realm, if they are not listed in the
krb5.conf information for the realm.  SRV records are used as a
fallback if no URI records were found.  The default value is true.
New in release 1.15.

\item[{\sphinxstylestrong{enforce\_ok\_as\_delegate}}] \leavevmode
If this flag to true, GSSAPI credential delegation will be
disabled when the \sphinxcode{ok-as-delegate} flag is not set in the
service ticket.  If this flag is false, the \sphinxcode{ok-as-delegate}
ticket flag is only enforced when an application specifically
requests enforcement.  The default value is false.

\item[{\sphinxstylestrong{err\_fmt}}] \leavevmode
This relation allows for custom error message formatting.  If a
value is set, error messages will be formatted by substituting a
normal error message for \%M and an error code for \%C in the value.

\item[{\sphinxstylestrong{extra\_addresses}}] \leavevmode
This allows a computer to use multiple local addresses, in order
to allow Kerberos to work in a network that uses NATs while still
using address-restricted tickets.  The addresses should be in a
comma-separated list.  This option has no effect if
\sphinxstylestrong{noaddresses} is true.

\item[{\sphinxstylestrong{forwardable}}] \leavevmode
If this flag is true, initial tickets will be forwardable by
default, if allowed by the KDC.  The default value is false.

\item[{\sphinxstylestrong{ignore\_acceptor\_hostname}}] \leavevmode
When accepting GSSAPI or krb5 security contexts for host-based
service principals, ignore any hostname passed by the calling
application, and allow clients to authenticate to any service
principal in the keytab matching the service name and realm name
(if given).  This option can improve the administrative
flexibility of server applications on multihomed hosts, but could
compromise the security of virtual hosting environments.  The
default value is false.  New in release 1.10.

\item[{\sphinxstylestrong{k5login\_authoritative}}] \leavevmode
If this flag is true, principals must be listed in a local user’s
k5login file to be granted login access, if a \DUrole{xref,std,std-ref}{.k5login(5)}
file exists.  If this flag is false, a principal may still be
granted login access through other mechanisms even if a k5login
file exists but does not list the principal.  The default value is
true.

\item[{\sphinxstylestrong{k5login\_directory}}] \leavevmode
If set, the library will look for a local user’s k5login file
within the named directory, with a filename corresponding to the
local username.  If not set, the library will look for k5login
files in the user’s home directory, with the filename .k5login.
For security reasons, .k5login files must be owned by
the local user or by root.

\item[{\sphinxstylestrong{kcm\_mach\_service}}] \leavevmode
On macOS only, determines the name of the bootstrap service used to
contact the KCM daemon for the KCM credential cache type.  If the
value is \sphinxcode{-}, Mach RPC will not be used to contact the KCM
daemon.  The default value is \sphinxcode{org.h5l.kcm}.

\item[{\sphinxstylestrong{kcm\_socket}}] \leavevmode
Determines the path to the Unix domain socket used to access the
KCM daemon for the KCM credential cache type.  If the value is
\sphinxcode{-}, Unix domain sockets will not be used to contact the KCM
daemon.  The default value is
\sphinxcode{/var/run/.heim\_org.h5l.kcm-socket}.

\item[{\sphinxstylestrong{kdc\_default\_options}}] \leavevmode
Default KDC options (Xored for multiple values) when requesting
initial tickets.  By default it is set to 0x00000010
(KDC\_OPT\_RENEWABLE\_OK).

\item[{\sphinxstylestrong{kdc\_timesync}}] \leavevmode
Accepted values for this relation are 1 or 0.  If it is nonzero,
client machines will compute the difference between their time and
the time returned by the KDC in the timestamps in the tickets and
use this value to correct for an inaccurate system clock when
requesting service tickets or authenticating to services.  This
corrective factor is only used by the Kerberos library; it is not
used to change the system clock.  The default value is 1.

\item[{\sphinxstylestrong{noaddresses}}] \leavevmode
If this flag is true, requests for initial tickets will not be
made with address restrictions set, allowing the tickets to be
used across NATs.  The default value is true.

\item[{\sphinxstylestrong{permitted\_enctypes}}] \leavevmode
Identifies the encryption types that servers will permit for
session keys and for ticket and authenticator encryption, ordered
by preference from highest to lowest.  Starting in release 1.18,
this tag also acts as the default value for
\sphinxstylestrong{default\_tgs\_enctypes} and \sphinxstylestrong{default\_tkt\_enctypes}.  The
default value for this tag is \sphinxcode{aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac}.

\item[{\sphinxstylestrong{plugin\_base\_dir}}] \leavevmode
If set, determines the base directory where krb5 plugins are
located.  The default value is the \sphinxcode{krb5/plugins} subdirectory
of the krb5 library directory.  This relation is subject to
parameter expansion (see below) in release 1.17 and later.

\item[{\sphinxstylestrong{preferred\_preauth\_types}}] \leavevmode
This allows you to set the preferred preauthentication types which
the client will attempt before others which may be advertised by a
KDC.  The default value for this setting is “17, 16, 15, 14”,
which forces libkrb5 to attempt to use PKINIT if it is supported.

\item[{\sphinxstylestrong{proxiable}}] \leavevmode
If this flag is true, initial tickets will be proxiable by
default, if allowed by the KDC.  The default value is false.

\item[{\sphinxstylestrong{qualify\_shortname}}] \leavevmode
If this string is set, it determines the domain suffix for
single-component hostnames when DNS canonicalization is not used
(either because \sphinxstylestrong{dns\_canonicalize\_hostname} is false or because
forward canonicalization failed).  The default value is the first
search domain of the system’s DNS configuration.  To disable
qualification of shortnames, set this relation to the empty string
with \sphinxcode{qualify\_shortname = ""}.  (New in release 1.18.)

\item[{\sphinxstylestrong{rdns}}] \leavevmode
If this flag is true, reverse name lookup will be used in addition
to forward name lookup to canonicalizing hostnames for use in
service principal names.  If \sphinxstylestrong{dns\_canonicalize\_hostname} is set
to false, this flag has no effect.  The default value is true.

\item[{\sphinxstylestrong{realm\_try\_domains}}] \leavevmode
Indicate whether a host’s domain components should be used to
determine the Kerberos realm of the host.  The value of this
variable is an integer: -1 means not to search, 0 means to try the
host’s domain itself, 1 means to also try the domain’s immediate
parent, and so forth.  The library’s usual mechanism for locating
Kerberos realms is used to determine whether a domain is a valid
realm, which may involve consulting DNS if \sphinxstylestrong{dns\_lookup\_kdc} is
set.  The default is not to search domain components.

\item[{\sphinxstylestrong{renew\_lifetime}}] \leavevmode
(\DUrole{xref,std,std-ref}{duration} string.)  Sets the default renewable lifetime
for initial ticket requests.  The default value is 0.

\item[{\sphinxstylestrong{spake\_preauth\_groups}}] \leavevmode
A whitespace or comma-separated list of words which specifies the
groups allowed for SPAKE preauthentication.  The possible values
are:


\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|}
\hline

edwards25519
&
Edwards25519 curve (\index{RFC!RFC 7748}\sphinxhref{https://tools.ietf.org/html/rfc7748.html}{\sphinxstylestrong{RFC 7748}})
\\
\hline
P-256
&
NIST P-256 curve (\index{RFC!RFC 5480}\sphinxhref{https://tools.ietf.org/html/rfc5480.html}{\sphinxstylestrong{RFC 5480}})
\\
\hline
P-384
&
NIST P-384 curve (\index{RFC!RFC 5480}\sphinxhref{https://tools.ietf.org/html/rfc5480.html}{\sphinxstylestrong{RFC 5480}})
\\
\hline
P-521
&
NIST P-521 curve (\index{RFC!RFC 5480}\sphinxhref{https://tools.ietf.org/html/rfc5480.html}{\sphinxstylestrong{RFC 5480}})
\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}

The default value for the client is \sphinxcode{edwards25519}.  The default
value for the KDC is empty.  New in release 1.17.

\item[{\sphinxstylestrong{ticket\_lifetime}}] \leavevmode
(\DUrole{xref,std,std-ref}{duration} string.)  Sets the default lifetime for initial
ticket requests.  The default value is 1 day.

\item[{\sphinxstylestrong{udp\_preference\_limit}}] \leavevmode
When sending a message to the KDC, the library will try using TCP
before UDP if the size of the message is above
\sphinxstylestrong{udp\_preference\_limit}.  If the message is smaller than
\sphinxstylestrong{udp\_preference\_limit}, then UDP will be tried before TCP.
Regardless of the size, both protocols will be tried if the first
attempt fails.

\item[{\sphinxstylestrong{verify\_ap\_req\_nofail}}] \leavevmode
If this flag is true, then an attempt to verify initial
credentials will fail if the client machine does not have a
keytab.  The default value is false.

\item[{\sphinxstylestrong{client\_aware\_channel\_bindings}}] \leavevmode
If this flag is true, then all application protocol authentication
requests will be flagged to indicate that the application supports
channel bindings when operating over a secure channel.  The
default value is false.

\end{description}


\paragraph{{[}realms{]}}
\label{\detokenize{admin/conf_files/krb5_conf:id2}}\label{\detokenize{admin/conf_files/krb5_conf:realms}}
Each tag in the {[}realms{]} section of the file is the name of a Kerberos
realm.  The value of the tag is a subsection with relations that
define the properties of that particular realm.  For each realm, the
following tags may be specified in the realm’s subsection:
\begin{description}
\item[{\sphinxstylestrong{admin\_server}}] \leavevmode
Identifies the host where the administration server is running.
Typically, this is the primary Kerberos server.  This tag must be
given a value in order to communicate with the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}}
server for the realm.

\item[{\sphinxstylestrong{auth\_to\_local}}] \leavevmode
This tag allows you to set a general rule for mapping principal
names to local user names.  It will be used if there is not an
explicit mapping for the principal name that is being
translated. The possible values are:
\begin{description}
\item[{\sphinxstylestrong{RULE:}\sphinxstyleemphasis{exp}}] \leavevmode
The local name will be formulated from \sphinxstyleemphasis{exp}.

The format for \sphinxstyleemphasis{exp} is \sphinxstylestrong{{[}}\sphinxstyleemphasis{n}\sphinxstylestrong{:}\sphinxstyleemphasis{string}\sphinxstylestrong{{]}(}\sphinxstyleemphasis{regexp}\sphinxstylestrong{)s/}\sphinxstyleemphasis{pattern}\sphinxstylestrong{/}\sphinxstyleemphasis{replacement}\sphinxstylestrong{/g}.
The integer \sphinxstyleemphasis{n} indicates how many components the target
principal should have.  If this matches, then a string will be
formed from \sphinxstyleemphasis{string}, substituting the realm of the principal
for \sphinxcode{\$0} and the \sphinxstyleemphasis{n}’th component of the principal for
\sphinxcode{\$n} (e.g., if the principal was \sphinxcode{johndoe/admin} then
\sphinxcode{{[}2:\$2\$1foo{]}} would result in the string
\sphinxcode{adminjohndoefoo}).  If this string matches \sphinxstyleemphasis{regexp}, then
the \sphinxcode{s//{[}g{]}} substitution command will be run over the
string.  The optional \sphinxstylestrong{g} will cause the substitution to be
global over the \sphinxstyleemphasis{string}, instead of replacing only the first
match in the \sphinxstyleemphasis{string}.

\item[{\sphinxstylestrong{DEFAULT}}] \leavevmode
The principal name will be used as the local user name.  If
the principal has more than one component or is not in the
default realm, this rule is not applicable and the conversion
will fail.

\end{description}

For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
[realms]
    ATHENA.MIT.EDU = \PYGZob{}
        auth\PYGZus{}to\PYGZus{}local = RULE:[2:\PYGZdl{}1](johndoe)s/\PYGZca{}.*\PYGZdl{}/guest/
        auth\PYGZus{}to\PYGZus{}local = RULE:[2:\PYGZdl{}1;\PYGZdl{}2](\PYGZca{}.*;admin\PYGZdl{})s/;admin\PYGZdl{}//
        auth\PYGZus{}to\PYGZus{}local = RULE:[2:\PYGZdl{}2](\PYGZca{}.*;root)s/\PYGZca{}.*\PYGZdl{}/root/
        auth\PYGZus{}to\PYGZus{}local = DEFAULT
    \PYGZcb{}
\end{sphinxVerbatim}

would result in any principal without \sphinxcode{root} or \sphinxcode{admin} as the
second component to be translated with the default rule.  A
principal with a second component of \sphinxcode{admin} will become its
first component.  \sphinxcode{root} will be used as the local name for any
principal with a second component of \sphinxcode{root}.  The exception to
these two rules are any principals \sphinxcode{johndoe/*}, which will
always get the local name \sphinxcode{guest}.

\item[{\sphinxstylestrong{auth\_to\_local\_names}}] \leavevmode
This subsection allows you to set explicit mappings from principal
names to local user names.  The tag is the mapping name, and the
value is the corresponding local user name.

\item[{\sphinxstylestrong{default\_domain}}] \leavevmode
This tag specifies the domain used to expand hostnames when
translating Kerberos 4 service principals to Kerberos 5 principals
(for example, when converting \sphinxcode{rcmd.hostname} to
\sphinxcode{host/hostname.domain}).

\item[{\sphinxstylestrong{disable\_encrypted\_timestamp}}] \leavevmode
If this flag is true, the client will not perform encrypted
timestamp preauthentication if requested by the KDC.  Setting this
flag can help to prevent dictionary attacks by active attackers,
if the realm’s KDCs support SPAKE preauthentication or if initial
authentication always uses another mechanism or always uses FAST.
This flag persists across client referrals during initial
authentication.  This flag does not prevent the KDC from offering
encrypted timestamp.  New in release 1.17.

\item[{\sphinxstylestrong{http\_anchors}}] \leavevmode
When KDCs and kpasswd servers are accessed through HTTPS proxies, this tag
can be used to specify the location of the CA certificate which should be
trusted to issue the certificate for a proxy server.  If left unspecified,
the system-wide default set of CA certificates is used.

The syntax for values is similar to that of values for the
\sphinxstylestrong{pkinit\_anchors} tag:

\sphinxstylestrong{FILE:} \sphinxstyleemphasis{filename}

\sphinxstyleemphasis{filename} is assumed to be the name of an OpenSSL-style ca-bundle file.

\sphinxstylestrong{DIR:} \sphinxstyleemphasis{dirname}

\sphinxstyleemphasis{dirname} is assumed to be an directory which contains CA certificates.
All files in the directory will be examined; if they contain certificates
(in PEM format), they will be used.

\sphinxstylestrong{ENV:} \sphinxstyleemphasis{envvar}

\sphinxstyleemphasis{envvar} specifies the name of an environment variable which has been set
to a value conforming to one of the previous values.  For example,
\sphinxcode{ENV:X509\_PROXY\_CA}, where environment variable \sphinxcode{X509\_PROXY\_CA} has
been set to \sphinxcode{FILE:/tmp/my\_proxy.pem}.

\item[{\sphinxstylestrong{kdc}}] \leavevmode
The name or address of a host running a KDC for that realm.  An
optional port number, separated from the hostname by a colon, may
be included.  If the name or address contains colons (for example,
if it is an IPv6 address), enclose it in square brackets to
distinguish the colon from a port separator.  For your computer to
be able to communicate with the KDC for each realm, this tag must
be given a value in each realm subsection in the configuration
file, or there must be DNS SRV records specifying the KDCs.

\item[{\sphinxstylestrong{kpasswd\_server}}] \leavevmode
Points to the server where all the password changes are performed.
If there is no such entry, DNS will be queried (unless forbidden
by \sphinxstylestrong{dns\_lookup\_kdc}).  Finally, port 464 on the \sphinxstylestrong{admin\_server}
host will be tried.

\item[{\sphinxstylestrong{master\_kdc}}] \leavevmode
The name for \sphinxstylestrong{primary\_kdc} prior to release 1.19.  Its value is
used as a fallback if \sphinxstylestrong{primary\_kdc} is not specified.

\item[{\sphinxstylestrong{primary\_kdc}}] \leavevmode
Identifies the primary KDC(s).  Currently, this tag is used in only
one case: If an attempt to get credentials fails because of an
invalid password, the client software will attempt to contact the
primary KDC, in case the user’s password has just been changed, and
the updated database has not been propagated to the replica
servers yet.  New in release 1.19.

\item[{\sphinxstylestrong{v4\_instance\_convert}}] \leavevmode
This subsection allows the administrator to configure exceptions
to the \sphinxstylestrong{default\_domain} mapping rule.  It contains V4 instances
(the tag name) which should be translated to some specific
hostname (the tag value) as the second component in a Kerberos V5
principal name.

\item[{\sphinxstylestrong{v4\_realm}}] \leavevmode
This relation is used by the krb524 library routines when
converting a V5 principal name to a V4 principal name.  It is used
when the V4 realm name and the V5 realm name are not the same, but
still share the same principal names and passwords. The tag value
is the Kerberos V4 realm name.

\end{description}


\paragraph{{[}domain\_realm{]}}
\label{\detokenize{admin/conf_files/krb5_conf:id3}}\label{\detokenize{admin/conf_files/krb5_conf:domain-realm}}
The {[}domain\_realm{]} section provides a translation from hostnames to
Kerberos realms.  Each tag is a domain name, providing the mapping for
that domain and all subdomains.  If the tag begins with a period
(\sphinxcode{.}) then it applies only to subdomains.  The Kerberos realm may be
identified either in the {\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{realms}}} section or using DNS SRV records.
Tag names should be in lower case.  For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{domain\PYGZus{}realm}\PYG{p}{]}
    \PYG{n}{crash}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{o}{=} \PYG{n}{TEST}\PYG{o}{.}\PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
    \PYG{o}{.}\PYG{n}{dev}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{o}{=} \PYG{n}{TEST}\PYG{o}{.}\PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
    \PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{o}{=} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\end{sphinxVerbatim}

maps the host with the name \sphinxcode{crash.mit.edu} into the
\sphinxcode{TEST.ATHENA.MIT.EDU} realm.  The second entry maps all hosts under the
domain \sphinxcode{dev.mit.edu} into the \sphinxcode{TEST.ATHENA.MIT.EDU} realm, but not
the host with the name \sphinxcode{dev.mit.edu}.  That host is matched
by the third entry, which maps the host \sphinxcode{mit.edu} and all hosts
under the domain \sphinxcode{mit.edu} that do not match a preceding rule
into the realm \sphinxcode{ATHENA.MIT.EDU}.

If no translation entry applies to a hostname used for a service
principal for a service ticket request, the library will try to get a
referral to the appropriate realm from the client realm’s KDC.  If
that does not succeed, the host’s realm is considered to be the
hostname’s domain portion converted to uppercase, unless the
\sphinxstylestrong{realm\_try\_domains} setting in {[}libdefaults{]} causes a different
parent domain to be used.


\paragraph{{[}capaths{]}}
\label{\detokenize{admin/conf_files/krb5_conf:id4}}\label{\detokenize{admin/conf_files/krb5_conf:capaths}}
In order to perform direct (non-hierarchical) cross-realm
authentication, configuration is needed to determine the
authentication paths between realms.

A client will use this section to find the authentication path between
its realm and the realm of the server.  The server will use this
section to verify the authentication path used by the client, by
checking the transited field of the received ticket.

There is a tag for each participating client realm, and each tag has
subtags for each of the server realms.  The value of the subtags is an
intermediate realm which may participate in the cross-realm
authentication.  The subtags may be repeated if there is more then one
intermediate realm.  A value of “.” means that the two realms share
keys directly, and no intermediate realms should be allowed to
participate.

Only those entries which will be needed on the client or the server
need to be present.  A client needs a tag for its local realm with
subtags for all the realms of servers it will need to authenticate to.
A server needs a tag for each realm of the clients it will serve, with
a subtag of the server realm.

For example, \sphinxcode{ANL.GOV}, \sphinxcode{PNL.GOV}, and \sphinxcode{NERSC.GOV} all wish to
use the \sphinxcode{ES.NET} realm as an intermediate realm.  ANL has a sub
realm of \sphinxcode{TEST.ANL.GOV} which will authenticate with \sphinxcode{NERSC.GOV}
but not \sphinxcode{PNL.GOV}.  The {[}capaths{]} section for \sphinxcode{ANL.GOV} systems
would look like this:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{capaths}\PYG{p}{]}
    \PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{TEST}\PYG{o}{.}\PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{o}{.}
        \PYG{n}{PNL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET}
        \PYG{n}{NERSC}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET}
        \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET} \PYG{o}{=} \PYG{o}{.}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{TEST}\PYG{o}{.}\PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{o}{.}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{PNL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{NERSC}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{o}{.}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

The {[}capaths{]} section of the configuration file used on \sphinxcode{NERSC.GOV}
systems would look like this:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{capaths}\PYG{p}{]}
    \PYG{n}{NERSC}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET}
        \PYG{n}{TEST}\PYG{o}{.}\PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET}
        \PYG{n}{TEST}\PYG{o}{.}\PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV}
        \PYG{n}{PNL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET}
        \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET} \PYG{o}{=} \PYG{o}{.}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{NERSC}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{PNL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{NERSC}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{NERSC}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{o}{.}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{TEST}\PYG{o}{.}\PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{NERSC}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ANL}\PYG{o}{.}\PYG{n}{GOV}
        \PYG{n}{NERSC}\PYG{o}{.}\PYG{n}{GOV} \PYG{o}{=} \PYG{n}{ES}\PYG{o}{.}\PYG{n}{NET}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

When a subtag is used more than once within a tag, clients will use
the order of values to determine the path.  The order of values is not
important to servers.


\paragraph{{[}appdefaults{]}}
\label{\detokenize{admin/conf_files/krb5_conf:id5}}\label{\detokenize{admin/conf_files/krb5_conf:appdefaults}}
Each tag in the {[}appdefaults{]} section names a Kerberos V5 application
or an option that is used by some Kerberos V5 application{[}s{]}.  The
value of the tag defines the default behaviors for that application.

For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{appdefaults}\PYG{p}{]}
    \PYG{n}{telnet} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
            \PYG{n}{option1} \PYG{o}{=} \PYG{n}{false}
        \PYG{p}{\PYGZcb{}}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{telnet} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{option1} \PYG{o}{=} \PYG{n}{true}
        \PYG{n}{option2} \PYG{o}{=} \PYG{n}{true}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{option2} \PYG{o}{=} \PYG{n}{false}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{option2} \PYG{o}{=} \PYG{n}{true}
\end{sphinxVerbatim}

The above four ways of specifying the value of an option are shown in
order of decreasing precedence. In this example, if telnet is running
in the realm EXAMPLE.COM, it should, by default, have option1 and
option2 set to true.  However, a telnet program in the realm
\sphinxcode{ATHENA.MIT.EDU} should have \sphinxcode{option1} set to false and
\sphinxcode{option2} set to true.  Any other programs in ATHENA.MIT.EDU should
have \sphinxcode{option2} set to false by default.  Any programs running in
other realms should have \sphinxcode{option2} set to true.

The list of specifiable options for each application may be found in
that application’s man pages.  The application defaults specified here
are overridden by those specified in the {\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{realms}}} section.


\paragraph{{[}plugins{]}}
\label{\detokenize{admin/conf_files/krb5_conf:id6}}\label{\detokenize{admin/conf_files/krb5_conf:plugins}}\begin{itemize}
\item {} 
{\hyperref[\detokenize{admin/conf_files/krb5_conf:pwqual}]{\sphinxcrossref{pwqual}}} interface

\item {} 
{\hyperref[\detokenize{admin/conf_files/krb5_conf:kadm5-hook}]{\sphinxcrossref{kadm5\_hook}}} interface

\item {} 
{\hyperref[\detokenize{admin/conf_files/krb5_conf:clpreauth}]{\sphinxcrossref{clpreauth}}} and {\hyperref[\detokenize{admin/conf_files/krb5_conf:kdcpreauth}]{\sphinxcrossref{kdcpreauth}}} interfaces

\end{itemize}

Tags in the {[}plugins{]} section can be used to register dynamic plugin
modules and to turn modules on and off.  Not every krb5 pluggable
interface uses the {[}plugins{]} section; the ones that do are documented
here.

New in release 1.9.

Each pluggable interface corresponds to a subsection of {[}plugins{]}.
All subsections support the same tags:
\begin{description}
\item[{\sphinxstylestrong{disable}}] \leavevmode
This tag may have multiple values. If there are values for this
tag, then the named modules will be disabled for the pluggable
interface.

\item[{\sphinxstylestrong{enable\_only}}] \leavevmode
This tag may have multiple values. If there are values for this
tag, then only the named modules will be enabled for the pluggable
interface.

\item[{\sphinxstylestrong{module}}] \leavevmode
This tag may have multiple values.  Each value is a string of the
form \sphinxcode{modulename:pathname}, which causes the shared object
located at \sphinxstyleemphasis{pathname} to be registered as a dynamic module named
\sphinxstyleemphasis{modulename} for the pluggable interface.  If \sphinxstyleemphasis{pathname} is not an
absolute path, it will be treated as relative to the
\sphinxstylestrong{plugin\_base\_dir} value from {\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}}.

\end{description}

For pluggable interfaces where module order matters, modules
registered with a \sphinxstylestrong{module} tag normally come first, in the order
they are registered, followed by built-in modules in the order they
are documented below.  If \sphinxstylestrong{enable\_only} tags are used, then the
order of those tags overrides the normal module order.

The following subsections are currently supported within the {[}plugins{]}
section:


\subparagraph{ccselect interface}
\label{\detokenize{admin/conf_files/krb5_conf:ccselect}}\label{\detokenize{admin/conf_files/krb5_conf:ccselect-interface}}
The ccselect subsection controls modules for credential cache
selection within a cache collection.  In addition to any registered
dynamic modules, the following built-in modules exist (and may be
disabled with the disable tag):
\begin{description}
\item[{\sphinxstylestrong{k5identity}}] \leavevmode
Uses a .k5identity file in the user’s home directory to select a
client principal

\item[{\sphinxstylestrong{realm}}] \leavevmode
Uses the service realm to guess an appropriate cache from the
collection

\item[{\sphinxstylestrong{hostname}}] \leavevmode
If the service principal is host-based, uses the service hostname
to guess an appropriate cache from the collection

\end{description}


\subparagraph{pwqual interface}
\label{\detokenize{admin/conf_files/krb5_conf:pwqual-interface}}\label{\detokenize{admin/conf_files/krb5_conf:pwqual}}
The pwqual subsection controls modules for the password quality
interface, which is used to reject weak passwords when passwords are
changed.  The following built-in modules exist for this interface:
\begin{description}
\item[{\sphinxstylestrong{dict}}] \leavevmode
Checks against the realm dictionary file

\item[{\sphinxstylestrong{empty}}] \leavevmode
Rejects empty passwords

\item[{\sphinxstylestrong{hesiod}}] \leavevmode
Checks against user information stored in Hesiod (only if Kerberos
was built with Hesiod support)

\item[{\sphinxstylestrong{princ}}] \leavevmode
Checks against components of the principal name

\end{description}


\subparagraph{kadm5\_hook interface}
\label{\detokenize{admin/conf_files/krb5_conf:kadm5-hook-interface}}\label{\detokenize{admin/conf_files/krb5_conf:kadm5-hook}}
The kadm5\_hook interface provides plugins with information on
principal creation, modification, password changes and deletion.  This
interface can be used to write a plugin to synchronize MIT Kerberos
with another database such as Active Directory.  No plugins are built
in for this interface.


\subparagraph{kadm5\_auth interface}
\label{\detokenize{admin/conf_files/krb5_conf:kadm5-auth-interface}}\label{\detokenize{admin/conf_files/krb5_conf:kadm5-auth}}
The kadm5\_auth section (introduced in release 1.16) controls modules
for the kadmin authorization interface, which determines whether a
client principal is allowed to perform a kadmin operation.  The
following built-in modules exist for this interface:
\begin{description}
\item[{\sphinxstylestrong{acl}}] \leavevmode
This module reads the {\hyperref[\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5.acl}}}} file, and authorizes
operations which are allowed according to the rules in the file.

\item[{\sphinxstylestrong{self}}] \leavevmode
This module authorizes self-service operations including password
changes, creation of new random keys, fetching the client’s
principal record or string attributes, and fetching the policy
record associated with the client principal.

\end{description}
\phantomsection\label{\detokenize{admin/conf_files/krb5_conf:clpreauth}}

\subparagraph{clpreauth and kdcpreauth interfaces}
\label{\detokenize{admin/conf_files/krb5_conf:clpreauth-and-kdcpreauth-interfaces}}\label{\detokenize{admin/conf_files/krb5_conf:clpreauth}}\label{\detokenize{admin/conf_files/krb5_conf:kdcpreauth}}
The clpreauth and kdcpreauth interfaces allow plugin modules to
provide client and KDC preauthentication mechanisms.  The following
built-in modules exist for these interfaces:
\begin{description}
\item[{\sphinxstylestrong{pkinit}}] \leavevmode
This module implements the PKINIT preauthentication mechanism.

\item[{\sphinxstylestrong{encrypted\_challenge}}] \leavevmode
This module implements the encrypted challenge FAST factor.

\item[{\sphinxstylestrong{encrypted\_timestamp}}] \leavevmode
This module implements the encrypted timestamp mechanism.

\end{description}


\subparagraph{hostrealm interface}
\label{\detokenize{admin/conf_files/krb5_conf:hostrealm-interface}}\label{\detokenize{admin/conf_files/krb5_conf:hostrealm}}
The hostrealm section (introduced in release 1.12) controls modules
for the host-to-realm interface, which affects the local mapping of
hostnames to realm names and the choice of default realm.  The following
built-in modules exist for this interface:
\begin{description}
\item[{\sphinxstylestrong{profile}}] \leavevmode
This module consults the {[}domain\_realm{]} section of the profile for
authoritative host-to-realm mappings, and the \sphinxstylestrong{default\_realm}
variable for the default realm.

\item[{\sphinxstylestrong{dns}}] \leavevmode
This module looks for DNS records for fallback host-to-realm
mappings and the default realm.  It only operates if the
\sphinxstylestrong{dns\_lookup\_realm} variable is set to true.

\item[{\sphinxstylestrong{domain}}] \leavevmode
This module applies heuristics for fallback host-to-realm
mappings.  It implements the \sphinxstylestrong{realm\_try\_domains} variable, and
uses the uppercased parent domain of the hostname if that does not
produce a result.

\end{description}


\subparagraph{localauth interface}
\label{\detokenize{admin/conf_files/krb5_conf:localauth-interface}}\label{\detokenize{admin/conf_files/krb5_conf:localauth}}
The localauth section (introduced in release 1.12) controls modules
for the local authorization interface, which affects the relationship
between Kerberos principals and local system accounts.  The following
built-in modules exist for this interface:
\begin{description}
\item[{\sphinxstylestrong{default}}] \leavevmode
This module implements the \sphinxstylestrong{DEFAULT} type for \sphinxstylestrong{auth\_to\_local}
values.

\item[{\sphinxstylestrong{rule}}] \leavevmode
This module implements the \sphinxstylestrong{RULE} type for \sphinxstylestrong{auth\_to\_local}
values.

\item[{\sphinxstylestrong{names}}] \leavevmode
This module looks for an \sphinxstylestrong{auth\_to\_local\_names} mapping for the
principal name.

\item[{\sphinxstylestrong{auth\_to\_local}}] \leavevmode
This module processes \sphinxstylestrong{auth\_to\_local} values in the default
realm’s section, and applies the default method if no
\sphinxstylestrong{auth\_to\_local} values exist.

\item[{\sphinxstylestrong{k5login}}] \leavevmode
This module authorizes a principal to a local account according to
the account’s \DUrole{xref,std,std-ref}{.k5login(5)} file.

\item[{\sphinxstylestrong{an2ln}}] \leavevmode
This module authorizes a principal to a local account if the
principal name maps to the local account name.

\end{description}


\subparagraph{certauth interface}
\label{\detokenize{admin/conf_files/krb5_conf:certauth}}\label{\detokenize{admin/conf_files/krb5_conf:certauth-interface}}
The certauth section (introduced in release 1.16) controls modules for
the certificate authorization interface, which determines whether a
certificate is allowed to preauthenticate a user via PKINIT.  The
following built-in modules exist for this interface:
\begin{description}
\item[{\sphinxstylestrong{pkinit\_san}}] \leavevmode
This module authorizes the certificate if it contains a PKINIT
Subject Alternative Name for the requested client principal, or a
Microsoft UPN SAN matching the principal if \sphinxstylestrong{pkinit\_allow\_upn}
is set to true for the realm.

\item[{\sphinxstylestrong{pkinit\_eku}}] \leavevmode
This module rejects the certificate if it does not contain an
Extended Key Usage attribute consistent with the
\sphinxstylestrong{pkinit\_eku\_checking} value for the realm.

\item[{\sphinxstylestrong{dbmatch}}] \leavevmode
This module authorizes or rejects the certificate according to
whether it matches the \sphinxstylestrong{pkinit\_cert\_match} string attribute on
the client principal, if that attribute is present.

\end{description}


\subsubsection{PKINIT options}
\label{\detokenize{admin/conf_files/krb5_conf:pkinit-options}}
\begin{sphinxadmonition}{note}{Note:}
The following are PKINIT-specific options.  These values may
be specified in {[}libdefaults{]} as global defaults, or within
a realm-specific subsection of {[}libdefaults{]}, or may be
specified as realm-specific values in the {[}realms{]} section.
A realm-specific value overrides, not adds to, a generic
{[}libdefaults{]} specification.  The search order is:
\end{sphinxadmonition}
\begin{enumerate}
\item {} 
realm-specific subsection of {[}libdefaults{]}:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{libdefaults}\PYG{p}{]}
    \PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{pkinit\PYGZus{}anchors} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{example}\PYG{o}{.}\PYG{n}{com}\PYG{o}{.}\PYG{n}{crt}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

\item {} 
realm-specific value in the {[}realms{]} section:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{realms}\PYG{p}{]}
    \PYG{n}{OTHERREALM}\PYG{o}{.}\PYG{n}{ORG} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{pkinit\PYGZus{}anchors} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{otherrealm}\PYG{o}{.}\PYG{n}{org}\PYG{o}{.}\PYG{n}{crt}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

\item {} 
generic value in the {[}libdefaults{]} section:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{libdefaults}\PYG{p}{]}
    \PYG{n}{pkinit\PYGZus{}anchors} \PYG{o}{=} \PYG{n}{DIR}\PYG{p}{:}\PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{generic\PYGZus{}trusted\PYGZus{}cas}\PYG{o}{/}
\end{sphinxVerbatim}

\end{enumerate}


\paragraph{Specifying PKINIT identity information}
\label{\detokenize{admin/conf_files/krb5_conf:specifying-pkinit-identity-information}}\label{\detokenize{admin/conf_files/krb5_conf:pkinit-identity}}
The syntax for specifying Public Key identity, trust, and revocation
information for PKINIT is as follows:
\begin{description}
\item[{\sphinxstylestrong{FILE:}\sphinxstyleemphasis{filename}{[}\sphinxstylestrong{,}\sphinxstyleemphasis{keyfilename}{]}}] \leavevmode
This option has context-specific behavior.

In \sphinxstylestrong{pkinit\_identity} or \sphinxstylestrong{pkinit\_identities}, \sphinxstyleemphasis{filename}
specifies the name of a PEM-format file containing the user’s
certificate.  If \sphinxstyleemphasis{keyfilename} is not specified, the user’s
private key is expected to be in \sphinxstyleemphasis{filename} as well.  Otherwise,
\sphinxstyleemphasis{keyfilename} is the name of the file containing the private key.

In \sphinxstylestrong{pkinit\_anchors} or \sphinxstylestrong{pkinit\_pool}, \sphinxstyleemphasis{filename} is assumed to
be the name of an OpenSSL-style ca-bundle file.

\item[{\sphinxstylestrong{DIR:}\sphinxstyleemphasis{dirname}}] \leavevmode
This option has context-specific behavior.

In \sphinxstylestrong{pkinit\_identity} or \sphinxstylestrong{pkinit\_identities}, \sphinxstyleemphasis{dirname}
specifies a directory with files named \sphinxcode{*.crt} and \sphinxcode{*.key}
where the first part of the file name is the same for matching
pairs of certificate and private key files.  When a file with a
name ending with \sphinxcode{.crt} is found, a matching file ending with
\sphinxcode{.key} is assumed to contain the private key.  If no such file
is found, then the certificate in the \sphinxcode{.crt} is not used.

In \sphinxstylestrong{pkinit\_anchors} or \sphinxstylestrong{pkinit\_pool}, \sphinxstyleemphasis{dirname} is assumed to
be an OpenSSL-style hashed CA directory where each CA cert is
stored in a file named \sphinxcode{hash-of-ca-cert.\#}.  This infrastructure
is encouraged, but all files in the directory will be examined and
if they contain certificates (in PEM format), they will be used.

In \sphinxstylestrong{pkinit\_revoke}, \sphinxstyleemphasis{dirname} is assumed to be an OpenSSL-style
hashed CA directory where each revocation list is stored in a file
named \sphinxcode{hash-of-ca-cert.r\#}.  This infrastructure is encouraged,
but all files in the directory will be examined and if they
contain a revocation list (in PEM format), they will be used.

\item[{\sphinxstylestrong{PKCS12:}\sphinxstyleemphasis{filename}}] \leavevmode
\sphinxstyleemphasis{filename} is the name of a PKCS \#12 format file, containing the
user’s certificate and private key.

\item[{\sphinxstylestrong{PKCS11:}{[}\sphinxstylestrong{module\_name=}{]}\sphinxstyleemphasis{modname}{[}\sphinxstylestrong{:slotid=}\sphinxstyleemphasis{slot-id}{]}{[}\sphinxstylestrong{:token=}\sphinxstyleemphasis{token-label}{]}{[}\sphinxstylestrong{:certid=}\sphinxstyleemphasis{cert-id}{]}{[}\sphinxstylestrong{:certlabel=}\sphinxstyleemphasis{cert-label}{]}}] \leavevmode
All keyword/values are optional.  \sphinxstyleemphasis{modname} specifies the location
of a library implementing PKCS \#11.  If a value is encountered
with no keyword, it is assumed to be the \sphinxstyleemphasis{modname}.  If no
module-name is specified, the default is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{PKCS11\_MODNAME}}}}.
\sphinxcode{slotid=} and/or \sphinxcode{token=} may be specified to force the use of
a particular smard card reader or token if there is more than one
available.  \sphinxcode{certid=} and/or \sphinxcode{certlabel=} may be specified to
force the selection of a particular certificate on the device.
See the \sphinxstylestrong{pkinit\_cert\_match} configuration option for more ways
to select a particular certificate to use for PKINIT.

\item[{\sphinxstylestrong{ENV:}\sphinxstyleemphasis{envvar}}] \leavevmode
\sphinxstyleemphasis{envvar} specifies the name of an environment variable which has
been set to a value conforming to one of the previous values.  For
example, \sphinxcode{ENV:X509\_PROXY}, where environment variable
\sphinxcode{X509\_PROXY} has been set to \sphinxcode{FILE:/tmp/my\_proxy.pem}.

\end{description}


\paragraph{PKINIT krb5.conf options}
\label{\detokenize{admin/conf_files/krb5_conf:pkinit-krb5-conf-options}}\begin{description}
\item[{\sphinxstylestrong{pkinit\_anchors}}] \leavevmode
Specifies the location of trusted anchor (root) certificates which
the client trusts to sign KDC certificates.  This option may be
specified multiple times.  These values from the config file are
not used if the user specifies X509\_anchors on the command line.

\item[{\sphinxstylestrong{pkinit\_cert\_match}}] \leavevmode
Specifies matching rules that the client certificate must match
before it is used to attempt PKINIT authentication.  If a user has
multiple certificates available (on a smart card, or via other
media), there must be exactly one certificate chosen before
attempting PKINIT authentication.  This option may be specified
multiple times.  All the available certificates are checked
against each rule in order until there is a match of exactly one
certificate.

The Subject and Issuer comparison strings are the \index{RFC!RFC 2253}\sphinxhref{https://tools.ietf.org/html/rfc2253.html}{\sphinxstylestrong{RFC 2253}}
string representations from the certificate Subject DN and Issuer
DN values.

The syntax of the matching rules is:
\begin{quote}

{[}\sphinxstyleemphasis{relation-operator}{]}\sphinxstyleemphasis{component-rule} …
\end{quote}

where:
\begin{description}
\item[{\sphinxstyleemphasis{relation-operator}}] \leavevmode
can be either \sphinxcode{\&\&}, meaning all component rules must match,
or \sphinxcode{\textbar{}\textbar{}}, meaning only one component rule must match.  The
default is \sphinxcode{\&\&}.

\item[{\sphinxstyleemphasis{component-rule}}] \leavevmode
can be one of the following.  Note that there is no
punctuation or whitespace between component rules.
\begin{quote}

\begin{DUlineblock}{0em}
\item[] \sphinxstylestrong{\textless{}SUBJECT\textgreater{}}\sphinxstyleemphasis{regular-expression}
\item[] \sphinxstylestrong{\textless{}ISSUER\textgreater{}}\sphinxstyleemphasis{regular-expression}
\item[] \sphinxstylestrong{\textless{}SAN\textgreater{}}\sphinxstyleemphasis{regular-expression}
\item[] \sphinxstylestrong{\textless{}EKU\textgreater{}}\sphinxstyleemphasis{extended-key-usage-list}
\item[] \sphinxstylestrong{\textless{}KU\textgreater{}}\sphinxstyleemphasis{key-usage-list}
\end{DUlineblock}
\end{quote}

\sphinxstyleemphasis{extended-key-usage-list} is a comma-separated list of
required Extended Key Usage values.  All values in the list
must be present in the certificate.  Extended Key Usage values
can be:
\begin{itemize}
\item {} 
pkinit

\item {} 
msScLogin

\item {} 
clientAuth

\item {} 
emailProtection

\end{itemize}

\sphinxstyleemphasis{key-usage-list} is a comma-separated list of required Key
Usage values.  All values in the list must be present in the
certificate.  Key Usage values can be:
\begin{itemize}
\item {} 
digitalSignature

\item {} 
keyEncipherment

\end{itemize}

\end{description}

Examples:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{pkinit\PYGZus{}cert\PYGZus{}match} \PYG{o}{=} \PYG{o}{\textbar{}}\PYG{o}{\textbar{}}\PYG{o}{\PYGZlt{}}\PYG{n}{SUBJECT}\PYG{o}{\PYGZgt{}}\PYG{o}{.}\PYG{o}{*}\PYG{n}{DoE}\PYG{o}{.}\PYG{o}{*}\PYG{o}{\PYGZlt{}}\PYG{n}{SAN}\PYG{o}{\PYGZgt{}}\PYG{o}{.}\PYG{o}{*}\PYG{n+nd}{@EXAMPLE}\PYG{o}{.}\PYG{n}{COM}
\PYG{n}{pkinit\PYGZus{}cert\PYGZus{}match} \PYG{o}{=} \PYG{o}{\PYGZam{}}\PYG{o}{\PYGZam{}}\PYG{o}{\PYGZlt{}}\PYG{n}{EKU}\PYG{o}{\PYGZgt{}}\PYG{n}{msScLogin}\PYG{p}{,}\PYG{n}{clientAuth}\PYG{o}{\PYGZlt{}}\PYG{n}{ISSUER}\PYG{o}{\PYGZgt{}}\PYG{o}{.}\PYG{o}{*}\PYG{n}{DoE}\PYG{o}{.}\PYG{o}{*}
\PYG{n}{pkinit\PYGZus{}cert\PYGZus{}match} \PYG{o}{=} \PYG{o}{\PYGZlt{}}\PYG{n}{EKU}\PYG{o}{\PYGZgt{}}\PYG{n}{msScLogin}\PYG{p}{,}\PYG{n}{clientAuth}\PYG{o}{\PYGZlt{}}\PYG{n}{KU}\PYG{o}{\PYGZgt{}}\PYG{n}{digitalSignature}
\end{sphinxVerbatim}

\item[{\sphinxstylestrong{pkinit\_eku\_checking}}] \leavevmode
This option specifies what Extended Key Usage value the KDC
certificate presented to the client must contain.  (Note that if
the KDC certificate has the pkinit SubjectAlternativeName encoded
as the Kerberos TGS name, EKU checking is not necessary since the
issuing CA has certified this as a KDC certificate.)  The values
recognized in the krb5.conf file are:
\begin{description}
\item[{\sphinxstylestrong{kpKDC}}] \leavevmode
This is the default value and specifies that the KDC must have
the id-pkinit-KPKdc EKU as defined in \index{RFC!RFC 4556}\sphinxhref{https://tools.ietf.org/html/rfc4556.html}{\sphinxstylestrong{RFC 4556}}.

\item[{\sphinxstylestrong{kpServerAuth}}] \leavevmode
If \sphinxstylestrong{kpServerAuth} is specified, a KDC certificate with the
id-kp-serverAuth EKU will be accepted.  This key usage value
is used in most commercially issued server certificates.

\item[{\sphinxstylestrong{none}}] \leavevmode
If \sphinxstylestrong{none} is specified, then the KDC certificate will not be
checked to verify it has an acceptable EKU.  The use of this
option is not recommended.

\end{description}

\item[{\sphinxstylestrong{pkinit\_dh\_min\_bits}}] \leavevmode
Specifies the size of the Diffie-Hellman key the client will
attempt to use.  The acceptable values are 1024, 2048, and 4096.
The default is 2048.

\item[{\sphinxstylestrong{pkinit\_identities}}] \leavevmode
Specifies the location(s) to be used to find the user’s X.509
identity information.  If this option is specified multiple times,
each value is attempted in order until certificates are found.
Note that these values are not used if the user specifies
\sphinxstylestrong{X509\_user\_identity} on the command line.

\item[{\sphinxstylestrong{pkinit\_kdc\_hostname}}] \leavevmode
The presence of this option indicates that the client is willing
to accept a KDC certificate with a dNSName SAN (Subject
Alternative Name) rather than requiring the id-pkinit-san as
defined in \index{RFC!RFC 4556}\sphinxhref{https://tools.ietf.org/html/rfc4556.html}{\sphinxstylestrong{RFC 4556}}.  This option may be specified multiple
times.  Its value should contain the acceptable hostname for the
KDC (as contained in its certificate).

\item[{\sphinxstylestrong{pkinit\_pool}}] \leavevmode
Specifies the location of intermediate certificates which may be
used by the client to complete the trust chain between a KDC
certificate and a trusted anchor.  This option may be specified
multiple times.

\item[{\sphinxstylestrong{pkinit\_require\_crl\_checking}}] \leavevmode
The default certificate verification process will always check the
available revocation information to see if a certificate has been
revoked.  If a match is found for the certificate in a CRL,
verification fails.  If the certificate being verified is not
listed in a CRL, or there is no CRL present for its issuing CA,
and \sphinxstylestrong{pkinit\_require\_crl\_checking} is false, then verification
succeeds.

However, if \sphinxstylestrong{pkinit\_require\_crl\_checking} is true and there is
no CRL information available for the issuing CA, then verification
fails.

\sphinxstylestrong{pkinit\_require\_crl\_checking} should be set to true if the
policy is such that up-to-date CRLs must be present for every CA.

\item[{\sphinxstylestrong{pkinit\_revoke}}] \leavevmode
Specifies the location of Certificate Revocation List (CRL)
information to be used by the client when verifying the validity
of the KDC certificate presented.  This option may be specified
multiple times.

\end{description}


\subsubsection{Parameter expansion}
\label{\detokenize{admin/conf_files/krb5_conf:id7}}\label{\detokenize{admin/conf_files/krb5_conf:parameter-expansion}}
Starting with release 1.11, several variables, such as
\sphinxstylestrong{default\_keytab\_name}, allow parameters to be expanded.
Valid parameters are:
\begin{quote}


\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|}
\hline

\%\{TEMP\}
&
Temporary directory
\\
\hline
\%\{uid\}
&
Unix real UID or Windows SID
\\
\hline
\%\{euid\}
&
Unix effective user ID or Windows SID
\\
\hline
\%\{USERID\}
&
Same as \%\{uid\}
\\
\hline
\%\{null\}
&
Empty string
\\
\hline
\%\{LIBDIR\}
&
Installation library directory
\\
\hline
\%\{BINDIR\}
&
Installation binary directory
\\
\hline
\%\{SBINDIR\}
&
Installation admin binary directory
\\
\hline
\%\{username\}
&
(Unix) Username of effective user ID
\\
\hline
\%\{APPDATA\}
&
(Windows) Roaming application data for current user
\\
\hline
\%\{COMMON\_APPDATA\}
&
(Windows) Application data for all users
\\
\hline
\%\{LOCAL\_APPDATA\}
&
(Windows) Local application data for current user
\\
\hline
\%\{SYSTEM\}
&
(Windows) Windows system folder
\\
\hline
\%\{WINDOWS\}
&
(Windows) Windows folder
\\
\hline
\%\{USERCONFIG\}
&
(Windows) Per-user MIT krb5 config file directory
\\
\hline
\%\{COMMONCONFIG\}
&
(Windows) Common MIT krb5 config file directory
\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}
\end{quote}


\subsubsection{Sample krb5.conf file}
\label{\detokenize{admin/conf_files/krb5_conf:sample-krb5-conf-file}}
Here is an example of a generic krb5.conf file:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{libdefaults}\PYG{p}{]}
    \PYG{n}{default\PYGZus{}realm} \PYG{o}{=} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
    \PYG{n}{dns\PYGZus{}lookup\PYGZus{}kdc} \PYG{o}{=} \PYG{n}{true}
    \PYG{n}{dns\PYGZus{}lookup\PYGZus{}realm} \PYG{o}{=} \PYG{n}{false}

\PYG{p}{[}\PYG{n}{realms}\PYG{p}{]}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{kdc} \PYG{o}{=} \PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
        \PYG{n}{kdc} \PYG{o}{=} \PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
        \PYG{n}{kdc} \PYG{o}{=} \PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{2.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
        \PYG{n}{admin\PYGZus{}server} \PYG{o}{=} \PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
        \PYG{n}{primary\PYGZus{}kdc} \PYG{o}{=} \PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{kdc} \PYG{o}{=} \PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{example}\PYG{o}{.}\PYG{n}{com}
        \PYG{n}{kdc} \PYG{o}{=} \PYG{n}{kerberos}\PYG{o}{\PYGZhy{}}\PYG{l+m+mf}{1.}\PYG{n}{example}\PYG{o}{.}\PYG{n}{com}
        \PYG{n}{admin\PYGZus{}server} \PYG{o}{=} \PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{example}\PYG{o}{.}\PYG{n}{com}
    \PYG{p}{\PYGZcb{}}

\PYG{p}{[}\PYG{n}{domain\PYGZus{}realm}\PYG{p}{]}
    \PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{o}{=} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}

\PYG{p}{[}\PYG{n}{capaths}\PYG{p}{]}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
           \PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM} \PYG{o}{=} \PYG{o}{.}
    \PYG{p}{\PYGZcb{}}
    \PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM} \PYG{o}{=} \PYG{p}{\PYGZob{}}
           \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{o}{.}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}


\subsubsection{FILES}
\label{\detokenize{admin/conf_files/krb5_conf:files}}
\sphinxcode{/etc/krb5.conf}


\subsubsection{SEE ALSO}
\label{\detokenize{admin/conf_files/krb5_conf:see-also}}
syslog(3)


\subsection{kdc.conf}
\label{\detokenize{admin/conf_files/kdc_conf:kdc-conf}}\label{\detokenize{admin/conf_files/kdc_conf::doc}}\label{\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}}
The kdc.conf file supplements {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} for programs which
are typically only used on a KDC, such as the {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} and
{\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} daemons and the {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} program.
Relations documented here may also be specified in krb5.conf; for the
KDC programs mentioned, krb5.conf and kdc.conf will be merged into a
single configuration profile.

Normally, the kdc.conf file is found in the KDC state directory,
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}.  You can override the default location by setting the
environment variable \sphinxstylestrong{KRB5\_KDC\_PROFILE}.

Please note that you need to restart the KDC daemon for any configuration
changes to take effect.


\subsubsection{Structure}
\label{\detokenize{admin/conf_files/kdc_conf:structure}}
The kdc.conf file is set up in the same format as the
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} file.


\subsubsection{Sections}
\label{\detokenize{admin/conf_files/kdc_conf:sections}}
The kdc.conf file may contain the following sections:


\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|}
\hline

{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdcdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}kdcdefaults{]}}}}}
&
Default values for KDC behavior
\\
\hline
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}}
&
Realm-specific database configuration and settings
\\
\hline
{\hyperref[\detokenize{admin/conf_files/kdc_conf:dbdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}dbdefaults{]}}}}}
&
Default database settings
\\
\hline
{\hyperref[\detokenize{admin/conf_files/kdc_conf:dbmodules}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}dbmodules{]}}}}}
&
Per-database settings
\\
\hline
{\hyperref[\detokenize{admin/conf_files/kdc_conf:logging}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}logging{]}}}}}
&
Controls how Kerberos daemons perform logging
\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}


\paragraph{{[}kdcdefaults{]}}
\label{\detokenize{admin/conf_files/kdc_conf:kdcdefaults}}\label{\detokenize{admin/conf_files/kdc_conf:id1}}
Some relations in the {[}kdcdefaults{]} section specify default values for
realm variables, to be used if the {[}realms{]} subsection does not
contain a relation for the tag.  See the {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} section for
the definitions of these relations.
\begin{itemize}
\item {} 
\sphinxstylestrong{host\_based\_services}

\item {} 
\sphinxstylestrong{kdc\_listen}

\item {} 
\sphinxstylestrong{kdc\_ports}

\item {} 
\sphinxstylestrong{kdc\_tcp\_listen}

\item {} 
\sphinxstylestrong{kdc\_tcp\_ports}

\item {} 
\sphinxstylestrong{no\_host\_referral}

\item {} 
\sphinxstylestrong{restrict\_anonymous\_to\_tgt}

\end{itemize}

The following {[}kdcdefaults{]} variables have no per-realm equivalent:
\begin{description}
\item[{\sphinxstylestrong{kdc\_max\_dgram\_reply\_size}}] \leavevmode
Specifies the maximum packet size that can be sent over UDP.  The
default value is 4096 bytes.

\item[{\sphinxstylestrong{kdc\_tcp\_listen\_backlog}}] \leavevmode
(Integer.)  Set the size of the listen queue length for the KDC
daemon.  The value may be limited by OS settings.  The default
value is 5.

\item[{\sphinxstylestrong{spake\_preauth\_kdc\_challenge}}] \leavevmode
(String.)  Specifies the group for a SPAKE optimistic challenge.
See the \sphinxstylestrong{spake\_preauth\_groups} variable in {\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}}
for possible values.  The default is not to issue an optimistic
challenge.  (New in release 1.17.)

\end{description}


\paragraph{{[}realms{]}}
\label{\detokenize{admin/conf_files/kdc_conf:realms}}\label{\detokenize{admin/conf_files/kdc_conf:kdc-realms}}
Each tag in the {[}realms{]} section is the name of a Kerberos realm.  The
value of the tag is a subsection where the relations define KDC
parameters for that particular realm.  The following example shows how
to define one parameter for the ATHENA.MIT.EDU realm:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{realms}\PYG{p}{]}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{max\PYGZus{}renewable\PYGZus{}life} \PYG{o}{=} \PYG{l+m+mi}{7}\PYG{n}{d} \PYG{l+m+mi}{0}\PYG{n}{h} \PYG{l+m+mi}{0}\PYG{n}{m} \PYG{l+m+mi}{0}\PYG{n}{s}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

The following tags may be specified in a {[}realms{]} subsection:
\begin{description}
\item[{\sphinxstylestrong{acl\_file}}] \leavevmode
(String.)  Location of the access control list file that
{\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} uses to determine which principals are allowed
which permissions on the Kerberos database.  To operate without an
ACL file, set this relation to the empty string with \sphinxcode{acl\_file =
""}.  The default value is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/kadm5.acl}.  For more
information on Kerberos ACL file see {\hyperref[\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5.acl}}}}.

\item[{\sphinxstylestrong{database\_module}}] \leavevmode
(String.)  This relation indicates the name of the configuration
section under {\hyperref[\detokenize{admin/conf_files/kdc_conf:dbmodules}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}dbmodules{]}}}}} for database-specific parameters
used by the loadable database library.  The default value is the
realm name.  If this configuration section does not exist, default
values will be used for all database parameters.

\item[{\sphinxstylestrong{database\_name}}] \leavevmode
(String, deprecated.)  This relation specifies the location of the
Kerberos database for this realm, if the DB2 module is being used
and the {\hyperref[\detokenize{admin/conf_files/kdc_conf:dbmodules}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}dbmodules{]}}}}} configuration section does not specify a
database name.  The default value is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/principal}.

\item[{\sphinxstylestrong{default\_principal\_expiration}}] \leavevmode
(\DUrole{xref,std,std-ref}{abstime} string.)  Specifies the default expiration date of
principals created in this realm.  The default value is 0, which
means no expiration date.

\item[{\sphinxstylestrong{default\_principal\_flags}}] \leavevmode
(Flag string.)  Specifies the default attributes of principals
created in this realm.  The format for this string is a
comma-separated list of flags, with ‘+’ before each flag that
should be enabled and ‘-‘ before each flag that should be
disabled.  The \sphinxstylestrong{postdateable}, \sphinxstylestrong{forwardable}, \sphinxstylestrong{tgt-based},
\sphinxstylestrong{renewable}, \sphinxstylestrong{proxiable}, \sphinxstylestrong{dup-skey}, \sphinxstylestrong{allow-tickets}, and
\sphinxstylestrong{service} flags default to enabled.

There are a number of possible flags:
\begin{description}
\item[{\sphinxstylestrong{allow-tickets}}] \leavevmode
Enabling this flag means that the KDC will issue tickets for
this principal.  Disabling this flag essentially deactivates
the principal within this realm.

\item[{\sphinxstylestrong{dup-skey}}] \leavevmode
Enabling this flag allows the KDC to issue user-to-user
service tickets for this principal.

\item[{\sphinxstylestrong{forwardable}}] \leavevmode
Enabling this flag allows the principal to obtain forwardable
tickets.

\item[{\sphinxstylestrong{hwauth}}] \leavevmode
If this flag is enabled, then the principal is required to
preauthenticate using a hardware device before receiving any
tickets.

\item[{\sphinxstylestrong{no-auth-data-required}}] \leavevmode
Enabling this flag prevents PAC or AD-SIGNEDPATH data from
being added to service tickets for the principal.

\item[{\sphinxstylestrong{ok-as-delegate}}] \leavevmode
If this flag is enabled, it hints the client that credentials
can and should be delegated when authenticating to the
service.

\item[{\sphinxstylestrong{ok-to-auth-as-delegate}}] \leavevmode
Enabling this flag allows the principal to use S4USelf tickets.

\item[{\sphinxstylestrong{postdateable}}] \leavevmode
Enabling this flag allows the principal to obtain postdateable
tickets.

\item[{\sphinxstylestrong{preauth}}] \leavevmode
If this flag is enabled on a client principal, then that
principal is required to preauthenticate to the KDC before
receiving any tickets.  On a service principal, enabling this
flag means that service tickets for this principal will only
be issued to clients with a TGT that has the preauthenticated
bit set.

\item[{\sphinxstylestrong{proxiable}}] \leavevmode
Enabling this flag allows the principal to obtain proxy
tickets.

\item[{\sphinxstylestrong{pwchange}}] \leavevmode
Enabling this flag forces a password change for this
principal.

\item[{\sphinxstylestrong{pwservice}}] \leavevmode
If this flag is enabled, it marks this principal as a password
change service.  This should only be used in special cases,
for example, if a user’s password has expired, then the user
has to get tickets for that principal without going through
the normal password authentication in order to be able to
change the password.

\item[{\sphinxstylestrong{renewable}}] \leavevmode
Enabling this flag allows the principal to obtain renewable
tickets.

\item[{\sphinxstylestrong{service}}] \leavevmode
Enabling this flag allows the the KDC to issue service tickets
for this principal.  In release 1.17 and later, user-to-user
service tickets are still allowed if the \sphinxstylestrong{dup-skey} flag is
set.

\item[{\sphinxstylestrong{tgt-based}}] \leavevmode
Enabling this flag allows a principal to obtain tickets based
on a ticket-granting-ticket, rather than repeating the
authentication process that was used to obtain the TGT.

\end{description}

\item[{\sphinxstylestrong{dict\_file}}] \leavevmode
(String.)  Location of the dictionary file containing strings that
are not allowed as passwords.  The file should contain one string
per line, with no additional whitespace.  If none is specified or
if there is no policy assigned to the principal, no dictionary
checks of passwords will be performed.

\item[{\sphinxstylestrong{disable\_pac}}] \leavevmode
(Boolean value.)  If true, the KDC will not issue PACs for this
realm, and S4U2Self and S4U2Proxy operations will be disabled.
The default is false, which will permit the KDC to issue PACs.
New in release 1.20.

\item[{\sphinxstylestrong{encrypted\_challenge\_indicator}}] \leavevmode
(String.)  Specifies the authentication indicator value that the KDC
asserts into tickets obtained using FAST encrypted challenge
pre-authentication.  New in 1.16.

\item[{\sphinxstylestrong{host\_based\_services}}] \leavevmode
(Whitespace- or comma-separated list.)  Lists services which will
get host-based referral processing even if the server principal is
not marked as host-based by the client.

\item[{\sphinxstylestrong{iprop\_enable}}] \leavevmode
(Boolean value.)  Specifies whether incremental database
propagation is enabled.  The default value is false.

\item[{\sphinxstylestrong{iprop\_ulogsize}}] \leavevmode
(Integer.)  Specifies the maximum number of log entries to be
retained for incremental propagation.  The default value is 1000.
Prior to release 1.11, the maximum value was 2500.  New in release
1.19.

\item[{\sphinxstylestrong{iprop\_master\_ulogsize}}] \leavevmode
The name for \sphinxstylestrong{iprop\_ulogsize} prior to release 1.19.  Its value is
used as a fallback if \sphinxstylestrong{iprop\_ulogsize} is not specified.

\item[{\sphinxstylestrong{iprop\_replica\_poll}}] \leavevmode
(Delta time string.)  Specifies how often the replica KDC polls
for new updates from the primary.  The default value is \sphinxcode{2m}
(that is, two minutes).  New in release 1.17.

\item[{\sphinxstylestrong{iprop\_slave\_poll}}] \leavevmode
(Delta time string.)  The name for \sphinxstylestrong{iprop\_replica\_poll} prior to
release 1.17.  Its value is used as a fallback if
\sphinxstylestrong{iprop\_replica\_poll} is not specified.

\item[{\sphinxstylestrong{iprop\_listen}}] \leavevmode
(Whitespace- or comma-separated list.)  Specifies the iprop RPC
listening addresses and/or ports for the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} daemon.
Each entry may be an interface address, a port number, or an
address and port number separated by a colon.  If the address
contains colons, enclose it in square brackets.  If no address is
specified, the wildcard address is used.  If kadmind fails to bind
to any of the specified addresses, it will fail to start.  The
default (when \sphinxstylestrong{iprop\_enable} is true) is to bind to the wildcard
address at the port specified in \sphinxstylestrong{iprop\_port}.  New in release
1.15.

\item[{\sphinxstylestrong{iprop\_port}}] \leavevmode
(Port number.)  Specifies the port number to be used for
incremental propagation.  When \sphinxstylestrong{iprop\_enable} is true, this
relation is required in the replica KDC configuration file, and
this relation or \sphinxstylestrong{iprop\_listen} is required in the primary
configuration file, as there is no default port number.  Port
numbers specified in \sphinxstylestrong{iprop\_listen} entries will override this
port number for the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} daemon.

\item[{\sphinxstylestrong{iprop\_resync\_timeout}}] \leavevmode
(Delta time string.)  Specifies the amount of time to wait for a
full propagation to complete.  This is optional in configuration
files, and is used by replica KDCs only.  The default value is 5
minutes (\sphinxcode{5m}).  New in release 1.11.

\item[{\sphinxstylestrong{iprop\_logfile}}] \leavevmode
(File name.)  Specifies where the update log file for the realm
database is to be stored.  The default is to use the
\sphinxstylestrong{database\_name} entry from the realms section of the krb5 config
file, with \sphinxcode{.ulog} appended.  (NOTE: If \sphinxstylestrong{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
{[}dbmodules{]} section, then the hard-coded default for
\sphinxstylestrong{database\_name} is used.  Determination of the \sphinxstylestrong{iprop\_logfile}
default value will not use values from the {[}dbmodules{]} section.)

\item[{\sphinxstylestrong{kadmind\_listen}}] \leavevmode
(Whitespace- or comma-separated list.)  Specifies the kadmin RPC
listening addresses and/or ports for the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} daemon.
Each entry may be an interface address, a port number, or an
address and port number separated by a colon.  If the address
contains colons, enclose it in square brackets.  If no address is
specified, the wildcard address is used.  If kadmind fails to bind
to any of the specified addresses, it will fail to start.  The
default is to bind to the wildcard address at the port specified
in \sphinxstylestrong{kadmind\_port}, or the standard kadmin port (749).  New in
release 1.15.

\item[{\sphinxstylestrong{kadmind\_port}}] \leavevmode
(Port number.)  Specifies the port on which the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}}
daemon is to listen for this realm.  Port numbers specified in
\sphinxstylestrong{kadmind\_listen} entries will override this port number.  The
assigned port for kadmind is 749, which is used by default.

\item[{\sphinxstylestrong{key\_stash\_file}}] \leavevmode
(String.)  Specifies the location where the master key has been
stored (via kdb5\_util stash).  The default is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/.k5.REALM}, where \sphinxstyleemphasis{REALM} is the Kerberos realm.

\item[{\sphinxstylestrong{kdc\_listen}}] \leavevmode
(Whitespace- or comma-separated list.)  Specifies the UDP
listening addresses and/or ports for the {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} daemon.
Each entry may be an interface address, a port number, or an
address and port number separated by a colon.  If the address
contains colons, enclose it in square brackets.  If no address is
specified, the wildcard address is used.  If no port is specified,
the standard port (88) is used.  If the KDC daemon fails to bind
to any of the specified addresses, it will fail to start.  The
default is to bind to the wildcard address on the standard port.
New in release 1.15.

\item[{\sphinxstylestrong{kdc\_ports}}] \leavevmode
(Whitespace- or comma-separated list, deprecated.)  Prior to
release 1.15, this relation lists the ports for the
{\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} daemon to listen on for UDP requests.  In
release 1.15 and later, it has the same meaning as \sphinxstylestrong{kdc\_listen}
if that relation is not defined.

\item[{\sphinxstylestrong{kdc\_tcp\_listen}}] \leavevmode
(Whitespace- or comma-separated list.)  Specifies the TCP
listening addresses and/or ports for the {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} daemon.
Each entry may be an interface address, a port number, or an
address and port number separated by a colon.  If the address
contains colons, enclose it in square brackets.  If no address is
specified, the wildcard address is used.  If no port is specified,
the standard port (88) is used.  To disable listening on TCP, set
this relation to the empty string with \sphinxcode{kdc\_tcp\_listen = ""}.
If the KDC daemon fails to bind to any of the specified addresses,
it will fail to start.  The default is to bind to the wildcard
address on the standard port.  New in release 1.15.

\item[{\sphinxstylestrong{kdc\_tcp\_ports}}] \leavevmode
(Whitespace- or comma-separated list, deprecated.)  Prior to
release 1.15, this relation lists the ports for the
{\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} daemon to listen on for UDP requests.  In
release 1.15 and later, it has the same meaning as
\sphinxstylestrong{kdc\_tcp\_listen} if that relation is not defined.

\item[{\sphinxstylestrong{kpasswd\_listen}}] \leavevmode
(Comma-separated list.)  Specifies the kpasswd listening addresses
and/or ports for the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} daemon.  Each entry may be
an interface address, a port number, or an address and port number
separated by a colon.  If the address contains colons, enclose it
in square brackets.  If no address is specified, the wildcard
address is used.  If kadmind fails to bind to any of the specified
addresses, it will fail to start.  The default is to bind to the
wildcard address at the port specified in \sphinxstylestrong{kpasswd\_port}, or the
standard kpasswd port (464).  New in release 1.15.

\item[{\sphinxstylestrong{kpasswd\_port}}] \leavevmode
(Port number.)  Specifies the port on which the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}}
daemon is to listen for password change requests for this realm.
Port numbers specified in \sphinxstylestrong{kpasswd\_listen} entries will override
this port number.  The assigned port for password change requests
is 464, which is used by default.

\item[{\sphinxstylestrong{master\_key\_name}}] \leavevmode
(String.)  Specifies the name of the principal associated with the
master key.  The default is \sphinxcode{K/M}.

\item[{\sphinxstylestrong{master\_key\_type}}] \leavevmode
(Key type string.)  Specifies the master key’s key type.  The
default value for this is \sphinxcode{aes256-cts-hmac-sha1-96}.  For a list of all possible
values, see {\hyperref[\detokenize{admin/conf_files/kdc_conf:encryption-types}]{\sphinxcrossref{\DUrole{std,std-ref}{Encryption types}}}}.

\item[{\sphinxstylestrong{max\_life}}] \leavevmode
(\DUrole{xref,std,std-ref}{duration} string.)  Specifies the maximum time period for
which a ticket may be valid in this realm.  The default value is
24 hours.

\item[{\sphinxstylestrong{max\_renewable\_life}}] \leavevmode
(\DUrole{xref,std,std-ref}{duration} string.)  Specifies the maximum time period
during which a valid ticket may be renewed in this realm.
The default value is 0.

\item[{\sphinxstylestrong{no\_host\_referral}}] \leavevmode
(Whitespace- or comma-separated list.)  Lists services to block
from getting host-based referral processing, even if the client
marks the server principal as host-based or the service is also
listed in \sphinxstylestrong{host\_based\_services}.  \sphinxcode{no\_host\_referral = *} will
disable referral processing altogether.

\item[{\sphinxstylestrong{reject\_bad\_transit}}] \leavevmode
(Boolean value.)  If set to true, the KDC will check the list of
transited realms for cross-realm tickets against the transit path
computed from the realm names and the capaths section of its
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} file; if the path in the ticket to be issued
contains any realms not in the computed path, the ticket will not
be issued, and an error will be returned to the client instead.
If this value is set to false, such tickets will be issued
anyways, and it will be left up to the application server to
validate the realm transit path.

If the disable-transited-check flag is set in the incoming
request, this check is not performed at all.  Having the
\sphinxstylestrong{reject\_bad\_transit} option will cause such ticket requests to
be rejected always.

This transit path checking and config file option currently apply
only to TGS requests.

The default value is true.

\item[{\sphinxstylestrong{restrict\_anonymous\_to\_tgt}}] \leavevmode
(Boolean value.)  If set to true, the KDC will reject ticket
requests from anonymous principals to service principals other
than the realm’s ticket-granting service.  This option allows
anonymous PKINIT to be enabled for use as FAST armor tickets
without allowing anonymous authentication to services.  The
default value is false.  New in release 1.9.

\item[{\sphinxstylestrong{spake\_preauth\_indicator}}] \leavevmode
(String.)  Specifies an authentication indicator value that the
KDC asserts into tickets obtained using SPAKE pre-authentication.
The default is not to add any indicators.  This option may be
specified multiple times.  New in release 1.17.

\item[{\sphinxstylestrong{supported\_enctypes}}] \leavevmode
(List of \sphinxstyleemphasis{key}:\sphinxstyleemphasis{salt} strings.)  Specifies the default key/salt
combinations of principals for this realm.  Any principals created
through {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} will have keys of these types.  The
default value for this tag is \sphinxcode{aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal}.  For lists of
possible values, see {\hyperref[\detokenize{admin/conf_files/kdc_conf:keysalt-lists}]{\sphinxcrossref{\DUrole{std,std-ref}{Keysalt lists}}}}.

\end{description}


\paragraph{{[}dbdefaults{]}}
\label{\detokenize{admin/conf_files/kdc_conf:id2}}\label{\detokenize{admin/conf_files/kdc_conf:dbdefaults}}
The {[}dbdefaults{]} section specifies default values for some database
parameters, to be used if the {[}dbmodules{]} subsection does not contain
a relation for the tag.  See the {\hyperref[\detokenize{admin/conf_files/kdc_conf:dbmodules}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}dbmodules{]}}}}} section for the
definitions of these relations.
\begin{itemize}
\item {} 
\sphinxstylestrong{ldap\_kerberos\_container\_dn}

\item {} 
\sphinxstylestrong{ldap\_kdc\_dn}

\item {} 
\sphinxstylestrong{ldap\_kdc\_sasl\_authcid}

\item {} 
\sphinxstylestrong{ldap\_kdc\_sasl\_authzid}

\item {} 
\sphinxstylestrong{ldap\_kdc\_sasl\_mech}

\item {} 
\sphinxstylestrong{ldap\_kdc\_sasl\_realm}

\item {} 
\sphinxstylestrong{ldap\_kadmind\_dn}

\item {} 
\sphinxstylestrong{ldap\_kadmind\_sasl\_authcid}

\item {} 
\sphinxstylestrong{ldap\_kadmind\_sasl\_authzid}

\item {} 
\sphinxstylestrong{ldap\_kadmind\_sasl\_mech}

\item {} 
\sphinxstylestrong{ldap\_kadmind\_sasl\_realm}

\item {} 
\sphinxstylestrong{ldap\_service\_password\_file}

\item {} 
\sphinxstylestrong{ldap\_conns\_per\_server}

\end{itemize}


\paragraph{{[}dbmodules{]}}
\label{\detokenize{admin/conf_files/kdc_conf:dbmodules}}\label{\detokenize{admin/conf_files/kdc_conf:id3}}
The {[}dbmodules{]} section contains parameters used by the KDC database
library and database modules.  Each tag in the {[}dbmodules{]} section is
the name of a Kerberos realm or a section name specified by a realm’s
\sphinxstylestrong{database\_module} parameter.  The following example shows how to
define one database parameter for the ATHENA.MIT.EDU realm:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{dbmodules}\PYG{p}{]}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{disable\PYGZus{}last\PYGZus{}success} \PYG{o}{=} \PYG{n}{true}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

The following tags may be specified in a {[}dbmodules{]} subsection:
\begin{description}
\item[{\sphinxstylestrong{database\_name}}] \leavevmode
This DB2-specific tag indicates the location of the database in
the filesystem.  The default is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/principal}.

\item[{\sphinxstylestrong{db\_library}}] \leavevmode
This tag indicates the name of the loadable database module.  The
value should be \sphinxcode{db2} for the DB2 module, \sphinxcode{klmdb} for the LMDB
module, or \sphinxcode{kldap} for the LDAP module.

\item[{\sphinxstylestrong{disable\_last\_success}}] \leavevmode
If set to \sphinxcode{true}, suppresses KDC updates to the “Last successful
authentication” field of principal entries requiring
preauthentication.  Setting this flag may improve performance.
(Principal entries which do not require preauthentication never
update the “Last successful authentication” field.).  First
introduced in release 1.9.

\item[{\sphinxstylestrong{disable\_lockout}}] \leavevmode
If set to \sphinxcode{true}, suppresses KDC updates to the “Last failed
authentication” and “Failed password attempts” fields of principal
entries requiring preauthentication.  Setting this flag may
improve performance, but also disables account lockout.  First
introduced in release 1.9.

\item[{\sphinxstylestrong{ldap\_conns\_per\_server}}] \leavevmode
This LDAP-specific tag indicates the number of connections to be
maintained per LDAP server.

\item[{\sphinxstylestrong{ldap\_kdc\_dn} and \sphinxstylestrong{ldap\_kadmind\_dn}}] \leavevmode
These LDAP-specific tags indicate the default DN for binding to
the LDAP server.  The {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} daemon uses
\sphinxstylestrong{ldap\_kdc\_dn}, while the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} daemon and other
administrative programs use \sphinxstylestrong{ldap\_kadmind\_dn}.  The kadmind DN
must have the rights to read and write the Kerberos data in the
LDAP database.  The KDC DN must have the same rights, unless
\sphinxstylestrong{disable\_lockout} and \sphinxstylestrong{disable\_last\_success} are true, in
which case it only needs to have rights to read the Kerberos data.
These tags are ignored if a SASL mechanism is set with
\sphinxstylestrong{ldap\_kdc\_sasl\_mech} or \sphinxstylestrong{ldap\_kadmind\_sasl\_mech}.

\item[{\sphinxstylestrong{ldap\_kdc\_sasl\_mech} and \sphinxstylestrong{ldap\_kadmind\_sasl\_mech}}] \leavevmode
These LDAP-specific tags specify the SASL mechanism (such as
\sphinxcode{EXTERNAL}) to use when binding to the LDAP server.  New in
release 1.13.

\item[{\sphinxstylestrong{ldap\_kdc\_sasl\_authcid} and \sphinxstylestrong{ldap\_kadmind\_sasl\_authcid}}] \leavevmode
These LDAP-specific tags specify the SASL authentication identity
to use when binding to the LDAP server.  Not all SASL mechanisms
require an authentication identity.  If the SASL mechanism
requires a secret (such as the password for \sphinxcode{DIGEST-MD5}), these
tags also determine the name within the
\sphinxstylestrong{ldap\_service\_password\_file} where the secret is stashed.  New
in release 1.13.

\item[{\sphinxstylestrong{ldap\_kdc\_sasl\_authzid} and \sphinxstylestrong{ldap\_kadmind\_sasl\_authzid}}] \leavevmode
These LDAP-specific tags specify the SASL authorization identity
to use when binding to the LDAP server.  In most circumstances
they do not need to be specified.  New in release 1.13.

\item[{\sphinxstylestrong{ldap\_kdc\_sasl\_realm} and \sphinxstylestrong{ldap\_kadmind\_sasl\_realm}}] \leavevmode
These LDAP-specific tags specify the SASL realm to use when
binding to the LDAP server.  In most circumstances they do not
need to be set.  New in release 1.13.

\item[{\sphinxstylestrong{ldap\_kerberos\_container\_dn}}] \leavevmode
This LDAP-specific tag indicates the DN of the container object
where the realm objects will be located.

\item[{\sphinxstylestrong{ldap\_servers}}] \leavevmode
This LDAP-specific tag indicates the list of LDAP servers that the
Kerberos servers can connect to.  The list of LDAP servers is
whitespace-separated.  The LDAP server is specified by a LDAP URI.
It is recommended to use \sphinxcode{ldapi:} or \sphinxcode{ldaps:} URLs to connect
to the LDAP server.

\item[{\sphinxstylestrong{ldap\_service\_password\_file}}] \leavevmode
This LDAP-specific tag indicates the file containing the stashed
passwords (created by \sphinxcode{kdb5\_ldap\_util stashsrvpw}) for the
\sphinxstylestrong{ldap\_kdc\_dn} and \sphinxstylestrong{ldap\_kadmind\_dn} objects, or for the
\sphinxstylestrong{ldap\_kdc\_sasl\_authcid} or \sphinxstylestrong{ldap\_kadmind\_sasl\_authcid} names
for SASL authentication.  This file must be kept secure.

\item[{\sphinxstylestrong{mapsize}}] \leavevmode
This LMDB-specific tag indicates the maximum size of the two
database environments in megabytes.  The default value is 128.
Increase this value to address “Environment mapsize limit reached”
errors.  New in release 1.17.

\item[{\sphinxstylestrong{max\_readers}}] \leavevmode
This LMDB-specific tag indicates the maximum number of concurrent
reading processes for the databases.  The default value is 128.
New in release 1.17.

\item[{\sphinxstylestrong{nosync}}] \leavevmode
This LMDB-specific tag can be set to improve the throughput of
kadmind and other administrative agents, at the expense of
durability (recent database changes may not survive a power outage
or other sudden reboot).  It does not affect the throughput of the
KDC.  The default value is false.  New in release 1.17.

\item[{\sphinxstylestrong{unlockiter}}] \leavevmode
If set to \sphinxcode{true}, this DB2-specific tag causes iteration
operations to release the database lock while processing each
principal.  Setting this flag to \sphinxcode{true} can prevent extended
blocking of KDC or kadmin operations when dumps of large databases
are in progress.  First introduced in release 1.13.

\end{description}

The following tag may be specified directly in the {[}dbmodules{]}
section to control where database modules are loaded from:
\begin{description}
\item[{\sphinxstylestrong{db\_module\_dir}}] \leavevmode
This tag controls where the plugin system looks for database
modules.  The value should be an absolute path.

\end{description}


\paragraph{{[}logging{]}}
\label{\detokenize{admin/conf_files/kdc_conf:id4}}\label{\detokenize{admin/conf_files/kdc_conf:logging}}
The {[}logging{]} section indicates how {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} and
{\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} perform logging.  It may contain the following
relations:
\begin{description}
\item[{\sphinxstylestrong{admin\_server}}] \leavevmode
Specifies how {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} performs logging.

\item[{\sphinxstylestrong{kdc}}] \leavevmode
Specifies how {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} performs logging.

\item[{\sphinxstylestrong{default}}] \leavevmode
Specifies how either daemon performs logging in the absence of
relations specific to the daemon.

\item[{\sphinxstylestrong{debug}}] \leavevmode
(Boolean value.)  Specifies whether debugging messages are
included in log outputs other than SYSLOG.  Debugging messages are
always included in the system log output because syslog performs
its own priority filtering.  The default value is false.  New in
release 1.15.

\end{description}

Logging specifications may have the following forms:
\begin{description}
\item[{\sphinxstylestrong{FILE=}\sphinxstyleemphasis{filename} or \sphinxstylestrong{FILE:}\sphinxstyleemphasis{filename}}] \leavevmode
This value causes the daemon’s logging messages to go to the
\sphinxstyleemphasis{filename}.  If the \sphinxcode{=} form is used, the file is overwritten.
If the \sphinxcode{:} form is used, the file is appended to.

\item[{\sphinxstylestrong{STDERR}}] \leavevmode
This value causes the daemon’s logging messages to go to its
standard error stream.

\item[{\sphinxstylestrong{CONSOLE}}] \leavevmode
This value causes the daemon’s logging messages to go to the
console, if the system supports it.

\item[{\sphinxstylestrong{DEVICE=}\sphinxstyleemphasis{\textless{}devicename\textgreater{}}}] \leavevmode
This causes the daemon’s logging messages to go to the specified
device.

\item[{\sphinxstylestrong{SYSLOG}{[}\sphinxstylestrong{:}\sphinxstyleemphasis{severity}{[}\sphinxstylestrong{:}\sphinxstyleemphasis{facility}{]}{]}}] \leavevmode
This causes the daemon’s logging messages to go to the system log.

For backward compatibility, a severity argument may be specified,
and must be specified in order to specify a facility.  This
argument will be ignored.

The facility argument specifies the facility under which the
messages are logged.  This may be any of the following facilities
supported by the syslog(3) call minus the LOG\_ prefix: \sphinxstylestrong{KERN},
\sphinxstylestrong{USER}, \sphinxstylestrong{MAIL}, \sphinxstylestrong{DAEMON}, \sphinxstylestrong{AUTH}, \sphinxstylestrong{LPR}, \sphinxstylestrong{NEWS},
\sphinxstylestrong{UUCP}, \sphinxstylestrong{CRON}, and \sphinxstylestrong{LOCAL0} through \sphinxstylestrong{LOCAL7}.  If no
facility is specified, the default is \sphinxstylestrong{AUTH}.

\end{description}

In the following example, the logging messages from the KDC will go to
the console and to the system log under the facility LOG\_DAEMON, and
the logging messages from the administrative server will be appended
to the file \sphinxcode{/var/adm/kadmin.log} and sent to the device
\sphinxcode{/dev/tty04}.

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{logging}\PYG{p}{]}
    \PYG{n}{kdc} \PYG{o}{=} \PYG{n}{CONSOLE}
    \PYG{n}{kdc} \PYG{o}{=} \PYG{n}{SYSLOG}\PYG{p}{:}\PYG{n}{INFO}\PYG{p}{:}\PYG{n}{DAEMON}
    \PYG{n}{admin\PYGZus{}server} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{adm}\PYG{o}{/}\PYG{n}{kadmin}\PYG{o}{.}\PYG{n}{log}
    \PYG{n}{admin\PYGZus{}server} \PYG{o}{=} \PYG{n}{DEVICE}\PYG{o}{=}\PYG{o}{/}\PYG{n}{dev}\PYG{o}{/}\PYG{n}{tty04}
\end{sphinxVerbatim}

If no logging specification is given, the default is to use syslog.
To disable logging entirely, specify \sphinxcode{default = DEVICE=/dev/null}.


\paragraph{{[}otp{]}}
\label{\detokenize{admin/conf_files/kdc_conf:otp}}\label{\detokenize{admin/conf_files/kdc_conf:id5}}
Each subsection of {[}otp{]} is the name of an OTP token type.  The tags
within the subsection define the configuration required to forward a
One Time Password request to a RADIUS server.

For each token type, the following tags may be specified:
\begin{description}
\item[{\sphinxstylestrong{server}}] \leavevmode
This is the server to send the RADIUS request to.  It can be a
hostname with optional port, an ip address with optional port, or
a Unix domain socket address.  The default is
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/\textless{}name\textgreater{}.socket}.

\item[{\sphinxstylestrong{secret}}] \leavevmode
This tag indicates a filename (which may be relative to {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc})
containing the secret used to encrypt the RADIUS packets.  The
secret should appear in the first line of the file by itself;
leading and trailing whitespace on the line will be removed.  If
the value of \sphinxstylestrong{server} is a Unix domain socket address, this tag
is optional, and an empty secret will be used if it is not
specified.  Otherwise, this tag is required.

\item[{\sphinxstylestrong{timeout}}] \leavevmode
An integer which specifies the time in seconds during which the
KDC should attempt to contact the RADIUS server.  This tag is the
total time across all retries and should be less than the time
which an OTP value remains valid for.  The default is 5 seconds.

\item[{\sphinxstylestrong{retries}}] \leavevmode
This tag specifies the number of retries to make to the RADIUS
server.  The default is 3 retries (4 tries).

\item[{\sphinxstylestrong{strip\_realm}}] \leavevmode
If this tag is \sphinxcode{true}, the principal without the realm will be
passed to the RADIUS server.  Otherwise, the realm will be
included.  The default value is \sphinxcode{true}.

\item[{\sphinxstylestrong{indicator}}] \leavevmode
This tag specifies an authentication indicator to be included in
the ticket if this token type is used to authenticate.  This
option may be specified multiple times.  (New in release 1.14.)

\end{description}

In the following example, requests are sent to a remote server via UDP:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
[otp]
    MyRemoteTokenType = \PYGZob{}
        server = radius.mydomain.com:1812
        secret = SEmfiajf42\PYGZdl{}
        timeout = 15
        retries = 5
        strip\PYGZus{}realm = true
    \PYGZcb{}
\end{sphinxVerbatim}

An implicit default token type named \sphinxcode{DEFAULT} is defined for when
the per-principal configuration does not specify a token type.  Its
configuration is shown below.  You may override this token type to
something applicable for your situation:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{otp}\PYG{p}{]}
    \PYG{n}{DEFAULT} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{strip\PYGZus{}realm} \PYG{o}{=} \PYG{n}{false}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}


\subsubsection{PKINIT options}
\label{\detokenize{admin/conf_files/kdc_conf:pkinit-options}}
\begin{sphinxadmonition}{note}{Note:}
The following are pkinit-specific options.  These values may
be specified in {[}kdcdefaults{]} as global defaults, or within
a realm-specific subsection of {[}realms{]}.  Also note that a
realm-specific value over-rides, does not add to, a generic
{[}kdcdefaults{]} specification.  The search order is:
\end{sphinxadmonition}
\begin{enumerate}
\item {} 
realm-specific subsection of {[}realms{]}:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{realms}\PYG{p}{]}
    \PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{pkinit\PYGZus{}anchors} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{example}\PYG{o}{.}\PYG{n}{com}\PYG{o}{.}\PYG{n}{crt}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

\item {} 
generic value in the {[}kdcdefaults{]} section:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{kdcdefaults}\PYG{p}{]}
    \PYG{n}{pkinit\PYGZus{}anchors} \PYG{o}{=} \PYG{n}{DIR}\PYG{p}{:}\PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{generic\PYGZus{}trusted\PYGZus{}cas}\PYG{o}{/}
\end{sphinxVerbatim}

\end{enumerate}

For information about the syntax of some of these options, see
{\hyperref[\detokenize{admin/conf_files/krb5_conf:pkinit-identity}]{\sphinxcrossref{\DUrole{std,std-ref}{Specifying PKINIT identity information}}}} in
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}.
\begin{description}
\item[{\sphinxstylestrong{pkinit\_anchors}}] \leavevmode
Specifies the location of trusted anchor (root) certificates which
the KDC trusts to sign client certificates.  This option is
required if pkinit is to be supported by the KDC.  This option may
be specified multiple times.

\item[{\sphinxstylestrong{pkinit\_dh\_min\_bits}}] \leavevmode
Specifies the minimum number of bits the KDC is willing to accept
for a client’s Diffie-Hellman key.  The default is 2048.

\item[{\sphinxstylestrong{pkinit\_allow\_upn}}] \leavevmode
Specifies that the KDC is willing to accept client certificates
with the Microsoft UserPrincipalName (UPN) Subject Alternative
Name (SAN).  This means the KDC accepts the binding of the UPN in
the certificate to the Kerberos principal name.  The default value
is false.

Without this option, the KDC will only accept certificates with
the id-pkinit-san as defined in \index{RFC!RFC 4556}\sphinxhref{https://tools.ietf.org/html/rfc4556.html}{\sphinxstylestrong{RFC 4556}}.  There is currently
no option to disable SAN checking in the KDC.

\item[{\sphinxstylestrong{pkinit\_eku\_checking}}] \leavevmode
This option specifies what Extended Key Usage (EKU) values the KDC
is willing to accept in client certificates.  The values
recognized in the kdc.conf file are:
\begin{description}
\item[{\sphinxstylestrong{kpClientAuth}}] \leavevmode
This is the default value and specifies that client
certificates must have the id-pkinit-KPClientAuth EKU as
defined in \index{RFC!RFC 4556}\sphinxhref{https://tools.ietf.org/html/rfc4556.html}{\sphinxstylestrong{RFC 4556}}.

\item[{\sphinxstylestrong{scLogin}}] \leavevmode
If scLogin is specified, client certificates with the
Microsoft Smart Card Login EKU (id-ms-kp-sc-logon) will be
accepted.

\item[{\sphinxstylestrong{none}}] \leavevmode
If none is specified, then client certificates will not be
checked to verify they have an acceptable EKU.  The use of
this option is not recommended.

\end{description}

\item[{\sphinxstylestrong{pkinit\_identity}}] \leavevmode
Specifies the location of the KDC’s X.509 identity information.
This option is required if pkinit is to be supported by the KDC.

\item[{\sphinxstylestrong{pkinit\_indicator}}] \leavevmode
Specifies an authentication indicator to include in the ticket if
pkinit is used to authenticate.  This option may be specified
multiple times.  (New in release 1.14.)

\item[{\sphinxstylestrong{pkinit\_pool}}] \leavevmode
Specifies the location of intermediate certificates which may be
used by the KDC to complete the trust chain between a client’s
certificate and a trusted anchor.  This option may be specified
multiple times.

\item[{\sphinxstylestrong{pkinit\_revoke}}] \leavevmode
Specifies the location of Certificate Revocation List (CRL)
information to be used by the KDC when verifying the validity of
client certificates.  This option may be specified multiple times.

\item[{\sphinxstylestrong{pkinit\_require\_crl\_checking}}] \leavevmode
The default certificate verification process will always check the
available revocation information to see if a certificate has been
revoked.  If a match is found for the certificate in a CRL,
verification fails.  If the certificate being verified is not
listed in a CRL, or there is no CRL present for its issuing CA,
and \sphinxstylestrong{pkinit\_require\_crl\_checking} is false, then verification
succeeds.

However, if \sphinxstylestrong{pkinit\_require\_crl\_checking} is true and there is
no CRL information available for the issuing CA, then verification
fails.

\sphinxstylestrong{pkinit\_require\_crl\_checking} should be set to true if the
policy is such that up-to-date CRLs must be present for every CA.

\item[{\sphinxstylestrong{pkinit\_require\_freshness}}] \leavevmode
Specifies whether to require clients to include a freshness token
in PKINIT requests.  The default value is false.  (New in release
1.17.)

\end{description}


\subsubsection{Encryption types}
\label{\detokenize{admin/conf_files/kdc_conf:id6}}\label{\detokenize{admin/conf_files/kdc_conf:encryption-types}}
Any tag in the configuration files which requires a list of encryption
types can be set to some combination of the following strings.
Encryption types marked as “weak” and “deprecated” are available for
compatibility but not recommended for use.


\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|}
\hline

des3-cbc-raw
&
Triple DES cbc mode raw (weak)
\\
\hline
des3-cbc-sha1 des3-hmac-sha1 des3-cbc-sha1-kd
&
Triple DES cbc mode with HMAC/sha1 (deprecated)
\\
\hline
aes256-cts-hmac-sha1-96 aes256-cts aes256-sha1
&
AES-256 CTS mode with 96-bit SHA-1 HMAC
\\
\hline
aes128-cts-hmac-sha1-96 aes128-cts aes128-sha1
&
AES-128 CTS mode with 96-bit SHA-1 HMAC
\\
\hline
aes256-cts-hmac-sha384-192 aes256-sha2
&
AES-256 CTS mode with 192-bit SHA-384 HMAC
\\
\hline
aes128-cts-hmac-sha256-128 aes128-sha2
&
AES-128 CTS mode with 128-bit SHA-256 HMAC
\\
\hline
arcfour-hmac rc4-hmac arcfour-hmac-md5
&
RC4 with HMAC/MD5 (deprecated)
\\
\hline
arcfour-hmac-exp rc4-hmac-exp arcfour-hmac-md5-exp
&
Exportable RC4 with HMAC/MD5 (weak)
\\
\hline
camellia256-cts-cmac camellia256-cts
&
Camellia-256 CTS mode with CMAC
\\
\hline
camellia128-cts-cmac camellia128-cts
&
Camellia-128 CTS mode with CMAC
\\
\hline
des3
&
The triple DES family: des3-cbc-sha1
\\
\hline
aes
&
The AES family: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, aes256-cts-hmac-sha384-192, and aes128-cts-hmac-sha256-128
\\
\hline
rc4
&
The RC4 family: arcfour-hmac
\\
\hline
camellia
&
The Camellia family: camellia256-cts-cmac and camellia128-cts-cmac
\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}

The string \sphinxstylestrong{DEFAULT} can be used to refer to the default set of
types for the variable in question.  Types or families can be removed
from the current list by prefixing them with a minus sign (“-“).
Types or families can be prefixed with a plus sign (“+”) for symmetry;
it has the same meaning as just listing the type or family.  For
example, “\sphinxcode{DEFAULT -rc4}” would be the default set of encryption
types with RC4 types removed, and “\sphinxcode{des3 DEFAULT}” would be the
default set of encryption types with triple DES types moved to the
front.

While \sphinxstylestrong{aes128-cts} and \sphinxstylestrong{aes256-cts} are supported for all Kerberos
operations, they are not supported by very old versions of our GSSAPI
implementation (krb5-1.3.1 and earlier).  Services running versions of
krb5 without AES support must not be given keys of these encryption
types in the KDC database.

The \sphinxstylestrong{aes128-sha2} and \sphinxstylestrong{aes256-sha2} encryption types are new in
release 1.15.  Services running versions of krb5 without support for
these newer encryption types must not be given keys of these
encryption types in the KDC database.


\subsubsection{Keysalt lists}
\label{\detokenize{admin/conf_files/kdc_conf:id7}}\label{\detokenize{admin/conf_files/kdc_conf:keysalt-lists}}
Kerberos keys for users are usually derived from passwords.  Kerberos
commands and configuration parameters that affect generation of keys
take lists of enctype-salttype (“keysalt”) pairs, known as \sphinxstyleemphasis{keysalt
lists}.  Each keysalt pair is an enctype name followed by a salttype
name, in the format \sphinxstyleemphasis{enc}:\sphinxstyleemphasis{salt}.  Individual keysalt list members are
separated by comma (“,”) characters or space characters.  For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin} \PYG{o}{\PYGZhy{}}\PYG{n}{e} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{p}{:}\PYG{n}{normal}\PYG{p}{,}\PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{p}{:}\PYG{n}{normal}
\end{sphinxVerbatim}

would start up kadmin so that by default it would generate
password-derived keys for the \sphinxstylestrong{aes256-cts} and \sphinxstylestrong{aes128-cts}
encryption types, using a \sphinxstylestrong{normal} salt.

To ensure that people who happen to pick the same password do not have
the same key, Kerberos 5 incorporates more information into the key
using something called a salt.  The supported salt types are as
follows:


\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|}
\hline

normal
&
default for Kerberos Version 5
\\
\hline
norealm
&
same as the default, without using realm information
\\
\hline
onlyrealm
&
uses only realm information as the salt
\\
\hline
special
&
generate a random salt
\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}


\subsubsection{Sample kdc.conf File}
\label{\detokenize{admin/conf_files/kdc_conf:sample-kdc-conf-file}}
Here’s an example of a kdc.conf file:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{kdcdefaults}\PYG{p}{]}
    \PYG{n}{kdc\PYGZus{}listen} \PYG{o}{=} \PYG{l+m+mi}{88}
    \PYG{n}{kdc\PYGZus{}tcp\PYGZus{}listen} \PYG{o}{=} \PYG{l+m+mi}{88}
\PYG{p}{[}\PYG{n}{realms}\PYG{p}{]}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{kadmind\PYGZus{}port} \PYG{o}{=} \PYG{l+m+mi}{749}
        \PYG{n}{max\PYGZus{}life} \PYG{o}{=} \PYG{l+m+mi}{12}\PYG{n}{h} \PYG{l+m+mi}{0}\PYG{n}{m} \PYG{l+m+mi}{0}\PYG{n}{s}
        \PYG{n}{max\PYGZus{}renewable\PYGZus{}life} \PYG{o}{=} \PYG{l+m+mi}{7}\PYG{n}{d} \PYG{l+m+mi}{0}\PYG{n}{h} \PYG{l+m+mi}{0}\PYG{n}{m} \PYG{l+m+mi}{0}\PYG{n}{s}
        \PYG{n}{master\PYGZus{}key\PYGZus{}type} \PYG{o}{=} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}
        \PYG{n}{supported\PYGZus{}enctypes} \PYG{o}{=} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}\PYG{p}{:}\PYG{n}{normal} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}\PYG{p}{:}\PYG{n}{normal}
        \PYG{n}{database\PYGZus{}module} \PYG{o}{=} \PYG{n}{openldap\PYGZus{}ldapconf}
    \PYG{p}{\PYGZcb{}}

\PYG{p}{[}\PYG{n}{logging}\PYG{p}{]}
    \PYG{n}{kdc} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{krb5kdc}\PYG{o}{/}\PYG{n}{kdc}\PYG{o}{.}\PYG{n}{log}
    \PYG{n}{admin\PYGZus{}server} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{krb5kdc}\PYG{o}{/}\PYG{n}{kadmin}\PYG{o}{.}\PYG{n}{log}

\PYG{p}{[}\PYG{n}{dbdefaults}\PYG{p}{]}
    \PYG{n}{ldap\PYGZus{}kerberos\PYGZus{}container\PYGZus{}dn} \PYG{o}{=} \PYG{n}{cn}\PYG{o}{=}\PYG{n}{krbcontainer}\PYG{p}{,}\PYG{n}{dc}\PYG{o}{=}\PYG{n}{mit}\PYG{p}{,}\PYG{n}{dc}\PYG{o}{=}\PYG{n}{edu}

\PYG{p}{[}\PYG{n}{dbmodules}\PYG{p}{]}
    \PYG{n}{openldap\PYGZus{}ldapconf} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{db\PYGZus{}library} \PYG{o}{=} \PYG{n}{kldap}
        \PYG{n}{disable\PYGZus{}last\PYGZus{}success} \PYG{o}{=} \PYG{n}{true}
        \PYG{n}{ldap\PYGZus{}kdc\PYGZus{}dn} \PYG{o}{=} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=krbadmin,dc=mit,dc=edu}\PYG{l+s+s2}{\PYGZdq{}}
            \PYG{c+c1}{\PYGZsh{} this object needs to have read rights on}
            \PYG{c+c1}{\PYGZsh{} the realm container and principal subtrees}
        \PYG{n}{ldap\PYGZus{}kadmind\PYGZus{}dn} \PYG{o}{=} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=krbadmin,dc=mit,dc=edu}\PYG{l+s+s2}{\PYGZdq{}}
            \PYG{c+c1}{\PYGZsh{} this object needs to have read and write rights on}
            \PYG{c+c1}{\PYGZsh{} the realm container and principal subtrees}
        \PYG{n}{ldap\PYGZus{}service\PYGZus{}password\PYGZus{}file} \PYG{o}{=} \PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{/}\PYG{n}{service}\PYG{o}{.}\PYG{n}{keyfile}
        \PYG{n}{ldap\PYGZus{}servers} \PYG{o}{=} \PYG{n}{ldaps}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
        \PYG{n}{ldap\PYGZus{}conns\PYGZus{}per\PYGZus{}server} \PYG{o}{=} \PYG{l+m+mi}{5}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}


\subsubsection{FILES}
\label{\detokenize{admin/conf_files/kdc_conf:files}}
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/kdc.conf}


\subsubsection{SEE ALSO}
\label{\detokenize{admin/conf_files/kdc_conf:see-also}}
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}, {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}}, {\hyperref[\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5.acl}}}}


\subsection{kadm5.acl}
\label{\detokenize{admin/conf_files/kadm5_acl:kadm5-acl}}\label{\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}}\label{\detokenize{admin/conf_files/kadm5_acl::doc}}

\subsubsection{DESCRIPTION}
\label{\detokenize{admin/conf_files/kadm5_acl:description}}
The Kerberos {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} daemon uses an Access Control List
(ACL) file to manage access rights to the Kerberos database.
For operations that affect principals, the ACL file also controls
which principals can operate on which other principals.

The default location of the Kerberos ACL file is
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/kadm5.acl}  unless this is overridden by the \sphinxstyleemphasis{acl\_file}
variable in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.


\subsubsection{SYNTAX}
\label{\detokenize{admin/conf_files/kadm5_acl:syntax}}
Empty lines and lines starting with the sharp sign (\sphinxcode{\#}) are
ignored.  Lines containing ACL entries have the format:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{principal}  \PYG{n}{permissions}  \PYG{p}{[}\PYG{n}{target\PYGZus{}principal}  \PYG{p}{[}\PYG{n}{restrictions}\PYG{p}{]} \PYG{p}{]}
\end{sphinxVerbatim}

\begin{sphinxadmonition}{note}{Note:}
Line order in the ACL file is important.  The first matching entry
will control access for an actor principal on a target principal.
\end{sphinxadmonition}
\begin{description}
\item[{\sphinxstyleemphasis{principal}}] \leavevmode
(Partially or fully qualified Kerberos principal name.) Specifies
the principal whose permissions are to be set.

Each component of the name may be wildcarded using the \sphinxcode{*}
character.

\item[{\sphinxstyleemphasis{permissions}}] \leavevmode
Specifies what operations may or may not be performed by a
\sphinxstyleemphasis{principal} matching a particular entry.  This is a string of one or
more of the following list of characters or their upper-case
counterparts.  If the character is \sphinxstyleemphasis{upper-case}, then the operation
is disallowed.  If the character is \sphinxstyleemphasis{lower-case}, then the operation
is permitted.


\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|}
\hline

a
&
{[}Dis{]}allows the addition of principals or policies
\\
\hline
c
&
{[}Dis{]}allows the changing of passwords for principals
\\
\hline
d
&
{[}Dis{]}allows the deletion of principals or policies
\\
\hline
e
&
{[}Dis{]}allows the extraction of principal keys
\\
\hline
i
&
{[}Dis{]}allows inquiries about principals or policies
\\
\hline
l
&
{[}Dis{]}allows the listing of all principals or policies
\\
\hline
m
&
{[}Dis{]}allows the modification of principals or policies
\\
\hline
p
&
{[}Dis{]}allows the propagation of the principal database (used in {\hyperref[\detokenize{admin/database:incr-db-prop}]{\sphinxcrossref{\DUrole{std,std-ref}{Incremental database propagation}}}})
\\
\hline
s
&
{[}Dis{]}allows the explicit setting of the key for a principal
\\
\hline
x
&
Short for admcilsp. All privileges (except \sphinxcode{e})
\\
\hline
*
&
Same as x.
\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}

\end{description}

\begin{sphinxadmonition}{note}{Note:}
The \sphinxcode{extract} privilege is not included in the wildcard
privilege; it must be explicitly assigned.  This privilege
allows the user to extract keys from the database, and must be
handled with great care to avoid disclosure of important keys
like those of the kadmin/* or krbtgt/* principals.  The
\sphinxstylestrong{lockdown\_keys} principal attribute can be used to prevent
key extraction from specific principals regardless of the
granted privilege.
\end{sphinxadmonition}
\begin{description}
\item[{\sphinxstyleemphasis{target\_principal}}] \leavevmode
(Optional. Partially or fully qualified Kerberos principal name.)
Specifies the principal on which \sphinxstyleemphasis{permissions} may be applied.
Each component of the name may be wildcarded using the \sphinxcode{*}
character.

\sphinxstyleemphasis{target\_principal} can also include back-references to \sphinxstyleemphasis{principal},
in which \sphinxcode{*number} matches the corresponding wildcard in
\sphinxstyleemphasis{principal}.

\item[{\sphinxstyleemphasis{restrictions}}] \leavevmode
(Optional) A string of flags. Allowed restrictions are:
\begin{quote}
\begin{description}
\item[{\{+\textbar{}-\}\sphinxstyleemphasis{flagname}}] \leavevmode
flag is forced to the indicated value.  The permissible flags
are the same as those for the \sphinxstylestrong{default\_principal\_flags}
variable in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.

\item[{\sphinxstyleemphasis{-clearpolicy}}] \leavevmode
policy is forced to be empty.

\item[{\sphinxstyleemphasis{-policy pol}}] \leavevmode
policy is forced to be \sphinxstyleemphasis{pol}.

\item[{-\{\sphinxstyleemphasis{expire, pwexpire, maxlife, maxrenewlife}\} \sphinxstyleemphasis{time}}] \leavevmode
(\DUrole{xref,std,std-ref}{getdate} string) associated value will be forced to
MIN(\sphinxstyleemphasis{time}, requested value).

\end{description}
\end{quote}

The above flags act as restrictions on any add or modify operation
which is allowed due to that ACL line.

\end{description}

\begin{sphinxadmonition}{warning}{Warning:}
If the kadmind ACL file is modified, the kadmind daemon needs to be
restarted for changes to take effect.
\end{sphinxadmonition}


\subsubsection{EXAMPLE}
\label{\detokenize{admin/conf_files/kadm5_acl:example}}
Here is an example of a kadm5.acl file:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{o}{*}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}    \PYG{o}{*}                               \PYG{c+c1}{\PYGZsh{} line 1}
\PYG{n}{joeadmin}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}   \PYG{n}{ADMCIL}                          \PYG{c+c1}{\PYGZsh{} line 2}
\PYG{n}{joeadmin}\PYG{o}{/}\PYG{o}{*}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{n}{i}   \PYG{o}{*}\PYG{o}{/}\PYG{n}{root}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}       \PYG{c+c1}{\PYGZsh{} line 3}
\PYG{o}{*}\PYG{o}{/}\PYG{n}{root}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}     \PYG{n}{ci}  \PYG{o}{*}\PYG{l+m+mi}{1}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}           \PYG{c+c1}{\PYGZsh{} line 4}
\PYG{o}{*}\PYG{o}{/}\PYG{n}{root}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}     \PYG{n}{l}   \PYG{o}{*}                           \PYG{c+c1}{\PYGZsh{} line 5}
\PYG{n}{sms}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}        \PYG{n}{x}   \PYG{o}{*} \PYG{o}{\PYGZhy{}}\PYG{n}{maxlife} \PYG{l+m+mi}{9}\PYG{n}{h} \PYG{o}{\PYGZhy{}}\PYG{n}{postdateable} \PYG{c+c1}{\PYGZsh{} line 6}
\end{sphinxVerbatim}

(line 1) Any principal in the \sphinxcode{ATHENA.MIT.EDU} realm with an
\sphinxcode{admin} instance has all administrative privileges except extracting
keys.

(lines 1-3) The user \sphinxcode{joeadmin} has all permissions except
extracting keys with his \sphinxcode{admin} instance,
\sphinxcode{joeadmin/admin@ATHENA.MIT.EDU} (matches line 1).  He has no
permissions at all with his null instance, \sphinxcode{joeadmin@ATHENA.MIT.EDU}
(matches line 2).  His \sphinxcode{root} and other non-\sphinxcode{admin}, non-null
instances (e.g., \sphinxcode{extra} or \sphinxcode{dbadmin}) have inquire permissions
with any principal that has the instance \sphinxcode{root} (matches line 3).

(line 4) Any \sphinxcode{root} principal in \sphinxcode{ATHENA.MIT.EDU} can inquire
or change the password of their null instance, but not any other
null instance.  (Here, \sphinxcode{*1} denotes a back-reference to the
component matching the first wildcard in the actor principal.)

(line 5) Any \sphinxcode{root} principal in \sphinxcode{ATHENA.MIT.EDU} can generate
the list of principals in the database, and the list of policies
in the database.  This line is separate from line 4, because list
permission can only be granted globally, not to specific target
principals.

(line 6) Finally, the Service Management System principal
\sphinxcode{sms@ATHENA.MIT.EDU} has all permissions except extracting keys, but
any principal that it creates or modifies will not be able to get
postdateable tickets or tickets with a life of longer than 9 hours.


\subsubsection{MODULE BEHAVIOR}
\label{\detokenize{admin/conf_files/kadm5_acl:module-behavior}}
The ACL file can coexist with other authorization modules in release
1.16 and later, as configured in the {\hyperref[\detokenize{admin/conf_files/krb5_conf:kadm5-auth}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5\_auth interface}}}} section of
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}.  The ACL file will positively authorize
operations according to the rules above, but will never
authoritatively deny an operation, so other modules can authorize
operations in addition to those authorized by the ACL file.

To operate without an ACL file, set the \sphinxstyleemphasis{acl\_file} variable in
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} to the empty string with \sphinxcode{acl\_file = ""}.


\subsubsection{SEE ALSO}
\label{\detokenize{admin/conf_files/kadm5_acl:see-also}}
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}, {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}}


\chapter{Realm configuration decisions}
\label{\detokenize{admin/realm_config:realm-configuration-decisions}}\label{\detokenize{admin/realm_config::doc}}
Before installing Kerberos V5, it is necessary to consider the
following issues:
\begin{itemize}
\item {} 
The name of your Kerberos realm (or the name of each realm, if you
need more than one).

\item {} 
How you will assign your hostnames to Kerberos realms.

\item {} 
Which ports your KDC and and kadmind services will use, if they will
not be using the default ports.

\item {} 
How many replica KDCs you need and where they should be located.

\item {} 
The hostnames of your primary and replica KDCs.

\item {} 
How frequently you will propagate the database from the primary KDC
to the replica KDCs.

\end{itemize}


\section{Realm name}
\label{\detokenize{admin/realm_config:realm-name}}
Although your Kerberos realm can be any ASCII string, convention is to
make it the same as your domain name, in upper-case letters.

For example, hosts in the domain \sphinxcode{example.com} would be in the
Kerberos realm:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM}
\end{sphinxVerbatim}

If you need multiple Kerberos realms, MIT recommends that you use
descriptive names which end with your domain name, such as:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{BOSTON}\PYG{o}{.}\PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM}
\PYG{n}{HOUSTON}\PYG{o}{.}\PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM}
\end{sphinxVerbatim}


\section{Mapping hostnames onto Kerberos realms}
\label{\detokenize{admin/realm_config:mapping-hostnames-onto-kerberos-realms}}\label{\detokenize{admin/realm_config:mapping-hostnames}}
Mapping hostnames onto Kerberos realms is done in one of three ways.

The first mechanism works through a set of rules in the
{\hyperref[\detokenize{admin/conf_files/krb5_conf:domain-realm}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}domain\_realm{]}}}}} section of {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}.  You can specify
mappings for an entire domain or on a per-hostname basis.  Typically
you would do this by specifying the mappings for a given domain or
subdomain and listing the exceptions.

The second mechanism is to use KDC host-based service referrals.  With
this method, the KDC’s krb5.conf has a full {[}domain\_realm{]} mapping for
hosts, but the clients do not, or have mappings for only a subset of
the hosts they might contact.  When a client needs to contact a server
host for which it has no mapping, it will ask the client realm’s KDC
for the service ticket, and will receive a referral to the appropriate
service realm.

To use referrals, clients must be running MIT krb5 1.6 or later, and
the KDC must be running MIT krb5 1.7 or later.  The
\sphinxstylestrong{host\_based\_services} and \sphinxstylestrong{no\_host\_referral} variables in the
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} section of {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} can be used to
fine-tune referral behavior on the KDC.

It is also possible for clients to use DNS TXT records, if
\sphinxstylestrong{dns\_lookup\_realm} is enabled in {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}.  Such lookups
are disabled by default because DNS is an insecure protocol and security
holes could result if DNS records are spoofed.  If enabled, the client
will try to look up a TXT record formed by prepending the prefix
\sphinxcode{\_kerberos} to the hostname in question.  If that record is not
found, the client will attempt a lookup by prepending \sphinxcode{\_kerberos} to the
host’s domain name, then its parent domain, up to the top-level domain.
For the hostname \sphinxcode{boston.engineering.example.com}, the names looked up
would be:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{\PYGZus{}kerberos}\PYG{o}{.}\PYG{n}{boston}\PYG{o}{.}\PYG{n}{engineering}\PYG{o}{.}\PYG{n}{example}\PYG{o}{.}\PYG{n}{com}
\PYG{n}{\PYGZus{}kerberos}\PYG{o}{.}\PYG{n}{engineering}\PYG{o}{.}\PYG{n}{example}\PYG{o}{.}\PYG{n}{com}
\PYG{n}{\PYGZus{}kerberos}\PYG{o}{.}\PYG{n}{example}\PYG{o}{.}\PYG{n}{com}
\PYG{n}{\PYGZus{}kerberos}\PYG{o}{.}\PYG{n}{com}
\end{sphinxVerbatim}

The value of the first TXT record found is taken as the realm name.

Even if you do not choose to use this mechanism within your site,
you may wish to set it up anyway, for use when interacting with other sites.


\section{Ports for the KDC and admin services}
\label{\detokenize{admin/realm_config:ports-for-the-kdc-and-admin-services}}
The default ports used by Kerberos are port 88 for the KDC and port
749 for the admin server.  You can, however, choose to run on other
ports, as long as they are specified in each host’s
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} files or in DNS SRV records, and the
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} file on each KDC.  For a more thorough treatment of
port numbers used by the Kerberos V5 programs, refer to the
{\hyperref[\detokenize{admin/appl_servers:conf-firewall}]{\sphinxcrossref{\DUrole{std,std-ref}{Configuring your firewall to work with Kerberos V5}}}}.


\section{Replica KDCs}
\label{\detokenize{admin/realm_config:replica-kdcs}}
Replica KDCs provide an additional source of Kerberos ticket-granting
services in the event of inaccessibility of the primary KDC.  The
number of replica KDCs you need and the decision of where to place them,
both physically and logically, depends on the specifics of your
network.

Kerberos authentication requires that each client be able to contact a
KDC.  Therefore, you need to anticipate any likely reason a KDC might
be unavailable and have a replica KDC to take up the slack.

Some considerations include:
\begin{itemize}
\item {} 
Have at least one replica KDC as a backup, for when the primary KDC
is down, is being upgraded, or is otherwise unavailable.

\item {} 
If your network is split such that a network outage is likely to
cause a network partition (some segment or segments of the network
to become cut off or isolated from other segments), have a replica
KDC accessible to each segment.

\item {} 
If possible, have at least one replica KDC in a different building
from the primary, in case of power outages, fires, or other
localized disasters.

\end{itemize}


\section{Hostnames for KDCs}
\label{\detokenize{admin/realm_config:kdc-hostnames}}\label{\detokenize{admin/realm_config:hostnames-for-kdcs}}
MIT recommends that your KDCs have a predefined set of CNAME records
(DNS hostname aliases), such as \sphinxcode{kerberos} for the primary KDC and
\sphinxcode{kerberos-1}, \sphinxcode{kerberos-2}, … for the replica KDCs.  This way,
if you need to swap a machine, you only need to change a DNS entry,
rather than having to change hostnames.

As of MIT krb5 1.4, clients can locate a realm’s KDCs through DNS
using SRV records (\index{RFC!RFC 2782}\sphinxhref{https://tools.ietf.org/html/rfc2782.html}{\sphinxstylestrong{RFC 2782}}), assuming the Kerberos realm name is
also a DNS domain name.  These records indicate the hostname and port
number to contact for that service, optionally with weighting and
prioritization.  The domain name used in the SRV record name is the
realm name.  Several different Kerberos-related service names are
used:
\begin{description}
\item[{\_kerberos.\_udp}] \leavevmode
This is for contacting any KDC by UDP.  This entry will be used
the most often.  Normally you should list port 88 on each of your
KDCs.

\item[{\_kerberos.\_tcp}] \leavevmode
This is for contacting any KDC by TCP.  Normally you should use
port 88.  This entry should be omitted if the KDC does not listen
on TCP ports, as was the default prior to release 1.13.

\item[{\_kerberos-master.\_udp}] \leavevmode
This entry should refer to those KDCs, if any, that will
immediately see password changes to the Kerberos database.  If a
user is logging in and the password appears to be incorrect, the
client will retry with the primary KDC before failing with an
“incorrect password” error given.

If you have only one KDC, or for whatever reason there is no
accessible KDC that would get database changes faster than the
others, you do not need to define this entry.  \_kerberos-adm.\_tcp
This should list port 749 on your primary KDC.  Support for it is
not complete at this time, but it will eventually be used by the
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} program and related utilities.  For now, you will
also need the \sphinxstylestrong{admin\_server} variable in {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}.

\item[{\_kerberos-master.\_tcp}] \leavevmode
The corresponding TCP port for \_kerberos-master.\_udp, assuming the
primary KDC listens on a TCP port.

\item[{\_kpasswd.\_udp}] \leavevmode
This entry should list port 464 on your primary KDC.  It is used
when a user changes her password.  If this entry is not defined
but a \_kerberos-adm.\_tcp entry is defined, the client will use the
\_kerberos-adm.\_tcp entry with the port number changed to 464.

\item[{\_kpasswd.\_tcp}] \leavevmode
The corresponding TCP port for \_kpasswd.\_udp.

\end{description}

The DNS SRV specification requires that the hostnames listed be the
canonical names, not aliases.  So, for example, you might include the
following records in your (BIND-style) zone file:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{}ORIGIN foobar.com.
\PYGZus{}kerberos               TXT       \PYGZdq{}FOOBAR.COM\PYGZdq{}
kerberos                CNAME     daisy
kerberos\PYGZhy{}1              CNAME     use\PYGZhy{}the\PYGZhy{}force\PYGZhy{}luke
kerberos\PYGZhy{}2              CNAME     bunny\PYGZhy{}rabbit
\PYGZus{}kerberos.\PYGZus{}udp          SRV       0 0 88 daisy
                        SRV       0 0 88 use\PYGZhy{}the\PYGZhy{}force\PYGZhy{}luke
                        SRV       0 0 88 bunny\PYGZhy{}rabbit
\PYGZus{}kerberos\PYGZhy{}master.\PYGZus{}udp   SRV       0 0 88 daisy
\PYGZus{}kerberos\PYGZhy{}adm.\PYGZus{}tcp      SRV       0 0 749 daisy
\PYGZus{}kpasswd.\PYGZus{}udp           SRV       0 0 464 daisy
\end{sphinxVerbatim}

Clients can also be configured with the explicit location of services
using the \sphinxstylestrong{kdc}, \sphinxstylestrong{master\_kdc}, \sphinxstylestrong{admin\_server}, and
\sphinxstylestrong{kpasswd\_server} variables in the {\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} section of
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}.  Even if some clients will be configured with
explicit server locations, providing SRV records will still benefit
unconfigured clients, and be useful for other sites.


\section{KDC Discovery}
\label{\detokenize{admin/realm_config:kdc-discovery}}\label{\detokenize{admin/realm_config:id1}}
As of MIT krb5 1.15, clients can also locate KDCs in DNS through URI
records (\index{RFC!RFC 7553}\sphinxhref{https://tools.ietf.org/html/rfc7553.html}{\sphinxstylestrong{RFC 7553}}).  Limitations with the SRV record format may
result in extra DNS queries in situations where a client must failover
to other transport types, or find a primary server.  The URI record
can convey more information about a realm’s KDCs with a single query.

The client performs a query for the following URI records:
\begin{itemize}
\item {} 
\sphinxcode{\_kerberos.REALM} for finding KDCs.

\item {} 
\sphinxcode{\_kerberos-adm.REALM} for finding kadmin services.

\item {} 
\sphinxcode{\_kpasswd.REALM} for finding password services.

\end{itemize}

The URI record includes a priority, weight, and a URI string that
consists of case-insensitive colon separated fields, in the form
\sphinxcode{scheme:{[}flags{]}:transport:residual}.
\begin{itemize}
\item {} 
\sphinxstyleemphasis{scheme} defines the registered URI type.  It should always be
\sphinxcode{krb5srv}.

\item {} 
\sphinxstyleemphasis{flags} contains zero or more flag characters.  Currently the only
valid flag is \sphinxcode{m}, which indicates that the record is for a
primary server.

\item {} 
\sphinxstyleemphasis{transport} defines the transport type of the residual URL or
address.  Accepted values are \sphinxcode{tcp}, \sphinxcode{udp}, or \sphinxcode{kkdcp} for the
MS-KKDCP type.

\item {} 
\sphinxstyleemphasis{residual} contains the hostname, IP address, or URL to be
contacted using the specified transport, with an optional port
extension.  The MS-KKDCP transport type uses a HTTPS URL, and can
include a port and/or path extension.

\end{itemize}

An example of URI records in a zone file:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{\PYGZus{}kerberos}\PYG{o}{.}\PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM}  \PYG{n}{URI}  \PYG{l+m+mi}{10} \PYG{l+m+mi}{1} \PYG{n}{krb5srv}\PYG{p}{:}\PYG{n}{m}\PYG{p}{:}\PYG{n}{tcp}\PYG{p}{:}\PYG{n}{kdc1}\PYG{o}{.}\PYG{n}{example}\PYG{o}{.}\PYG{n}{com}
                       \PYG{n}{URI}  \PYG{l+m+mi}{20} \PYG{l+m+mi}{1} \PYG{n}{krb5srv}\PYG{p}{:}\PYG{n}{m}\PYG{p}{:}\PYG{n}{udp}\PYG{p}{:}\PYG{n}{kdc2}\PYG{o}{.}\PYG{n}{example}\PYG{o}{.}\PYG{n}{com}\PYG{p}{:}\PYG{l+m+mi}{89}
                       \PYG{n}{URI}  \PYG{l+m+mi}{40} \PYG{l+m+mi}{1} \PYG{n}{krb5srv}\PYG{p}{:}\PYG{p}{:}\PYG{n}{udp}\PYG{p}{:}\PYG{l+m+mf}{10.10}\PYG{o}{.}\PYG{l+m+mf}{0.23}
                       \PYG{n}{URI}  \PYG{l+m+mi}{30} \PYG{l+m+mi}{1} \PYG{n}{krb5srv}\PYG{p}{:}\PYG{p}{:}\PYG{n}{kkdcp}\PYG{p}{:}\PYG{n}{https}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{proxy}\PYG{p}{:}\PYG{l+m+mi}{89}\PYG{o}{/}\PYG{n}{auth}
\end{sphinxVerbatim}

URI lookups are enabled by default, and can be disabled by setting
\sphinxstylestrong{dns\_uri\_lookup} in the {\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}} section of
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} to False.  When enabled, URI lookups take
precedence over SRV lookups, falling back to SRV lookups if no URI
records are found.


\section{Database propagation}
\label{\detokenize{admin/realm_config:database-propagation}}\label{\detokenize{admin/realm_config:db-prop}}
The Kerberos database resides on the primary KDC, and must be
propagated regularly (usually by a cron job) to the replica KDCs.  In
deciding how frequently the propagation should happen, you will need
to balance the amount of time the propagation takes against the
maximum reasonable amount of time a user should have to wait for a
password change to take effect.

If the propagation time is longer than this maximum reasonable time
(e.g., you have a particularly large database, you have a lot of
replicas, or you experience frequent network delays), you may wish to
cut down on your propagation delay by performing the propagation in
parallel.  To do this, have the primary KDC propagate the database to
one set of replicas, and then have each of these replicas propagate
the database to additional replicas.

See also {\hyperref[\detokenize{admin/database:incr-db-prop}]{\sphinxcrossref{\DUrole{std,std-ref}{Incremental database propagation}}}}


\chapter{Database administration}
\label{\detokenize{admin/database::doc}}\label{\detokenize{admin/database:database-administration}}
A Kerberos database contains all of a realm’s Kerberos principals,
their passwords, and other administrative information about each
principal.  For the most part, you will use the {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}}
program to manipulate the Kerberos database as a whole, and the
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} program to make changes to the entries in the
database.  (One notable exception is that users will use the
\DUrole{xref,std,std-ref}{kpasswd(1)} program to change their own passwords.)  The kadmin
program has its own command-line interface, to which you type the
database administrating commands.

{\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} provides a means to create, delete, load, or dump
a Kerberos database.  It also contains commands to roll over the
database master key, and to stash a copy of the key so that the
{\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} and {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} daemons can use the database
without manual input.

{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} provides for the maintenance of Kerberos principals,
password policies, and service key tables (keytabs).  Normally it
operates as a network client using Kerberos authentication to
communicate with {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}}, but there is also a variant, named
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.

kadmin can authenticate to the admin server using the service
principal \sphinxcode{kadmin/admin} or \sphinxcode{kadmin/HOST} (where \sphinxstyleemphasis{HOST} is the
hostname of the admin server).  If the credentials cache contains a
ticket for either service principal and the \sphinxstylestrong{-c} ccache option is
specified, that ticket is used to authenticate to KADM5.  Otherwise,
the \sphinxstylestrong{-p} and \sphinxstylestrong{-k} options are used to specify the client Kerberos
principal name used to authenticate.  Once kadmin has determined the
principal name, it requests a \sphinxcode{kadmin/admin} Kerberos service ticket
from the KDC, and uses that service ticket to authenticate to KADM5.

See {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} for the available kadmin and kadmin.local
commands and options.


\section{Principals}
\label{\detokenize{admin/database:principals}}\label{\detokenize{admin/database:id1}}
Each entry in the Kerberos database contains a Kerberos principal and
the attributes and policies associated with that principal.

To add a principal to the database, use the {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}
\sphinxstylestrong{add\_principal} command.  User principals should usually be created
with the \sphinxcode{+requires\_preauth -allow\_svr} options to help mitigate
dictionary attacks (see {\hyperref[\detokenize{admin/dictionary:dictionary}]{\sphinxcrossref{\DUrole{std,std-ref}{Addressing dictionary attack risks}}}}):

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{addprinc} \PYG{o}{+}\PYG{n}{requires\PYGZus{}preauth} \PYG{o}{\PYGZhy{}}\PYG{n}{allow\PYGZus{}svr} \PYG{n}{alice}
\PYG{n}{Enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{alice@KRBTEST.COM}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\PYG{n}{Re}\PYG{o}{\PYGZhy{}}\PYG{n}{enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{alice@KRBTEST.COM}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\end{sphinxVerbatim}

User principals which will authenticate with {\hyperref[\detokenize{admin/pkinit:pkinit}]{\sphinxcrossref{\DUrole{std,std-ref}{PKINIT configuration}}}} should
instead by created with the \sphinxcode{-nokey} option:
\begin{quote}

kadmin: addprinc -nokey alice
\end{quote}

Service principals can be created with the \sphinxcode{-nokey} option;
long-term keys will be added when a keytab is generated:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{addprinc} \PYG{o}{\PYGZhy{}}\PYG{n}{nokey} \PYG{n}{host}\PYG{o}{/}\PYG{n}{foo}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{ktadd} \PYG{o}{\PYGZhy{}}\PYG{n}{k} \PYG{n}{foo}\PYG{o}{.}\PYG{n}{keytab} \PYG{n}{host}\PYG{o}{/}\PYG{n}{foo}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{foo}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{1}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{n}{foo}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{foo}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{1}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{n}{foo}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\end{sphinxVerbatim}

To modify attributes of an existing principal, use the kadmin
\sphinxstylestrong{modify\_principal} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{modprinc} \PYG{o}{\PYGZhy{}}\PYG{n}{expire} \PYG{n}{tomorrow} \PYG{n}{alice}
\PYG{n}{Principal} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{alice@KRBTEST.COM}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{modified}\PYG{o}{.}
\end{sphinxVerbatim}

To delete a principal, use the kadmin \sphinxstylestrong{delete\_principal} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
kadmin: delprinc alice
Are you sure you want to delete the principal \PYGZdq{}alice@KRBTEST.COM\PYGZdq{}? (yes/no): yes
Principal \PYGZdq{}alice@KRBTEST.COM\PYGZdq{} deleted.
Make sure that you have removed this principal from all ACLs before reusing.
\end{sphinxVerbatim}

To change a principal’s password, use the kadmin \sphinxstylestrong{change\_password}
command.  Password changes made through kadmin are subject to the same
password policies as would apply to password changes made through
\DUrole{xref,std,std-ref}{kpasswd(1)}.

To view the attributes of a principal, use the kadmin{}`
\sphinxstylestrong{get\_principal} command.

To generate a listing of principals, use the kadmin
\sphinxstylestrong{list\_principals} command.


\section{Policies}
\label{\detokenize{admin/database:id2}}\label{\detokenize{admin/database:policies}}
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.

To add a new policy, use the {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} \sphinxstylestrong{add\_policy} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{addpol} \PYG{o}{\PYGZhy{}}\PYG{n}{maxlife} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{1 year}\PYG{l+s+s2}{\PYGZdq{}} \PYG{o}{\PYGZhy{}}\PYG{n}{history} \PYG{l+m+mi}{3} \PYG{n}{stduser}
\end{sphinxVerbatim}

To modify attributes of a principal, use the kadmin \sphinxstylestrong{modify\_policy}
command.  To delete a policy, use the kadmin \sphinxstylestrong{delete\_policy}
command.

To associate a policy with a principal, use the kadmin
\sphinxstylestrong{modify\_principal} command with the \sphinxstylestrong{-policy} option:
\begin{quote}

kadmin: modprinc -policy stduser alice
Principal “\sphinxhref{mailto:alice@KRBTEST.COM}{alice@KRBTEST.COM}” modified.
\end{quote}

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 \sphinxstylestrong{get\_principal} output.


\subsection{Updating the history key}
\label{\detokenize{admin/database:updating-history-key}}\label{\detokenize{admin/database:updating-the-history-key}}
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 \sphinxcode{kadmin/history} principal.

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:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{change\PYGZus{}password} \PYG{o}{\PYGZhy{}}\PYG{n}{randkey} \PYG{n}{kadmin}\PYG{o}{/}\PYG{n}{history}
\end{sphinxVerbatim}

This command will fail if you specify the \sphinxstylestrong{-keepold} flag.  Only one
new history key will be created, even if you specify multiple key/salt
combinations.

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.


\section{Privileges}
\label{\detokenize{admin/database:privileges}}\label{\detokenize{admin/database:id3}}
Administrative privileges for the Kerberos database are stored in the
file {\hyperref[\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5.acl}}}}.

\begin{sphinxadmonition}{note}{Note:}
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 \sphinxcode{joeadmin} might have a principal for
his administrative use, called \sphinxcode{joeadmin/admin}.  This
way, \sphinxcode{joeadmin} would obtain \sphinxcode{joeadmin/admin} tickets
only when he actually needs to use those permissions.
\end{sphinxadmonition}


\section{Operations on the Kerberos database}
\label{\detokenize{admin/database:db-operations}}\label{\detokenize{admin/database:operations-on-the-kerberos-database}}
The {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} command is the primary tool for administrating
the Kerberos database when using the DB2 or LMDB modules (see
{\hyperref[\detokenize{admin/dbtypes:dbtypes}]{\sphinxcrossref{\DUrole{std,std-ref}{Database types}}}}).  Creating a database is described in
{\hyperref[\detokenize{admin/install_kdc:create-db}]{\sphinxcrossref{\DUrole{std,std-ref}{Create the KDC database}}}}.

To create a stash file using the master password (because the database
was not created with one using the \sphinxcode{create -s} flag, or after
restoring from a backup which did not contain the stash file), use the
kdb5\_util \sphinxstylestrong{stash} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}util stash
kdb5\PYGZus{}util: Cannot find/read stored master key while reading master key
kdb5\PYGZus{}util: Warning: proceeding without master key
Enter KDC database master key:  \PYGZlt{}= Type the KDC database master password.
\end{sphinxVerbatim}

To destroy a database, use the kdb5\_util destroy command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}util destroy
Deleting KDC database stored in \PYGZsq{}/var/krb5kdc/principal\PYGZsq{}, are you sure?
(type \PYGZsq{}yes\PYGZsq{} to confirm)? yes
OK, deleting database \PYGZsq{}/var/krb5kdc/principal\PYGZsq{}...
** Database \PYGZsq{}/var/krb5kdc/principal\PYGZsq{} destroyed.
\end{sphinxVerbatim}


\subsection{Dumping and loading a Kerberos database}
\label{\detokenize{admin/database:dumping-and-loading-a-kerberos-database}}\label{\detokenize{admin/database:restore-from-dump}}
To dump a Kerberos database into a text file for backup or transfer
purposes, use the {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} \sphinxstylestrong{dump} command on one of the
KDCs:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}util dump dumpfile

\PYGZdl{} kbd5\PYGZus{}util dump \PYGZhy{}verbose dumpfile
kadmin/admin@ATHENA.MIT.EDU
krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
kadmin/history@ATHENA.MIT.EDU
K/M@ATHENA.MIT.EDU
kadmin/changepw@ATHENA.MIT.EDU
\end{sphinxVerbatim}

You may specify which principals to dump, using full principal names
including realm:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}util dump \PYGZhy{}verbose someprincs K/M@ATHENA.MIT.EDU kadmin/admin@ATHENA.MIT.EDU
kadmin/admin@ATHENA.MIT.EDU
K/M@ATHENA.MIT.EDU
\end{sphinxVerbatim}

To restore a Kerberos database dump from a file, use the
{\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} \sphinxstylestrong{load} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}util load dumpfile
\end{sphinxVerbatim}

To update an existing database with a partial dump file containing
only some principals, use the \sphinxcode{-update} flag:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}util load \PYGZhy{}update someprincs
\end{sphinxVerbatim}

\begin{sphinxadmonition}{note}{Note:}
If the database file exists, and the \sphinxstyleemphasis{-update} flag was not
given, \sphinxstyleemphasis{kdb5\_util} will overwrite the existing database.
\end{sphinxadmonition}


\subsection{Updating the master key}
\label{\detokenize{admin/database:updating-master-key}}\label{\detokenize{admin/database:updating-the-master-key}}
Starting with release 1.7, {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} 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:
\begin{enumerate}
\item {} 
On the primary KDC, run \sphinxcode{kdb5\_util list\_mkeys} 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:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}util list\PYGZus{}mkeys
Master keys for Principal: K/M@KRBTEST.COM
KVNO: 1, Enctype: aes256\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha384\PYGZhy{}192, Active on: Thu Jan 01 00:00:00 UTC 1970 *
\end{sphinxVerbatim}

\item {} 
On the primary KDC, run \sphinxcode{kdb5\_util use\_mkey 1} 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.

\item {} 
On the primary KDC, run \sphinxcode{kdb5\_util add\_mkey -s} 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.

\item {} 
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.

\item {} 
On each replica KDC, run \sphinxcode{kdb5\_util list\_mkeys} to verify that
the new master key is present, and then \sphinxcode{kdb5\_util stash} to
write the new master key to the replica KDC’s stash file.

\item {} 
On the primary KDC, run \sphinxcode{kdb5\_util use\_mkey 2} to begin using the
new master key.  Replace \sphinxcode{2} 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, {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} must be
restarted for this change to take full effect.

\item {} 
On the primary KDC, run \sphinxcode{kdb5\_util update\_princ\_encryption}.
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 \sphinxcode{kdb5\_util -x unlockiter update\_princ\_encryption} to
use unlocked iteration; this variant will take longer, but will
keep the database available to the KDC and kadmind while it runs.

\item {} 
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.

\item {} 
On the primary KDC, run \sphinxcode{kdb5\_util purge\_mkeys} to clean up the
old master key.

\end{enumerate}


\section{Operations on the LDAP database}
\label{\detokenize{admin/database:operations-on-the-ldap-database}}\label{\detokenize{admin/database:ops-on-ldap}}
The {\hyperref[\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_ldap\_util}}}} command is the primary tool for
administrating the Kerberos database when using the LDAP module.
Creating an LDAP Kerberos database is describe in {\hyperref[\detokenize{admin/conf_ldap:conf-ldap}]{\sphinxcrossref{\DUrole{std,std-ref}{Configuring Kerberos with OpenLDAP back-end}}}}.

To view a list of realms in the LDAP database, use the kdb5\_ldap\_util
\sphinxstylestrong{list} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}ldap\PYGZus{}util list
KRBTEST.COM
\end{sphinxVerbatim}

To modify the attributes of a realm, use the kdb5\_ldap\_util \sphinxstylestrong{modify}
command.  For example, to change the default realm’s maximum ticket
life:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}ldap\PYGZus{}util modify \PYGZhy{}maxtktlife \PYGZdq{}10 hours\PYGZdq{}
\end{sphinxVerbatim}

To display the attributes of a realm, use the kdb5\_ldap\_util \sphinxstylestrong{view}
command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}ldap\PYGZus{}util view
               Realm Name: KRBTEST.COM
      Maximum Ticket Life: 0 days 00:10:00
\end{sphinxVerbatim}

To remove a realm from the LDAP database, destroying its contents, use
the kdb5\_ldap\_util \sphinxstylestrong{destroy} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}ldap\PYGZus{}util destroy
Deleting KDC database of \PYGZsq{}KRBTEST.COM\PYGZsq{}, are you sure?
(type \PYGZsq{}yes\PYGZsq{} to confirm)? yes
OK, deleting database of \PYGZsq{}KRBTEST.COM\PYGZsq{}...
** Database of \PYGZsq{}KRBTEST.COM\PYGZsq{} destroyed.
\end{sphinxVerbatim}


\subsection{Ticket Policy operations}
\label{\detokenize{admin/database:ticket-policy-operations}}
Unlike the DB2 and LMDB modules, the LDAP module supports ticket
policy objects, which can be associated with principals to restrict
maximum ticket lifetimes and set mandatory principal flags.  Ticket
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 \sphinxstylestrong{create\_policy} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}ldap\PYGZus{}util create\PYGZus{}policy \PYGZhy{}maxrenewlife \PYGZdq{}2 days\PYGZdq{} users
\end{sphinxVerbatim}

To associate a ticket policy with a principal, use the
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} \sphinxstylestrong{modify\_principal} (or \sphinxstylestrong{add\_principal}) command
with the \sphinxstylestrong{-x tktpolicy=}\sphinxstyleemphasis{policy} option:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kadmin.local modprinc \PYGZhy{}x tktpolicy=users alice
\end{sphinxVerbatim}

To remove a ticket policy reference from a principal, use the same
command with an empty \sphinxstyleemphasis{policy}:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kadmin.local modprinc \PYGZhy{}x tktpolicy= alice
\end{sphinxVerbatim}

To list the existing ticket policy objects, use the kdb5\_ldap\_util
\sphinxstylestrong{list\_policy} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}ldap\PYGZus{}util list\PYGZus{}policy
users
\end{sphinxVerbatim}

To modify the attributes of a ticket policy object, use the
kdb5\_ldap\_util \sphinxstylestrong{modify\_policy} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}ldap\PYGZus{}util modify\PYGZus{}policy \PYGZhy{}allow\PYGZus{}svr +requires\PYGZus{}preauth users
\end{sphinxVerbatim}

To view the attributes of a ticket policy object, use the
kdb5\_ldap\_util \sphinxstylestrong{view\_policy} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}ldap\PYGZus{}util view\PYGZus{}policy users
            Ticket policy: users
   Maximum renewable life: 2 days 00:00:00
             Ticket flags: REQUIRES\PYGZus{}PRE\PYGZus{}AUTH DISALLOW\PYGZus{}SVR
\end{sphinxVerbatim}

To destroy an ticket policy object, use the kdb5\_ldap\_util
\sphinxstylestrong{destroy\_policy} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}ldap\PYGZus{}util destroy\PYGZus{}policy users
This will delete the policy object \PYGZsq{}users\PYGZsq{}, are you sure?
(type \PYGZsq{}yes\PYGZsq{} to confirm)? yes
** policy object \PYGZsq{}users\PYGZsq{} deleted.
\end{sphinxVerbatim}


\section{Cross-realm authentication}
\label{\detokenize{admin/database:cross-realm-authentication}}\label{\detokenize{admin/database:xrealm-authn}}
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
\sphinxcode{ATHENA.MIT.EDU} and \sphinxcode{EXAMPLE.COM}, you would need to add the
principals \sphinxcode{krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU} and
\sphinxcode{krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM} 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 \sphinxstylestrong{-kvno} option.

In the ATHENA.MIT.EDU and EXAMPLE.COM cross-realm case, the administrators
would run the following commands on the KDCs in both realms:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}}\PYG{p}{:} \PYG{n}{kadmin}\PYG{o}{.}\PYG{n}{local} \PYG{o}{\PYGZhy{}}\PYG{n}{e} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{aes256\PYGZhy{}cts:normal}\PYG{l+s+s2}{\PYGZdq{}}
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{addprinc} \PYG{o}{\PYGZhy{}}\PYG{n}{requires\PYGZus{}preauth} \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{n+nd}{@EXAMPLE}\PYG{o}{.}\PYG{n}{COM}
\PYG{n}{Enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{n+nd}{@EXAMPLE}\PYG{o}{.}\PYG{n}{COM}\PYG{p}{:}
\PYG{n}{Re}\PYG{o}{\PYGZhy{}}\PYG{n}{enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{n+nd}{@EXAMPLE}\PYG{o}{.}\PYG{n}{COM}\PYG{p}{:}
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{addprinc} \PYG{o}{\PYGZhy{}}\PYG{n}{requires\PYGZus{}preauth} \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\PYG{n}{Enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{p}{:}
\PYG{n}{Enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{EXAMPLE}\PYG{o}{.}\PYG{n}{COM}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{p}{:}
\PYG{n}{kadmin}\PYG{p}{:}
\end{sphinxVerbatim}

\begin{sphinxadmonition}{note}{Note:}
Even if most principals in a realm are generally created
with the \sphinxstylestrong{requires\_preauth} flag enabled, this flag is not
desirable on cross-realm authentication keys because doing
so makes it impossible to disable preauthentication on a
service-by-service basis.  Disabling it as in the example
above is recommended.
\end{sphinxadmonition}

\begin{sphinxadmonition}{note}{Note:}
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.
\end{sphinxadmonition}


\section{Changing the krbtgt key}
\label{\detokenize{admin/database:changing-krbtgt-key}}\label{\detokenize{admin/database:changing-the-krbtgt-key}}
A Kerberos Ticket Granting Ticket (TGT) is a service ticket for the
principal \sphinxcode{krbtgt/REALM}.  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
encryption types for the TGT, this key has to be changed.

Changing this key using the normal {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}
\sphinxstylestrong{change\_password} command would invalidate any previously issued
TGTs.  Therefore, when changing this key, normally one should use the
\sphinxstylestrong{-keepold} flag to change\_password to retain the previous key in the
database as well as the new key.  For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{change\PYGZus{}password} \PYG{o}{\PYGZhy{}}\PYG{n}{randkey} \PYG{o}{\PYGZhy{}}\PYG{n}{keepold} \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\end{sphinxVerbatim}

\begin{sphinxadmonition}{warning}{Warning:}
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 \sphinxstylestrong{purgekeys} command to delete keys
with older kvnos, ideally first making sure that all
tickets issued with the old keys have expired.
\end{sphinxadmonition}

Only the first krbtgt key of the newest key version is used to encrypt
ticket-granting tickets.  However, the set of encryption types present
in the krbtgt keys is used by default to determine the session key
types supported by the krbtgt service (see
{\hyperref[\detokenize{admin/enctypes:session-key-selection}]{\sphinxcrossref{\DUrole{std,std-ref}{Session key selection}}}}).  Because non-MIT Kerberos clients
sometimes send a limited set of encryption types when making AS
requests, it can be important for the krbtgt service to support
multiple encryption types.  This can be accomplished by giving the
krbtgt principal multiple keys, which is usually as simple as not
specifying any \sphinxstylestrong{-e} option when changing the krbtgt key, or by
setting the \sphinxstylestrong{session\_enctypes} string attribute on the krbtgt
principal (see {\hyperref[\detokenize{admin/admin_commands/kadmin_local:set-string}]{\sphinxcrossref{\DUrole{std,std-ref}{set\_string}}}}).

Due to a bug in releases 1.8 through 1.13, renewed and forwarded
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.


\section{Incremental database propagation}
\label{\detokenize{admin/database:incremental-database-propagation}}\label{\detokenize{admin/database:incr-db-prop}}

\subsection{Overview}
\label{\detokenize{admin/database:overview}}
At some very large sites, dumping and transmitting the database can
take more time than is desirable for changes to propagate from the
primary KDC to the replica KDCs.  The incremental propagation support
added in the 1.7 release is intended to address this.

With incremental propagation enabled, all programs on the primary KDC
that change the database also write information about the changes to
an “update log” file, maintained as a circular buffer of a certain
size.  A process on each replica KDC connects to a service on the
primary KDC (currently implemented in the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} server) and
periodically requests the changes that have been made since the last
check.  By default, this check is done every two minutes.

Incremental propagation uses the following entries in the per-realm
data in the KDC config file (See {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}):


\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|T|}
\hline

iprop\_enable
&
\sphinxstyleemphasis{boolean}
&
If \sphinxstyleemphasis{true}, then incremental propagation is enabled, and (as noted below) normal kprop propagation is disabled. The default is \sphinxstyleemphasis{false}.
\\
\hline
iprop\_master\_ulogsize
&
\sphinxstyleemphasis{integer}
&
Indicates the number of entries that should be retained in the update log. The default is 1000; the maximum number is 2500.
\\
\hline
iprop\_replica\_poll
&
\sphinxstyleemphasis{time interval}
&
Indicates how often the replica should poll the primary KDC for changes to the database. The default is two minutes.
\\
\hline
iprop\_port
&
\sphinxstyleemphasis{integer}
&
Specifies the port number to be used for incremental propagation. This is required in both primary and replica configuration files.
\\
\hline
iprop\_resync\_timeout
&
\sphinxstyleemphasis{integer}
&
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).
\\
\hline
iprop\_logfile
&
\sphinxstyleemphasis{file name}
&
Specifies where the update log file for the realm database is to be stored. The default is to use the \sphinxstyleemphasis{database\_name} entry from the realms section of the config file {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}, with \sphinxstyleemphasis{.ulog} 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 \sphinxstyleemphasis{dbmodules} section, then the hard-coded default for \sphinxstyleemphasis{database\_name} is used. Determination of the \sphinxstyleemphasis{iprop\_logfile}  default value will not use values from the \sphinxstyleemphasis{dbmodules} section.)
\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}

Both primary and replica sides must have a principal named
\sphinxcode{kiprop/hostname} (where \sphinxstyleemphasis{hostname} 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 ({\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{DEFKTNAME}}}}).  The \sphinxcode{kiprop/hostname} principal may
have been created automatically for the primary KDC, but it must
always be created for replica KDCs.

On the primary KDC side, the \sphinxcode{kiprop/hostname} principal must be
listed in the kadmind ACL file {\hyperref[\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5.acl}}}}, and given the
\sphinxstylestrong{p} privilege (see {\hyperref[\detokenize{admin/database:privileges}]{\sphinxcrossref{\DUrole{std,std-ref}{Privileges}}}}).

On the replica KDC side, {\hyperref[\detokenize{admin/admin_commands/kpropd:kpropd-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kpropd}}}} should be run.  When
incremental propagation is enabled, it will connect to the kadmind on
the primary KDC and start requesting updates.

The normal kprop mechanism is disabled by the incremental propagation
support.  However, if the replica has been unable to fetch changes
from the primary KDC for too long (network problems, perhaps), the log
on the primary may wrap around and overwrite some of the updates that
the replica has not yet retrieved.  In this case, the replica will
instruct the primary KDC to dump the current database out to a file
and invoke a one-time kprop propagation, with special options to also
convey the point in the update log at which the replica should resume
fetching incremental updates.  Thus, all the keytab and ACL setup
previously described for kprop propagation is still needed.

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 \sphinxcode{kadmind -proponly} on
each intermediate replica, and \sphinxcode{kpropd -A upstreamhostname} on
downstream replicas to direct each one to the appropriate upstream
replica.

There are several known restrictions in the current implementation:
\begin{itemize}
\item {} 
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.

\item {} 
The replica’s KDB module must support locking; it cannot be using the
LDAP KDB module.

\item {} 
The primary and replica must be able to initiate TCP connections in
both directions, without an intervening NAT.

\end{itemize}


\subsection{Sun/MIT incremental propagation differences}
\label{\detokenize{admin/database:sun-mit-incremental-propagation-differences}}
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.)

The Sun config file support looks for \sphinxcode{sunw\_dbprop\_enable},
\sphinxcode{sunw\_dbprop\_master\_ulogsize}, and \sphinxcode{sunw\_dbprop\_slave\_poll}.

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
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.

The Sun implementation hard-codes pathnames in \sphinxcode{/var/krb5} 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
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/replica\_datatrans\_hostname}.


\chapter{Database types}
\label{\detokenize{admin/dbtypes::doc}}\label{\detokenize{admin/dbtypes:database-types}}\label{\detokenize{admin/dbtypes:dbtypes}}
A Kerberos database can be implemented with one of three built-in
database providers, called KDB modules.  Software which incorporates
the MIT krb5 KDC may also provide its own KDB module.  The following
subsections describe the three built-in KDB modules and the
configuration specific to them.

The database type can be configured with the \sphinxstylestrong{db\_library} variable
in the {\hyperref[\detokenize{admin/conf_files/kdc_conf:dbmodules}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}dbmodules{]}}}}} subsection for the realm.  For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{dbmodules}\PYG{p}{]}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{db\PYGZus{}library} \PYG{o}{=} \PYG{n}{db2}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

If the \sphinxcode{ATHENA.MIT.EDU} realm subsection contains a
\sphinxstylestrong{database\_module} setting, then the subsection within
\sphinxcode{{[}dbmodules{]}} should use that name instead of \sphinxcode{ATHENA.MIT.EDU}.

To transition from one database type to another, stop the
{\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} service, use \sphinxcode{kdb5\_util dump} to create a dump
file, change the \sphinxstylestrong{db\_library} value and set any appropriate
configuration for the new database type, and use \sphinxcode{kdb5\_util load} to
create and populate the new database.  If the new database type is
LDAP, create the new database using \sphinxcode{kdb5\_ldap\_util} and populate it
from the dump file using \sphinxcode{kdb5\_util load -update}.  Then restart the
{\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} and {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} services.


\section{Berkeley database module (db2)}
\label{\detokenize{admin/dbtypes:berkeley-database-module-db2}}
The default KDB module is \sphinxcode{db2}, which uses a version of the
Berkeley DB library.  It creates four files based on the database
pathname.  If the pathname ends with \sphinxcode{principal} then the four files
are:
\begin{itemize}
\item {} 
\sphinxcode{principal}, containing principal entry data

\item {} 
\sphinxcode{principal.ok}, a lock file for the principal database

\item {} 
\sphinxcode{principal.kadm5}, containing policy object data

\item {} 
\sphinxcode{principal.kadm5.lock}, a lock file for the policy database

\end{itemize}

For large databases, the {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} \sphinxstylestrong{dump} command (perhaps
invoked by {\hyperref[\detokenize{admin/admin_commands/kprop:kprop-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop}}}} or by {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} for incremental
propagation) may cause {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} to stop for a noticeable
period of time while it iterates over the database.  This delay can be
avoided by disabling account lockout features so that the KDC does not
perform database writes (see {\hyperref[\detokenize{admin/lockout:disable-lockout}]{\sphinxcrossref{\DUrole{std,std-ref}{KDC performance and account lockout}}}}).  Alternatively,
a slower form of iteration can be enabled by setting the
\sphinxstylestrong{unlockiter} variable to \sphinxcode{true}.  For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{dbmodules}\PYG{p}{]}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{db\PYGZus{}library} \PYG{o}{=} \PYG{n}{db2}
        \PYG{n}{unlockiter} \PYG{o}{=} \PYG{n}{true}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

In rare cases, a power failure or other unclean system shutdown may
cause inconsistencies in the internal pointers within a database file,
such that \sphinxcode{kdb5\_util dump} cannot retrieve all principal entries in
the database.  In this situation, it may be possible to retrieve all
of the principal data by running \sphinxcode{kdb5\_util dump -recurse} to
iterate over the database using the tree pointers instead of the
iteration pointers.  Running \sphinxcode{kdb5\_util dump -rev} to iterate over
the database backwards may also retrieve some of the data which is not
retrieved by a normal dump operation.


\section{Lightning Memory-Mapped Database module (klmdb)}
\label{\detokenize{admin/dbtypes:lightning-memory-mapped-database-module-klmdb}}
The klmdb module was added in release 1.17.  It uses the LMDB library,
and may offer better performance and reliability than the db2 module.
It creates four files based on the database pathname.  If the pathname
ends with \sphinxcode{principal}, then the four files are:
\begin{itemize}
\item {} 
\sphinxcode{principal.mdb}, containing policy object data and most principal
entry data

\item {} 
\sphinxcode{principal.mdb-lock}, a lock file for the primary database

\item {} 
\sphinxcode{principal.lockout.mdb}, containing the account lockout attributes
(last successful authentication time, last failed authentication
time, and number of failed attempts) for each principal entry

\item {} 
\sphinxcode{principal.lockout.mdb-lock}, a lock file for the lockout database

\end{itemize}

Separating out the lockout attributes ensures that the KDC will never
block on an administrative operation such as a database dump or load.
It also allows the KDC to operate without write access to the primary
database.  If both account lockout features are disabled (see
{\hyperref[\detokenize{admin/lockout:disable-lockout}]{\sphinxcrossref{\DUrole{std,std-ref}{KDC performance and account lockout}}}}), the lockout database files will be created
but will not subsequently be opened, and the account lockout
attributes will always have zero values.

Because LMDB creates a memory map to the database files, it requires a
configured memory map size which also determines the maximum size of
the database.  This size is applied equally to the two databases, so
twice the configured size will be consumed in the process address
space; this is primarily a limitation on 32-bit platforms.  The
default value of 128 megabytes should be sufficient for several
hundred thousand principal entries.  If the limit is reached, kadmin
operations will fail and the error message “Environment mapsize limit
reached” will appear in the kadmind log file.  In this case, the
\sphinxstylestrong{mapsize} variable can be used to increase the map size.  The
following example sets the map size to 512 megabytes:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{dbmodules}\PYG{p}{]}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{db\PYGZus{}library} \PYG{o}{=} \PYG{n}{klmdb}
        \PYG{n}{mapsize} \PYG{o}{=} \PYG{l+m+mi}{512}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

LMDB has a configurable maximum number of readers.  The default value
of 128 should be sufficient for most deployments.  If you are going to
use a large number of KDC worker processes, it may be necessary to set
the \sphinxstylestrong{max\_readers} variable to a larger number.

By default, LMDB synchronizes database files to disk after each write
transaction to ensure durability in the case of an unclean system
shutdown.  The klmdb module always turns synchronization off for the
lockout database to ensure reasonable KDC performance, but leaves it
on for the primary database.  If high throughput for administrative
operations (including password changes) is required, the \sphinxstylestrong{nosync}
variable can be set to “true” to disable synchronization for the
primary database.

The klmdb module does not support explicit locking with the
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} \sphinxstylestrong{lock} command.


\section{LDAP module (kldap)}
\label{\detokenize{admin/dbtypes:ldap-module-kldap}}
The kldap module stores principal and policy data using an LDAP
server.  To use it you must configure an LDAP server to use the
Kerberos schema.  See {\hyperref[\detokenize{admin/conf_ldap:conf-ldap}]{\sphinxcrossref{\DUrole{std,std-ref}{Configuring Kerberos with OpenLDAP back-end}}}} for details.

Because {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} is single-threaded, latency in LDAP database
accesses may limit KDC operation throughput.  If the LDAP server is
located on the same server host as the KDC and accessed through an
\sphinxcode{ldapi://} URL, latency should be minimal.  If this is not possible,
consider starting multiple KDC worker processes with the
{\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} \sphinxstylestrong{-w} option to enable concurrent processing of KDC
requests.

The kldap module does not support explicit locking with the
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} \sphinxstylestrong{lock} command.


\chapter{Account lockout}
\label{\detokenize{admin/lockout:lockout}}\label{\detokenize{admin/lockout::doc}}\label{\detokenize{admin/lockout:account-lockout}}
As of release 1.8, the KDC can be configured to lock out principals
after a number of failed authentication attempts within a period of
time.  Account lockout can make it more difficult to attack a
principal’s password by brute force, but also makes it easy for an
attacker to deny access to a principal.


\section{Configuring account lockout}
\label{\detokenize{admin/lockout:configuring-account-lockout}}
Account lockout only works for principals with the
\sphinxstylestrong{+requires\_preauth} flag set.  Without this flag, the KDC cannot
know whether or not a client successfully decrypted the ticket it
issued.  It is also important to set the \sphinxstylestrong{-allow\_svr} flag on a
principal to protect its password from an off-line dictionary attack
through a TGS request.  You can set these flags on a principal with
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} as follows:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{modprinc} \PYG{o}{+}\PYG{n}{requires\PYGZus{}preauth} \PYG{o}{\PYGZhy{}}\PYG{n}{allow\PYGZus{}svr} \PYG{n}{PRINCNAME}
\end{sphinxVerbatim}

Account lockout parameters are configured via {\hyperref[\detokenize{admin/database:policies}]{\sphinxcrossref{\DUrole{std,std-ref}{policy objects}}}}.  There may be an existing policy associated with user
principals (such as the “default” policy), or you may need to create a
new one and associate it with each user principal.

The policy parameters related to account lockout are:
\begin{itemize}
\item {} 
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:policy-maxfailure}]{\sphinxcrossref{\DUrole{std,std-ref}{maxfailure}}}}: the number of failed attempts
before the principal is locked out

\item {} 
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:policy-failurecountinterval}]{\sphinxcrossref{\DUrole{std,std-ref}{failurecountinterval}}}}: the
allowable interval between failed attempts

\item {} 
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:policy-lockoutduration}]{\sphinxcrossref{\DUrole{std,std-ref}{lockoutduration}}}}: the amount of time
a principal is locked out for

\end{itemize}

Here is an example of setting these parameters on a new policy and
associating it with a principal:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{addpol} \PYG{o}{\PYGZhy{}}\PYG{n}{maxfailure} \PYG{l+m+mi}{10} \PYG{o}{\PYGZhy{}}\PYG{n}{failurecountinterval} \PYG{l+m+mi}{180}
    \PYG{o}{\PYGZhy{}}\PYG{n}{lockoutduration} \PYG{l+m+mi}{60} \PYG{n}{lockout\PYGZus{}policy}
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{modprinc} \PYG{o}{\PYGZhy{}}\PYG{n}{policy} \PYG{n}{lockout\PYGZus{}policy} \PYG{n}{PRINCNAME}
\end{sphinxVerbatim}


\section{Testing account lockout}
\label{\detokenize{admin/lockout:testing-account-lockout}}
To test that account lockout is working, try authenticating as the
principal (hopefully not one that might be in use) multiple times with
the wrong password.  For instance, if \sphinxstylestrong{maxfailure} is set to 2, you
might see:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kinit user
Password for user@KRBTEST.COM:
kinit: Password incorrect while getting initial credentials
\PYGZdl{} kinit user
Password for user@KRBTEST.COM:
kinit: Password incorrect while getting initial credentials
\PYGZdl{} kinit user
kinit: Client\PYGZsq{}s credentials have been revoked while getting initial credentials
\end{sphinxVerbatim}


\section{Account lockout principal state}
\label{\detokenize{admin/lockout:account-lockout-principal-state}}
A principal entry keeps three pieces of state related to account
lockout:
\begin{itemize}
\item {} 
The time of last successful authentication

\item {} 
The time of last failed authentication

\item {} 
A counter of failed attempts

\end{itemize}

The time of last successful authentication is not actually needed for
the account lockout system to function, but may be of administrative
interest.  These fields can be observed with the \sphinxstylestrong{getprinc} kadmin
command.  For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{getprinc} \PYG{n}{user}
\PYG{n}{Principal}\PYG{p}{:} \PYG{n}{user}\PYG{n+nd}{@KRBTEST}\PYG{o}{.}\PYG{n}{COM}
\PYG{o}{.}\PYG{o}{.}\PYG{o}{.}
\PYG{n}{Last} \PYG{n}{successful} \PYG{n}{authentication}\PYG{p}{:} \PYG{p}{[}\PYG{n}{never}\PYG{p}{]}
\PYG{n}{Last} \PYG{n}{failed} \PYG{n}{authentication}\PYG{p}{:} \PYG{n}{Mon} \PYG{n}{Dec} \PYG{l+m+mi}{03} \PYG{l+m+mi}{12}\PYG{p}{:}\PYG{l+m+mi}{30}\PYG{p}{:}\PYG{l+m+mi}{33} \PYG{n}{EST} \PYG{l+m+mi}{2012}
\PYG{n}{Failed} \PYG{n}{password} \PYG{n}{attempts}\PYG{p}{:} \PYG{l+m+mi}{2}
\PYG{o}{.}\PYG{o}{.}\PYG{o}{.}
\end{sphinxVerbatim}

A principal which has been locked out can be administratively unlocked
with the \sphinxstylestrong{-unlock} option to the \sphinxstylestrong{modprinc} kadmin command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{modprinc} \PYG{o}{\PYGZhy{}}\PYG{n}{unlock} \PYG{n}{PRINCNAME}
\end{sphinxVerbatim}

This command will reset the number of failed attempts to 0.


\section{KDC replication and account lockout}
\label{\detokenize{admin/lockout:kdc-replication-and-account-lockout}}
The account lockout state of a principal is not replicated by either
traditional {\hyperref[\detokenize{admin/admin_commands/kprop:kprop-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop}}}} or incremental propagation.  Because of
this, the number of attempts an attacker can make within a time period
is multiplied by the number of KDCs.  For instance, if the
\sphinxstylestrong{maxfailure} parameter on a policy is 10 and there are four KDCs in
the environment (a primary and three replicas), an attacker could make
as many as 40 attempts before the principal is locked out on all four
KDCs.

An administrative unlock is propagated from the primary to the replica
KDCs during the next propagation.  Propagation of an administrative
unlock will cause the counter of failed attempts on each replica to
reset to 1 on the next failure.

If a KDC environment uses a replication strategy other than kprop or
incremental propagation, such as the LDAP KDB module with multi-master
LDAP replication, then account lockout state may be replicated between
KDCs and the concerns of this section may not apply.


\section{KDC performance and account lockout}
\label{\detokenize{admin/lockout:kdc-performance-and-account-lockout}}\label{\detokenize{admin/lockout:disable-lockout}}
In order to fully track account lockout state, the KDC must write to
the the database on each successful and failed authentication.
Writing to the database is generally more expensive than reading from
it, so these writes may have a significant impact on KDC performance.
As of release 1.9, it is possible to turn off account lockout state
tracking in order to improve performance, by setting the
\sphinxstylestrong{disable\_last\_success} and \sphinxstylestrong{disable\_lockout} variables in the
database module subsection of {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.  For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{dbmodules}\PYG{p}{]}
    \PYG{n}{DB} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{disable\PYGZus{}last\PYGZus{}success} \PYG{o}{=} \PYG{n}{true}
        \PYG{n}{disable\PYGZus{}lockout} \PYG{o}{=} \PYG{n}{true}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

Of the two variables, setting \sphinxstylestrong{disable\_last\_success} will usually
have the largest positive impact on performance, and will still allow
account lockout policies to operate.  However, it will make it
impossible to observe the last successful authentication time with
kadmin.


\section{KDC setup and account lockout}
\label{\detokenize{admin/lockout:kdc-setup-and-account-lockout}}
To update the account lockout state on principals, the KDC must be
able to write to the principal database.  For the DB2 module, no
special setup is required.  For the LDAP module, the KDC DN must be
granted write access to the principal objects.  If the KDC DN has only
read access, account lockout will not function.


\chapter{Configuring Kerberos with OpenLDAP back-end}
\label{\detokenize{admin/conf_ldap:conf-ldap}}\label{\detokenize{admin/conf_ldap::doc}}\label{\detokenize{admin/conf_ldap:configuring-kerberos-with-openldap-back-end}}\begin{enumerate}
\item {} 
Make sure the LDAP server is using local authentication
(\sphinxcode{ldapi://}) or TLS (\sphinxcode{ldaps}).  See
\sphinxurl{https://www.openldap.org/doc/admin/tls.html} for instructions on
configuring TLS support in OpenLDAP.

\item {} 
Add the Kerberos schema file to the LDAP Server using the OpenLDAP
LDIF file from the krb5 source directory
(\sphinxcode{src/plugins/kdb/ldap/libkdb\_ldap/kerberos.openldap.ldif}).
The following example uses local authentication:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{ldapadd} \PYG{o}{\PYGZhy{}}\PYG{n}{Y} \PYG{n}{EXTERNAL} \PYG{o}{\PYGZhy{}}\PYG{n}{H} \PYG{n}{ldapi}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{o}{/} \PYG{o}{\PYGZhy{}}\PYG{n}{f} \PYG{o}{/}\PYG{n}{path}\PYG{o}{/}\PYG{n}{to}\PYG{o}{/}\PYG{n}{kerberos}\PYG{o}{.}\PYG{n}{openldap}\PYG{o}{.}\PYG{n}{ldif}
\end{sphinxVerbatim}

\item {} 
Choose DNs for the {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} and {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} servers
to bind to the LDAP server, and create them if necessary.  Specify
these DNs with the \sphinxstylestrong{ldap\_kdc\_dn} and \sphinxstylestrong{ldap\_kadmind\_dn}
directives in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.  The kadmind DN will also be
used for administrative commands such as {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}}.

Alternatively, you may configure krb5kdc and kadmind to use SASL
authentication to access the LDAP server; see the {\hyperref[\detokenize{admin/conf_files/kdc_conf:dbmodules}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}dbmodules{]}}}}}
relations \sphinxstylestrong{ldap\_kdc\_sasl\_mech} and similar.

\item {} 
Specify a location for the LDAP service password file by setting
\sphinxstylestrong{ldap\_service\_password\_file}.  Use \sphinxcode{kdb5\_ldap\_util stashsrvpw}
to stash passwords for the KDC and kadmind DNs chosen above.  For
example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kdb5\PYGZus{}ldap\PYGZus{}util} \PYG{n}{stashsrvpw} \PYG{o}{\PYGZhy{}}\PYG{n}{f} \PYG{o}{/}\PYG{n}{path}\PYG{o}{/}\PYG{n}{to}\PYG{o}{/}\PYG{n}{service}\PYG{o}{.}\PYG{n}{keyfile} \PYG{n}{cn}\PYG{o}{=}\PYG{n}{krbadmin}\PYG{p}{,}\PYG{n}{dc}\PYG{o}{=}\PYG{n}{example}\PYG{p}{,}\PYG{n}{dc}\PYG{o}{=}\PYG{n}{com}
\end{sphinxVerbatim}

Skip this step if you are using SASL authentication and the
mechanism does not require a password.

\item {} 
Choose a DN for the global Kerberos container entry (but do not
create the entry at this time).  Specify this DN with the
\sphinxstylestrong{ldap\_kerberos\_container\_dn} directive in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.
Realm container entries will be created underneath this DN.
Principal entries may exist either underneath the realm container
(the default) or in separate trees referenced from the realm
container.

\item {} 
Configure the LDAP server ACLs to enable the KDC and kadmin server
DNs to read and write the Kerberos data.  If
\sphinxstylestrong{disable\_last\_success} and \sphinxstylestrong{disable\_lockout} are both set to
true in the {\hyperref[\detokenize{admin/conf_files/kdc_conf:dbmodules}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}dbmodules{]}}}}} subsection for the realm, then the
KDC DN only requires read access to the Kerberos data.

Sample access control information:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{access} \PYG{n}{to} \PYG{n}{dn}\PYG{o}{.}\PYG{n}{base}\PYG{o}{=}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{\PYGZdq{}}
    \PYG{n}{by} \PYG{o}{*} \PYG{n}{read}

\PYG{n}{access} \PYG{n}{to} \PYG{n}{dn}\PYG{o}{.}\PYG{n}{base}\PYG{o}{=}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=Subschema}\PYG{l+s+s2}{\PYGZdq{}}
    \PYG{n}{by} \PYG{o}{*} \PYG{n}{read}

\PYG{c+c1}{\PYGZsh{} Provide access to the realm container.}
\PYG{n}{access} \PYG{n}{to} \PYG{n}{dn}\PYG{o}{.}\PYG{n}{subtree}\PYG{o}{=} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=EXAMPLE.COM,cn=krbcontainer,dc=example,dc=com}\PYG{l+s+s2}{\PYGZdq{}}
    \PYG{n}{by} \PYG{n}{dn}\PYG{o}{.}\PYG{n}{exact}\PYG{o}{=}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=kdc\PYGZhy{}service,dc=example,dc=com}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{write}
    \PYG{n}{by} \PYG{n}{dn}\PYG{o}{.}\PYG{n}{exact}\PYG{o}{=}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=adm\PYGZhy{}service,dc=example,dc=com}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{write}
    \PYG{n}{by} \PYG{o}{*} \PYG{n}{none}

\PYG{c+c1}{\PYGZsh{} Provide access to principals, if not underneath the realm container.}
\PYG{n}{access} \PYG{n}{to} \PYG{n}{dn}\PYG{o}{.}\PYG{n}{subtree}\PYG{o}{=} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{ou=users,dc=example,dc=com}\PYG{l+s+s2}{\PYGZdq{}}
    \PYG{n}{by} \PYG{n}{dn}\PYG{o}{.}\PYG{n}{exact}\PYG{o}{=}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=kdc\PYGZhy{}service,dc=example,dc=com}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{write}
    \PYG{n}{by} \PYG{n}{dn}\PYG{o}{.}\PYG{n}{exact}\PYG{o}{=}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=adm\PYGZhy{}service,dc=example,dc=com}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{write}
    \PYG{n}{by} \PYG{o}{*} \PYG{n}{none}

\PYG{n}{access} \PYG{n}{to} \PYG{o}{*}
    \PYG{n}{by} \PYG{o}{*} \PYG{n}{read}
\end{sphinxVerbatim}

If the locations of the container and principals or the DNs of the
service objects for a realm are changed then this information
should be updated.

\item {} 
In {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}, make sure the following relations are set
in the {\hyperref[\detokenize{admin/conf_files/kdc_conf:dbmodules}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}dbmodules{]}}}}} subsection for the realm:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
db\PYGZus{}library (set to {}`{}`kldap{}`{}`)
ldap\PYGZus{}kerberos\PYGZus{}container\PYGZus{}dn
ldap\PYGZus{}kdc\PYGZus{}dn
ldap\PYGZus{}kadmind\PYGZus{}dn
ldap\PYGZus{}service\PYGZus{}password\PYGZus{}file
ldap\PYGZus{}servers
\end{sphinxVerbatim}

\item {} 
Create the realm using {\hyperref[\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_ldap\_util}}}}:
\begin{quote}

kdb5\_ldap\_util create -subtrees ou=users,dc=example,dc=com -s
\end{quote}

Use the \sphinxstylestrong{-subtrees} option if the principals are to exist in a
separate subtree from the realm container.  Before executing the
command, make sure that the subtree mentioned above
\sphinxcode{(ou=users,dc=example,dc=com)} exists.  If the principals will
exist underneath the realm container, omit the \sphinxstylestrong{-subtrees} option
and do not worry about creating the principal subtree.

For more information, refer to the section {\hyperref[\detokenize{admin/database:ops-on-ldap}]{\sphinxcrossref{\DUrole{std,std-ref}{Operations on the LDAP database}}}}.

The realm object is created under the
\sphinxstylestrong{ldap\_kerberos\_container\_dn} specified in the configuration
file.  This operation will also create the Kerberos container, if
not present already.  This container can be used to store
information related to multiple realms.

\item {} 
Add an \sphinxcode{eq} index for \sphinxcode{krbPrincipalName} to speed up principal
lookup operations.  See
\sphinxurl{https://www.openldap.org/doc/admin/tuning.html\#Indexes} for
details.

\end{enumerate}

With the LDAP back end it is possible to provide aliases for principal
entries.  Currently we provide no administrative utilities for
creating aliases, so it must be done by direct manipulation of the
LDAP entries.

An entry with aliases contains multiple values of the
\sphinxstyleemphasis{krbPrincipalName} attribute.  Since LDAP attribute values are not
ordered, it is necessary to specify which principal name is canonical,
by using the \sphinxstyleemphasis{krbCanonicalName} attribute.  Therefore, to create
aliases for an entry, first set the \sphinxstyleemphasis{krbCanonicalName} attribute of
the entry to the canonical principal name (which should be identical
to the pre-existing \sphinxstyleemphasis{krbPrincipalName} value), and then add additional
\sphinxstyleemphasis{krbPrincipalName} attributes for the aliases.

Principal aliases are only returned by the KDC when the client
requests canonicalization.  Canonicalization is normally requested for
service principals; for client principals, an explicit flag is often
required (e.g., \sphinxcode{kinit -C}) and canonicalization is only performed
for initial ticket requests.


\chapter{Application servers}
\label{\detokenize{admin/appl_servers::doc}}\label{\detokenize{admin/appl_servers:application-servers}}
If you need to install the Kerberos V5 programs on an application
server, please refer to the Kerberos V5 Installation Guide.  Once you
have installed the software, you need to add that host to the Kerberos
database (see {\hyperref[\detokenize{admin/database:principals}]{\sphinxcrossref{\DUrole{std,std-ref}{Principals}}}}), and generate a keytab for that host,
that contains the host’s key.  You also need to make sure the host’s
clock is within your maximum clock skew of the KDCs.


\section{Keytabs}
\label{\detokenize{admin/appl_servers:keytabs}}
A keytab is a host’s copy of its own keylist, which is analogous to a
user’s password.  An application server that needs to authenticate
itself to the KDC has to have a keytab that contains its own principal
and key.  Just as it is important for users to protect their
passwords, it is equally important for hosts to protect their keytabs.
You should always store keytab files on local disk, and make them
readable only by root, and you should never send a keytab file over a
network in the clear.  Ideally, you should run the {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}
command to extract a keytab on the host on which the keytab is to
reside.


\subsection{Adding principals to keytabs}
\label{\detokenize{admin/appl_servers:adding-principals-to-keytabs}}\label{\detokenize{admin/appl_servers:add-princ-kt}}
To generate a keytab, or to add a principal to an existing keytab, use
the \sphinxstylestrong{ktadd} command from kadmin.  Here is a sample session, using
configuration files that enable only AES encryption:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{ktadd} \PYG{n}{host}\PYG{o}{/}\PYG{n}{daffodil}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{daffodil}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{daffodil}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}
\end{sphinxVerbatim}


\subsection{Removing principals from keytabs}
\label{\detokenize{admin/appl_servers:removing-principals-from-keytabs}}
To remove a principal from an existing keytab, use the kadmin
\sphinxstylestrong{ktremove} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:}  \PYG{n}{ktremove} \PYG{n}{host}\PYG{o}{/}\PYG{n}{daffodil}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{daffodil}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{2} \PYG{n}{removed} \PYG{k+kn}{from} \PYG{n+nn}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{daffodil}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{2} \PYG{n}{removed} \PYG{k+kn}{from} \PYG{n+nn}{keytab} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\end{sphinxVerbatim}


\subsection{Using a keytab to acquire client credentials}
\label{\detokenize{admin/appl_servers:using-a-keytab-to-acquire-client-credentials}}
While keytabs are ordinarily used to accept credentials from clients,
they can also be used to acquire initial credentials, allowing one
service to authenticate to another.

To manually obtain credentials using a keytab, use the \DUrole{xref,std,std-ref}{kinit(1)}
\sphinxstylestrong{-k} option, together with the \sphinxstylestrong{-t} option if the keytab is not in
the default location.

Beginning with release 1.11, GSSAPI applications can be configured to
automatically obtain initial credentials from a keytab as needed.  The
recommended configuration is as follows:
\begin{enumerate}
\item {} 
Create a keytab containing a single entry for the desired client
identity.

\item {} 
Place the keytab in a location readable by the service, and set the
\sphinxstylestrong{KRB5\_CLIENT\_KTNAME} environment variable to its filename.
Alternatively, use the \sphinxstylestrong{default\_client\_keytab\_name} profile
variable in {\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}}, or use the default location of
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{DEFCKTNAME}}}}.

\item {} 
Set \sphinxstylestrong{KRB5CCNAME} to a filename writable by the service, which
will not be used for any other purpose.  Do not manually obtain
credentials at this location.  (Another credential cache type
besides \sphinxstylestrong{FILE} can be used if desired, as long the cache will not
conflict with another use.  A \sphinxstylestrong{MEMORY} cache can be used if the
service runs as a long-lived process.  See \DUrole{xref,std,std-ref}{ccache\_definition}
for details.)

\item {} 
Start the service.  When it authenticates using GSSAPI, it will
automatically obtain credentials from the client keytab into the
specified credential cache, and refresh them before they expire.

\end{enumerate}


\section{Clock Skew}
\label{\detokenize{admin/appl_servers:clock-skew}}
A Kerberos application server host must keep its clock synchronized or
it will reject authentication requests from clients.  Modern operating
systems typically provide a facility to maintain the correct time;
make sure it is enabled.  This is especially important on virtual
machines, where clocks tend to drift more rapidly than normal machine
clocks.

The default allowable clock skew is controlled by the \sphinxstylestrong{clockskew}
variable in {\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}}.


\section{Getting DNS information correct}
\label{\detokenize{admin/appl_servers:getting-dns-information-correct}}
Several aspects of Kerberos rely on name service.  When a hostname is
used to name a service, clients may canonicalize the hostname using
forward and possibly reverse name resolution.  The result of this
canonicalization must match the principal entry in the host’s keytab,
or authentication will fail.  To work with all client canonicalization
configurations, each host’s canonical name must be the fully-qualified
host name (including the domain), and each host’s IP address must
reverse-resolve to the canonical name.

Configuration of hostnames varies by operating system.  On the
application server itself, canonicalization will typically use the
\sphinxcode{/etc/hosts} file rather than the DNS.  Ensure that the line for the
server’s hostname is in the following form:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{IP} \PYG{n}{address}      \PYG{n}{fully}\PYG{o}{\PYGZhy{}}\PYG{n}{qualified} \PYG{n}{hostname}        \PYG{n}{aliases}
\end{sphinxVerbatim}

Here is a sample \sphinxcode{/etc/hosts} file:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{c+c1}{\PYGZsh{} this is a comment}
\PYG{l+m+mf}{127.0}\PYG{o}{.}\PYG{l+m+mf}{0.1}      \PYG{n}{localhost} \PYG{n}{localhost}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
\PYG{l+m+mf}{10.0}\PYG{o}{.}\PYG{l+m+mf}{0.6}       \PYG{n}{daffodil}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{n}{daffodil} \PYG{n}{trillium} \PYG{n}{wake}\PYG{o}{\PYGZhy{}}\PYG{n}{robin}
\end{sphinxVerbatim}

The output of \sphinxcode{klist -k} for this example host should look like:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{viola}\PYG{c+c1}{\PYGZsh{} klist \PYGZhy{}k}
\PYG{n}{Keytab} \PYG{n}{name}\PYG{p}{:} \PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}
\PYG{n}{KVNO} \PYG{n}{Principal}
\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}} \PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}
   \PYG{l+m+mi}{2} \PYG{n}{host}\PYG{o}{/}\PYG{n}{daffodil}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\end{sphinxVerbatim}

If you were to ssh to this host with a fresh credentials cache (ticket
file), and then \DUrole{xref,std,std-ref}{klist(1)}, the output should list a service
principal of \sphinxcode{host/daffodil.mit.edu@ATHENA.MIT.EDU}.


\section{Configuring your firewall to work with Kerberos V5}
\label{\detokenize{admin/appl_servers:conf-firewall}}\label{\detokenize{admin/appl_servers:configuring-your-firewall-to-work-with-kerberos-v5}}
If you need off-site users to be able to get Kerberos tickets in your
realm, they must be able to get to your KDC.  This requires either
that you have a replica KDC outside your firewall, or that you
configure your firewall to allow UDP requests into at least one of
your KDCs, on whichever port the KDC is running.  (The default is port
88; other ports may be specified in the KDC’s {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}
file.)  Similarly, if you need off-site users to be able to change
their passwords in your realm, they must be able to get to your
Kerberos admin server on the kpasswd port (which defaults to 464).  If
you need off-site users to be able to administer your Kerberos realm,
they must be able to get to your Kerberos admin server on the
administrative port (which defaults to 749).

If your on-site users inside your firewall will need to get to KDCs in
other realms, you will also need to configure your firewall to allow
outgoing TCP and UDP requests to port 88, and to port 464 to allow
password changes.  If your on-site users inside your firewall will
need to get to Kerberos admin servers in other realms, you will also
need to allow outgoing TCP and UDP requests to port 749.

If any of your KDCs are outside your firewall, you will need to allow
kprop requests to get through to the remote KDC.  {\hyperref[\detokenize{admin/admin_commands/kprop:kprop-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop}}}} uses
the \sphinxcode{krb5\_prop} service on port 754 (tcp).

The book \sphinxstyleemphasis{UNIX System Security}, by David Curry, is a good starting
point for learning to configure firewalls.


\chapter{Host configuration}
\label{\detokenize{admin/host_config:host-configuration}}\label{\detokenize{admin/host_config::doc}}
All hosts running Kerberos software, whether they are clients,
application servers, or KDCs, can be configured using
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}.  Here we describe some of the behavior changes
you might want to make.


\section{Default realm}
\label{\detokenize{admin/host_config:default-realm}}
In the {\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}} section, the \sphinxstylestrong{default\_realm} realm
relation sets the default Kerberos realm.  For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{libdefaults}\PYG{p}{]}
    \PYG{n}{default\PYGZus{}realm} \PYG{o}{=} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\end{sphinxVerbatim}

The default realm affects Kerberos behavior in the following ways:
\begin{itemize}
\item {} 
When a principal name is parsed from text, the default realm is used
if no \sphinxcode{@REALM} component is specified.

\item {} 
The default realm affects login authorization as described below.

\item {} 
For programs which operate on a Kerberos database, the default realm
is used to determine which database to operate on, unless the \sphinxstylestrong{-r}
parameter is given to specify a realm.

\item {} 
A server program may use the default realm when looking up its key
in a {\hyperref[\detokenize{admin/install_appl_srv:keytab-file}]{\sphinxcrossref{\DUrole{std,std-ref}{keytab file}}}}, if its realm is not
determined by {\hyperref[\detokenize{admin/conf_files/krb5_conf:domain-realm}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}domain\_realm{]}}}}} configuration or by the server
program itself.

\item {} 
If \DUrole{xref,std,std-ref}{kinit(1)} is passed the \sphinxstylestrong{-n} flag, it requests anonymous
tickets from the default realm.

\end{itemize}

In some situations, these uses of the default realm might conflict.
For example, it might be desirable for principal name parsing to use
one realm by default, but for login authorization to use a second
realm.  In this situation, the first realm can be configured as the
default realm, and \sphinxstylestrong{auth\_to\_local} relations can be used as
described below to use the second realm for login authorization.


\section{Login authorization}
\label{\detokenize{admin/host_config:login-authorization}}\label{\detokenize{admin/host_config:id1}}
If a host runs a Kerberos-enabled login service such as OpenSSH with
GSSAPIAuthentication enabled, login authorization rules determine
whether a Kerberos principal is allowed to access a local account.

By default, a Kerberos principal is allowed access to an account if
its realm matches the default realm and its name matches the account
name.  (For historical reasons, access is also granted by default if
the name has two components and the second component matches the
default realm; for instance, \sphinxcode{alice/ATHENA.MIT.EDU@ATHENA.MIT.EDU}
is granted access to the \sphinxcode{alice} account if \sphinxcode{ATHENA.MIT.EDU} is
the default realm.)

The simplest way to control local access is using \DUrole{xref,std,std-ref}{.k5login(5)}
files.  To use these, place a \sphinxcode{.k5login} file in the home directory
of each account listing the principal names which should have login
access to that account.  If it is not desirable to use \sphinxcode{.k5login}
files located in account home directories, the \sphinxstylestrong{k5login\_directory}
relation in the {\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}} section can specify a directory
containing one file per account uname.

By default, if a \sphinxcode{.k5login} file is present, it controls
authorization both positively and negatively\textendash{}any principal name
contained in the file is granted access and any other principal name
is denied access, even if it would have had access if the \sphinxcode{.k5login}
file didn’t exist.  The \sphinxstylestrong{k5login\_authoritative} relation in the
{\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}} section can be set to false to make \sphinxcode{.k5login}
files provide positive authorization only.

The \sphinxstylestrong{auth\_to\_local} relation in the {\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} section for the
default realm can specify pattern-matching rules to control login
authorization.  For example, the following configuration allows access
to principals from a different realm than the default realm:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
[realms]
    DEFAULT.REALM = \PYGZob{}
        \PYGZsh{} Allow access to principals from OTHER.REALM.
        \PYGZsh{}
        \PYGZsh{} [1:\PYGZdl{}1@\PYGZdl{}0] matches single\PYGZhy{}component principal names and creates
        \PYGZsh{} a selection string containing the principal name and realm.
        \PYGZsh{}
        \PYGZsh{} (.*@OTHER\PYGZbs{}.REALM) matches against the selection string, so that
        \PYGZsh{} only principals in OTHER.REALM are matched.
        \PYGZsh{}
        \PYGZsh{} s/@OTHER\PYGZbs{}.REALM\PYGZdl{}// removes the realm name, leaving behind the
        \PYGZsh{} principal name as the account name.
        auth\PYGZus{}to\PYGZus{}local = RULE:[1:\PYGZdl{}1@\PYGZdl{}0](.*@OTHER\PYGZbs{}.REALM)s/@OTHER\PYGZbs{}.REALM\PYGZdl{}//

        \PYGZsh{} Also allow principals from the default realm.  Omit this line
        \PYGZsh{} to only allow access to principals in OTHER.REALM.
        auth\PYGZus{}to\PYGZus{}local = DEFAULT
    \PYGZcb{}
\end{sphinxVerbatim}

The \sphinxstylestrong{auth\_to\_local\_names} subsection of the {\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} section
for the default realm can specify explicit mappings from principal
names to local accounts.  The key used in this subsection is the
principal name without realm, so it is only safe to use in a Kerberos
environment with a single realm or a tightly controlled set of realms.
An example use of \sphinxstylestrong{auth\_to\_local\_names} might be:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{realms}\PYG{p}{]}
    \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{auth\PYGZus{}to\PYGZus{}local\PYGZus{}names} \PYG{o}{=} \PYG{p}{\PYGZob{}}
            \PYG{c+c1}{\PYGZsh{} Careful, these match principals in any realm!}
            \PYG{n}{host}\PYG{o}{/}\PYG{n}{example}\PYG{o}{.}\PYG{n}{com} \PYG{o}{=} \PYG{n}{hostaccount}
            \PYG{n}{fred} \PYG{o}{=} \PYG{n}{localfred}
        \PYG{p}{\PYGZcb{}}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

Local authorization behavior can also be modified using plugin
modules; see \DUrole{xref,std,std-ref}{hostrealm\_plugin} for details.


\section{Plugin module configuration}
\label{\detokenize{admin/host_config:plugin-config}}\label{\detokenize{admin/host_config:plugin-module-configuration}}
Many aspects of Kerberos behavior, such as client preauthentication
and KDC service location, can be modified through the use of plugin
modules.  For most of these behaviors, you can use the {\hyperref[\detokenize{admin/conf_files/krb5_conf:plugins}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}plugins{]}}}}}
section of krb5.conf to register third-party modules, and to switch
off registered or built-in modules.

A plugin module takes the form of a Unix shared object
(\sphinxcode{modname.so}) or Windows DLL (\sphinxcode{modname.dll}).  If you have
installed a third-party plugin module and want to register it, you do
so using the \sphinxstylestrong{module} relation in the appropriate subsection of the
{[}plugins{]} section.  The value for \sphinxstylestrong{module} must give the module name
and the path to the module, separated by a colon.  The module name
will often be the same as the shared object’s name, but in unusual
cases (such as a shared object which implements multiple modules for
the same interface) it might not be.  For example, to register a
client preauthentication module named \sphinxcode{mypreauth} installed at
\sphinxcode{/path/to/mypreauth.so}, you could write:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{plugins}\PYG{p}{]}
    \PYG{n}{clpreauth} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{module} \PYG{o}{=} \PYG{n}{mypreauth}\PYG{p}{:}\PYG{o}{/}\PYG{n}{path}\PYG{o}{/}\PYG{n}{to}\PYG{o}{/}\PYG{n}{mypreauth}\PYG{o}{.}\PYG{n}{so}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

Many of the pluggable behaviors in MIT krb5 contain built-in modules
which can be switched off.  You can disable a built-in module (or one
you have registered) using the \sphinxstylestrong{disable} directive in the
appropriate subsection of the {[}plugins{]} section.  For example, to
disable the use of .k5identity files to select credential caches, you
could write:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{plugins}\PYG{p}{]}
    \PYG{n}{ccselect} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{disable} \PYG{o}{=} \PYG{n}{k5identity}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

If you want to disable multiple modules, specify the \sphinxstylestrong{disable}
directive multiple times, giving one module to disable each time.

Alternatively, you can explicitly specify which modules you want to be
enabled for that behavior using the \sphinxstylestrong{enable\_only} directive.  For
example, to make {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} check password quality using only a
module you have registered, and no other mechanism, you could write:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{plugins}\PYG{p}{]}
    \PYG{n}{pwqual} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{module} \PYG{o}{=} \PYG{n}{mymodule}\PYG{p}{:}\PYG{o}{/}\PYG{n}{path}\PYG{o}{/}\PYG{n}{to}\PYG{o}{/}\PYG{n}{mymodule}\PYG{o}{.}\PYG{n}{so}
        \PYG{n}{enable\PYGZus{}only} \PYG{o}{=} \PYG{n}{mymodule}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

Again, if you want to specify multiple modules, specify the
\sphinxstylestrong{enable\_only} directive multiple times, giving one module to enable
each time.

Some Kerberos interfaces use different mechanisms to register plugin
modules.


\subsection{KDC location modules}
\label{\detokenize{admin/host_config:kdc-location-modules}}
For historical reasons, modules to control how KDC servers are located
are registered simply by placing the shared object or DLL into the
“libkrb5” subdirectory of the krb5 plugin directory, which defaults to
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LIBDIR}}}}\sphinxcode{/krb5/plugins}.  For example, Samba’s winbind krb5
locator plugin would be registered by placing its shared object in
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LIBDIR}}}}\sphinxcode{/krb5/plugins/libkrb5/winbind\_krb5\_locator.so}.


\subsection{GSSAPI mechanism modules}
\label{\detokenize{admin/host_config:gssapi-plugin-config}}\label{\detokenize{admin/host_config:gssapi-mechanism-modules}}
GSSAPI mechanism modules are registered using the file
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{SYSCONFDIR}}}}\sphinxcode{/gss/mech} or configuration files in the
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{SYSCONFDIR}}}}\sphinxcode{/gss/mech.d} directory with a \sphinxcode{.conf}
suffix.  Each line in these files has the form:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{name}  \PYG{n}{oid}  \PYG{n}{pathname}  \PYG{p}{[}\PYG{n}{options}\PYG{p}{]}  \PYG{o}{\PYGZlt{}}\PYG{n+nb}{type}\PYG{o}{\PYGZgt{}}
\end{sphinxVerbatim}

Only the name, oid, and pathname are required.  \sphinxstyleemphasis{name} is the
mechanism name, which may be used for debugging or logging purposes.
\sphinxstyleemphasis{oid} is the object identifier of the GSSAPI mechanism to be
registered.  \sphinxstyleemphasis{pathname} is a path to the module shared object or DLL.
\sphinxstyleemphasis{options} (if present) are options provided to the plugin module,
surrounded in square brackets.  \sphinxstyleemphasis{type} (if present) can be used to
indicate a special type of module.  Currently the only special module
type is “interposer”, for a module designed to intercept calls to
other mechanisms.

If the environment variable \sphinxstylestrong{GSS\_MECH\_CONFIG} is set, its value is
used as the sole mechanism configuration filename.


\subsection{Configuration profile modules}
\label{\detokenize{admin/host_config:profile-plugin-config}}\label{\detokenize{admin/host_config:configuration-profile-modules}}
A configuration profile module replaces the information source for
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} itself.  To use a profile module, begin krb5.conf
with the line:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{module} \PYG{n}{PATHNAME}\PYG{p}{:}\PYG{n}{STRING}
\end{sphinxVerbatim}

where \sphinxstyleemphasis{PATHNAME} is a path to the module shared object or DLL, and
\sphinxstyleemphasis{STRING} is a string to provide to the module.  The module will then
take over, and the rest of krb5.conf will be ignored.


\chapter{Backups of secure hosts}
\label{\detokenize{admin/backup_host:backups-of-secure-hosts}}\label{\detokenize{admin/backup_host::doc}}
When you back up a secure host, you should exclude the host’s keytab
file from the backup.  If someone obtained a copy of the keytab from a
backup, that person could make any host masquerade as the host whose
keytab was compromised.  In many configurations, knowledge of the
host’s keytab also allows root access to the host.  This could be
particularly dangerous if the compromised keytab was from one of your
KDCs.  If the machine has a disk crash and the keytab file is lost, it
is easy to generate another keytab file.  (See {\hyperref[\detokenize{admin/appl_servers:add-princ-kt}]{\sphinxcrossref{\DUrole{std,std-ref}{Adding principals to keytabs}}}}.)
If you are unable to exclude particular files from backups, you should
ensure that the backups are kept as secure as the host’s root
password.


\section{Backing up the Kerberos database}
\label{\detokenize{admin/backup_host:backing-up-the-kerberos-database}}
As with any file, it is possible that your Kerberos database could
become corrupted.  If this happens on one of the replica KDCs, you
might never notice, since the next automatic propagation of the
database would install a fresh copy.  However, if it happens to the
primary KDC, the corrupted database would be propagated to all of the
replicas during the next propagation.  For this reason, MIT recommends
that you back up your Kerberos database regularly.  Because the primary
KDC is continuously dumping the database to a file in order to
propagate it to the replica KDCs, it is a simple matter to have a cron
job periodically copy the dump file to a secure machine elsewhere on
your network.  (Of course, it is important to make the host where
these backups are stored as secure as your KDCs, and to encrypt its
transmission across your network.)  Then if your database becomes
corrupted, you can load the most recent dump onto the primary KDC.
(See {\hyperref[\detokenize{admin/database:restore-from-dump}]{\sphinxcrossref{\DUrole{std,std-ref}{Dumping and loading a Kerberos database}}}}.)


\chapter{PKINIT configuration}
\label{\detokenize{admin/pkinit:pkinit-configuration}}\label{\detokenize{admin/pkinit:pkinit}}\label{\detokenize{admin/pkinit::doc}}
PKINIT is a preauthentication mechanism for Kerberos 5 which uses
X.509 certificates to authenticate the KDC to clients and vice versa.
PKINIT can also be used to enable anonymity support, allowing clients
to communicate securely with the KDC or with application servers
without authenticating as a particular client principal.


\section{Creating certificates}
\label{\detokenize{admin/pkinit:creating-certificates}}
PKINIT requires an X.509 certificate for the KDC and one for each
client principal which will authenticate using PKINIT.  For anonymous
PKINIT, a KDC certificate is required, but client certificates are
not.  A commercially issued server certificate can be used for the KDC
certificate, but generally cannot be used for client certificates.

The instruction in this section describe how to establish a
certificate authority and create standard PKINIT certificates.  Skip
this section if you are using a commercially issued server certificate
as the KDC certificate for anonymous PKINIT, or if you are configuring
a client to use an Active Directory KDC.


\subsection{Generating a certificate authority certificate}
\label{\detokenize{admin/pkinit:generating-a-certificate-authority-certificate}}
You can establish a new certificate authority (CA) for use with a
PKINIT deployment with the commands:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{openssl} \PYG{n}{genrsa} \PYG{o}{\PYGZhy{}}\PYG{n}{out} \PYG{n}{cakey}\PYG{o}{.}\PYG{n}{pem} \PYG{l+m+mi}{2048}
\PYG{n}{openssl} \PYG{n}{req} \PYG{o}{\PYGZhy{}}\PYG{n}{key} \PYG{n}{cakey}\PYG{o}{.}\PYG{n}{pem} \PYG{o}{\PYGZhy{}}\PYG{n}{new} \PYG{o}{\PYGZhy{}}\PYG{n}{x509} \PYG{o}{\PYGZhy{}}\PYG{n}{out} \PYG{n}{cacert}\PYG{o}{.}\PYG{n}{pem} \PYG{o}{\PYGZhy{}}\PYG{n}{days} \PYG{l+m+mi}{3650}
\end{sphinxVerbatim}

The second command will ask for the values of several certificate
fields.  These fields can be set to any values.  You can adjust the
expiration time of the CA certificate by changing the number after
\sphinxcode{-days}.  Since the CA certificate must be deployed to client
machines each time it changes, it should normally have an expiration
time far in the future; however, expiration times after 2037 may cause
interoperability issues in rare circumstances.

The result of these commands will be two files, cakey.pem and
cacert.pem.  cakey.pem will contain a 2048-bit RSA private key, which
must be carefully protected.  cacert.pem will contain the CA
certificate, which must be placed in the filesystems of the KDC and
each client host.  cakey.pem will be required to create KDC and client
certificates.


\subsection{Generating a KDC certificate}
\label{\detokenize{admin/pkinit:generating-a-kdc-certificate}}
A KDC certificate for use with PKINIT is required to have some unusual
fields, which makes generating them with OpenSSL somewhat complicated.
First, you will need a file containing the following:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
[kdc\PYGZus{}cert]
basicConstraints=CA:FALSE
keyUsage=nonRepudiation,digitalSignature,keyEncipherment,keyAgreement
extendedKeyUsage=1.3.6.1.5.2.3.5
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
issuerAltName=issuer:copy
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:kdc\PYGZus{}princ\PYGZus{}name

[kdc\PYGZus{}princ\PYGZus{}name]
realm=EXP:0,GeneralString:\PYGZdl{}\PYGZob{}ENV::REALM\PYGZcb{}
principal\PYGZus{}name=EXP:1,SEQUENCE:kdc\PYGZus{}principal\PYGZus{}seq

[kdc\PYGZus{}principal\PYGZus{}seq]
name\PYGZus{}type=EXP:0,INTEGER:2
name\PYGZus{}string=EXP:1,SEQUENCE:kdc\PYGZus{}principals

[kdc\PYGZus{}principals]
princ1=GeneralString:krbtgt
princ2=GeneralString:\PYGZdl{}\PYGZob{}ENV::REALM\PYGZcb{}
\end{sphinxVerbatim}

If the above contents are placed in extensions.kdc, you can generate
and sign a KDC certificate with the following commands:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{openssl} \PYG{n}{genrsa} \PYG{o}{\PYGZhy{}}\PYG{n}{out} \PYG{n}{kdckey}\PYG{o}{.}\PYG{n}{pem} \PYG{l+m+mi}{2048}
\PYG{n}{openssl} \PYG{n}{req} \PYG{o}{\PYGZhy{}}\PYG{n}{new} \PYG{o}{\PYGZhy{}}\PYG{n}{out} \PYG{n}{kdc}\PYG{o}{.}\PYG{n}{req} \PYG{o}{\PYGZhy{}}\PYG{n}{key} \PYG{n}{kdckey}\PYG{o}{.}\PYG{n}{pem}
\PYG{n}{env} \PYG{n}{REALM}\PYG{o}{=}\PYG{n}{YOUR\PYGZus{}REALMNAME} \PYG{n}{openssl} \PYG{n}{x509} \PYG{o}{\PYGZhy{}}\PYG{n}{req} \PYG{o}{\PYGZhy{}}\PYG{o+ow}{in} \PYG{n}{kdc}\PYG{o}{.}\PYG{n}{req} \PYGZbs{}
    \PYG{o}{\PYGZhy{}}\PYG{n}{CAkey} \PYG{n}{cakey}\PYG{o}{.}\PYG{n}{pem} \PYG{o}{\PYGZhy{}}\PYG{n}{CA} \PYG{n}{cacert}\PYG{o}{.}\PYG{n}{pem} \PYG{o}{\PYGZhy{}}\PYG{n}{out} \PYG{n}{kdc}\PYG{o}{.}\PYG{n}{pem} \PYG{o}{\PYGZhy{}}\PYG{n}{days} \PYG{l+m+mi}{365} \PYGZbs{}
    \PYG{o}{\PYGZhy{}}\PYG{n}{extfile} \PYG{n}{extensions}\PYG{o}{.}\PYG{n}{kdc} \PYG{o}{\PYGZhy{}}\PYG{n}{extensions} \PYG{n}{kdc\PYGZus{}cert} \PYG{o}{\PYGZhy{}}\PYG{n}{CAcreateserial}
\PYG{n}{rm} \PYG{n}{kdc}\PYG{o}{.}\PYG{n}{req}
\end{sphinxVerbatim}

The second command will ask for the values of certificate fields,
which can be set to any values.  In the third command, substitute your
KDC’s realm name for YOUR\_REALMNAME.  You can adjust the certificate’s
expiration date by changing the number after \sphinxcode{-days}.  Remember to
create a new KDC certificate before the old one expires.

The result of this operation will be in two files, kdckey.pem and
kdc.pem.  Both files must be placed in the KDC’s filesystem.
kdckey.pem, which contains the KDC’s private key, must be carefully
protected.

If you examine the KDC certificate with \sphinxcode{openssl x509 -in kdc.pem
-text -noout}, OpenSSL will not know how to display the KDC principal
name in the Subject Alternative Name extension, so it will appear as
\sphinxcode{othername:\textless{}unsupported\textgreater{}}.  This is normal and does not mean
anything is wrong with the KDC certificate.


\subsection{Generating client certificates}
\label{\detokenize{admin/pkinit:generating-client-certificates}}
PKINIT client certificates also must have some unusual certificate
fields.  To generate a client certificate with OpenSSL for a
single-component principal name, you will need an extensions file
(different from the KDC extensions file above) containing:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
[client\PYGZus{}cert]
basicConstraints=CA:FALSE
keyUsage=digitalSignature,keyEncipherment,keyAgreement
extendedKeyUsage=1.3.6.1.5.2.3.4
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
issuerAltName=issuer:copy
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ\PYGZus{}name

[princ\PYGZus{}name]
realm=EXP:0,GeneralString:\PYGZdl{}\PYGZob{}ENV::REALM\PYGZcb{}
principal\PYGZus{}name=EXP:1,SEQUENCE:principal\PYGZus{}seq

[principal\PYGZus{}seq]
name\PYGZus{}type=EXP:0,INTEGER:1
name\PYGZus{}string=EXP:1,SEQUENCE:principals

[principals]
princ1=GeneralString:\PYGZdl{}\PYGZob{}ENV::CLIENT\PYGZcb{}
\end{sphinxVerbatim}

If the above contents are placed in extensions.client, you can
generate and sign a client certificate with the following commands:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{openssl} \PYG{n}{genrsa} \PYG{o}{\PYGZhy{}}\PYG{n}{out} \PYG{n}{clientkey}\PYG{o}{.}\PYG{n}{pem} \PYG{l+m+mi}{2048}
\PYG{n}{openssl} \PYG{n}{req} \PYG{o}{\PYGZhy{}}\PYG{n}{new} \PYG{o}{\PYGZhy{}}\PYG{n}{key} \PYG{n}{clientkey}\PYG{o}{.}\PYG{n}{pem} \PYG{o}{\PYGZhy{}}\PYG{n}{out} \PYG{n}{client}\PYG{o}{.}\PYG{n}{req}
\PYG{n}{env} \PYG{n}{REALM}\PYG{o}{=}\PYG{n}{YOUR\PYGZus{}REALMNAME} \PYG{n}{CLIENT}\PYG{o}{=}\PYG{n}{YOUR\PYGZus{}PRINCNAME} \PYG{n}{openssl} \PYG{n}{x509} \PYGZbs{}
    \PYG{o}{\PYGZhy{}}\PYG{n}{CAkey} \PYG{n}{cakey}\PYG{o}{.}\PYG{n}{pem} \PYG{o}{\PYGZhy{}}\PYG{n}{CA} \PYG{n}{cacert}\PYG{o}{.}\PYG{n}{pem} \PYG{o}{\PYGZhy{}}\PYG{n}{req} \PYG{o}{\PYGZhy{}}\PYG{o+ow}{in} \PYG{n}{client}\PYG{o}{.}\PYG{n}{req} \PYGZbs{}
    \PYG{o}{\PYGZhy{}}\PYG{n}{extensions} \PYG{n}{client\PYGZus{}cert} \PYG{o}{\PYGZhy{}}\PYG{n}{extfile} \PYG{n}{extensions}\PYG{o}{.}\PYG{n}{client} \PYGZbs{}
    \PYG{o}{\PYGZhy{}}\PYG{n}{days} \PYG{l+m+mi}{365} \PYG{o}{\PYGZhy{}}\PYG{n}{out} \PYG{n}{client}\PYG{o}{.}\PYG{n}{pem}
\PYG{n}{rm} \PYG{n}{client}\PYG{o}{.}\PYG{n}{req}
\end{sphinxVerbatim}

Normally, the first two commands should be run on the client host, and
the resulting client.req file transferred to the certificate authority
host for the third command.  As in the previous steps, the second
command will ask for the values of certificate fields, which can be
set to any values.  In the third command, substitute your realm’s name
for YOUR\_REALMNAME and the client’s principal name (without realm) for
YOUR\_PRINCNAME.  You can adjust the certificate’s expiration date by
changing the number after \sphinxcode{-days}.

The result of this operation will be two files, clientkey.pem and
client.pem.  Both files must be present on the client’s host;
clientkey.pem, which contains the client’s private key, must be
protected from access by others.

As in the KDC certificate, OpenSSL will display the client principal
name as \sphinxcode{othername:\textless{}unsupported\textgreater{}} in the Subject Alternative Name
extension of a PKINIT client certificate.

If the client principal name contains more than one component
(e.g. \sphinxcode{host/example.com@REALM}), the \sphinxcode{{[}principals{]}} section of
\sphinxcode{extensions.client} must be altered to contain multiple entries.
(Simply setting \sphinxcode{CLIENT} to \sphinxcode{host/example.com} would generate a
certificate for \sphinxcode{host\textbackslash{}/example.com@REALM} which would not match the
multi-component principal name.)  For a two-component principal, the
section should read:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
[principals]
princ1=GeneralString:\PYGZdl{}\PYGZob{}ENV::CLIENT1\PYGZcb{}
princ2=GeneralString:\PYGZdl{}\PYGZob{}ENV::CLIENT2\PYGZcb{}
\end{sphinxVerbatim}

The environment variables \sphinxcode{CLIENT1} and \sphinxcode{CLIENT2} must then be set
to the first and second components when running \sphinxcode{openssl x509}.


\section{Configuring the KDC}
\label{\detokenize{admin/pkinit:configuring-the-kdc}}
The KDC must have filesystem access to the KDC certificate (kdc.pem)
and the KDC private key (kdckey.pem).  Configure the following
relation in the KDC’s {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} file, either in the
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdcdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}kdcdefaults{]}}}}} section or in a {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} subsection (with
appropriate pathnames):

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{pkinit\PYGZus{}identity} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{lib}\PYG{o}{/}\PYG{n}{krb5kdc}\PYG{o}{/}\PYG{n}{kdc}\PYG{o}{.}\PYG{n}{pem}\PYG{p}{,}\PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{lib}\PYG{o}{/}\PYG{n}{krb5kdc}\PYG{o}{/}\PYG{n}{kdckey}\PYG{o}{.}\PYG{n}{pem}
\end{sphinxVerbatim}

If any clients will authenticate using regular (as opposed to
anonymous) PKINIT, the KDC must also have filesystem access to the CA
certificate (cacert.pem), and the following configuration (with the
appropriate pathname):

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{pkinit\PYGZus{}anchors} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{var}\PYG{o}{/}\PYG{n}{lib}\PYG{o}{/}\PYG{n}{krb5kdc}\PYG{o}{/}\PYG{n}{cacert}\PYG{o}{.}\PYG{n}{pem}
\end{sphinxVerbatim}

Because of the larger size of requests and responses using PKINIT, you
may also need to allow TCP access to the KDC:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kdc\PYGZus{}tcp\PYGZus{}listen} \PYG{o}{=} \PYG{l+m+mi}{88}
\end{sphinxVerbatim}

Restart the {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} daemon to pick up the configuration
changes.

The principal entry for each PKINIT-using client must be configured to
require preauthentication.  Ensure this with the command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin} \PYG{o}{\PYGZhy{}}\PYG{n}{q} \PYG{l+s+s1}{\PYGZsq{}}\PYG{l+s+s1}{modprinc +requires\PYGZus{}preauth YOUR\PYGZus{}PRINCNAME}\PYG{l+s+s1}{\PYGZsq{}}
\end{sphinxVerbatim}

Starting with release 1.12, it is possible to remove the long-term
keys of a principal entry, which can save some space in the database
and help to clarify some PKINIT-related error conditions by not asking
for a password:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin} \PYG{o}{\PYGZhy{}}\PYG{n}{q} \PYG{l+s+s1}{\PYGZsq{}}\PYG{l+s+s1}{purgekeys \PYGZhy{}all YOUR\PYGZus{}PRINCNAME}\PYG{l+s+s1}{\PYGZsq{}}
\end{sphinxVerbatim}

These principal options can also be specified at principal creation
time as follows:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin} \PYG{o}{\PYGZhy{}}\PYG{n}{q} \PYG{l+s+s1}{\PYGZsq{}}\PYG{l+s+s1}{add\PYGZus{}principal +requires\PYGZus{}preauth \PYGZhy{}nokey YOUR\PYGZus{}PRINCNAME}\PYG{l+s+s1}{\PYGZsq{}}
\end{sphinxVerbatim}

By default, the KDC requires PKINIT client certificates to have the
standard Extended Key Usage and Subject Alternative Name attributes
for PKINIT.  Starting in release 1.16, it is possible to authorize
client certificates based on the subject or other criteria instead of
the standard PKINIT Subject Alternative Name, by setting the
\sphinxstylestrong{pkinit\_cert\_match} string attribute on each client principal entry.
For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin} \PYG{n}{set\PYGZus{}string} \PYG{n}{user}\PYG{n+nd}{@REALM} \PYG{n}{pkinit\PYGZus{}cert\PYGZus{}match} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{\PYGZlt{}SUBJECT\PYGZgt{}CN=user@REALM\PYGZdl{}}\PYG{l+s+s2}{\PYGZdq{}}
\end{sphinxVerbatim}

The \sphinxstylestrong{pkinit\_cert\_match} string attribute follows the syntax used by
the {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} \sphinxstylestrong{pkinit\_cert\_match} relation.  To allow the
use of non-PKINIT client certificates, it will also be necessary to
disable key usage checking using the \sphinxstylestrong{pkinit\_eku\_checking} relation;
for example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{kdcdefaults}\PYG{p}{]}
    \PYG{n}{pkinit\PYGZus{}eku\PYGZus{}checking} \PYG{o}{=} \PYG{n}{none}
\end{sphinxVerbatim}


\section{Configuring the clients}
\label{\detokenize{admin/pkinit:configuring-the-clients}}
Client hosts must be configured to trust the issuing authority for the
KDC certificate.  For a newly established certificate authority, the
client host must have filesystem access to the CA certificate
(cacert.pem) and the following relation in {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} in the
appropriate {\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} subsection (with appropriate pathnames):

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{pkinit\PYGZus{}anchors} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{/}\PYG{n}{cacert}\PYG{o}{.}\PYG{n}{pem}
\end{sphinxVerbatim}

If the KDC certificate is a commercially issued server certificate,
the issuing certificate is most likely included in a system directory.
You can specify it by filename as above, or specify the whole
directory like so:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{pkinit\PYGZus{}anchors} \PYG{o}{=} \PYG{n}{DIR}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{ssl}\PYG{o}{/}\PYG{n}{certs}
\end{sphinxVerbatim}

A commercially issued server certificate will usually not have the
standard PKINIT principal name or Extended Key Usage extensions, so
the following additional configuration is required:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{pkinit\PYGZus{}eku\PYGZus{}checking} \PYG{o}{=} \PYG{n}{kpServerAuth}
\PYG{n}{pkinit\PYGZus{}kdc\PYGZus{}hostname} \PYG{o}{=} \PYG{n}{hostname}\PYG{o}{.}\PYG{n}{of}\PYG{o}{.}\PYG{n}{kdc}\PYG{o}{.}\PYG{n}{certificate}
\end{sphinxVerbatim}

Multiple \sphinxstylestrong{pkinit\_kdc\_hostname} relations can be configured to
recognize multiple KDC certificates.  If the KDC is an Active
Directory domain controller, setting \sphinxstylestrong{pkinit\_kdc\_hostname} is
necessary, but it should not be necessary to set
\sphinxstylestrong{pkinit\_eku\_checking}.

To perform regular (as opposed to anonymous) PKINIT authentication, a
client host must have filesystem access to a client certificate
(client.pem), and the corresponding private key (clientkey.pem).
Configure the following relations in the client host’s
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} file in the appropriate {\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} subsection
(with appropriate pathnames):

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{pkinit\PYGZus{}identities} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{/}\PYG{n}{client}\PYG{o}{.}\PYG{n}{pem}\PYG{p}{,}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{/}\PYG{n}{clientkey}\PYG{o}{.}\PYG{n}{pem}
\end{sphinxVerbatim}

If the KDC and client are properly configured, it should now be
possible to run \sphinxcode{kinit username} without entering a password.


\section{Anonymous PKINIT}
\label{\detokenize{admin/pkinit:anonymous-pkinit}}\label{\detokenize{admin/pkinit:id1}}
Anonymity support in Kerberos allows a client to obtain a ticket
without authenticating as any particular principal.  Such a ticket can
be used as a FAST armor ticket, or to securely communicate with an
application server anonymously.

To configure anonymity support, you must generate or otherwise procure
a KDC certificate and configure the KDC host, but you do not need to
generate any client certificates.  On the KDC, you must set the
\sphinxstylestrong{pkinit\_identity} variable to provide the KDC certificate, but do
not need to set the \sphinxstylestrong{pkinit\_anchors} variable or store the issuing
certificate if you won’t have any client certificates to verify.  On
client hosts, you must set the \sphinxstylestrong{pkinit\_anchors} variable (and
possibly \sphinxstylestrong{pkinit\_kdc\_hostname} and \sphinxstylestrong{pkinit\_eku\_checking}) in order
to trust the issuing authority for the KDC certificate, but do not
need to set the \sphinxstylestrong{pkinit\_identities} variable.

Anonymity support is not enabled by default.  To enable it, you must
create the principal \sphinxcode{WELLKNOWN/ANONYMOUS} using the command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin} \PYG{o}{\PYGZhy{}}\PYG{n}{q} \PYG{l+s+s1}{\PYGZsq{}}\PYG{l+s+s1}{addprinc \PYGZhy{}randkey WELLKNOWN/ANONYMOUS}\PYG{l+s+s1}{\PYGZsq{}}
\end{sphinxVerbatim}

Some Kerberos deployments include application servers which lack
proper access control, and grant some level of access to any user who
can authenticate.  In such an environment, enabling anonymity support
on the KDC would present a security issue.  If you need to enable
anonymity support for TGTs (for use as FAST armor tickets) without
enabling anonymous authentication to application servers, you can set
the variable \sphinxstylestrong{restrict\_anonymous\_to\_tgt} to \sphinxcode{true} in the
appropriate {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} subsection of the KDC’s
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} file.

To obtain anonymous credentials on a client, run \sphinxcode{kinit -n}, or
\sphinxcode{kinit -n @REALMNAME} to specify a realm.  The resulting tickets
will have the client name \sphinxcode{WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS}.


\section{Freshness tokens}
\label{\detokenize{admin/pkinit:freshness-tokens}}
Freshness tokens can ensure that the client has recently had access to
its certificate private key.  If freshness tokens are not required by
the KDC, a client program with temporary possession of the private key
can compose requests for future timestamps and use them later.

In release 1.17 and later, freshness tokens are supported by the
client and are sent by the KDC when the client indicates support for
them.  Because not all clients support freshness tokens yet, they are
not required by default.  To check if freshness tokens are supported
by a realm’s clients, look in the KDC logs for the lines:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{PKINIT}\PYG{p}{:} \PYG{n}{freshness} \PYG{n}{token} \PYG{n}{received} \PYG{k+kn}{from} \PYG{o}{\PYGZlt{}}\PYG{n}{client} \PYG{n}{principal}\PYG{o}{\PYGZgt{}}
\PYG{n}{PKINIT}\PYG{p}{:} \PYG{n}{no} \PYG{n}{freshness} \PYG{n}{token} \PYG{n}{received} \PYG{k+kn}{from} \PYG{o}{\PYGZlt{}}\PYG{n}{client} \PYG{n}{principal}\PYG{o}{\PYGZgt{}}
\end{sphinxVerbatim}

To require freshness tokens for all clients in a realm (except for
clients authenticating anonymously), set the
\sphinxstylestrong{pkinit\_require\_freshness} variable to \sphinxcode{true} in the appropriate
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} subsection of the KDC’s {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} file.  To
test that this option is in effect, run \sphinxcode{kinit -X disable\_freshness}
and verify that authentication is unsuccessful.


\chapter{OTP Preauthentication}
\label{\detokenize{admin/otp::doc}}\label{\detokenize{admin/otp:otp-preauthentication}}\label{\detokenize{admin/otp:otp-preauth}}
OTP is a preauthentication mechanism for Kerberos 5 which uses One
Time Passwords (OTP) to authenticate the client to the KDC.  The OTP
is passed to the KDC over an encrypted FAST channel in clear-text.
The KDC uses the password along with per-user configuration to proxy
the request to a third-party RADIUS system.  This enables
out-of-the-box compatibility with a large number of already widely
deployed proprietary systems.

Additionally, our implementation of the OTP system allows for the
passing of RADIUS requests over a UNIX domain stream socket.  This
permits the use of a local companion daemon which can handle the
details of authentication.


\section{Defining token types}
\label{\detokenize{admin/otp:defining-token-types}}
Token types are defined in either {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} or
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} according to the following format:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{otp}\PYG{p}{]}
    \PYG{o}{\PYGZlt{}}\PYG{n}{name}\PYG{o}{\PYGZgt{}} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{server} \PYG{o}{=} \PYG{o}{\PYGZlt{}}\PYG{n}{host}\PYG{p}{:}\PYG{n}{port} \PYG{o+ow}{or} \PYG{n}{filename}\PYG{o}{\PYGZgt{}} \PYG{p}{(}\PYG{n}{default}\PYG{p}{:} \PYG{n}{see} \PYG{n}{below}\PYG{p}{)}
        \PYG{n}{secret} \PYG{o}{=} \PYG{o}{\PYGZlt{}}\PYG{n}{filename}\PYG{o}{\PYGZgt{}}
        \PYG{n}{timeout} \PYG{o}{=} \PYG{o}{\PYGZlt{}}\PYG{n}{integer}\PYG{o}{\PYGZgt{}} \PYG{p}{(}\PYG{n}{default}\PYG{p}{:} \PYG{l+m+mi}{5} \PYG{p}{[}\PYG{n}{seconds}\PYG{p}{]}\PYG{p}{)}
        \PYG{n}{retries} \PYG{o}{=} \PYG{o}{\PYGZlt{}}\PYG{n}{integer}\PYG{o}{\PYGZgt{}} \PYG{p}{(}\PYG{n}{default}\PYG{p}{:} \PYG{l+m+mi}{3}\PYG{p}{)}
        \PYG{n}{strip\PYGZus{}realm} \PYG{o}{=} \PYG{o}{\PYGZlt{}}\PYG{n}{boolean}\PYG{o}{\PYGZgt{}} \PYG{p}{(}\PYG{n}{default}\PYG{p}{:} \PYG{n}{true}\PYG{p}{)}
        \PYG{n}{indicator} \PYG{o}{=} \PYG{o}{\PYGZlt{}}\PYG{n}{string}\PYG{o}{\PYGZgt{}} \PYG{p}{(}\PYG{n}{default}\PYG{p}{:} \PYG{n}{none}\PYG{p}{)}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

If the server field begins with ‘/’, it will be interpreted as a UNIX
socket.  Otherwise, it is assumed to be in the format host:port.  When
a UNIX domain socket is specified, the secret field is optional and an
empty secret is used by default.  If the server field is not
specified, it defaults to {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{RUNSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/\textless{}name\textgreater{}.socket}.

When forwarding the request over RADIUS, by default the principal is
used in the User-Name attribute of the RADIUS packet.  The strip\_realm
parameter controls whether the principal is forwarded with or without
the realm portion.

If an indicator field is present, tickets issued using this token type
will be annotated with the specified authentication indicator (see
{\hyperref[\detokenize{admin/auth_indicator:auth-indicator}]{\sphinxcrossref{\DUrole{std,std-ref}{Authentication indicators}}}}).  This key may be specified multiple times to
add multiple indicators.


\section{The default token type}
\label{\detokenize{admin/otp:the-default-token-type}}
A default token type is used internally when no token type is specified for a
given user.  It is defined as follows:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{otp}\PYG{p}{]}
    \PYG{n}{DEFAULT} \PYG{o}{=} \PYG{p}{\PYGZob{}}
        \PYG{n}{strip\PYGZus{}realm} \PYG{o}{=} \PYG{n}{false}
    \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

The administrator may override the internal \sphinxcode{DEFAULT} token type
simply by defining a configuration with the same name.


\section{Token instance configuration}
\label{\detokenize{admin/otp:token-instance-configuration}}
To enable OTP for a client principal, the administrator must define
the \sphinxstylestrong{otp} string attribute for that principal.  (See
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:set-string}]{\sphinxcrossref{\DUrole{std,std-ref}{set\_string}}}}.)  The \sphinxstylestrong{otp} user string is a JSON string of the
format:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
[\PYGZob{}
    \PYGZdq{}type\PYGZdq{}: \PYG{n+nt}{\PYGZlt{}string}\PYG{n+nt}{\PYGZgt{}},
    \PYGZdq{}username\PYGZdq{}: \PYG{n+nt}{\PYGZlt{}string}\PYG{n+nt}{\PYGZgt{}},
    \PYGZdq{}indicators\PYGZdq{}: [\PYG{n+nt}{\PYGZlt{}string}\PYG{n+nt}{\PYGZgt{}}, ...]
 \PYGZcb{}, ...]
\end{sphinxVerbatim}

This is an array of token objects.  Both fields of token objects are
optional.  The \sphinxstylestrong{type} field names the token type of this token; if
not specified, it defaults to \sphinxcode{DEFAULT}.  The \sphinxstylestrong{username} field
specifies the value to be sent in the User-Name RADIUS attribute.  If
not specified, the principal name is sent, with or without realm as
defined in the token type.  The \sphinxstylestrong{indicators} field specifies a list
of authentication indicators to annotate tickets with, overriding any
indicators specified in the token type.

For ease of configuration, an empty array (\sphinxcode{{[}{]}}) is treated as
equivalent to one DEFAULT token (\sphinxcode{{[}\{\}{]}}).


\section{Other considerations}
\label{\detokenize{admin/otp:other-considerations}}\begin{enumerate}
\item {} 
FAST is required for OTP to work.

\end{enumerate}


\chapter{SPAKE Preauthentication}
\label{\detokenize{admin/spake::doc}}\label{\detokenize{admin/spake:spake-preauthentication}}\label{\detokenize{admin/spake:spake}}
SPAKE preauthentication (added in release 1.17) uses public key
cryptography techniques to protect against {\hyperref[\detokenize{admin/dictionary:dictionary}]{\sphinxcrossref{\DUrole{std,std-ref}{password dictionary
attacks}}}}.  Unlike {\hyperref[\detokenize{admin/pkinit:pkinit}]{\sphinxcrossref{\DUrole{std,std-ref}{PKINIT}}}}, it does not
require any additional infrastructure such as certificates; it simply
needs to be turned on.  Using SPAKE preauthentication may modestly
increase the CPU and network load on the KDC.

SPAKE preauthentication can use one of four elliptic curve groups for
its password-authenticated key exchange.  The recommended group is
\sphinxcode{edwards25519}; three NIST curves (\sphinxcode{P-256}, \sphinxcode{P-384}, and
\sphinxcode{P-521}) are also supported.

By default, SPAKE with the \sphinxcode{edwards25519} group is enabled on
clients, but the KDC does not offer SPAKE by default.  To turn it on,
set the \sphinxstylestrong{spake\_preauth\_groups} variable in {\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}} to a
list of allowed groups.  This variable affects both the client and the
KDC.  Simply setting it to \sphinxcode{edwards25519} is recommended:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{libdefaults}\PYG{p}{]}
    \PYG{n}{spake\PYGZus{}preauth\PYGZus{}groups} \PYG{o}{=} \PYG{n}{edwards25519}
\end{sphinxVerbatim}

Set the \sphinxstylestrong{+requires\_preauth} and \sphinxstylestrong{-allow\_svr} flags on client
principal entries, as you would for any preauthentication mechanism:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{modprinc} \PYG{o}{+}\PYG{n}{requires\PYGZus{}preauth} \PYG{o}{\PYGZhy{}}\PYG{n}{allow\PYGZus{}svr} \PYG{n}{PRINCNAME}
\end{sphinxVerbatim}

Clients which do not implement SPAKE preauthentication will fall back
to encrypted timestamp.

An active attacker can force a fallback to encrypted timestamp by
modifying the initial KDC response, defeating the protection against
dictionary attacks.  To prevent this fallback on clients which do
implement SPAKE preauthentication, set the
\sphinxstylestrong{disable\_encrypted\_timestamp} variable to \sphinxcode{true} in the
{\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} subsection for realms whose KDCs offer SPAKE
preauthentication.

By default, SPAKE preauthentication requires an extra network round
trip to the KDC during initial authentication.  If most of the clients
in a realm support SPAKE, this extra round trip can be eliminated
using an optimistic challenge, by setting the
\sphinxstylestrong{spake\_preauth\_kdc\_challenge} variable in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdcdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}kdcdefaults{]}}}}} to a
single group name:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{kdcdefaults}\PYG{p}{]}
    \PYG{n}{spake\PYGZus{}preauth\PYGZus{}kdc\PYGZus{}challenge} \PYG{o}{=} \PYG{n}{edwards25519}
\end{sphinxVerbatim}

Using optimistic challenge will cause the KDC to do extra work for
initial authentication requests that do not result in SPAKE
preauthentication, but will save work when SPAKE preauthentication is
used.


\chapter{Addressing dictionary attack risks}
\label{\detokenize{admin/dictionary:addressing-dictionary-attack-risks}}\label{\detokenize{admin/dictionary::doc}}\label{\detokenize{admin/dictionary:dictionary}}
Kerberos initial authentication is normally secured using the client
principal’s long-term key, which for users is generally derived from a
password.  Using a pasword-derived long-term key carries the risk of a
dictionary attack, where an attacker tries a sequence of possible
passwords, possibly requiring much less effort than would be required
to try all possible values of the key.  Even if {\hyperref[\detokenize{admin/database:policies}]{\sphinxcrossref{\DUrole{std,std-ref}{password policy
objects}}}} are used to force users not to pick trivial
passwords, dictionary attacks can sometimes be successful against a
significant fraction of the users in a realm.  Dictionary attacks are
not a concern for principals using random keys.

A dictionary attack may be online or offline.  An online dictionary
attack is performed by trying each password in a separate request to
the KDC, and is therefore visible to the KDC and also limited in speed
by the KDC’s processing power and the network capacity between the
client and the KDC.  Online dictionary attacks can be mitigated using
{\hyperref[\detokenize{admin/lockout:lockout}]{\sphinxcrossref{\DUrole{std,std-ref}{account lockout}}}}.  This measure is not totally
satisfactory, as it makes it easy for an attacker to deny access to a
client principal.

An offline dictionary attack is performed by obtaining a ciphertext
generated using the password-derived key, and trying each password
against the ciphertext.  This category of attack is invisible to the
KDC and can be performed much faster than an online attack.  The
attack will generally take much longer with more recent encryption
types (particularly the ones based on AES), because those encryption
types use a much more expensive string-to-key function.  However, the
best defense is to deny the attacker access to a useful ciphertext.
The required defensive measures depend on the attacker’s level of
network access.

An off-path attacker has no access to packets sent between legitimate
users and the KDC.  An off-path attacker could gain access to an
attackable ciphertext either by making an AS request for a client
principal which does not have the \sphinxstylestrong{+requires\_preauth} flag, or by
making a TGS request (after authenticating as a different user) for a
server principal which does not have the \sphinxstylestrong{-allow\_svr} flag.  To
address off-path attackers, a KDC administrator should set those flags
on principals with password-derived keys:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{add\PYGZus{}principal} \PYG{o}{+}\PYG{n}{requires\PYGZus{}preauth} \PYG{o}{\PYGZhy{}}\PYG{n}{allow\PYGZus{}svr} \PYG{n}{princname}
\end{sphinxVerbatim}

An attacker with passive network access (one who can monitor packets
sent between legitimate users and the KDC, but cannot change them or
insert their own packets) can gain access to an attackable ciphertext
by observing an authentication by a user using the most common form of
preauthentication, encrypted timestamp.  Any of the following methods
can prevent dictionary attacks by attackers with passive network
access:
\begin{itemize}
\item {} 
Enabling {\hyperref[\detokenize{admin/spake:spake}]{\sphinxcrossref{\DUrole{std,std-ref}{SPAKE preauthentication}}}} (added in release
1.17) on the KDC, and ensuring that all clients are able to support
it.

\item {} 
Using an {\hyperref[\detokenize{admin/https:https}]{\sphinxcrossref{\DUrole{std,std-ref}{HTTPS proxy}}}} for communication with the KDC,
if the attacker cannot monitor communication between the proxy
server and the KDC.

\item {} 
Using FAST, protecting the initial authentication with either a
random key (such as a host key) or with {\hyperref[\detokenize{admin/pkinit:anonymous-pkinit}]{\sphinxcrossref{\DUrole{std,std-ref}{anonymous PKINIT}}}}.

\end{itemize}

An attacker with active network access (one who can inject or modify
packets sent between legitimate users and the KDC) can try to fool the
client software into sending an attackable ciphertext using an
encryption type and salt string of the attacker’s choosing.  Any of the
following methods can prevent dictionary attacks by active attackers:
\begin{itemize}
\item {} 
Enabling SPAKE preauthentication and setting the
\sphinxstylestrong{disable\_encrypted\_timestamp} variable to \sphinxcode{true} in the
{\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} subsection of the client configuration.

\item {} 
Using an HTTPS proxy as described above, configured in the client’s
krb5.conf realm configuration.  If {\hyperref[\detokenize{admin/realm_config:kdc-discovery}]{\sphinxcrossref{\DUrole{std,std-ref}{KDC discovery}}}} is used to locate a proxy server, an active
attacker may be able to use DNS spoofing to cause the client to use
a different HTTPS server or to not use HTTPS.

\item {} 
Using FAST as described above.

\end{itemize}

If {\hyperref[\detokenize{admin/pkinit:pkinit}]{\sphinxcrossref{\DUrole{std,std-ref}{PKINIT}}}} or {\hyperref[\detokenize{admin/otp:otp-preauth}]{\sphinxcrossref{\DUrole{std,std-ref}{OTP}}}} are used for
initial authentication, the principal’s long-term keys are not used
and dictionary attacks are usually not a concern.


\chapter{Principal names and DNS}
\label{\detokenize{admin/princ_dns:principal-names-and-dns}}\label{\detokenize{admin/princ_dns::doc}}
Kerberos clients can do DNS lookups to canonicalize service principal
names.  This can cause difficulties when setting up Kerberos
application servers, especially when the client’s name for the service
is different from what the service thinks its name is.


\section{Service principal names}
\label{\detokenize{admin/princ_dns:service-principal-names}}
A frequently used kind of principal name is the host-based service
principal name.  This kind of principal name has two components: a
service name and a hostname.  For example, \sphinxcode{imap/imap.example.com}
is the principal name of the “imap” service on the host
“imap.example.com”.  Other possible service names for the first
component include “host” (remote login services such as ssh), “HTTP”,
and “nfs” (Network File System).

Service administrators often publish well-known hostname aliases that
they would prefer users to use instead of the canonical name of the
service host.  This gives service administrators more flexibility in
deploying services.  For example, a shell login server might be named
“long-vanity-hostname.example.com”, but users will naturally prefer to
type something like “login.example.com”.  Hostname aliases also allow
for administrators to set up load balancing for some sorts of services
based on rotating \sphinxcode{CNAME} records in DNS.


\section{Service principal canonicalization}
\label{\detokenize{admin/princ_dns:service-principal-canonicalization}}
In the MIT krb5 client library, canonicalization of host-based service
principals is controlled by the \sphinxstylestrong{dns\_canonicalize\_hostname},
\sphinxstylestrong{rnds}, and \sphinxstylestrong{qualify\_shortname} variables in {\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}}.

If \sphinxstylestrong{dns\_canonicalize\_hostname} is set to \sphinxcode{true} (the default
value), the client performs forward resolution by looking up the IPv4
and/or IPv6 addresses of the hostname using \sphinxcode{getaddrinfo()}.  This
process will typically add a domain suffix to the hostname if needed,
and follow CNAME records in the DNS.  If \sphinxstylestrong{rdns} is also set to
\sphinxcode{true} (the default), the client will then perform a reverse lookup
of the first returned Internet address using \sphinxcode{getnameinfo()},
finding the name associated with the PTR record.

If \sphinxstylestrong{dns\_canonicalize\_hostname} is set to \sphinxcode{false}, the hostname is
not canonicalized using DNS.  If the hostname has only one component
(i.e. it contains no “.” characters), the host’s primary DNS search
domain will be appended, if there is one.  The \sphinxstylestrong{qualify\_shortname}
variable can be used to override or disable this suffix.

If \sphinxstylestrong{dns\_canonicalize\_hostname} is set to \sphinxcode{fallback} (added in
release 1.18), the hostname is initially treated according to the
rules for \sphinxcode{dns\_canonicalize\_hostname=false}.  If a ticket request
fails because the service principal is unknown, the hostname will be
canonicalized according to the rules for
\sphinxcode{dns\_canonicalize\_hostname=true} and the request will be retried.

In all cases, the hostname is converted to lowercase, and any trailing
dot is removed.


\section{Reverse DNS mismatches}
\label{\detokenize{admin/princ_dns:reverse-dns-mismatches}}
Sometimes, an enterprise will have control over its forward DNS but
not its reverse DNS.  The reverse DNS is sometimes under the control
of the Internet service provider of the enterprise, and the enterprise
may not have much influence in setting up reverse DNS records for its
address space.  If there are difficulties with getting forward and
reverse DNS to match, it is best to set \sphinxcode{rdns = false} on client
machines.


\section{Overriding application behavior}
\label{\detokenize{admin/princ_dns:overriding-application-behavior}}
Applications can choose to use a default hostname component in their
service principal name when accepting authentication, which avoids
some sorts of hostname mismatches.  Because not all relevant
applications do this yet, using the {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} setting:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{libdefaults}\PYG{p}{]}
    \PYG{n}{ignore\PYGZus{}acceptor\PYGZus{}hostname} \PYG{o}{=} \PYG{n}{true}
\end{sphinxVerbatim}

will allow the Kerberos library to override the application’s choice
of service principal hostname and will allow a server program to
accept incoming authentications using any key in its keytab that
matches the service name and realm name (if given).  This setting
defaults to “false” and is available in releases krb5-1.10 and later.


\section{Provisioning keytabs}
\label{\detokenize{admin/princ_dns:provisioning-keytabs}}
One service principal entry that should be in the keytab is a
principal whose hostname component is the canonical hostname that
\sphinxcode{getaddrinfo()} reports for all known aliases for the host.  If the
reverse DNS information does not match this canonical hostname, an
additional service principal entry should be in the keytab for this
different hostname.


\section{Specific application advice}
\label{\detokenize{admin/princ_dns:specific-application-advice}}

\subsection{Secure shell (ssh)}
\label{\detokenize{admin/princ_dns:secure-shell-ssh}}
Setting \sphinxcode{GSSAPIStrictAcceptorCheck = no} in the configuration file
of modern versions of the openssh daemon will allow the daemon to try
any key in its keytab when accepting a connection, rather than looking
for the keytab entry that matches the host’s own idea of its name
(typically the name that \sphinxcode{gethostname()} returns).  This requires
krb5-1.10 or later.


\subsection{OpenLDAP (ldapsearch, etc.)}
\label{\detokenize{admin/princ_dns:openldap-ldapsearch-etc}}
OpenLDAP’s SASL implementation performs reverse DNS lookup in order to
canonicalize service principal names, even if \sphinxstylestrong{rdns} is set to
\sphinxcode{false} in the Kerberos configuration.  To disable this behavior,
add \sphinxcode{SASL\_NOCANON on} to \sphinxcode{ldap.conf}, or set the
\sphinxcode{LDAPSASL\_NOCANON} environment variable.


\chapter{Encryption types}
\label{\detokenize{admin/enctypes:enctypes}}\label{\detokenize{admin/enctypes::doc}}\label{\detokenize{admin/enctypes:encryption-types}}
Kerberos can use a variety of cipher algorithms to protect data.  A
Kerberos \sphinxstylestrong{encryption type} (also known as an \sphinxstylestrong{enctype}) is a
specific combination of a cipher algorithm with an integrity algorithm
to provide both confidentiality and integrity to data.


\section{Enctypes in requests}
\label{\detokenize{admin/enctypes:enctypes-in-requests}}
Clients make two types of requests (KDC-REQ) to the KDC: AS-REQs and
TGS-REQs.  The client uses the AS-REQ to obtain initial tickets
(typically a Ticket-Granting Ticket (TGT)), and uses the TGS-REQ to
obtain service tickets.

The KDC uses three different keys when issuing a ticket to a client:
\begin{itemize}
\item {} 
The long-term key of the service: the KDC uses this to encrypt the
actual service ticket.  The KDC only uses the first long-term key in
the most recent kvno for this purpose.

\item {} 
The session key: the KDC randomly chooses this key and places one
copy inside the ticket and the other copy inside the encrypted part
of the reply.

\item {} 
The reply-encrypting key: the KDC uses this to encrypt the reply it
sends to the client.  For AS replies, this is a long-term key of the
client principal.  For TGS replies, this is either the session key of the
authenticating ticket, or a subsession key.

\end{itemize}

Each of these keys is of a specific enctype.

Each request type allows the client to submit a list of enctypes that
it is willing to accept.  For the AS-REQ, this list affects both the
session key selection and the reply-encrypting key selection.  For the
TGS-REQ, this list only affects the session key selection.


\section{Session key selection}
\label{\detokenize{admin/enctypes:session-key-selection}}\label{\detokenize{admin/enctypes:id1}}
The KDC chooses the session key enctype by taking the intersection of
its \sphinxstylestrong{permitted\_enctypes} list, the list of long-term keys for the
most recent kvno of the service, and the client’s requested list of
enctypes.  Starting in krb5-1.21, all services are assumed to support
aes256-cts-hmac-sha1-96; also, des3-cbc-sha1 and arcfour-hmac session
keys will not be issued by default.

Starting in krb5-1.11, it is possible to set a string attribute on a
service principal to control what session key enctypes the KDC may
issue for service tickets for that principal, overriding the service’s
long-term keys and the assumption of aes256-cts-hmac-sha1-96 support.
See {\hyperref[\detokenize{admin/admin_commands/kadmin_local:set-string}]{\sphinxcrossref{\DUrole{std,std-ref}{set\_string}}}} in {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} for details.


\section{Choosing enctypes for a service}
\label{\detokenize{admin/enctypes:choosing-enctypes-for-a-service}}
Generally, a service should have a key of the strongest
enctype that both it and the KDC support.  If the KDC is running a
release earlier than krb5-1.11, it is also useful to generate an
additional key for each enctype that the service can support.  The KDC
will only use the first key in the list of long-term keys for encrypting
the service ticket, but the additional long-term keys indicate the
other enctypes that the service supports.

As noted above, starting with release krb5-1.11, there are additional
configuration settings that control session key enctype selection
independently of the set of long-term keys that the KDC has stored for
a service principal.


\section{Configuration variables}
\label{\detokenize{admin/enctypes:configuration-variables}}
The following \sphinxcode{{[}libdefaults{]}} settings in {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} will
affect how enctypes are chosen.
\begin{description}
\item[{\sphinxstylestrong{allow\_weak\_crypto}}] \leavevmode
defaults to \sphinxstyleemphasis{false} starting with krb5-1.8.  When \sphinxstyleemphasis{false}, removes
weak enctypes from \sphinxstylestrong{permitted\_enctypes},
\sphinxstylestrong{default\_tkt\_enctypes}, and \sphinxstylestrong{default\_tgs\_enctypes}.  Do not
set this to \sphinxstyleemphasis{true} unless the use of weak enctypes is an
acceptable risk for your environment and the weak enctypes are
required for backward compatibility.

\item[{\sphinxstylestrong{allow\_des3}}] \leavevmode
was added in release 1.21 and defaults to \sphinxstyleemphasis{false}.  Unless this
flag is set to \sphinxstyleemphasis{true}, the KDC will not issue tickets with
des3-cbc-sha1 session keys.  In a future release, this flag will
control whether des3-cbc-sha1 is permitted in similar fashion to
weak enctypes.

\item[{\sphinxstylestrong{allow\_rc4}}] \leavevmode
was added in release 1.21 and defaults to \sphinxstyleemphasis{false}.  Unless this
flag is set to \sphinxstyleemphasis{true}, the KDC will not issue tickets with
arcfour-hmac session keys.  In a future release, this flag will
control whether arcfour-hmac is permitted in similar fashion to
weak enctypes.

\item[{\sphinxstylestrong{permitted\_enctypes}}] \leavevmode
controls the set of enctypes that a service will permit for
session keys and for ticket and authenticator encryption.  The KDC
and other programs that access the Kerberos database will ignore
keys of non-permitted enctypes.  Starting in release 1.18, this
setting also acts as the default for \sphinxstylestrong{default\_tkt\_enctypes} and
\sphinxstylestrong{default\_tgs\_enctypes}.

\item[{\sphinxstylestrong{default\_tkt\_enctypes}}] \leavevmode
controls the default set of enctypes that the Kerberos client
library requests when making an AS-REQ.  Do not set this unless
required for specific backward compatibility purposes; stale
values of this setting can prevent clients from taking advantage
of new stronger enctypes when the libraries are upgraded.

\item[{\sphinxstylestrong{default\_tgs\_enctypes}}] \leavevmode
controls the default set of enctypes that the Kerberos client
library requests when making a TGS-REQ.  Do not set this unless
required for specific backward compatibility purposes; stale
values of this setting can prevent clients from taking advantage
of new stronger enctypes when the libraries are upgraded.

\end{description}

The following per-realm setting in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} affects the
generation of long-term keys.
\begin{description}
\item[{\sphinxstylestrong{supported\_enctypes}}] \leavevmode
controls the default set of enctype-salttype pairs that {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}}
will use for generating long-term keys, either randomly or from
passwords

\end{description}


\section{Enctype compatibility}
\label{\detokenize{admin/enctypes:enctype-compatibility}}
See {\hyperref[\detokenize{admin/conf_files/kdc_conf:encryption-types}]{\sphinxcrossref{\DUrole{std,std-ref}{Encryption types}}}} for additional information about enctypes.


\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|T|T|}
\hline
\sphinxstylethead{\sphinxstyletheadfamily 
enctype
\unskip}\relax &\sphinxstylethead{\sphinxstyletheadfamily 
weak?
\unskip}\relax &\sphinxstylethead{\sphinxstyletheadfamily 
krb5
\unskip}\relax &\sphinxstylethead{\sphinxstyletheadfamily 
Windows
\unskip}\relax \\
\hline
des-cbc-crc
&
weak
&
\textless{}1.18
&
\textgreater{}=2000
\\
\hline
des-cbc-md4
&
weak
&
\textless{}1.18
&
?
\\
\hline
des-cbc-md5
&
weak
&
\textless{}1.18
&
\textgreater{}=2000
\\
\hline
des3-cbc-sha1
&
deprecated
&
\textgreater{}=1.1
&
none
\\
\hline
arcfour-hmac
&
deprecated
&
\textgreater{}=1.3
&
\textgreater{}=2000
\\
\hline
arcfour-hmac-exp
&
weak
&
\textgreater{}=1.3
&
\textgreater{}=2000
\\
\hline
aes128-cts-hmac-sha1-96
&&
\textgreater{}=1.3
&
\textgreater{}=Vista
\\
\hline
aes256-cts-hmac-sha1-96
&&
\textgreater{}=1.3
&
\textgreater{}=Vista
\\
\hline
aes128-cts-hmac-sha256-128
&&
\textgreater{}=1.15
&
none
\\
\hline
aes256-cts-hmac-sha384-192
&&
\textgreater{}=1.15
&
none
\\
\hline
camellia128-cts-cmac
&&
\textgreater{}=1.9
&
none
\\
\hline
camellia256-cts-cmac
&&
\textgreater{}=1.9
&
none
\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}

krb5 releases 1.18 and later do not support single-DES.  krb5 releases
1.8 and later disable the single-DES enctypes by default.  Microsoft
Windows releases Windows 7 and later disable single-DES enctypes by
default.

krb5 releases 1.17 and later flag deprecated encryption types
(including \sphinxcode{des3-cbc-sha1} and \sphinxcode{arcfour-hmac}) in KDC logs and
kadmin output.  krb5 release 1.19 issues a warning during initial
authentication if \sphinxcode{des3-cbc-sha1} is used.  Future releases will
disable \sphinxcode{des3-cbc-sha1} by default and eventually remove support for
it.


\section{Migrating away from older encryption types}
\label{\detokenize{admin/enctypes:migrating-away-from-older-encryption-types}}
Administrator intervention may be required to migrate a realm away
from legacy encryption types, especially if the realm was created
using krb5 release 1.2 or earlier.  This migration should be performed
before upgrading to krb5 versions which disable or remove support for
legacy encryption types.

If there is a \sphinxstylestrong{supported\_enctypes} setting in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} on
the KDC, make sure that it does not include weak or deprecated
encryption types.  This will ensure that newly created keys do not use
those encryption types by default.

Check the \sphinxcode{krbtgt/REALM} principal using the {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}
\sphinxstylestrong{getprinc} command.  If it lists a weak or deprecated encryption
type as the first key, it must be migrated using the procedure in
{\hyperref[\detokenize{admin/database:changing-krbtgt-key}]{\sphinxcrossref{\DUrole{std,std-ref}{Changing the krbtgt key}}}}.

Check the \sphinxcode{kadmin/history} principal, which should have only one key
entry.  If it uses a weak or deprecated encryption type, it should be
upgraded following the notes in {\hyperref[\detokenize{admin/database:updating-history-key}]{\sphinxcrossref{\DUrole{std,std-ref}{Updating the history key}}}}.

Check the other kadmin principals: kadmin/changepw, kadmin/admin, and
any kadmin/hostname principals that may exist.  These principals can
be upgraded with \sphinxstylestrong{change\_password -randkey} in kadmin.

Check the \sphinxcode{K/M} entry.  If it uses a weak or deprecated encryption
type, it should be upgraded following the procedure in
{\hyperref[\detokenize{admin/database:updating-master-key}]{\sphinxcrossref{\DUrole{std,std-ref}{Updating the master key}}}}.

User and service principals using legacy encryption types can be
enumerated with the {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} \sphinxstylestrong{tabdump keyinfo} command.

Service principals can be migrated with a keytab rotation on the
service host, which can be accomplished using the {\hyperref[\detokenize{admin/admin_commands/k5srvutil:k5srvutil-1}]{\sphinxcrossref{\DUrole{std,std-ref}{k5srvutil}}}}
\sphinxstylestrong{change} and \sphinxstylestrong{delold} commands.  Allow enough time for existing
tickets to expire between the change and delold operations.

User principals with password-based keys can be migrated with a
password change.  The realm administrator can set a password
expiration date using the {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} \sphinxstylestrong{modify\_principal
-pwexpire} command to force a password change.

If a legacy encryption type has not yet been disabled by default in
the version of krb5 running on the KDC, it can be disabled
administratively with the \sphinxstylestrong{permitted\_enctypes} variable.  For
example, setting \sphinxstylestrong{permitted\_enctypes} to \sphinxcode{DEFAULT -des3 -rc4} will
cause any database keys of the triple-DES and RC4 encryption types to
be ignored.


\chapter{HTTPS proxy configuration}
\label{\detokenize{admin/https:https-proxy-configuration}}\label{\detokenize{admin/https::doc}}\label{\detokenize{admin/https:https}}
In addition to being able to use UDP or TCP to communicate directly
with a KDC as is outlined in RFC4120, and with kpasswd services in a
similar fashion, the client libraries can attempt to use an HTTPS
proxy server to communicate with a KDC or kpasswd service, using the
protocol outlined in {[}MS-KKDCP{]}.

Communicating with a KDC through an HTTPS proxy allows clients to
contact servers when network firewalls might otherwise prevent them
from doing so.  The use of TLS also encrypts all traffic between the
clients and the KDC, preventing observers from conducting password
dictionary attacks or from observing the client and server principals
being authenticated, at additional computational cost to both clients
and servers.

An HTTPS proxy server is provided as a feature in some versions of
Microsoft Windows Server, and a WSGI implementation named \sphinxtitleref{kdcproxy}
is available in the python package index.


\section{Configuring the clients}
\label{\detokenize{admin/https:configuring-the-clients}}
To use an HTTPS proxy, a client host must trust the CA which issued
that proxy’s SSL certificate.  If that CA’s certificate is not in the
system-wide default set of trusted certificates, configure the
following relation in the client host’s {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} file in
the appropriate {\hyperref[\detokenize{admin/conf_files/krb5_conf:realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} subsection:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{http\PYGZus{}anchors} \PYG{o}{=} \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{/}\PYG{n}{cacert}\PYG{o}{.}\PYG{n}{pem}
\end{sphinxVerbatim}

Adjust the pathname to match the path of the file which contains a
copy of the CA’s certificate.  The \sphinxtitleref{http\_anchors} option is documented
more fully in {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}.

Configure the client to access the KDC and kpasswd service by
specifying their locations in its {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} file in the form
of HTTPS URLs for the proxy server:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kdc} \PYG{o}{=} \PYG{n}{https}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{server}\PYG{o}{.}\PYG{n}{fqdn}\PYG{o}{/}\PYG{n}{KdcProxy}
\PYG{n}{kpasswd\PYGZus{}server} \PYG{o}{=} \PYG{n}{https}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{server}\PYG{o}{.}\PYG{n}{fqdn}\PYG{o}{/}\PYG{n}{KdcProxy}
\end{sphinxVerbatim}

If the proxy and client are properly configured, client commands such
as \sphinxcode{kinit}, \sphinxcode{kvno}, and \sphinxcode{kpasswd} should all function normally.


\chapter{Authentication indicators}
\label{\detokenize{admin/auth_indicator:auth-indicator}}\label{\detokenize{admin/auth_indicator:authentication-indicators}}\label{\detokenize{admin/auth_indicator::doc}}
As of release 1.14, the KDC can be configured to annotate tickets if
the client authenticated using a stronger preauthentication mechanism
such as {\hyperref[\detokenize{admin/pkinit:pkinit}]{\sphinxcrossref{\DUrole{std,std-ref}{PKINIT}}}} or {\hyperref[\detokenize{admin/otp:otp-preauth}]{\sphinxcrossref{\DUrole{std,std-ref}{OTP}}}}.  These
annotations are called “authentication indicators.”  Service
principals can be configured to require particular authentication
indicators in order to authenticate to that service.  An
authentication indicator value can be any string chosen by the KDC
administrator; there are no pre-set values.

To use authentication indicators with PKINIT or OTP, first configure
the KDC to include an indicator when that preauthentication mechanism
is used.  For PKINIT, use the \sphinxstylestrong{pkinit\_indicator} variable in
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.  For OTP, use the \sphinxstylestrong{indicator} variable in the
token type definition, or specify the indicators in the \sphinxstylestrong{otp} user
string as described in {\hyperref[\detokenize{admin/otp:otp-preauth}]{\sphinxcrossref{\DUrole{std,std-ref}{OTP Preauthentication}}}}.

To require an indicator to be present in order to authenticate to a
service principal, set the \sphinxstylestrong{require\_auth} string attribute on the
principal to the indicator value to be required.  If you wish to allow
one of several indicators to be accepted, you can specify multiple
indicator values separated by spaces.

For example, a realm could be configured to set the authentication
indicator value “strong” when PKINIT is used to authenticate, using a
setting in the {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-realms}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}realms{]}}}}} subsection:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{pkinit\PYGZus{}indicator} \PYG{o}{=} \PYG{n}{strong}
\end{sphinxVerbatim}

A service principal could be configured to require the “strong”
authentication indicator value:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kadmin setstr host/high.value.server require\PYGZus{}auth strong
Password for user/admin@KRBTEST.COM:
\end{sphinxVerbatim}

A user who authenticates with PKINIT would be able to obtain a ticket
for the service principal:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kinit \PYGZhy{}X X509\PYGZus{}user\PYGZus{}identity=FILE:/my/cert.pem,/my/key.pem user
\PYGZdl{} kvno host/high.value.server
host/high.value.server@KRBTEST.COM: kvno = 1
\end{sphinxVerbatim}

but a user who authenticates with a password would not:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kinit user
Password for user@KRBTEST.COM:
\PYGZdl{} kvno host/high.value.server
kvno: KDC policy rejects request while getting credentials for
  host/high.value.server@KRBTEST.COM
\end{sphinxVerbatim}

GSSAPI server applications can inspect authentication indicators
through the \DUrole{xref,std,std-ref}{auth-indicators} name
attribute.


\chapter{Administration  programs}
\label{\detokenize{admin/admin_commands/index:administration-programs}}\label{\detokenize{admin/admin_commands/index::doc}}

\section{kadmin}
\label{\detokenize{admin/admin_commands/kadmin_local::doc}}\label{\detokenize{admin/admin_commands/kadmin_local:kadmin}}\label{\detokenize{admin/admin_commands/kadmin_local:kadmin-1}}

\subsection{SYNOPSIS}
\label{\detokenize{admin/admin_commands/kadmin_local:synopsis}}\phantomsection\label{\detokenize{admin/admin_commands/kadmin_local:kadmin-synopsis}}
\sphinxstylestrong{kadmin}
{[}\sphinxstylestrong{-O}\textbar{}\sphinxstylestrong{-N}{]}
{[}\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}{]}
{[}\sphinxstylestrong{-p} \sphinxstyleemphasis{principal}{]}
{[}\sphinxstylestrong{-q} \sphinxstyleemphasis{query}{]}
{[}{[}\sphinxstylestrong{-c} \sphinxstyleemphasis{cache\_name}{]}\textbar{}{[}\sphinxstylestrong{-k} {[}\sphinxstylestrong{-t} \sphinxstyleemphasis{keytab}{]}{]}\textbar{}\sphinxstylestrong{-n}{]}
{[}\sphinxstylestrong{-w} \sphinxstyleemphasis{password}{]}
{[}\sphinxstylestrong{-s} \sphinxstyleemphasis{admin\_server}{[}:\sphinxstyleemphasis{port}{]}{]}
{[}command args…{]}

\sphinxstylestrong{kadmin.local}
{[}\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}{]}
{[}\sphinxstylestrong{-p} \sphinxstyleemphasis{principal}{]}
{[}\sphinxstylestrong{-q} \sphinxstyleemphasis{query}{]}
{[}\sphinxstylestrong{-d} \sphinxstyleemphasis{dbname}{]}
{[}\sphinxstylestrong{-e} \sphinxstyleemphasis{enc}:\sphinxstyleemphasis{salt} …{]}
{[}\sphinxstylestrong{-m}{]}
{[}\sphinxstylestrong{-x} \sphinxstyleemphasis{db\_args}{]}
{[}command args…{]}


\subsection{DESCRIPTION}
\label{\detokenize{admin/admin_commands/kadmin_local:description}}
kadmin and kadmin.local are command-line interfaces to the Kerberos V5
administration system.  They provide nearly identical functionalities;
the difference is that kadmin.local directly accesses the KDC
database, while kadmin performs operations using {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}}.
Except as explicitly noted otherwise, this man page will use “kadmin”
to refer to both versions.  kadmin provides for the maintenance of
Kerberos principals, password policies, and service key tables
(keytabs).

The remote kadmin client uses Kerberos to authenticate to kadmind
using the service principal \sphinxcode{kadmin/admin} or \sphinxcode{kadmin/ADMINHOST}
(where \sphinxstyleemphasis{ADMINHOST} is the fully-qualified hostname of the admin
server).  If the credentials cache contains a ticket for one of these
principals, and the \sphinxstylestrong{-c} credentials\_cache option is specified, that
ticket is used to authenticate to kadmind.  Otherwise, the \sphinxstylestrong{-p} and
\sphinxstylestrong{-k} options are used to specify the client Kerberos principal name
used to authenticate.  Once kadmin has determined the principal name,
it requests a service ticket from the KDC, and uses that service
ticket to authenticate to kadmind.

Since kadmin.local directly accesses the KDC database, it usually must
be run directly on the primary KDC with sufficient permissions to read
the KDC database.  If the KDC database uses the LDAP database module,
kadmin.local can be run on any host which can access the LDAP server.


\subsection{OPTIONS}
\label{\detokenize{admin/admin_commands/kadmin_local:options}}\phantomsection\label{\detokenize{admin/admin_commands/kadmin_local:kadmin-options}}\begin{description}
\item[{\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}}] \leavevmode
Use \sphinxstyleemphasis{realm} as the default database realm.

\item[{\sphinxstylestrong{-p} \sphinxstyleemphasis{principal}}] \leavevmode
Use \sphinxstyleemphasis{principal} to authenticate.  Otherwise, kadmin will append
\sphinxcode{/admin} to the primary principal name of the default ccache,
the value of the \sphinxstylestrong{USER} environment variable, or the username as
obtained with getpwuid, in order of preference.

\item[{\sphinxstylestrong{-k}}] \leavevmode
Use a keytab to decrypt the KDC response instead of prompting for
a password.  In this case, the default principal will be
\sphinxcode{host/hostname}.  If there is no keytab specified with the
\sphinxstylestrong{-t} option, then the default keytab will be used.

\item[{\sphinxstylestrong{-t} \sphinxstyleemphasis{keytab}}] \leavevmode
Use \sphinxstyleemphasis{keytab} to decrypt the KDC response.  This can only be used
with the \sphinxstylestrong{-k} option.

\item[{\sphinxstylestrong{-n}}] \leavevmode
Requests anonymous processing.  Two types of anonymous principals
are supported.  For fully anonymous Kerberos, configure PKINIT on
the KDC and configure \sphinxstylestrong{pkinit\_anchors} in the client’s
{\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}.  Then use the \sphinxstylestrong{-n} option with a principal
of the form \sphinxcode{@REALM} (an empty principal name followed by the
at-sign and a realm name).  If permitted by the KDC, an anonymous
ticket will be returned.  A second form of anonymous tickets is
supported; these realm-exposed tickets hide the identity of the
client but not the client’s realm.  For this mode, use \sphinxcode{kinit
-n} with a normal principal name.  If supported by the KDC, the
principal (but not realm) will be replaced by the anonymous
principal.  As of release 1.8, the MIT Kerberos KDC only supports
fully anonymous operation.

\item[{\sphinxstylestrong{-c} \sphinxstyleemphasis{credentials\_cache}}] \leavevmode
Use \sphinxstyleemphasis{credentials\_cache} as the credentials cache.  The cache
should contain a service ticket for the \sphinxcode{kadmin/admin} or
\sphinxcode{kadmin/ADMINHOST} (where \sphinxstyleemphasis{ADMINHOST} is the fully-qualified
hostname of the admin server) service; it can be acquired with the
\DUrole{xref,std,std-ref}{kinit(1)} program.  If this option is not specified, kadmin
requests a new service ticket from the KDC, and stores it in its
own temporary ccache.

\item[{\sphinxstylestrong{-w} \sphinxstyleemphasis{password}}] \leavevmode
Use \sphinxstyleemphasis{password} instead of prompting for one.  Use this option with
care, as it may expose the password to other users on the system
via the process list.

\item[{\sphinxstylestrong{-q} \sphinxstyleemphasis{query}}] \leavevmode
Perform the specified query and then exit.

\item[{\sphinxstylestrong{-d} \sphinxstyleemphasis{dbname}}] \leavevmode
Specifies the name of the KDC database.  This option does not
apply to the LDAP database module.

\item[{\sphinxstylestrong{-s} \sphinxstyleemphasis{admin\_server}{[}:\sphinxstyleemphasis{port}{]}}] \leavevmode
Specifies the admin server which kadmin should contact.

\item[{\sphinxstylestrong{-m}}] \leavevmode
If using kadmin.local, prompt for the database master password
instead of reading it from a stash file.

\item[{\sphinxstylestrong{-e} “\sphinxstyleemphasis{enc}:\sphinxstyleemphasis{salt} …”}] \leavevmode
Sets the keysalt list to be used for any new keys created.  See
{\hyperref[\detokenize{admin/conf_files/kdc_conf:keysalt-lists}]{\sphinxcrossref{\DUrole{std,std-ref}{Keysalt lists}}}} in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} for a list of possible
values.

\item[{\sphinxstylestrong{-O}}] \leavevmode
Force use of old AUTH\_GSSAPI authentication flavor.

\item[{\sphinxstylestrong{-N}}] \leavevmode
Prevent fallback to AUTH\_GSSAPI authentication flavor.

\item[{\sphinxstylestrong{-x} \sphinxstyleemphasis{db\_args}}] \leavevmode
Specifies the database specific arguments.  See the next section
for supported options.

\end{description}

Starting with release 1.14, if any command-line arguments remain after
the options, they will be treated as a single query to be executed.
This mode of operation is intended for scripts and behaves differently
from the interactive mode in several respects:
\begin{itemize}
\item {} 
Query arguments are split by the shell, not by kadmin.

\item {} 
Informational and warning messages are suppressed.  Error messages
and query output (e.g. for \sphinxstylestrong{get\_principal}) will still be
displayed.

\item {} 
Confirmation prompts are disabled (as if \sphinxstylestrong{-force} was given).
Password prompts will still be issued as required.

\item {} 
The exit status will be non-zero if the query fails.

\end{itemize}

The \sphinxstylestrong{-q} option does not carry these behavior differences; the query
will be processed as if it was entered interactively.  The \sphinxstylestrong{-q}
option cannot be used in combination with a query in the remaining
arguments.


\subsection{DATABASE OPTIONS}
\label{\detokenize{admin/admin_commands/kadmin_local:database-options}}\label{\detokenize{admin/admin_commands/kadmin_local:dboptions}}
Database options can be used to override database-specific defaults.
Supported options for the DB2 module are:
\begin{quote}
\begin{description}
\item[{\sphinxstylestrong{-x dbname=}*filename*}] \leavevmode
Specifies the base filename of the DB2 database.

\item[{\sphinxstylestrong{-x lockiter}}] \leavevmode
Make iteration operations hold the lock for the duration of
the entire operation, rather than temporarily releasing the
lock while handling each principal.  This is the default
behavior, but this option exists to allow command line
override of a {[}dbmodules{]} setting.  First introduced in
release 1.13.

\item[{\sphinxstylestrong{-x unlockiter}}] \leavevmode
Make iteration operations unlock the database for each
principal, instead of holding the lock for the duration of the
entire operation.  First introduced in release 1.13.

\end{description}
\end{quote}

Supported options for the LDAP module are:
\begin{quote}
\begin{description}
\item[{\sphinxstylestrong{-x host=}\sphinxstyleemphasis{ldapuri}}] \leavevmode
Specifies the LDAP server to connect to by a LDAP URI.

\item[{\sphinxstylestrong{-x binddn=}\sphinxstyleemphasis{bind\_dn}}] \leavevmode
Specifies the DN used to bind to the LDAP server.

\item[{\sphinxstylestrong{-x bindpwd=}\sphinxstyleemphasis{password}}] \leavevmode
Specifies the password or SASL secret used to bind to the LDAP
server.  Using this option may expose the password to other
users on the system via the process list; to avoid this,
instead stash the password using the \sphinxstylestrong{stashsrvpw} command of
{\hyperref[\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_ldap\_util}}}}.

\item[{\sphinxstylestrong{-x sasl\_mech=}\sphinxstyleemphasis{mechanism}}] \leavevmode
Specifies the SASL mechanism used to bind to the LDAP server.
The bind DN is ignored if a SASL mechanism is used.  New in
release 1.13.

\item[{\sphinxstylestrong{-x sasl\_authcid=}\sphinxstyleemphasis{name}}] \leavevmode
Specifies the authentication name used when binding to the
LDAP server with a SASL mechanism, if the mechanism requires
one.  New in release 1.13.

\item[{\sphinxstylestrong{-x sasl\_authzid=}\sphinxstyleemphasis{name}}] \leavevmode
Specifies the authorization name used when binding to the LDAP
server with a SASL mechanism.  New in release 1.13.

\item[{\sphinxstylestrong{-x sasl\_realm=}\sphinxstyleemphasis{realm}}] \leavevmode
Specifies the realm used when binding to the LDAP server with
a SASL mechanism, if the mechanism uses one.  New in release
1.13.

\item[{\sphinxstylestrong{-x debug=}\sphinxstyleemphasis{level}}] \leavevmode
sets the OpenLDAP client library debug level.  \sphinxstyleemphasis{level} is an
integer to be interpreted by the library.  Debugging messages
are printed to standard error.  New in release 1.12.

\end{description}
\end{quote}


\subsection{COMMANDS}
\label{\detokenize{admin/admin_commands/kadmin_local:commands}}
When using the remote client, available commands may be restricted
according to the privileges specified in the {\hyperref[\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5.acl}}}} file
on the admin server.


\subsubsection{add\_principal}
\label{\detokenize{admin/admin_commands/kadmin_local:add-principal}}\label{\detokenize{admin/admin_commands/kadmin_local:id1}}\begin{quote}

\sphinxstylestrong{add\_principal} {[}\sphinxstyleemphasis{options}{]} \sphinxstyleemphasis{newprinc}
\end{quote}

Creates the principal \sphinxstyleemphasis{newprinc}, prompting twice for a password.  If
no password policy is specified with the \sphinxstylestrong{-policy} option, and the
policy named \sphinxcode{default} is assigned to the principal if it exists.
However, creating a policy named \sphinxcode{default} will not automatically
assign this policy to previously existing principals.  This policy
assignment can be suppressed with the \sphinxstylestrong{-clearpolicy} option.

This command requires the \sphinxstylestrong{add} privilege.

Aliases: \sphinxstylestrong{addprinc}, \sphinxstylestrong{ank}

Options:
\begin{description}
\item[{\sphinxstylestrong{-expire} \sphinxstyleemphasis{expdate}}] \leavevmode
(\DUrole{xref,std,std-ref}{getdate} string) The expiration date of the principal.

\item[{\sphinxstylestrong{-pwexpire} \sphinxstyleemphasis{pwexpdate}}] \leavevmode
(\DUrole{xref,std,std-ref}{getdate} string) The password expiration date.

\item[{\sphinxstylestrong{-maxlife} \sphinxstyleemphasis{maxlife}}] \leavevmode
(\DUrole{xref,std,std-ref}{duration} or \DUrole{xref,std,std-ref}{getdate} string) The maximum ticket life
for the principal.

\item[{\sphinxstylestrong{-maxrenewlife} \sphinxstyleemphasis{maxrenewlife}}] \leavevmode
(\DUrole{xref,std,std-ref}{duration} or \DUrole{xref,std,std-ref}{getdate} string) The maximum renewable
life of tickets for the principal.

\item[{\sphinxstylestrong{-kvno} \sphinxstyleemphasis{kvno}}] \leavevmode
The initial key version number.

\item[{\sphinxstylestrong{-policy} \sphinxstyleemphasis{policy}}] \leavevmode
The password policy used by this principal.  If not specified, the
policy \sphinxcode{default} is used if it exists (unless \sphinxstylestrong{-clearpolicy}
is specified).

\item[{\sphinxstylestrong{-clearpolicy}}] \leavevmode
Prevents any policy from being assigned when \sphinxstylestrong{-policy} is not
specified.

\item[{\{-\textbar{}+\}\sphinxstylestrong{allow\_postdated}}] \leavevmode
\sphinxstylestrong{-allow\_postdated} prohibits this principal from obtaining
postdated tickets.  \sphinxstylestrong{+allow\_postdated} clears this flag.

\item[{\{-\textbar{}+\}\sphinxstylestrong{allow\_forwardable}}] \leavevmode
\sphinxstylestrong{-allow\_forwardable} prohibits this principal from obtaining
forwardable tickets.  \sphinxstylestrong{+allow\_forwardable} clears this flag.

\item[{\{-\textbar{}+\}\sphinxstylestrong{allow\_renewable}}] \leavevmode
\sphinxstylestrong{-allow\_renewable} prohibits this principal from obtaining
renewable tickets.  \sphinxstylestrong{+allow\_renewable} clears this flag.

\item[{\{-\textbar{}+\}\sphinxstylestrong{allow\_proxiable}}] \leavevmode
\sphinxstylestrong{-allow\_proxiable} prohibits this principal from obtaining
proxiable tickets.  \sphinxstylestrong{+allow\_proxiable} clears this flag.

\item[{\{-\textbar{}+\}\sphinxstylestrong{allow\_dup\_skey}}] \leavevmode
\sphinxstylestrong{-allow\_dup\_skey} disables user-to-user authentication for this
principal by prohibiting others from obtaining a service ticket
encrypted in this principal’s TGT session key.
\sphinxstylestrong{+allow\_dup\_skey} clears this flag.

\item[{\{-\textbar{}+\}\sphinxstylestrong{requires\_preauth}}] \leavevmode
\sphinxstylestrong{+requires\_preauth} requires this principal to preauthenticate
before being allowed to kinit.  \sphinxstylestrong{-requires\_preauth} clears this
flag.  When \sphinxstylestrong{+requires\_preauth} is set on a service principal,
the KDC will only issue service tickets for that service principal
if the client’s initial authentication was performed using
preauthentication.

\item[{\{-\textbar{}+\}\sphinxstylestrong{requires\_hwauth}}] \leavevmode
\sphinxstylestrong{+requires\_hwauth} requires this principal to preauthenticate
using a hardware device before being allowed to kinit.
\sphinxstylestrong{-requires\_hwauth} clears this flag.  When \sphinxstylestrong{+requires\_hwauth} is
set on a service principal, the KDC will only issue service tickets
for that service principal if the client’s initial authentication was
performed using a hardware device to preauthenticate.

\item[{\{-\textbar{}+\}\sphinxstylestrong{ok\_as\_delegate}}] \leavevmode
\sphinxstylestrong{+ok\_as\_delegate} sets the \sphinxstylestrong{okay as delegate} flag on tickets
issued with this principal as the service.  Clients may use this
flag as a hint that credentials should be delegated when
authenticating to the service.  \sphinxstylestrong{-ok\_as\_delegate} clears this
flag.

\item[{\{-\textbar{}+\}\sphinxstylestrong{allow\_svr}}] \leavevmode
\sphinxstylestrong{-allow\_svr} prohibits the issuance of service tickets for this
principal.  In release 1.17 and later, user-to-user service
tickets are still allowed unless the \sphinxstylestrong{-allow\_dup\_skey} flag is
also set.  \sphinxstylestrong{+allow\_svr} clears this flag.

\item[{\{-\textbar{}+\}\sphinxstylestrong{allow\_tgs\_req}}] \leavevmode
\sphinxstylestrong{-allow\_tgs\_req} specifies that a Ticket-Granting Service (TGS)
request for a service ticket for this principal is not permitted.
\sphinxstylestrong{+allow\_tgs\_req} clears this flag.

\item[{\{-\textbar{}+\}\sphinxstylestrong{allow\_tix}}] \leavevmode
\sphinxstylestrong{-allow\_tix} forbids the issuance of any tickets for this
principal.  \sphinxstylestrong{+allow\_tix} clears this flag.

\item[{\{-\textbar{}+\}\sphinxstylestrong{needchange}}] \leavevmode
\sphinxstylestrong{+needchange} forces a password change on the next initial
authentication to this principal.  \sphinxstylestrong{-needchange} clears this
flag.

\item[{\{-\textbar{}+\}\sphinxstylestrong{password\_changing\_service}}] \leavevmode
\sphinxstylestrong{+password\_changing\_service} marks this principal as a password
change service principal.

\item[{\{-\textbar{}+\}\sphinxstylestrong{ok\_to\_auth\_as\_delegate}}] \leavevmode
\sphinxstylestrong{+ok\_to\_auth\_as\_delegate} allows this principal to acquire
forwardable tickets to itself from arbitrary users, for use with
constrained delegation.

\item[{\{-\textbar{}+\}\sphinxstylestrong{no\_auth\_data\_required}}] \leavevmode
\sphinxstylestrong{+no\_auth\_data\_required} prevents PAC or AD-SIGNEDPATH data from
being added to service tickets for the principal.

\item[{\{-\textbar{}+\}\sphinxstylestrong{lockdown\_keys}}] \leavevmode
\sphinxstylestrong{+lockdown\_keys} prevents keys for this principal from leaving
the KDC via kadmind.  The chpass and extract operations are denied
for a principal with this attribute.  The chrand operation is
allowed, but will not return the new keys.  The delete and rename
operations are also denied if this attribute is set, in order to
prevent a malicious administrator from replacing principals like
krbtgt/* or kadmin/* with new principals without the attribute.
This attribute can be set via the network protocol, but can only
be removed using kadmin.local.

\item[{\sphinxstylestrong{-randkey}}] \leavevmode
Sets the key of the principal to a random value.

\item[{\sphinxstylestrong{-nokey}}] \leavevmode
Causes the principal to be created with no key.  New in release
1.12.

\item[{\sphinxstylestrong{-pw} \sphinxstyleemphasis{password}}] \leavevmode
Sets the password of the principal to the specified string and
does not prompt for a password.  Note: using this option in a
shell script may expose the password to other users on the system
via the process list.

\item[{\sphinxstylestrong{-e} \sphinxstyleemphasis{enc}:\sphinxstyleemphasis{salt},…}] \leavevmode
Uses the specified keysalt list for setting the keys of the
principal.  See {\hyperref[\detokenize{admin/conf_files/kdc_conf:keysalt-lists}]{\sphinxcrossref{\DUrole{std,std-ref}{Keysalt lists}}}} in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} for a
list of possible values.

\item[{\sphinxstylestrong{-x} \sphinxstyleemphasis{db\_princ\_args}}] \leavevmode
Indicates database-specific options.  The options for the LDAP
database module are:
\begin{description}
\item[{\sphinxstylestrong{-x dn=}\sphinxstyleemphasis{dn}}] \leavevmode
Specifies the LDAP object that will contain the Kerberos
principal being created.

\item[{\sphinxstylestrong{-x linkdn=}\sphinxstyleemphasis{dn}}] \leavevmode
Specifies the LDAP object to which the newly created Kerberos
principal object will point.

\item[{\sphinxstylestrong{-x containerdn=}\sphinxstyleemphasis{container\_dn}}] \leavevmode
Specifies the container object under which the Kerberos
principal is to be created.

\item[{\sphinxstylestrong{-x tktpolicy=}\sphinxstyleemphasis{policy}}] \leavevmode
Associates a ticket policy to the Kerberos principal.

\end{description}

\begin{sphinxadmonition}{note}{Note:}\begin{itemize}
\item {} 
The \sphinxstylestrong{containerdn} and \sphinxstylestrong{linkdn} options cannot be
specified with the \sphinxstylestrong{dn} option.

\item {} 
If the \sphinxstyleemphasis{dn} or \sphinxstyleemphasis{containerdn} options are not specified while
adding the principal, the principals are created under the
principal container configured in the realm or the realm
container.

\item {} 
\sphinxstyleemphasis{dn} and \sphinxstyleemphasis{containerdn} should be within the subtrees or
principal container configured in the realm.

\end{itemize}
\end{sphinxadmonition}

\end{description}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{addprinc} \PYG{n}{jennifer}
\PYG{n}{No} \PYG{n}{policy} \PYG{n}{specified} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{jennifer@ATHENA.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{;}
\PYG{n}{defaulting} \PYG{n}{to} \PYG{n}{no} \PYG{n}{policy}\PYG{o}{.}
\PYG{n}{Enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{jennifer}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{p}{:}
\PYG{n}{Re}\PYG{o}{\PYGZhy{}}\PYG{n}{enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{jennifer}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{p}{:}
\PYG{n}{Principal} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{jennifer@ATHENA.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{created}\PYG{o}{.}
\PYG{n}{kadmin}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{modify\_principal}
\label{\detokenize{admin/admin_commands/kadmin_local:id2}}\label{\detokenize{admin/admin_commands/kadmin_local:modify-principal}}\begin{quote}

\sphinxstylestrong{modify\_principal} {[}\sphinxstyleemphasis{options}{]} \sphinxstyleemphasis{principal}
\end{quote}

Modifies the specified principal, changing the fields as specified.
The options to \sphinxstylestrong{add\_principal} also apply to this command, except
for the \sphinxstylestrong{-randkey}, \sphinxstylestrong{-pw}, and \sphinxstylestrong{-e} options.  In addition, the
option \sphinxstylestrong{-clearpolicy} will clear the current policy of a principal.

This command requires the \sphinxstyleemphasis{modify} privilege.

Alias: \sphinxstylestrong{modprinc}

Options (in addition to the \sphinxstylestrong{addprinc} options):
\begin{description}
\item[{\sphinxstylestrong{-unlock}}] \leavevmode
Unlocks a locked principal (one which has received too many failed
authentication attempts without enough time between them according
to its password policy) so that it can successfully authenticate.

\end{description}


\subsubsection{rename\_principal}
\label{\detokenize{admin/admin_commands/kadmin_local:rename-principal}}\label{\detokenize{admin/admin_commands/kadmin_local:id3}}\begin{quote}

\sphinxstylestrong{rename\_principal} {[}\sphinxstylestrong{-force}{]} \sphinxstyleemphasis{old\_principal} \sphinxstyleemphasis{new\_principal}
\end{quote}

Renames the specified \sphinxstyleemphasis{old\_principal} to \sphinxstyleemphasis{new\_principal}.  This
command prompts for confirmation, unless the \sphinxstylestrong{-force} option is
given.

This command requires the \sphinxstylestrong{add} and \sphinxstylestrong{delete} privileges.

Alias: \sphinxstylestrong{renprinc}


\subsubsection{delete\_principal}
\label{\detokenize{admin/admin_commands/kadmin_local:id4}}\label{\detokenize{admin/admin_commands/kadmin_local:delete-principal}}\begin{quote}

\sphinxstylestrong{delete\_principal} {[}\sphinxstylestrong{-force}{]} \sphinxstyleemphasis{principal}
\end{quote}

Deletes the specified \sphinxstyleemphasis{principal} from the database.  This command
prompts for deletion, unless the \sphinxstylestrong{-force} option is given.

This command requires the \sphinxstylestrong{delete} privilege.

Alias: \sphinxstylestrong{delprinc}


\subsubsection{change\_password}
\label{\detokenize{admin/admin_commands/kadmin_local:id5}}\label{\detokenize{admin/admin_commands/kadmin_local:change-password}}\begin{quote}

\sphinxstylestrong{change\_password} {[}\sphinxstyleemphasis{options}{]} \sphinxstyleemphasis{principal}
\end{quote}

Changes the password of \sphinxstyleemphasis{principal}.  Prompts for a new password if
neither \sphinxstylestrong{-randkey} or \sphinxstylestrong{-pw} is specified.

This command requires the \sphinxstylestrong{changepw} privilege, or that the
principal running the program is the same as the principal being
changed.

Alias: \sphinxstylestrong{cpw}

The following options are available:
\begin{description}
\item[{\sphinxstylestrong{-randkey}}] \leavevmode
Sets the key of the principal to a random value.

\item[{\sphinxstylestrong{-pw} \sphinxstyleemphasis{password}}] \leavevmode
Set the password to the specified string.  Using this option in a
script may expose the password to other users on the system via
the process list.

\item[{\sphinxstylestrong{-e} \sphinxstyleemphasis{enc}:\sphinxstyleemphasis{salt},…}] \leavevmode
Uses the specified keysalt list for setting the keys of the
principal.  See {\hyperref[\detokenize{admin/conf_files/kdc_conf:keysalt-lists}]{\sphinxcrossref{\DUrole{std,std-ref}{Keysalt lists}}}} in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} for a
list of possible values.

\item[{\sphinxstylestrong{-keepold}}] \leavevmode
Keeps the existing keys in the database.  This flag is usually not
necessary except perhaps for \sphinxcode{krbtgt} principals.

\end{description}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{cpw} \PYG{n}{systest}
\PYG{n}{Enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{systest}\PYG{n+nd}{@BLEEP}\PYG{o}{.}\PYG{n}{COM}\PYG{p}{:}
\PYG{n}{Re}\PYG{o}{\PYGZhy{}}\PYG{n}{enter} \PYG{n}{password} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{systest}\PYG{n+nd}{@BLEEP}\PYG{o}{.}\PYG{n}{COM}\PYG{p}{:}
\PYG{n}{Password} \PYG{k}{for} \PYG{n}{systest}\PYG{n+nd}{@BLEEP}\PYG{o}{.}\PYG{n}{COM} \PYG{n}{changed}\PYG{o}{.}
\PYG{n}{kadmin}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{purgekeys}
\label{\detokenize{admin/admin_commands/kadmin_local:id6}}\label{\detokenize{admin/admin_commands/kadmin_local:purgekeys}}\begin{quote}

\sphinxstylestrong{purgekeys} {[}\sphinxstylestrong{-all}\textbar{}\sphinxstylestrong{-keepkvno} \sphinxstyleemphasis{oldest\_kvno\_to\_keep}{]} \sphinxstyleemphasis{principal}
\end{quote}

Purges previously retained old keys (e.g., from \sphinxstylestrong{change\_password
-keepold}) from \sphinxstyleemphasis{principal}.  If \sphinxstylestrong{-keepkvno} is specified, then
only purges keys with kvnos lower than \sphinxstyleemphasis{oldest\_kvno\_to\_keep}.  If
\sphinxstylestrong{-all} is specified, then all keys are purged.  The \sphinxstylestrong{-all} option
is new in release 1.12.

This command requires the \sphinxstylestrong{modify} privilege.


\subsubsection{get\_principal}
\label{\detokenize{admin/admin_commands/kadmin_local:get-principal}}\label{\detokenize{admin/admin_commands/kadmin_local:id7}}\begin{quote}

\sphinxstylestrong{get\_principal} {[}\sphinxstylestrong{-terse}{]} \sphinxstyleemphasis{principal}
\end{quote}

Gets the attributes of principal.  With the \sphinxstylestrong{-terse} option, outputs
fields as quoted tab-separated strings.

This command requires the \sphinxstylestrong{inquire} privilege, or that the principal
running the the program to be the same as the one being listed.

Alias: \sphinxstylestrong{getprinc}

Examples:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{getprinc} \PYG{n}{tlyu}\PYG{o}{/}\PYG{n}{admin}
\PYG{n}{Principal}\PYG{p}{:} \PYG{n}{tlyu}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@BLEEP}\PYG{o}{.}\PYG{n}{COM}
\PYG{n}{Expiration} \PYG{n}{date}\PYG{p}{:} \PYG{p}{[}\PYG{n}{never}\PYG{p}{]}
\PYG{n}{Last} \PYG{n}{password} \PYG{n}{change}\PYG{p}{:} \PYG{n}{Mon} \PYG{n}{Aug} \PYG{l+m+mi}{12} \PYG{l+m+mi}{14}\PYG{p}{:}\PYG{l+m+mi}{16}\PYG{p}{:}\PYG{l+m+mi}{47} \PYG{n}{EDT} \PYG{l+m+mi}{1996}
\PYG{n}{Password} \PYG{n}{expiration} \PYG{n}{date}\PYG{p}{:} \PYG{p}{[}\PYG{n}{never}\PYG{p}{]}
\PYG{n}{Maximum} \PYG{n}{ticket} \PYG{n}{life}\PYG{p}{:} \PYG{l+m+mi}{0} \PYG{n}{days} \PYG{l+m+mi}{10}\PYG{p}{:}\PYG{l+m+mi}{00}\PYG{p}{:}\PYG{l+m+mi}{00}
\PYG{n}{Maximum} \PYG{n}{renewable} \PYG{n}{life}\PYG{p}{:} \PYG{l+m+mi}{7} \PYG{n}{days} \PYG{l+m+mi}{00}\PYG{p}{:}\PYG{l+m+mi}{00}\PYG{p}{:}\PYG{l+m+mi}{00}
\PYG{n}{Last} \PYG{n}{modified}\PYG{p}{:} \PYG{n}{Mon} \PYG{n}{Aug} \PYG{l+m+mi}{12} \PYG{l+m+mi}{14}\PYG{p}{:}\PYG{l+m+mi}{16}\PYG{p}{:}\PYG{l+m+mi}{47} \PYG{n}{EDT} \PYG{l+m+mi}{1996} \PYG{p}{(}\PYG{n}{bjaspan}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@BLEEP}\PYG{o}{.}\PYG{n}{COM}\PYG{p}{)}
\PYG{n}{Last} \PYG{n}{successful} \PYG{n}{authentication}\PYG{p}{:} \PYG{p}{[}\PYG{n}{never}\PYG{p}{]}
\PYG{n}{Last} \PYG{n}{failed} \PYG{n}{authentication}\PYG{p}{:} \PYG{p}{[}\PYG{n}{never}\PYG{p}{]}
\PYG{n}{Failed} \PYG{n}{password} \PYG{n}{attempts}\PYG{p}{:} \PYG{l+m+mi}{0}
\PYG{n}{Number} \PYG{n}{of} \PYG{n}{keys}\PYG{p}{:} \PYG{l+m+mi}{1}
\PYG{n}{Key}\PYG{p}{:} \PYG{n}{vno} \PYG{l+m+mi}{1}\PYG{p}{,} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha384}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{192}
\PYG{n}{MKey}\PYG{p}{:} \PYG{n}{vno} \PYG{l+m+mi}{1}
\PYG{n}{Attributes}\PYG{p}{:}
\PYG{n}{Policy}\PYG{p}{:} \PYG{p}{[}\PYG{n}{none}\PYG{p}{]}

\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{getprinc} \PYG{o}{\PYGZhy{}}\PYG{n}{terse} \PYG{n}{systest}
\PYG{n}{systest}\PYG{n+nd}{@BLEEP}\PYG{o}{.}\PYG{n}{COM}   \PYG{l+m+mi}{3}    \PYG{l+m+mi}{86400}     \PYG{l+m+mi}{604800}    \PYG{l+m+mi}{1}
\PYG{l+m+mi}{785926535} \PYG{l+m+mi}{753241234} \PYG{l+m+mi}{785900000}
\PYG{n}{tlyu}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@BLEEP}\PYG{o}{.}\PYG{n}{COM}     \PYG{l+m+mi}{786100034} \PYG{l+m+mi}{0}    \PYG{l+m+mi}{0}
\PYG{n}{kadmin}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{list\_principals}
\label{\detokenize{admin/admin_commands/kadmin_local:id8}}\label{\detokenize{admin/admin_commands/kadmin_local:list-principals}}\begin{quote}

\sphinxstylestrong{list\_principals} {[}\sphinxstyleemphasis{expression}{]}
\end{quote}

Retrieves all or some principal names.  \sphinxstyleemphasis{expression} is a shell-style
glob expression that can contain the wild-card characters \sphinxcode{?},
\sphinxcode{*}, and \sphinxcode{{[}{]}}.  All principal names matching the expression are
printed.  If no expression is provided, all principal names are
printed.  If the expression does not contain an \sphinxcode{@} character, an
\sphinxcode{@} character followed by the local realm is appended to the
expression.

This command requires the \sphinxstylestrong{list} privilege.

Alias: \sphinxstylestrong{listprincs}, \sphinxstylestrong{get\_principals}, \sphinxstylestrong{getprincs}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:}  \PYG{n}{listprincs} \PYG{n}{test}\PYG{o}{*}
\PYG{n}{test3}\PYG{n+nd}{@SECURE}\PYG{o}{\PYGZhy{}}\PYG{n}{TEST}\PYG{o}{.}\PYG{n}{OV}\PYG{o}{.}\PYG{n}{COM}
\PYG{n}{test2}\PYG{n+nd}{@SECURE}\PYG{o}{\PYGZhy{}}\PYG{n}{TEST}\PYG{o}{.}\PYG{n}{OV}\PYG{o}{.}\PYG{n}{COM}
\PYG{n}{test1}\PYG{n+nd}{@SECURE}\PYG{o}{\PYGZhy{}}\PYG{n}{TEST}\PYG{o}{.}\PYG{n}{OV}\PYG{o}{.}\PYG{n}{COM}
\PYG{n}{testuser}\PYG{n+nd}{@SECURE}\PYG{o}{\PYGZhy{}}\PYG{n}{TEST}\PYG{o}{.}\PYG{n}{OV}\PYG{o}{.}\PYG{n}{COM}
\PYG{n}{kadmin}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{get\_strings}
\label{\detokenize{admin/admin_commands/kadmin_local:get-strings}}\label{\detokenize{admin/admin_commands/kadmin_local:id9}}\begin{quote}

\sphinxstylestrong{get\_strings} \sphinxstyleemphasis{principal}
\end{quote}

Displays string attributes on \sphinxstyleemphasis{principal}.

This command requires the \sphinxstylestrong{inquire} privilege.

Alias: \sphinxstylestrong{getstrs}


\subsubsection{set\_string}
\label{\detokenize{admin/admin_commands/kadmin_local:id10}}\label{\detokenize{admin/admin_commands/kadmin_local:set-string}}\begin{quote}

\sphinxstylestrong{set\_string} \sphinxstyleemphasis{principal} \sphinxstyleemphasis{name} \sphinxstyleemphasis{value}
\end{quote}

Sets a string attribute on \sphinxstyleemphasis{principal}.  String attributes are used to
supply per-principal configuration to the KDC and some KDC plugin
modules.  The following string attribute names are recognized by the
KDC:
\begin{description}
\item[{\sphinxstylestrong{require\_auth}}] \leavevmode
Specifies an authentication indicator which is required to
authenticate to the principal as a service.  Multiple indicators
can be specified, separated by spaces; in this case any of the
specified indicators will be accepted.  (New in release 1.14.)

\item[{\sphinxstylestrong{session\_enctypes}}] \leavevmode
Specifies the encryption types supported for session keys when the
principal is authenticated to as a server.  See
{\hyperref[\detokenize{admin/conf_files/kdc_conf:encryption-types}]{\sphinxcrossref{\DUrole{std,std-ref}{Encryption types}}}} in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} for a list of the
accepted values.

\item[{\sphinxstylestrong{otp}}] \leavevmode
Enables One Time Passwords (OTP) preauthentication for a client
\sphinxstyleemphasis{principal}.  The \sphinxstyleemphasis{value} is a JSON string representing an array
of objects, each having optional \sphinxcode{type} and \sphinxcode{username} fields.

\item[{\sphinxstylestrong{pkinit\_cert\_match}}] \leavevmode
Specifies a matching expression that defines the certificate
attributes required for the client certificate used by the
principal during PKINIT authentication.  The matching expression
is in the same format as those used by the \sphinxstylestrong{pkinit\_cert\_match}
option in {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}.  (New in release 1.16.)

\item[{\sphinxstylestrong{pac\_privsvr\_enctype}}] \leavevmode
Forces the encryption type of the PAC KDC checksum buffers to the
specified encryption type for tickets issued to this server, by
deriving a key from the local krbtgt key if it is of a different
encryption type.  It may be necessary to set this value to
“aes256-sha1” on the cross-realm krbtgt entry for an Active
Directory realm when using aes-sha2 keys on the local krbtgt
entry.

\end{description}

This command requires the \sphinxstylestrong{modify} privilege.

Alias: \sphinxstylestrong{setstr}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{set\PYGZus{}string} \PYG{n}{host}\PYG{o}{/}\PYG{n}{foo}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{n}{session\PYGZus{}enctypes} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}
\PYG{n}{set\PYGZus{}string} \PYG{n}{user}\PYG{n+nd}{@FOO}\PYG{o}{.}\PYG{n}{COM} \PYG{n}{otp} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{[}\PYG{l+s+s2}{\PYGZob{}}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{type}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{:}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{hotp}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{,}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{username}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{:}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{al}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{\PYGZcb{}]}\PYG{l+s+s2}{\PYGZdq{}}
\end{sphinxVerbatim}


\subsubsection{del\_string}
\label{\detokenize{admin/admin_commands/kadmin_local:del-string}}\label{\detokenize{admin/admin_commands/kadmin_local:id11}}\begin{quote}

\sphinxstylestrong{del\_string} \sphinxstyleemphasis{principal} \sphinxstyleemphasis{key}
\end{quote}

Deletes a string attribute from \sphinxstyleemphasis{principal}.

This command requires the \sphinxstylestrong{delete} privilege.

Alias: \sphinxstylestrong{delstr}


\subsubsection{add\_policy}
\label{\detokenize{admin/admin_commands/kadmin_local:id12}}\label{\detokenize{admin/admin_commands/kadmin_local:add-policy}}\begin{quote}

\sphinxstylestrong{add\_policy} {[}\sphinxstyleemphasis{options}{]} \sphinxstyleemphasis{policy}
\end{quote}

Adds a password policy named \sphinxstyleemphasis{policy} to the database.

This command requires the \sphinxstylestrong{add} privilege.

Alias: \sphinxstylestrong{addpol}

The following options are available:
\begin{description}
\item[{\sphinxstylestrong{-maxlife} \sphinxstyleemphasis{time}}] \leavevmode
(\DUrole{xref,std,std-ref}{duration} or \DUrole{xref,std,std-ref}{getdate} string) Sets the maximum
lifetime of a password.

\item[{\sphinxstylestrong{-minlife} \sphinxstyleemphasis{time}}] \leavevmode
(\DUrole{xref,std,std-ref}{duration} or \DUrole{xref,std,std-ref}{getdate} string) Sets the minimum
lifetime of a password.

\item[{\sphinxstylestrong{-minlength} \sphinxstyleemphasis{length}}] \leavevmode
Sets the minimum length of a password.

\item[{\sphinxstylestrong{-minclasses} \sphinxstyleemphasis{number}}] \leavevmode
Sets the minimum number of character classes required in a
password.  The five character classes are lower case, upper case,
numbers, punctuation, and whitespace/unprintable characters.

\item[{\sphinxstylestrong{-history} \sphinxstyleemphasis{number}}] \leavevmode
Sets the number of past keys kept for a principal.  This option is
not supported with the LDAP KDC database module.

\end{description}
\phantomsection\label{\detokenize{admin/admin_commands/kadmin_local:policy-maxfailure}}\begin{description}
\item[{\sphinxstylestrong{-maxfailure} \sphinxstyleemphasis{maxnumber}}] \leavevmode
Sets the number of authentication failures before the principal is
locked.  Authentication failures are only tracked for principals
which require preauthentication.  The counter of failed attempts
resets to 0 after a successful attempt to authenticate.  A
\sphinxstyleemphasis{maxnumber} value of 0 (the default) disables lockout.

\end{description}
\phantomsection\label{\detokenize{admin/admin_commands/kadmin_local:policy-failurecountinterval}}\begin{description}
\item[{\sphinxstylestrong{-failurecountinterval} \sphinxstyleemphasis{failuretime}}] \leavevmode
(\DUrole{xref,std,std-ref}{duration} or \DUrole{xref,std,std-ref}{getdate} string) Sets the allowable time
between authentication failures.  If an authentication failure
happens after \sphinxstyleemphasis{failuretime} has elapsed since the previous
failure, the number of authentication failures is reset to 1.  A
\sphinxstyleemphasis{failuretime} value of 0 (the default) means forever.

\end{description}
\phantomsection\label{\detokenize{admin/admin_commands/kadmin_local:policy-lockoutduration}}\begin{description}
\item[{\sphinxstylestrong{-lockoutduration} \sphinxstyleemphasis{lockouttime}}] \leavevmode
(\DUrole{xref,std,std-ref}{duration} or \DUrole{xref,std,std-ref}{getdate} string) Sets the duration for
which the principal is locked from authenticating if too many
authentication failures occur without the specified failure count
interval elapsing.  A duration of 0 (the default) means the
principal remains locked out until it is administratively unlocked
with \sphinxcode{modprinc -unlock}.

\item[{\sphinxstylestrong{-allowedkeysalts}}] \leavevmode
Specifies the key/salt tuples supported for long-term keys when
setting or changing a principal’s password/keys.  See
{\hyperref[\detokenize{admin/conf_files/kdc_conf:keysalt-lists}]{\sphinxcrossref{\DUrole{std,std-ref}{Keysalt lists}}}} in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} for a list of the
accepted values, but note that key/salt tuples must be separated
with commas (‘,’) only.  To clear the allowed key/salt policy use
a value of ‘-‘.

\end{description}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{add\PYGZus{}policy} \PYG{o}{\PYGZhy{}}\PYG{n}{maxlife} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{2 days}\PYG{l+s+s2}{\PYGZdq{}} \PYG{o}{\PYGZhy{}}\PYG{n}{minlength} \PYG{l+m+mi}{5} \PYG{n}{guests}
\PYG{n}{kadmin}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{modify\_policy}
\label{\detokenize{admin/admin_commands/kadmin_local:id13}}\label{\detokenize{admin/admin_commands/kadmin_local:modify-policy}}\begin{quote}

\sphinxstylestrong{modify\_policy} {[}\sphinxstyleemphasis{options}{]} \sphinxstyleemphasis{policy}
\end{quote}

Modifies the password policy named \sphinxstyleemphasis{policy}.  Options are as described
for \sphinxstylestrong{add\_policy}.

This command requires the \sphinxstylestrong{modify} privilege.

Alias: \sphinxstylestrong{modpol}


\subsubsection{delete\_policy}
\label{\detokenize{admin/admin_commands/kadmin_local:delete-policy}}\label{\detokenize{admin/admin_commands/kadmin_local:id14}}\begin{quote}

\sphinxstylestrong{delete\_policy} {[}\sphinxstylestrong{-force}{]} \sphinxstyleemphasis{policy}
\end{quote}

Deletes the password policy named \sphinxstyleemphasis{policy}.  Prompts for confirmation
before deletion.  The command will fail if the policy is in use by any
principals.

This command requires the \sphinxstylestrong{delete} privilege.

Alias: \sphinxstylestrong{delpol}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
kadmin: del\PYGZus{}policy guests
Are you sure you want to delete the policy \PYGZdq{}guests\PYGZdq{}?
(yes/no): yes
kadmin:
\end{sphinxVerbatim}


\subsubsection{get\_policy}
\label{\detokenize{admin/admin_commands/kadmin_local:get-policy}}\label{\detokenize{admin/admin_commands/kadmin_local:id15}}\begin{quote}

\sphinxstylestrong{get\_policy} {[} \sphinxstylestrong{-terse} {]} \sphinxstyleemphasis{policy}
\end{quote}

Displays the values of the password policy named \sphinxstyleemphasis{policy}.  With the
\sphinxstylestrong{-terse} flag, outputs the fields as quoted strings separated by
tabs.

This command requires the \sphinxstylestrong{inquire} privilege.

Alias: \sphinxstylestrong{getpol}

Examples:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{get\PYGZus{}policy} \PYG{n}{admin}
\PYG{n}{Policy}\PYG{p}{:} \PYG{n}{admin}
\PYG{n}{Maximum} \PYG{n}{password} \PYG{n}{life}\PYG{p}{:} \PYG{l+m+mi}{180} \PYG{n}{days} \PYG{l+m+mi}{00}\PYG{p}{:}\PYG{l+m+mi}{00}\PYG{p}{:}\PYG{l+m+mi}{00}
\PYG{n}{Minimum} \PYG{n}{password} \PYG{n}{life}\PYG{p}{:} \PYG{l+m+mi}{00}\PYG{p}{:}\PYG{l+m+mi}{00}\PYG{p}{:}\PYG{l+m+mi}{00}
\PYG{n}{Minimum} \PYG{n}{password} \PYG{n}{length}\PYG{p}{:} \PYG{l+m+mi}{6}
\PYG{n}{Minimum} \PYG{n}{number} \PYG{n}{of} \PYG{n}{password} \PYG{n}{character} \PYG{n}{classes}\PYG{p}{:} \PYG{l+m+mi}{2}
\PYG{n}{Number} \PYG{n}{of} \PYG{n}{old} \PYG{n}{keys} \PYG{n}{kept}\PYG{p}{:} \PYG{l+m+mi}{5}
\PYG{n}{Reference} \PYG{n}{count}\PYG{p}{:} \PYG{l+m+mi}{17}

\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{get\PYGZus{}policy} \PYG{o}{\PYGZhy{}}\PYG{n}{terse} \PYG{n}{admin}
\PYG{n}{admin}     \PYG{l+m+mi}{15552000}  \PYG{l+m+mi}{0}    \PYG{l+m+mi}{6}    \PYG{l+m+mi}{2}    \PYG{l+m+mi}{5}    \PYG{l+m+mi}{17}
\PYG{n}{kadmin}\PYG{p}{:}
\end{sphinxVerbatim}

The “Reference count” is the number of principals using that policy.
With the LDAP KDC database module, the reference count field is not
meaningful.


\subsubsection{list\_policies}
\label{\detokenize{admin/admin_commands/kadmin_local:list-policies}}\label{\detokenize{admin/admin_commands/kadmin_local:id16}}\begin{quote}

\sphinxstylestrong{list\_policies} {[}\sphinxstyleemphasis{expression}{]}
\end{quote}

Retrieves all or some policy names.  \sphinxstyleemphasis{expression} is a shell-style
glob expression that can contain the wild-card characters \sphinxcode{?},
\sphinxcode{*}, and \sphinxcode{{[}{]}}.  All policy names matching the expression are
printed.  If no expression is provided, all existing policy names are
printed.

This command requires the \sphinxstylestrong{list} privilege.

Aliases: \sphinxstylestrong{listpols}, \sphinxstylestrong{get\_policies}, \sphinxstylestrong{getpols}.

Examples:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:}  \PYG{n}{listpols}
\PYG{n}{test}\PYG{o}{\PYGZhy{}}\PYG{n}{pol}
\PYG{n+nb}{dict}\PYG{o}{\PYGZhy{}}\PYG{n}{only}
\PYG{n}{once}\PYG{o}{\PYGZhy{}}\PYG{n}{a}\PYG{o}{\PYGZhy{}}\PYG{n+nb}{min}
\PYG{n}{test}\PYG{o}{\PYGZhy{}}\PYG{n}{pol}\PYG{o}{\PYGZhy{}}\PYG{n}{nopw}

\PYG{n}{kadmin}\PYG{p}{:}  \PYG{n}{listpols} \PYG{n}{t}\PYG{o}{*}
\PYG{n}{test}\PYG{o}{\PYGZhy{}}\PYG{n}{pol}
\PYG{n}{test}\PYG{o}{\PYGZhy{}}\PYG{n}{pol}\PYG{o}{\PYGZhy{}}\PYG{n}{nopw}
\PYG{n}{kadmin}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{ktadd}
\label{\detokenize{admin/admin_commands/kadmin_local:ktadd}}\label{\detokenize{admin/admin_commands/kadmin_local:id17}}\begin{quote}

\begin{DUlineblock}{0em}
\item[] \sphinxstylestrong{ktadd} {[}options{]} \sphinxstyleemphasis{principal}
\item[] \sphinxstylestrong{ktadd} {[}options{]} \sphinxstylestrong{-glob} \sphinxstyleemphasis{princ-exp}
\end{DUlineblock}
\end{quote}

Adds a \sphinxstyleemphasis{principal}, or all principals matching \sphinxstyleemphasis{princ-exp}, to a
keytab file.  Each principal’s keys are randomized in the process.
The rules for \sphinxstyleemphasis{princ-exp} are described in the \sphinxstylestrong{list\_principals}
command.

This command requires the \sphinxstylestrong{inquire} and \sphinxstylestrong{changepw} privileges.
With the \sphinxstylestrong{-glob} form, it also requires the \sphinxstylestrong{list} privilege.

The options are:
\begin{description}
\item[{\sphinxstylestrong{-k{[}eytab{]}} \sphinxstyleemphasis{keytab}}] \leavevmode
Use \sphinxstyleemphasis{keytab} as the keytab file.  Otherwise, the default keytab is
used.

\item[{\sphinxstylestrong{-e} \sphinxstyleemphasis{enc}:\sphinxstyleemphasis{salt},…}] \leavevmode
Uses the specified keysalt list for setting the new keys of the
principal.  See {\hyperref[\detokenize{admin/conf_files/kdc_conf:keysalt-lists}]{\sphinxcrossref{\DUrole{std,std-ref}{Keysalt lists}}}} in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} for a
list of possible values.

\item[{\sphinxstylestrong{-q}}] \leavevmode
Display less verbose information.

\item[{\sphinxstylestrong{-norandkey}}] \leavevmode
Do not randomize the keys. The keys and their version numbers stay
unchanged.  This option cannot be specified in combination with the
\sphinxstylestrong{-e} option.

\end{description}

An entry for each of the principal’s unique encryption types is added,
ignoring multiple keys with the same encryption type but different
salt types.

Alias: \sphinxstylestrong{xst}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{ktadd} \PYG{o}{\PYGZhy{}}\PYG{n}{k} \PYG{o}{/}\PYG{n}{tmp}\PYG{o}{/}\PYG{n}{foo}\PYG{o}{\PYGZhy{}}\PYG{n}{new}\PYG{o}{\PYGZhy{}}\PYG{n}{keytab} \PYG{n}{host}\PYG{o}{/}\PYG{n}{foo}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{foo}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{3}\PYG{p}{,}
     \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab}
     \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{tmp}\PYG{o}{/}\PYG{n}{foo}\PYG{o}{\PYGZhy{}}\PYG{n}{new}\PYG{o}{\PYGZhy{}}\PYG{n}{keytab}
\PYG{n}{kadmin}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{ktremove}
\label{\detokenize{admin/admin_commands/kadmin_local:id18}}\label{\detokenize{admin/admin_commands/kadmin_local:ktremove}}\begin{quote}

\sphinxstylestrong{ktremove} {[}options{]} \sphinxstyleemphasis{principal} {[}\sphinxstyleemphasis{kvno} \textbar{} \sphinxstyleemphasis{all} \textbar{} \sphinxstyleemphasis{old}{]}
\end{quote}

Removes entries for the specified \sphinxstyleemphasis{principal} from a keytab.  Requires
no permissions, since this does not require database access.

If the string “all” is specified, all entries for that principal are
removed; if the string “old” is specified, all entries for that
principal except those with the highest kvno are removed.  Otherwise,
the value specified is parsed as an integer, and all entries whose
kvno match that integer are removed.

The options are:
\begin{description}
\item[{\sphinxstylestrong{-k{[}eytab{]}} \sphinxstyleemphasis{keytab}}] \leavevmode
Use \sphinxstyleemphasis{keytab} as the keytab file.  Otherwise, the default keytab is
used.

\item[{\sphinxstylestrong{-q}}] \leavevmode
Display less verbose information.

\end{description}

Alias: \sphinxstylestrong{ktrem}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kadmin}\PYG{p}{:} \PYG{n}{ktremove} \PYG{n}{kadmin}\PYG{o}{/}\PYG{n}{admin} \PYG{n+nb}{all}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{kadmin}\PYG{o}{/}\PYG{n}{admin} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{3} \PYG{n}{removed} \PYG{k+kn}{from} \PYG{n+nn}{keytab}
     \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}
\PYG{n}{kadmin}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{lock}
\label{\detokenize{admin/admin_commands/kadmin_local:lock}}
Lock database exclusively.  Use with extreme caution!  This command
only works with the DB2 KDC database module.


\subsubsection{unlock}
\label{\detokenize{admin/admin_commands/kadmin_local:unlock}}
Release the exclusive database lock.


\subsubsection{list\_requests}
\label{\detokenize{admin/admin_commands/kadmin_local:list-requests}}
Lists available for kadmin requests.

Aliases: \sphinxstylestrong{lr}, \sphinxstylestrong{?}


\subsubsection{quit}
\label{\detokenize{admin/admin_commands/kadmin_local:quit}}
Exit program.  If the database was locked, the lock is released.

Aliases: \sphinxstylestrong{exit}, \sphinxstylestrong{q}


\subsection{HISTORY}
\label{\detokenize{admin/admin_commands/kadmin_local:history}}
The kadmin program was originally written by Tom Yu at MIT, as an
interface to the OpenVision Kerberos administration program.


\subsection{ENVIRONMENT}
\label{\detokenize{admin/admin_commands/kadmin_local:environment}}
See \DUrole{xref,std,std-ref}{kerberos(7)} for a description of Kerberos environment
variables.


\subsection{SEE ALSO}
\label{\detokenize{admin/admin_commands/kadmin_local:see-also}}
\DUrole{xref,std,std-ref}{kpasswd(1)}, {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}}, \DUrole{xref,std,std-ref}{kerberos(7)}


\section{kadmind}
\label{\detokenize{admin/admin_commands/kadmind:kadmind-8}}\label{\detokenize{admin/admin_commands/kadmind:kadmind}}\label{\detokenize{admin/admin_commands/kadmind::doc}}

\subsection{SYNOPSIS}
\label{\detokenize{admin/admin_commands/kadmind:synopsis}}
\sphinxstylestrong{kadmind}
{[}\sphinxstylestrong{-x} \sphinxstyleemphasis{db\_args}{]}
{[}\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}{]}
{[}\sphinxstylestrong{-m}{]}
{[}\sphinxstylestrong{-nofork}{]}
{[}\sphinxstylestrong{-proponly}{]}
{[}\sphinxstylestrong{-port} \sphinxstyleemphasis{port-number}{]}
{[}\sphinxstylestrong{-P} \sphinxstyleemphasis{pid\_file}{]}
{[}\sphinxstylestrong{-p} \sphinxstyleemphasis{kdb5\_util\_path}{]}
{[}\sphinxstylestrong{-K} \sphinxstyleemphasis{kprop\_path}{]}
{[}\sphinxstylestrong{-k} \sphinxstyleemphasis{kprop\_port}{]}
{[}\sphinxstylestrong{-F} \sphinxstyleemphasis{dump\_file}{]}


\subsection{DESCRIPTION}
\label{\detokenize{admin/admin_commands/kadmind:description}}
kadmind starts the Kerberos administration server.  kadmind typically
runs on the primary Kerberos server, which stores the KDC database.
If the KDC database uses the LDAP module, the administration server
and the KDC server need not run on the same machine.  kadmind accepts
remote requests from programs such as {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} and
\DUrole{xref,std,std-ref}{kpasswd(1)} to administer the information in these database.

kadmind requires a number of configuration files to be set up in order
for it to work:
\begin{description}
\item[{{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}}] \leavevmode
The KDC configuration file contains configuration information for
the KDC and admin servers.  kadmind uses settings in this file to
locate the Kerberos database, and is also affected by the
\sphinxstylestrong{acl\_file}, \sphinxstylestrong{dict\_file}, \sphinxstylestrong{kadmind\_port}, and iprop-related
settings.

\item[{{\hyperref[\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5.acl}}}}}] \leavevmode
kadmind’s ACL (access control list) tells it which principals are
allowed to perform administration actions.  The pathname to the
ACL file can be specified with the \sphinxstylestrong{acl\_file} {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}
variable; by default, it is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/kadm5.acl}.

\end{description}

After the server begins running, it puts itself in the background and
disassociates itself from its controlling terminal.

kadmind can be configured for incremental database propagation.
Incremental propagation allows replica KDC servers to receive
principal and policy updates incrementally instead of receiving full
dumps of the database.  This facility can be enabled in the
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} file with the \sphinxstylestrong{iprop\_enable} option.  Incremental
propagation requires the principal \sphinxcode{kiprop/PRIMARY\textbackslash{}@REALM} (where
PRIMARY is the primary KDC’s canonical host name, and REALM the realm
name).  In release 1.13, this principal is automatically created and
registered into the datebase.


\subsection{OPTIONS}
\label{\detokenize{admin/admin_commands/kadmind:options}}\begin{description}
\item[{\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}}] \leavevmode
specifies the realm that kadmind will serve; if it is not
specified, the default realm of the host is used.

\item[{\sphinxstylestrong{-m}}] \leavevmode
causes the master database password to be fetched from the
keyboard (before the server puts itself in the background, if not
invoked with the \sphinxstylestrong{-nofork} option) rather than from a file on
disk.

\item[{\sphinxstylestrong{-nofork}}] \leavevmode
causes the server to remain in the foreground and remain
associated to the terminal.

\item[{\sphinxstylestrong{-proponly}}] \leavevmode
causes the server to only listen and respond to Kerberos replica
incremental propagation polling requests.  This option can be used
to set up a hierarchical propagation topology where a replica KDC
provides incremental updates to other Kerberos replicas.

\item[{\sphinxstylestrong{-port} \sphinxstyleemphasis{port-number}}] \leavevmode
specifies the port on which the administration server listens for
connections.  The default port is determined by the
\sphinxstylestrong{kadmind\_port} configuration variable in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.

\item[{\sphinxstylestrong{-P} \sphinxstyleemphasis{pid\_file}}] \leavevmode
specifies the file to which the PID of kadmind process should be
written after it starts up.  This file can be used to identify
whether kadmind is still running and to allow init scripts to stop
the correct process.

\item[{\sphinxstylestrong{-p} \sphinxstyleemphasis{kdb5\_util\_path}}] \leavevmode
specifies the path to the kdb5\_util command to use when dumping the
KDB in response to full resync requests when iprop is enabled.

\item[{\sphinxstylestrong{-K} \sphinxstyleemphasis{kprop\_path}}] \leavevmode
specifies the path to the kprop command to use to send full dumps
to replicas in response to full resync requests.

\item[{\sphinxstylestrong{-k} \sphinxstyleemphasis{kprop\_port}}] \leavevmode
specifies the port by which the kprop process that is spawned by
kadmind connects to the replica kpropd, in order to transfer the
dump file during an iprop full resync request.

\item[{\sphinxstylestrong{-F} \sphinxstyleemphasis{dump\_file}}] \leavevmode
specifies the file path to be used for dumping the KDB in response
to full resync requests when iprop is enabled.

\item[{\sphinxstylestrong{-x} \sphinxstyleemphasis{db\_args}}] \leavevmode
specifies database-specific arguments.  See {\hyperref[\detokenize{admin/admin_commands/kadmin_local:dboptions}]{\sphinxcrossref{\DUrole{std,std-ref}{Database Options}}}} in {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} for supported arguments.

\end{description}


\subsection{ENVIRONMENT}
\label{\detokenize{admin/admin_commands/kadmind:environment}}
See \DUrole{xref,std,std-ref}{kerberos(7)} for a description of Kerberos environment
variables.


\subsection{SEE ALSO}
\label{\detokenize{admin/admin_commands/kadmind:see-also}}
\DUrole{xref,std,std-ref}{kpasswd(1)}, {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}, {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}},
{\hyperref[\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_ldap\_util}}}}, {\hyperref[\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5.acl}}}}, \DUrole{xref,std,std-ref}{kerberos(7)}


\section{kdb5\_util}
\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}}\label{\detokenize{admin/admin_commands/kdb5_util::doc}}\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util}}

\subsection{SYNOPSIS}
\label{\detokenize{admin/admin_commands/kdb5_util:synopsis}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-synopsis}}
\sphinxstylestrong{kdb5\_util}
{[}\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}{]}
{[}\sphinxstylestrong{-d} \sphinxstyleemphasis{dbname}{]}
{[}\sphinxstylestrong{-k} \sphinxstyleemphasis{mkeytype}{]}
{[}\sphinxstylestrong{-kv} \sphinxstyleemphasis{mkeyVNO}{]}
{[}\sphinxstylestrong{-M} \sphinxstyleemphasis{mkeyname}{]}
{[}\sphinxstylestrong{-m}{]}
{[}\sphinxstylestrong{-sf} \sphinxstyleemphasis{stashfilename}{]}
{[}\sphinxstylestrong{-P} \sphinxstyleemphasis{password}{]}
{[}\sphinxstylestrong{-x} \sphinxstyleemphasis{db\_args}{]}
\sphinxstyleemphasis{command} {[}\sphinxstyleemphasis{command\_options}{]}


\subsection{DESCRIPTION}
\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-synopsis-end}}\label{\detokenize{admin/admin_commands/kdb5_util:description}}
kdb5\_util allows an administrator to perform maintenance procedures on
the KDC database.  Databases can be created, destroyed, and dumped to
or loaded from ASCII files.  kdb5\_util can create a Kerberos master
key stash file or perform live rollover of the master key.

When kdb5\_util is run, it attempts to acquire the master key and open
the database.  However, execution continues regardless of whether or
not kdb5\_util successfully opens the database, because the database
may not exist yet or the stash file may be corrupt.

Note that some KDC database modules may not support all kdb5\_util
commands.


\subsection{COMMAND-LINE OPTIONS}
\label{\detokenize{admin/admin_commands/kdb5_util:command-line-options}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-options}}\begin{description}
\item[{\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}}] \leavevmode
specifies the Kerberos realm of the database.

\item[{\sphinxstylestrong{-d} \sphinxstyleemphasis{dbname}}] \leavevmode
specifies the name under which the principal database is stored;
by default the database is that listed in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.  The
password policy database and lock files are also derived from this
value.

\item[{\sphinxstylestrong{-k} \sphinxstyleemphasis{mkeytype}}] \leavevmode
specifies the key type of the master key in the database.  The
default is given by the \sphinxstylestrong{master\_key\_type} variable in
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.

\item[{\sphinxstylestrong{-kv} \sphinxstyleemphasis{mkeyVNO}}] \leavevmode
Specifies the version number of the master key in the database;
the default is 1.  Note that 0 is not allowed.

\item[{\sphinxstylestrong{-M} \sphinxstyleemphasis{mkeyname}}] \leavevmode
principal name for the master key in the database.  If not
specified, the name is determined by the \sphinxstylestrong{master\_key\_name}
variable in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.

\item[{\sphinxstylestrong{-m}}] \leavevmode
specifies that the master database password should be read from
the keyboard rather than fetched from a file on disk.

\item[{\sphinxstylestrong{-sf} \sphinxstyleemphasis{stash\_file}}] \leavevmode
specifies the stash filename of the master database password.  If
not specified, the filename is determined by the
\sphinxstylestrong{key\_stash\_file} variable in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.

\item[{\sphinxstylestrong{-P} \sphinxstyleemphasis{password}}] \leavevmode
specifies the master database password.  Using this option may
expose the password to other users on the system via the process
list.

\item[{\sphinxstylestrong{-x} \sphinxstyleemphasis{db\_args}}] \leavevmode
specifies database-specific options.  See {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} for
supported options.

\end{description}


\subsection{COMMANDS}
\label{\detokenize{admin/admin_commands/kdb5_util:commands}}\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-options-end}}

\subsubsection{create}
\label{\detokenize{admin/admin_commands/kdb5_util:create}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-create}}\begin{quote}

\sphinxstylestrong{create} {[}\sphinxstylestrong{-s}{]}
\end{quote}

Creates a new database.  If the \sphinxstylestrong{-s} option is specified, the stash
file is also created.  This command fails if the database already
exists.  If the command is successful, the database is opened just as
if it had already existed when the program was first run.


\subsubsection{destroy}
\label{\detokenize{admin/admin_commands/kdb5_util:destroy}}\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-create-end}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-destroy}}\begin{quote}

\sphinxstylestrong{destroy} {[}\sphinxstylestrong{-f}{]}
\end{quote}

Destroys the database, first overwriting the disk sectors and then
unlinking the files, after prompting the user for confirmation.  With
the \sphinxstylestrong{-f} argument, does not prompt the user.


\subsubsection{stash}
\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-destroy-end}}\label{\detokenize{admin/admin_commands/kdb5_util:stash}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-stash}}\begin{quote}

\sphinxstylestrong{stash} {[}\sphinxstylestrong{-f} \sphinxstyleemphasis{keyfile}{]}
\end{quote}

Stores the master principal’s keys in a stash file.  The \sphinxstylestrong{-f}
argument can be used to override the \sphinxstyleemphasis{keyfile} specified in
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.


\subsubsection{dump}
\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-stash-end}}\label{\detokenize{admin/admin_commands/kdb5_util:dump}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-dump}}\begin{quote}

\sphinxstylestrong{dump} {[}\sphinxstylestrong{-b7}\textbar{}\sphinxstylestrong{-r13}\textbar{}\sphinxstylestrong{-r18}{]}
{[}\sphinxstylestrong{-verbose}{]} {[}\sphinxstylestrong{-mkey\_convert}{]} {[}\sphinxstylestrong{-new\_mkey\_file}
\sphinxstyleemphasis{mkey\_file}{]} {[}\sphinxstylestrong{-rev}{]} {[}\sphinxstylestrong{-recurse}{]} {[}\sphinxstyleemphasis{filename}
{[}\sphinxstyleemphasis{principals}…{]}{]}
\end{quote}

Dumps the current Kerberos and KADM5 database into an ASCII file.  By
default, the database is dumped in current format, “kdb5\_util
load\_dump version 7”.  If filename is not specified, or is the string
“-“, the dump is sent to standard output.  Options:
\begin{description}
\item[{\sphinxstylestrong{-b7}}] \leavevmode
causes the dump to be in the Kerberos 5 Beta 7 format (“kdb5\_util
load\_dump version 4”).  This was the dump format produced on
releases prior to 1.2.2.

\item[{\sphinxstylestrong{-r13}}] \leavevmode
causes the dump to be in the Kerberos 5 1.3 format (“kdb5\_util
load\_dump version 5”).  This was the dump format produced on
releases prior to 1.8.

\item[{\sphinxstylestrong{-r18}}] \leavevmode
causes the dump to be in the Kerberos 5 1.8 format (“kdb5\_util
load\_dump version 6”).  This was the dump format produced on
releases prior to 1.11.

\item[{\sphinxstylestrong{-verbose}}] \leavevmode
causes the name of each principal and policy to be printed as it
is dumped.

\item[{\sphinxstylestrong{-mkey\_convert}}] \leavevmode
prompts for a new master key.  This new master key will be used to
re-encrypt principal key data in the dumpfile.  The principal keys
themselves will not be changed.

\item[{\sphinxstylestrong{-new\_mkey\_file} \sphinxstyleemphasis{mkey\_file}}] \leavevmode
the filename of a stash file.  The master key in this stash file
will be used to re-encrypt the key data in the dumpfile.  The key
data in the database will not be changed.

\item[{\sphinxstylestrong{-rev}}] \leavevmode
dumps in reverse order.  This may recover principals that do not
dump normally, in cases where database corruption has occurred.

\item[{\sphinxstylestrong{-recurse}}] \leavevmode
causes the dump to walk the database recursively (btree only).
This may recover principals that do not dump normally, in cases
where database corruption has occurred.  In cases of such
corruption, this option will probably retrieve more principals
than the \sphinxstylestrong{-rev} option will.

\DUrole{versionmodified}{Changed in version 1.15: }Release 1.15 restored the functionality of the \sphinxstylestrong{-recurse}
option.

\DUrole{versionmodified}{Changed in version 1.5: }The \sphinxstylestrong{-recurse} option ceased working until release 1.15,
doing a normal dump instead of a recursive traversal.

\end{description}


\subsubsection{load}
\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-dump-end}}\label{\detokenize{admin/admin_commands/kdb5_util:load}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-load}}\begin{quote}

\sphinxstylestrong{load} {[}\sphinxstylestrong{-b7}\textbar{}\sphinxstylestrong{-r13}\textbar{}\sphinxstylestrong{-r18}{]} {[}\sphinxstylestrong{-hash}{]}
{[}\sphinxstylestrong{-verbose}{]} {[}\sphinxstylestrong{-update}{]} \sphinxstyleemphasis{filename}
\end{quote}

Loads a database dump from the named file into the named database.  If
no option is given to determine the format of the dump file, the
format is detected automatically and handled as appropriate.  Unless
the \sphinxstylestrong{-update} option is given, \sphinxstylestrong{load} creates a new database
containing only the data in the dump file, overwriting the contents of
any previously existing database.  Note that when using the LDAP KDC
database module, the \sphinxstylestrong{-update} flag is required.

Options:
\begin{description}
\item[{\sphinxstylestrong{-b7}}] \leavevmode
requires the database to be in the Kerberos 5 Beta 7 format
(“kdb5\_util load\_dump version 4”).  This was the dump format
produced on releases prior to 1.2.2.

\item[{\sphinxstylestrong{-r13}}] \leavevmode
requires the database to be in Kerberos 5 1.3 format (“kdb5\_util
load\_dump version 5”).  This was the dump format produced on
releases prior to 1.8.

\item[{\sphinxstylestrong{-r18}}] \leavevmode
requires the database to be in Kerberos 5 1.8 format (“kdb5\_util
load\_dump version 6”).  This was the dump format produced on
releases prior to 1.11.

\item[{\sphinxstylestrong{-hash}}] \leavevmode
stores the database in hash format, if using the DB2 database
type.  If this option is not specified, the database will be
stored in btree format.  This option is not recommended, as
databases stored in hash format are known to corrupt data and lose
principals.

\item[{\sphinxstylestrong{-verbose}}] \leavevmode
causes the name of each principal and policy to be printed as it
is dumped.

\item[{\sphinxstylestrong{-update}}] \leavevmode
records from the dump file are added to or updated in the existing
database.  Otherwise, a new database is created containing only
what is in the dump file and the old one destroyed upon successful
completion.

\end{description}


\subsubsection{ark}
\label{\detokenize{admin/admin_commands/kdb5_util:kdb5-util-load-end}}\label{\detokenize{admin/admin_commands/kdb5_util:ark}}\begin{quote}

\sphinxstylestrong{ark} {[}\sphinxstylestrong{-e} \sphinxstyleemphasis{enc}:\sphinxstyleemphasis{salt},…{]} \sphinxstyleemphasis{principal}
\end{quote}

Adds new random keys to \sphinxstyleemphasis{principal} at the next available key version
number.  Keys for the current highest key version number will be
preserved.  The \sphinxstylestrong{-e} option specifies the list of encryption and
salt types to be used for the new keys.


\subsubsection{add\_mkey}
\label{\detokenize{admin/admin_commands/kdb5_util:add-mkey}}\begin{quote}

\sphinxstylestrong{add\_mkey} {[}\sphinxstylestrong{-e} \sphinxstyleemphasis{etype}{]} {[}\sphinxstylestrong{-s}{]}
\end{quote}

Adds a new master key to the master key principal, but does not mark
it as active.  Existing master keys will remain.  The \sphinxstylestrong{-e} option
specifies the encryption type of the new master key; see
{\hyperref[\detokenize{admin/conf_files/kdc_conf:encryption-types}]{\sphinxcrossref{\DUrole{std,std-ref}{Encryption types}}}} in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} for a list of possible
values.  The \sphinxstylestrong{-s} option stashes the new master key in the stash
file, which will be created if it doesn’t already exist.

After a new master key is added, it should be propagated to replica
servers via a manual or periodic invocation of {\hyperref[\detokenize{admin/admin_commands/kprop:kprop-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop}}}}.  Then,
the stash files on the replica servers should be updated with the
kdb5\_util \sphinxstylestrong{stash} command.  Once those steps are complete, the key
is ready to be marked active with the kdb5\_util \sphinxstylestrong{use\_mkey} command.


\subsubsection{use\_mkey}
\label{\detokenize{admin/admin_commands/kdb5_util:use-mkey}}\begin{quote}

\sphinxstylestrong{use\_mkey} \sphinxstyleemphasis{mkeyVNO} {[}\sphinxstyleemphasis{time}{]}
\end{quote}

Sets the activation time of the master key specified by \sphinxstyleemphasis{mkeyVNO}.
Once a master key becomes active, it will be used to encrypt newly
created principal keys.  If no \sphinxstyleemphasis{time} argument is given, the current
time is used, causing the specified master key version to become
active immediately.  The format for \sphinxstyleemphasis{time} is \DUrole{xref,std,std-ref}{getdate} string.

After a new master key becomes active, the kdb5\_util
\sphinxstylestrong{update\_princ\_encryption} command can be used to update all
principal keys to be encrypted in the new master key.


\subsubsection{list\_mkeys}
\label{\detokenize{admin/admin_commands/kdb5_util:list-mkeys}}\begin{quote}

\sphinxstylestrong{list\_mkeys}
\end{quote}

List all master keys, from most recent to earliest, in the master key
principal.  The output will show the kvno, enctype, and salt type for
each mkey, similar to the output of {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} \sphinxstylestrong{getprinc}.  A
\sphinxcode{*} following an mkey denotes the currently active master key.


\subsubsection{purge\_mkeys}
\label{\detokenize{admin/admin_commands/kdb5_util:purge-mkeys}}\begin{quote}

\sphinxstylestrong{purge\_mkeys} {[}\sphinxstylestrong{-f}{]} {[}\sphinxstylestrong{-n}{]} {[}\sphinxstylestrong{-v}{]}
\end{quote}

Delete master keys from the master key principal that are not used to
protect any principals.  This command can be used to remove old master
keys all principal keys are protected by a newer master key.
\begin{description}
\item[{\sphinxstylestrong{-f}}] \leavevmode
does not prompt for confirmation.

\item[{\sphinxstylestrong{-n}}] \leavevmode
performs a dry run, showing master keys that would be purged, but
not actually purging any keys.

\item[{\sphinxstylestrong{-v}}] \leavevmode
gives more verbose output.

\end{description}


\subsubsection{update\_princ\_encryption}
\label{\detokenize{admin/admin_commands/kdb5_util:update-princ-encryption}}\begin{quote}

\sphinxstylestrong{update\_princ\_encryption} {[}\sphinxstylestrong{-f}{]} {[}\sphinxstylestrong{-n}{]} {[}\sphinxstylestrong{-v}{]}
{[}\sphinxstyleemphasis{princ-pattern}{]}
\end{quote}

Update all principal records (or only those matching the
\sphinxstyleemphasis{princ-pattern} glob pattern) to re-encrypt the key data using the
active database master key, if they are encrypted using a different
version, and give a count at the end of the number of principals
updated.  If the \sphinxstylestrong{-f} option is not given, ask for confirmation
before starting to make changes.  The \sphinxstylestrong{-v} option causes each
principal processed to be listed, with an indication as to whether it
needed updating or not.  The \sphinxstylestrong{-n} option performs a dry run, only
showing the actions which would have been taken.


\subsubsection{tabdump}
\label{\detokenize{admin/admin_commands/kdb5_util:tabdump}}\begin{quote}

\sphinxstylestrong{tabdump} {[}\sphinxstylestrong{-H}{]} {[}\sphinxstylestrong{-c}{]} {[}\sphinxstylestrong{-e}{]} {[}\sphinxstylestrong{-n}{]} {[}\sphinxstylestrong{-o} \sphinxstyleemphasis{outfile}{]}
\sphinxstyleemphasis{dumptype}
\end{quote}

Dump selected fields of the database in a tabular format suitable for
reporting (e.g., using traditional Unix text processing tools) or
importing into relational databases.  The data format is tab-separated
(default), or optionally comma-separated (CSV), with a fixed number of
columns.  The output begins with a header line containing field names,
unless suppression is requested using the \sphinxstylestrong{-H} option.

The \sphinxstyleemphasis{dumptype} parameter specifies the name of an output table (see
below).

Options:
\begin{description}
\item[{\sphinxstylestrong{-H}}] \leavevmode
suppress writing the field names in a header line

\item[{\sphinxstylestrong{-c}}] \leavevmode
use comma separated values (CSV) format, with minimal quoting,
instead of the default tab-separated (unquoted, unescaped) format

\item[{\sphinxstylestrong{-e}}] \leavevmode
write empty hexadecimal string fields as empty fields instead of
as “-1”.

\item[{\sphinxstylestrong{-n}}] \leavevmode
produce numeric output for fields that normally have symbolic
output, such as enctypes and flag names.  Also requests output of
time stamps as decimal POSIX time\_t values.

\item[{\sphinxstylestrong{-o} \sphinxstyleemphasis{outfile}}] \leavevmode
write the dump to the specified output file instead of to standard
output

\end{description}

Dump types:
\begin{description}
\item[{\sphinxstylestrong{keydata}}] \leavevmode
principal encryption key information, including actual key data
(which is still encrypted in the master key)
\begin{description}
\item[{\sphinxstylestrong{name}}] \leavevmode
principal name

\item[{\sphinxstylestrong{keyindex}}] \leavevmode
index of this key in the principal’s key list

\item[{\sphinxstylestrong{kvno}}] \leavevmode
key version number

\item[{\sphinxstylestrong{enctype}}] \leavevmode
encryption type

\item[{\sphinxstylestrong{key}}] \leavevmode
key data as a hexadecimal string

\item[{\sphinxstylestrong{salttype}}] \leavevmode
salt type

\item[{\sphinxstylestrong{salt}}] \leavevmode
salt data as a hexadecimal string

\end{description}

\item[{\sphinxstylestrong{keyinfo}}] \leavevmode
principal encryption key information (as in \sphinxstylestrong{keydata} above),
excluding actual key data

\item[{\sphinxstylestrong{princ\_flags}}] \leavevmode
principal boolean attributes.  Flag names print as hexadecimal
numbers if the \sphinxstylestrong{-n} option is specified, and all flag positions
are printed regardless of whether or not they are set.  If \sphinxstylestrong{-n}
is not specified, print all known flag names for each principal,
but only print hexadecimal flag names if the corresponding flag is
set.
\begin{description}
\item[{\sphinxstylestrong{name}}] \leavevmode
principal name

\item[{\sphinxstylestrong{flag}}] \leavevmode
flag name

\item[{\sphinxstylestrong{value}}] \leavevmode
boolean value (0 for clear, or 1 for set)

\end{description}

\item[{\sphinxstylestrong{princ\_lockout}}] \leavevmode
state information used for tracking repeated password failures
\begin{description}
\item[{\sphinxstylestrong{name}}] \leavevmode
principal name

\item[{\sphinxstylestrong{last\_success}}] \leavevmode
time stamp of most recent successful authentication

\item[{\sphinxstylestrong{last\_failed}}] \leavevmode
time stamp of most recent failed authentication

\item[{\sphinxstylestrong{fail\_count}}] \leavevmode
count of failed attempts

\end{description}

\item[{\sphinxstylestrong{princ\_meta}}] \leavevmode
principal metadata
\begin{description}
\item[{\sphinxstylestrong{name}}] \leavevmode
principal name

\item[{\sphinxstylestrong{modby}}] \leavevmode
name of last principal to modify this principal

\item[{\sphinxstylestrong{modtime}}] \leavevmode
timestamp of last modification

\item[{\sphinxstylestrong{lastpwd}}] \leavevmode
timestamp of last password change

\item[{\sphinxstylestrong{policy}}] \leavevmode
policy object name

\item[{\sphinxstylestrong{mkvno}}] \leavevmode
key version number of the master key that encrypts this
principal’s key data

\item[{\sphinxstylestrong{hist\_kvno}}] \leavevmode
key version number of the history key that encrypts the key
history data for this principal

\end{description}

\item[{\sphinxstylestrong{princ\_stringattrs}}] \leavevmode
string attributes (key/value pairs)
\begin{description}
\item[{\sphinxstylestrong{name}}] \leavevmode
principal name

\item[{\sphinxstylestrong{key}}] \leavevmode
attribute name

\item[{\sphinxstylestrong{value}}] \leavevmode
attribute value

\end{description}

\item[{\sphinxstylestrong{princ\_tktpolicy}}] \leavevmode
per-principal ticket policy data, including maximum ticket
lifetimes
\begin{description}
\item[{\sphinxstylestrong{name}}] \leavevmode
principal name

\item[{\sphinxstylestrong{expiration}}] \leavevmode
principal expiration date

\item[{\sphinxstylestrong{pw\_expiration}}] \leavevmode
password expiration date

\item[{\sphinxstylestrong{max\_life}}] \leavevmode
maximum ticket lifetime

\item[{\sphinxstylestrong{max\_renew\_life}}] \leavevmode
maximum renewable ticket lifetime

\end{description}

\end{description}

Examples:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYGZdl{} kdb5\PYGZus{}util tabdump \PYGZhy{}o keyinfo.txt keyinfo
\PYGZdl{} cat keyinfo.txt
name        keyindex        kvno    enctype salttype        salt
K/M@EXAMPLE.COM     0       1       aes256\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha384\PYGZhy{}192      normal  \PYGZhy{}1
foo@EXAMPLE.COM     0       1       aes128\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha1\PYGZhy{}96 normal  \PYGZhy{}1
bar@EXAMPLE.COM     0       1       aes128\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha1\PYGZhy{}96 normal  \PYGZhy{}1
\PYGZdl{} sqlite3
sqlite\PYGZgt{} .mode tabs
sqlite\PYGZgt{} .import keyinfo.txt keyinfo
sqlite\PYGZgt{} select * from keyinfo where enctype like \PYGZsq{}aes256\PYGZhy{}\PYGZpc{}\PYGZsq{};
K/M@EXAMPLE.COM     1       1       aes256\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha384\PYGZhy{}192      normal  \PYGZhy{}1
sqlite\PYGZgt{} .quit
\PYGZdl{} awk \PYGZhy{}F\PYGZsq{}\PYGZbs{}t\PYGZsq{} \PYGZsq{}\PYGZdl{}4 \PYGZti{} /aes256\PYGZhy{}/ \PYGZob{} print \PYGZcb{}\PYGZsq{} keyinfo.txt
K/M@EXAMPLE.COM     1       1       aes256\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha384\PYGZhy{}192      normal  \PYGZhy{}1
\end{sphinxVerbatim}


\subsection{ENVIRONMENT}
\label{\detokenize{admin/admin_commands/kdb5_util:environment}}
See \DUrole{xref,std,std-ref}{kerberos(7)} for a description of Kerberos environment
variables.


\subsection{SEE ALSO}
\label{\detokenize{admin/admin_commands/kdb5_util:see-also}}
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}, \DUrole{xref,std,std-ref}{kerberos(7)}


\section{kdb5\_ldap\_util}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-8}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util::doc}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util}}

\subsection{SYNOPSIS}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:synopsis}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-synopsis}}
\sphinxstylestrong{kdb5\_ldap\_util}
{[}\sphinxstylestrong{-D} \sphinxstyleemphasis{user\_dn} {[}\sphinxstylestrong{-w} \sphinxstyleemphasis{passwd}{]}{]}
{[}\sphinxstylestrong{-H} \sphinxstyleemphasis{ldapuri}{]}
\sphinxstylestrong{command}
{[}\sphinxstyleemphasis{command\_options}{]}


\subsection{DESCRIPTION}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-synopsis-end}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:description}}
kdb5\_ldap\_util allows an administrator to manage realms, Kerberos
services and ticket policies.


\subsection{COMMAND-LINE OPTIONS}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:command-line-options}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-options}}\begin{description}
\item[{\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}}] \leavevmode
Specifies the realm to be operated on.

\item[{\sphinxstylestrong{-D} \sphinxstyleemphasis{user\_dn}}] \leavevmode
Specifies the Distinguished Name (DN) of the user who has
sufficient rights to perform the operation on the LDAP server.

\item[{\sphinxstylestrong{-w} \sphinxstyleemphasis{passwd}}] \leavevmode
Specifies the password of \sphinxstyleemphasis{user\_dn}.  This option is not
recommended.

\item[{\sphinxstylestrong{-H} \sphinxstyleemphasis{ldapuri}}] \leavevmode
Specifies the URI of the LDAP server.

\end{description}

By default, kdb5\_ldap\_util operates on the default realm (as specified
in {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}) and connects and authenticates to the LDAP
server in the same manner as :ref:kadmind(8){}` would given the
parameters in {\hyperref[\detokenize{admin/conf_files/kdc_conf:dbdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}dbdefaults{]}}}}} in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.


\subsection{COMMANDS}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-options-end}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:commands}}

\subsubsection{create}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:create}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-create}}\begin{quote}

\sphinxstylestrong{create}
{[}\sphinxstylestrong{-subtrees} \sphinxstyleemphasis{subtree\_dn\_list}{]}
{[}\sphinxstylestrong{-sscope} \sphinxstyleemphasis{search\_scope}{]}
{[}\sphinxstylestrong{-containerref} \sphinxstyleemphasis{container\_reference\_dn}{]}
{[}\sphinxstylestrong{-k} \sphinxstyleemphasis{mkeytype}{]}
{[}\sphinxstylestrong{-kv} \sphinxstyleemphasis{mkeyVNO}{]}
{[}\sphinxstylestrong{-M} \sphinxstyleemphasis{mkeyname}{]}
{[}\sphinxstylestrong{-m\textbar{}-P} \sphinxstyleemphasis{password}\textbar{}\sphinxstylestrong{-sf} \sphinxstyleemphasis{stashfilename}{]}
{[}\sphinxstylestrong{-s}{]}
{[}\sphinxstylestrong{-maxtktlife} \sphinxstyleemphasis{max\_ticket\_life}{]}
{[}\sphinxstylestrong{-maxrenewlife} \sphinxstyleemphasis{max\_renewable\_ticket\_life}{]}
{[}\sphinxstyleemphasis{ticket\_flags}{]}
\end{quote}

Creates realm in directory. Options:
\begin{description}
\item[{\sphinxstylestrong{-subtrees} \sphinxstyleemphasis{subtree\_dn\_list}}] \leavevmode
Specifies the list of subtrees containing the principals of a
realm.  The list contains the DNs of the subtree objects separated
by colon (\sphinxcode{:}).

\item[{\sphinxstylestrong{-sscope} \sphinxstyleemphasis{search\_scope}}] \leavevmode
Specifies the scope for searching the principals under the
subtree.  The possible values are 1 or one (one level), 2 or sub
(subtrees).

\item[{\sphinxstylestrong{-containerref} \sphinxstyleemphasis{container\_reference\_dn}}] \leavevmode
Specifies the DN of the container object in which the principals
of a realm will be created.  If the container reference is not
configured for a realm, the principals will be created in the
realm container.

\item[{\sphinxstylestrong{-k} \sphinxstyleemphasis{mkeytype}}] \leavevmode
Specifies the key type of the master key in the database.  The
default is given by the \sphinxstylestrong{master\_key\_type} variable in
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.

\item[{\sphinxstylestrong{-kv} \sphinxstyleemphasis{mkeyVNO}}] \leavevmode
Specifies the version number of the master key in the database;
the default is 1.  Note that 0 is not allowed.

\item[{\sphinxstylestrong{-M} \sphinxstyleemphasis{mkeyname}}] \leavevmode
Specifies the principal name for the master key in the database.
If not specified, the name is determined by the
\sphinxstylestrong{master\_key\_name} variable in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.

\item[{\sphinxstylestrong{-m}}] \leavevmode
Specifies that the master database password should be read from
the TTY rather than fetched from a file on the disk.

\item[{\sphinxstylestrong{-P} \sphinxstyleemphasis{password}}] \leavevmode
Specifies the master database password. This option is not
recommended.

\item[{\sphinxstylestrong{-sf} \sphinxstyleemphasis{stashfilename}}] \leavevmode
Specifies the stash file of the master database password.

\item[{\sphinxstylestrong{-s}}] \leavevmode
Specifies that the stash file is to be created.

\item[{\sphinxstylestrong{-maxtktlife} \sphinxstyleemphasis{max\_ticket\_life}}] \leavevmode
(\DUrole{xref,std,std-ref}{getdate} string) Specifies maximum ticket life for
principals in this realm.

\item[{\sphinxstylestrong{-maxrenewlife} \sphinxstyleemphasis{max\_renewable\_ticket\_life}}] \leavevmode
(\DUrole{xref,std,std-ref}{getdate} string) Specifies maximum renewable life of
tickets for principals in this realm.

\item[{\sphinxstyleemphasis{ticket\_flags}}] \leavevmode
Specifies global ticket flags for the realm.  Allowable flags are
documented in the description of the \sphinxstylestrong{add\_principal} command in
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}.

\end{description}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kdb5\PYGZus{}ldap\PYGZus{}util} \PYG{o}{\PYGZhy{}}\PYG{n}{D} \PYG{n}{cn}\PYG{o}{=}\PYG{n}{admin}\PYG{p}{,}\PYG{n}{o}\PYG{o}{=}\PYG{n}{org} \PYG{o}{\PYGZhy{}}\PYG{n}{H} \PYG{n}{ldaps}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{ldap}\PYG{o}{\PYGZhy{}}\PYG{n}{server1}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
    \PYG{o}{\PYGZhy{}}\PYG{n}{r} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{n}{create} \PYG{o}{\PYGZhy{}}\PYG{n}{subtrees} \PYG{n}{o}\PYG{o}{=}\PYG{n}{org} \PYG{o}{\PYGZhy{}}\PYG{n}{sscope} \PYG{n}{SUB}
\PYG{n}{Password} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=admin,o=org}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\PYG{n}{Initializing} \PYG{n}{database} \PYG{k}{for} \PYG{n}{realm} \PYG{l+s+s1}{\PYGZsq{}}\PYG{l+s+s1}{ATHENA.MIT.EDU}\PYG{l+s+s1}{\PYGZsq{}}
\PYG{n}{You} \PYG{n}{will} \PYG{n}{be} \PYG{n}{prompted} \PYG{k}{for} \PYG{n}{the} \PYG{n}{database} \PYG{n}{Master} \PYG{n}{Password}\PYG{o}{.}
\PYG{n}{It} \PYG{o+ow}{is} \PYG{n}{important} \PYG{n}{that} \PYG{n}{you} \PYG{n}{NOT} \PYG{n}{FORGET} \PYG{n}{this} \PYG{n}{password}\PYG{o}{.}
\PYG{n}{Enter} \PYG{n}{KDC} \PYG{n}{database} \PYG{n}{master} \PYG{n}{key}\PYG{p}{:}
\PYG{n}{Re}\PYG{o}{\PYGZhy{}}\PYG{n}{enter} \PYG{n}{KDC} \PYG{n}{database} \PYG{n}{master} \PYG{n}{key} \PYG{n}{to} \PYG{n}{verify}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{modify}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-create-end}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:modify}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-modify}}\begin{quote}

\sphinxstylestrong{modify}
{[}\sphinxstylestrong{-subtrees} \sphinxstyleemphasis{subtree\_dn\_list}{]}
{[}\sphinxstylestrong{-sscope} \sphinxstyleemphasis{search\_scope}{]}
{[}\sphinxstylestrong{-containerref} \sphinxstyleemphasis{container\_reference\_dn}{]}
{[}\sphinxstylestrong{-maxtktlife} \sphinxstyleemphasis{max\_ticket\_life}{]}
{[}\sphinxstylestrong{-maxrenewlife} \sphinxstyleemphasis{max\_renewable\_ticket\_life}{]}
{[}\sphinxstyleemphasis{ticket\_flags}{]}
\end{quote}

Modifies the attributes of a realm.  Options:
\begin{description}
\item[{\sphinxstylestrong{-subtrees} \sphinxstyleemphasis{subtree\_dn\_list}}] \leavevmode
Specifies the list of subtrees containing the principals of a
realm.  The list contains the DNs of the subtree objects separated
by colon (\sphinxcode{:}).  This list replaces the existing list.

\item[{\sphinxstylestrong{-sscope} \sphinxstyleemphasis{search\_scope}}] \leavevmode
Specifies the scope for searching the principals under the
subtrees.  The possible values are 1 or one (one level), 2 or sub
(subtrees).

\item[{\sphinxstylestrong{-containerref} \sphinxstyleemphasis{container\_reference\_dn} Specifies the DN of the}] \leavevmode
container object in which the principals of a realm will be
created.

\item[{\sphinxstylestrong{-maxtktlife} \sphinxstyleemphasis{max\_ticket\_life}}] \leavevmode
(\DUrole{xref,std,std-ref}{getdate} string) Specifies maximum ticket life for
principals in this realm.

\item[{\sphinxstylestrong{-maxrenewlife} \sphinxstyleemphasis{max\_renewable\_ticket\_life}}] \leavevmode
(\DUrole{xref,std,std-ref}{getdate} string) Specifies maximum renewable life of
tickets for principals in this realm.

\item[{\sphinxstyleemphasis{ticket\_flags}}] \leavevmode
Specifies global ticket flags for the realm.  Allowable flags are
documented in the description of the \sphinxstylestrong{add\_principal} command in
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}.

\end{description}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{kdb5\PYGZus{}ldap\PYGZus{}util} \PYG{o}{\PYGZhy{}}\PYG{n}{r} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{\PYGZhy{}}\PYG{n}{D} \PYG{n}{cn}\PYG{o}{=}\PYG{n}{admin}\PYG{p}{,}\PYG{n}{o}\PYG{o}{=}\PYG{n}{org} \PYG{o}{\PYGZhy{}}\PYG{n}{H}
    \PYG{n}{ldaps}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{ldap}\PYG{o}{\PYGZhy{}}\PYG{n}{server1}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{n}{modify} \PYG{o}{+}\PYG{n}{requires\PYGZus{}preauth}
\PYG{n}{Password} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=admin,o=org}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\PYG{n}{shell}\PYG{o}{\PYGZpc{}}
\end{sphinxVerbatim}


\subsubsection{view}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-modify-end}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:view}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-view}}\begin{quote}

\sphinxstylestrong{view}
\end{quote}

Displays the attributes of a realm.

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kdb5\PYGZus{}ldap\PYGZus{}util} \PYG{o}{\PYGZhy{}}\PYG{n}{D} \PYG{n}{cn}\PYG{o}{=}\PYG{n}{admin}\PYG{p}{,}\PYG{n}{o}\PYG{o}{=}\PYG{n}{org} \PYG{o}{\PYGZhy{}}\PYG{n}{H} \PYG{n}{ldaps}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{ldap}\PYG{o}{\PYGZhy{}}\PYG{n}{server1}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
    \PYG{o}{\PYGZhy{}}\PYG{n}{r} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{n}{view}
\PYG{n}{Password} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=admin,o=org}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\PYG{n}{Realm} \PYG{n}{Name}\PYG{p}{:} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\PYG{n}{Subtree}\PYG{p}{:} \PYG{n}{ou}\PYG{o}{=}\PYG{n}{users}\PYG{p}{,}\PYG{n}{o}\PYG{o}{=}\PYG{n}{org}
\PYG{n}{Subtree}\PYG{p}{:} \PYG{n}{ou}\PYG{o}{=}\PYG{n}{servers}\PYG{p}{,}\PYG{n}{o}\PYG{o}{=}\PYG{n}{org}
\PYG{n}{SearchScope}\PYG{p}{:} \PYG{n}{ONE}
\PYG{n}{Maximum} \PYG{n}{ticket} \PYG{n}{life}\PYG{p}{:} \PYG{l+m+mi}{0} \PYG{n}{days} \PYG{l+m+mi}{01}\PYG{p}{:}\PYG{l+m+mi}{00}\PYG{p}{:}\PYG{l+m+mi}{00}
\PYG{n}{Maximum} \PYG{n}{renewable} \PYG{n}{life}\PYG{p}{:} \PYG{l+m+mi}{0} \PYG{n}{days} \PYG{l+m+mi}{10}\PYG{p}{:}\PYG{l+m+mi}{00}\PYG{p}{:}\PYG{l+m+mi}{00}
\PYG{n}{Ticket} \PYG{n}{flags}\PYG{p}{:} \PYG{n}{DISALLOW\PYGZus{}FORWARDABLE} \PYG{n}{REQUIRES\PYGZus{}PWCHANGE}
\end{sphinxVerbatim}


\subsubsection{destroy}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:destroy}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-view-end}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-destroy}}\begin{quote}

\sphinxstylestrong{destroy} {[}\sphinxstylestrong{-f}{]}
\end{quote}

Destroys an existing realm. Options:
\begin{description}
\item[{\sphinxstylestrong{-f}}] \leavevmode
If specified, will not prompt the user for confirmation.

\end{description}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
shell\PYGZpc{} kdb5\PYGZus{}ldap\PYGZus{}util \PYGZhy{}r ATHENA.MIT.EDU \PYGZhy{}D cn=admin,o=org \PYGZhy{}H
    ldaps://ldap\PYGZhy{}server1.mit.edu destroy
Password for \PYGZdq{}cn=admin,o=org\PYGZdq{}:
Deleting KDC database of \PYGZsq{}ATHENA.MIT.EDU\PYGZsq{}, are you sure?
(type \PYGZsq{}yes\PYGZsq{} to confirm)? yes
OK, deleting database of \PYGZsq{}ATHENA.MIT.EDU\PYGZsq{}...
shell\PYGZpc{}
\end{sphinxVerbatim}


\subsubsection{list}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-destroy-end}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:list}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-list}}\begin{quote}

\sphinxstylestrong{list}
\end{quote}

Lists the names of realms under the container.

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{kdb5\PYGZus{}ldap\PYGZus{}util} \PYG{o}{\PYGZhy{}}\PYG{n}{D} \PYG{n}{cn}\PYG{o}{=}\PYG{n}{admin}\PYG{p}{,}\PYG{n}{o}\PYG{o}{=}\PYG{n}{org} \PYG{o}{\PYGZhy{}}\PYG{n}{H}
    \PYG{n}{ldaps}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{ldap}\PYG{o}{\PYGZhy{}}\PYG{n}{server1}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{n+nb}{list}
\PYG{n}{Password} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=admin,o=org}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\PYG{n}{OPENLDAP}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\PYG{n}{MEDIA}\PYG{o}{\PYGZhy{}}\PYG{n}{LAB}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\PYG{n}{shell}\PYG{o}{\PYGZpc{}}
\end{sphinxVerbatim}


\subsubsection{stashsrvpw}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-list-end}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:stashsrvpw}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-stashsrvpw}}\begin{quote}

\sphinxstylestrong{stashsrvpw}
{[}\sphinxstylestrong{-f} \sphinxstyleemphasis{filename}{]}
\sphinxstyleemphasis{name}
\end{quote}

Allows an administrator to store the password for service object in a
file so that KDC and Administration server can use it to authenticate
to the LDAP server.  Options:
\begin{description}
\item[{\sphinxstylestrong{-f} \sphinxstyleemphasis{filename}}] \leavevmode
Specifies the complete path of the service password file. By
default, \sphinxcode{/usr/local/var/service\_passwd} is used.

\item[{\sphinxstyleemphasis{name}}] \leavevmode
Specifies the name of the object whose password is to be stored.
If {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}} or {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} are configured for
simple binding, this should be the distinguished name it will
use as given by the \sphinxstylestrong{ldap\_kdc\_dn} or \sphinxstylestrong{ldap\_kadmind\_dn}
variable in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.  If the KDC or kadmind is
configured for SASL binding, this should be the authentication
name it will use as given by the \sphinxstylestrong{ldap\_kdc\_sasl\_authcid} or
\sphinxstylestrong{ldap\_kadmind\_sasl\_authcid} variable.

\end{description}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kdb5\PYGZus{}ldap\PYGZus{}util} \PYG{n}{stashsrvpw} \PYG{o}{\PYGZhy{}}\PYG{n}{f} \PYG{o}{/}\PYG{n}{home}\PYG{o}{/}\PYG{n}{andrew}\PYG{o}{/}\PYG{n}{conf\PYGZus{}keyfile}
    \PYG{n}{cn}\PYG{o}{=}\PYG{n}{service}\PYG{o}{\PYGZhy{}}\PYG{n}{kdc}\PYG{p}{,}\PYG{n}{o}\PYG{o}{=}\PYG{n}{org}
\PYG{n}{Password} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=service\PYGZhy{}kdc,o=org}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\PYG{n}{Re}\PYG{o}{\PYGZhy{}}\PYG{n}{enter} \PYG{n}{password} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=service\PYGZhy{}kdc,o=org}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{create\_policy}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:create-policy}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-stashsrvpw-end}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-create-policy}}\begin{quote}

\sphinxstylestrong{create\_policy}
{[}\sphinxstylestrong{-maxtktlife} \sphinxstyleemphasis{max\_ticket\_life}{]}
{[}\sphinxstylestrong{-maxrenewlife} \sphinxstyleemphasis{max\_renewable\_ticket\_life}{]}
{[}\sphinxstyleemphasis{ticket\_flags}{]}
\sphinxstyleemphasis{policy\_name}
\end{quote}

Creates a ticket policy in the directory.  Options:
\begin{description}
\item[{\sphinxstylestrong{-maxtktlife} \sphinxstyleemphasis{max\_ticket\_life}}] \leavevmode
(\DUrole{xref,std,std-ref}{getdate} string) Specifies maximum ticket life for
principals.

\item[{\sphinxstylestrong{-maxrenewlife} \sphinxstyleemphasis{max\_renewable\_ticket\_life}}] \leavevmode
(\DUrole{xref,std,std-ref}{getdate} string) Specifies maximum renewable life of
tickets for principals.

\item[{\sphinxstyleemphasis{ticket\_flags}}] \leavevmode
Specifies the ticket flags.  If this option is not specified, by
default, no restriction will be set by the policy.  Allowable
flags are documented in the description of the \sphinxstylestrong{add\_principal}
command in {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}.

\item[{\sphinxstyleemphasis{policy\_name}}] \leavevmode
Specifies the name of the ticket policy.

\end{description}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kdb5\PYGZus{}ldap\PYGZus{}util} \PYG{o}{\PYGZhy{}}\PYG{n}{D} \PYG{n}{cn}\PYG{o}{=}\PYG{n}{admin}\PYG{p}{,}\PYG{n}{o}\PYG{o}{=}\PYG{n}{org} \PYG{o}{\PYGZhy{}}\PYG{n}{H} \PYG{n}{ldaps}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{ldap}\PYG{o}{\PYGZhy{}}\PYG{n}{server1}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
    \PYG{o}{\PYGZhy{}}\PYG{n}{r} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{n}{create\PYGZus{}policy} \PYG{o}{\PYGZhy{}}\PYG{n}{maxtktlife} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{1 day}\PYG{l+s+s2}{\PYGZdq{}}
    \PYG{o}{\PYGZhy{}}\PYG{n}{maxrenewlife} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{1 week}\PYG{l+s+s2}{\PYGZdq{}} \PYG{o}{\PYGZhy{}}\PYG{n}{allow\PYGZus{}postdated} \PYG{o}{+}\PYG{n}{needchange}
    \PYG{o}{\PYGZhy{}}\PYG{n}{allow\PYGZus{}forwardable} \PYG{n}{tktpolicy}
\PYG{n}{Password} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=admin,o=org}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{modify\_policy}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:modify-policy}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-create-policy-end}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-modify-policy}}\begin{quote}

\sphinxstylestrong{modify\_policy}
{[}\sphinxstylestrong{-maxtktlife} \sphinxstyleemphasis{max\_ticket\_life}{]}
{[}\sphinxstylestrong{-maxrenewlife} \sphinxstyleemphasis{max\_renewable\_ticket\_life}{]}
{[}\sphinxstyleemphasis{ticket\_flags}{]}
\sphinxstyleemphasis{policy\_name}
\end{quote}

Modifies the attributes of a ticket policy.  Options are same as for
\sphinxstylestrong{create\_policy}.

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kdb5\PYGZus{}ldap\PYGZus{}util} \PYG{o}{\PYGZhy{}}\PYG{n}{D} \PYG{n}{cn}\PYG{o}{=}\PYG{n}{admin}\PYG{p}{,}\PYG{n}{o}\PYG{o}{=}\PYG{n}{org} \PYG{o}{\PYGZhy{}}\PYG{n}{H}
    \PYG{n}{ldaps}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{ldap}\PYG{o}{\PYGZhy{}}\PYG{n}{server1}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu} \PYG{o}{\PYGZhy{}}\PYG{n}{r} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{n}{modify\PYGZus{}policy}
    \PYG{o}{\PYGZhy{}}\PYG{n}{maxtktlife} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{60 minutes}\PYG{l+s+s2}{\PYGZdq{}} \PYG{o}{\PYGZhy{}}\PYG{n}{maxrenewlife} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{10 hours}\PYG{l+s+s2}{\PYGZdq{}}
    \PYG{o}{+}\PYG{n}{allow\PYGZus{}postdated} \PYG{o}{\PYGZhy{}}\PYG{n}{requires\PYGZus{}preauth} \PYG{n}{tktpolicy}
\PYG{n}{Password} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=admin,o=org}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\end{sphinxVerbatim}


\subsubsection{view\_policy}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:view-policy}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-modify-policy-end}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-view-policy}}\begin{quote}

\sphinxstylestrong{view\_policy}
\sphinxstyleemphasis{policy\_name}
\end{quote}

Displays the attributes of the named ticket policy.

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kdb5\PYGZus{}ldap\PYGZus{}util} \PYG{o}{\PYGZhy{}}\PYG{n}{D} \PYG{n}{cn}\PYG{o}{=}\PYG{n}{admin}\PYG{p}{,}\PYG{n}{o}\PYG{o}{=}\PYG{n}{org} \PYG{o}{\PYGZhy{}}\PYG{n}{H} \PYG{n}{ldaps}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{ldap}\PYG{o}{\PYGZhy{}}\PYG{n}{server1}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
    \PYG{o}{\PYGZhy{}}\PYG{n}{r} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{n}{view\PYGZus{}policy} \PYG{n}{tktpolicy}
\PYG{n}{Password} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=admin,o=org}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\PYG{n}{Ticket} \PYG{n}{policy}\PYG{p}{:} \PYG{n}{tktpolicy}
\PYG{n}{Maximum} \PYG{n}{ticket} \PYG{n}{life}\PYG{p}{:} \PYG{l+m+mi}{0} \PYG{n}{days} \PYG{l+m+mi}{01}\PYG{p}{:}\PYG{l+m+mi}{00}\PYG{p}{:}\PYG{l+m+mi}{00}
\PYG{n}{Maximum} \PYG{n}{renewable} \PYG{n}{life}\PYG{p}{:} \PYG{l+m+mi}{0} \PYG{n}{days} \PYG{l+m+mi}{10}\PYG{p}{:}\PYG{l+m+mi}{00}\PYG{p}{:}\PYG{l+m+mi}{00}
\PYG{n}{Ticket} \PYG{n}{flags}\PYG{p}{:} \PYG{n}{DISALLOW\PYGZus{}FORWARDABLE} \PYG{n}{REQUIRES\PYGZus{}PWCHANGE}
\end{sphinxVerbatim}


\subsubsection{destroy\_policy}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:destroy-policy}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-view-policy-end}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-destroy-policy}}\begin{quote}

\sphinxstylestrong{destroy\_policy}
{[}\sphinxstylestrong{-force}{]}
\sphinxstyleemphasis{policy\_name}
\end{quote}

Destroys an existing ticket policy.  Options:
\begin{description}
\item[{\sphinxstylestrong{-force}}] \leavevmode
Forces the deletion of the policy object.  If not specified, the
user will be prompted for confirmation before deleting the policy.

\item[{\sphinxstyleemphasis{policy\_name}}] \leavevmode
Specifies the name of the ticket policy.

\end{description}

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
kdb5\PYGZus{}ldap\PYGZus{}util \PYGZhy{}D cn=admin,o=org \PYGZhy{}H ldaps://ldap\PYGZhy{}server1.mit.edu
    \PYGZhy{}r ATHENA.MIT.EDU destroy\PYGZus{}policy tktpolicy
Password for \PYGZdq{}cn=admin,o=org\PYGZdq{}:
This will delete the policy object \PYGZsq{}tktpolicy\PYGZsq{}, are you sure?
(type \PYGZsq{}yes\PYGZsq{} to confirm)? yes
** policy object \PYGZsq{}tktpolicy\PYGZsq{} deleted.
\end{sphinxVerbatim}


\subsubsection{list\_policy}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:list-policy}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-destroy-policy-end}}\phantomsection\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-list-policy}}\begin{quote}

\sphinxstylestrong{list\_policy}
\end{quote}

Lists ticket policies.

Example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kdb5\PYGZus{}ldap\PYGZus{}util} \PYG{o}{\PYGZhy{}}\PYG{n}{D} \PYG{n}{cn}\PYG{o}{=}\PYG{n}{admin}\PYG{p}{,}\PYG{n}{o}\PYG{o}{=}\PYG{n}{org} \PYG{o}{\PYGZhy{}}\PYG{n}{H} \PYG{n}{ldaps}\PYG{p}{:}\PYG{o}{/}\PYG{o}{/}\PYG{n}{ldap}\PYG{o}{\PYGZhy{}}\PYG{n}{server1}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}
    \PYG{o}{\PYGZhy{}}\PYG{n}{r} \PYG{n}{ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{n}{list\PYGZus{}policy}
\PYG{n}{Password} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{cn=admin,o=org}\PYG{l+s+s2}{\PYGZdq{}}\PYG{p}{:}
\PYG{n}{tktpolicy}
\PYG{n}{tmppolicy}
\PYG{n}{userpolicy}
\end{sphinxVerbatim}


\subsection{ENVIRONMENT}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:environment}}\label{\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-list-policy-end}}
See \DUrole{xref,std,std-ref}{kerberos(7)} for a description of Kerberos environment
variables.


\subsection{SEE ALSO}
\label{\detokenize{admin/admin_commands/kdb5_ldap_util:see-also}}
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}, \DUrole{xref,std,std-ref}{kerberos(7)}


\section{krb5kdc}
\label{\detokenize{admin/admin_commands/krb5kdc::doc}}\label{\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}}\label{\detokenize{admin/admin_commands/krb5kdc:krb5kdc}}

\subsection{SYNOPSIS}
\label{\detokenize{admin/admin_commands/krb5kdc:synopsis}}
\sphinxstylestrong{krb5kdc}
{[}\sphinxstylestrong{-x} \sphinxstyleemphasis{db\_args}{]}
{[}\sphinxstylestrong{-d} \sphinxstyleemphasis{dbname}{]}
{[}\sphinxstylestrong{-k} \sphinxstyleemphasis{keytype}{]}
{[}\sphinxstylestrong{-M} \sphinxstyleemphasis{mkeyname}{]}
{[}\sphinxstylestrong{-p} \sphinxstyleemphasis{portnum}{]}
{[}\sphinxstylestrong{-m}{]}
{[}\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}{]}
{[}\sphinxstylestrong{-n}{]}
{[}\sphinxstylestrong{-w} \sphinxstyleemphasis{numworkers}{]}
{[}\sphinxstylestrong{-P} \sphinxstyleemphasis{pid\_file}{]}
{[}\sphinxstylestrong{-T} \sphinxstyleemphasis{time\_offset}{]}


\subsection{DESCRIPTION}
\label{\detokenize{admin/admin_commands/krb5kdc:description}}
krb5kdc is the Kerberos version 5 Authentication Service and Key
Distribution Center (AS/KDC).


\subsection{OPTIONS}
\label{\detokenize{admin/admin_commands/krb5kdc:options}}
The \sphinxstylestrong{-r} \sphinxstyleemphasis{realm} option specifies the realm for which the server
should provide service.  This option may be specified multiple times
to serve multiple realms.  If no \sphinxstylestrong{-r} option is given, the default
realm (as specified in {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}) will be served.

The \sphinxstylestrong{-d} \sphinxstyleemphasis{dbname} option specifies the name under which the
principal database can be found.  This option does not apply to the
LDAP database.

The \sphinxstylestrong{-k} \sphinxstyleemphasis{keytype} option specifies the key type of the master key
to be entered manually as a password when \sphinxstylestrong{-m} is given; the default
is \sphinxcode{aes256-cts-hmac-sha1-96}.

The \sphinxstylestrong{-M} \sphinxstyleemphasis{mkeyname} option specifies the principal name for the
master key in the database (usually \sphinxcode{K/M} in the KDC’s realm).

The \sphinxstylestrong{-m} option specifies that the master database password should
be fetched from the keyboard rather than from a stash file.

The \sphinxstylestrong{-n} option specifies that the KDC does not put itself in the
background and does not disassociate itself from the terminal.

The \sphinxstylestrong{-P} \sphinxstyleemphasis{pid\_file} option tells the KDC to write its PID into
\sphinxstyleemphasis{pid\_file} after it starts up.  This can be used to identify whether
the KDC is still running and to allow init scripts to stop the correct
process.

The \sphinxstylestrong{-p} \sphinxstyleemphasis{portnum} option specifies the default UDP and TCP port
numbers which the KDC should listen on for Kerberos version 5
requests, as a comma-separated list.  This value overrides the port
numbers specified in the {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdcdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}kdcdefaults{]}}}}} section of
{\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}, but may be overridden by realm-specific values.
If no value is given from any source, the default port is 88.

The \sphinxstylestrong{-w} \sphinxstyleemphasis{numworkers} option tells the KDC to fork \sphinxstyleemphasis{numworkers}
processes to listen to the KDC ports and process requests in parallel.
The top level KDC process (whose pid is recorded in the pid file if
the \sphinxstylestrong{-P} option is also given) acts as a supervisor.  The supervisor
will relay SIGHUP signals to the worker subprocesses, and will
terminate the worker subprocess if the it is itself terminated or if
any other worker process exits.

The \sphinxstylestrong{-x} \sphinxstyleemphasis{db\_args} option specifies database-specific arguments.
See {\hyperref[\detokenize{admin/admin_commands/kadmin_local:dboptions}]{\sphinxcrossref{\DUrole{std,std-ref}{Database Options}}}} in {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} for
supported arguments.

The \sphinxstylestrong{-T} \sphinxstyleemphasis{offset} option specifies a time offset, in seconds, which
the KDC will operate under.  It is intended only for testing purposes.


\subsection{EXAMPLE}
\label{\detokenize{admin/admin_commands/krb5kdc:example}}
The KDC may service requests for multiple realms (maximum 32 realms).
The realms are listed on the command line.  Per-realm options that can
be specified on the command line pertain for each realm that follows
it and are superseded by subsequent definitions of the same option.

For example:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{krb5kdc} \PYG{o}{\PYGZhy{}}\PYG{n}{p} \PYG{l+m+mi}{2001} \PYG{o}{\PYGZhy{}}\PYG{n}{r} \PYG{n}{REALM1} \PYG{o}{\PYGZhy{}}\PYG{n}{p} \PYG{l+m+mi}{2002} \PYG{o}{\PYGZhy{}}\PYG{n}{r} \PYG{n}{REALM2} \PYG{o}{\PYGZhy{}}\PYG{n}{r} \PYG{n}{REALM3}
\end{sphinxVerbatim}

specifies that the KDC listen on port 2001 for REALM1 and on port 2002
for REALM2 and REALM3.  Additionally, per-realm parameters may be
specified in the {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} file.  The location of this file
may be specified by the \sphinxstylestrong{KRB5\_KDC\_PROFILE} environment variable.
Per-realm parameters specified in this file take precedence over
options specified on the command line.  See the {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}
description for further details.


\subsection{ENVIRONMENT}
\label{\detokenize{admin/admin_commands/krb5kdc:environment}}
See \DUrole{xref,std,std-ref}{kerberos(7)} for a description of Kerberos environment
variables.


\subsection{SEE ALSO}
\label{\detokenize{admin/admin_commands/krb5kdc:see-also}}
{\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}}, {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}, {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}},
{\hyperref[\detokenize{admin/admin_commands/kdb5_ldap_util:kdb5-ldap-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_ldap\_util}}}}, \DUrole{xref,std,std-ref}{kerberos(7)}


\section{kprop}
\label{\detokenize{admin/admin_commands/kprop:kprop-8}}\label{\detokenize{admin/admin_commands/kprop::doc}}\label{\detokenize{admin/admin_commands/kprop:kprop}}

\subsection{SYNOPSIS}
\label{\detokenize{admin/admin_commands/kprop:synopsis}}
\sphinxstylestrong{kprop}
{[}\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}{]}
{[}\sphinxstylestrong{-f} \sphinxstyleemphasis{file}{]}
{[}\sphinxstylestrong{-d}{]}
{[}\sphinxstylestrong{-P} \sphinxstyleemphasis{port}{]}
{[}\sphinxstylestrong{-s} \sphinxstyleemphasis{keytab}{]}
\sphinxstyleemphasis{replica\_host}


\subsection{DESCRIPTION}
\label{\detokenize{admin/admin_commands/kprop:description}}
kprop is used to securely propagate a Kerberos V5 database dump file
from the primary Kerberos server to a replica Kerberos server, which is
specified by \sphinxstyleemphasis{replica\_host}.  The dump file must be created by
{\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}}.


\subsection{OPTIONS}
\label{\detokenize{admin/admin_commands/kprop:options}}\begin{description}
\item[{\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}}] \leavevmode
Specifies the realm of the primary server.

\item[{\sphinxstylestrong{-f} \sphinxstyleemphasis{file}}] \leavevmode
Specifies the filename where the dumped principal database file is
to be found; by default the dumped database file is normally
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/replica\_datatrans}.

\item[{\sphinxstylestrong{-P} \sphinxstyleemphasis{port}}] \leavevmode
Specifies the port to use to contact the {\hyperref[\detokenize{admin/admin_commands/kpropd:kpropd-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kpropd}}}} server
on the remote host.

\item[{\sphinxstylestrong{-d}}] \leavevmode
Prints debugging information.

\item[{\sphinxstylestrong{-s} \sphinxstyleemphasis{keytab}}] \leavevmode
Specifies the location of the keytab file.

\end{description}


\subsection{ENVIRONMENT}
\label{\detokenize{admin/admin_commands/kprop:environment}}
See \DUrole{xref,std,std-ref}{kerberos(7)} for a description of Kerberos environment
variables.


\subsection{SEE ALSO}
\label{\detokenize{admin/admin_commands/kprop:see-also}}
{\hyperref[\detokenize{admin/admin_commands/kpropd:kpropd-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kpropd}}}}, {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}}, {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}},
\DUrole{xref,std,std-ref}{kerberos(7)}


\section{kpropd}
\label{\detokenize{admin/admin_commands/kpropd::doc}}\label{\detokenize{admin/admin_commands/kpropd:kpropd}}\label{\detokenize{admin/admin_commands/kpropd:kpropd-8}}

\subsection{SYNOPSIS}
\label{\detokenize{admin/admin_commands/kpropd:synopsis}}
\sphinxstylestrong{kpropd}
{[}\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}{]}
{[}\sphinxstylestrong{-A} \sphinxstyleemphasis{admin\_server}{]}
{[}\sphinxstylestrong{-a} \sphinxstyleemphasis{acl\_file}{]}
{[}\sphinxstylestrong{-f} \sphinxstyleemphasis{replica\_dumpfile}{]}
{[}\sphinxstylestrong{-F} \sphinxstyleemphasis{principal\_database}{]}
{[}\sphinxstylestrong{-p} \sphinxstyleemphasis{kdb5\_util\_prog}{]}
{[}\sphinxstylestrong{-P} \sphinxstyleemphasis{port}{]}
{[}\sphinxstylestrong{\textendash{}pid-file}=\sphinxstyleemphasis{pid\_file}{]}
{[}\sphinxstylestrong{-D}{]}
{[}\sphinxstylestrong{-d}{]}
{[}\sphinxstylestrong{-s} \sphinxstyleemphasis{keytab\_file}{]}


\subsection{DESCRIPTION}
\label{\detokenize{admin/admin_commands/kpropd:description}}
The \sphinxstyleemphasis{kpropd} command runs on the replica KDC server.  It listens for
update requests made by the {\hyperref[\detokenize{admin/admin_commands/kprop:kprop-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop}}}} program.  If incremental
propagation is enabled, it periodically requests incremental updates
from the primary KDC.

When the replica receives a kprop request from the primary, kpropd
accepts the dumped KDC database and places it in a file, and then runs
{\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}} to load the dumped database into the active
database which is used by {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}}.  This allows the primary
Kerberos server to use {\hyperref[\detokenize{admin/admin_commands/kprop:kprop-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop}}}} to propagate its database to
the replica servers.  Upon a successful download of the KDC database
file, the replica Kerberos server will have an up-to-date KDC
database.

Where incremental propagation is not used, kpropd is commonly invoked
out of inetd(8) as a nowait service.  This is done by adding a line to
the \sphinxcode{/etc/inetd.conf} file which looks like this:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kprop}  \PYG{n}{stream}  \PYG{n}{tcp}  \PYG{n}{nowait}  \PYG{n}{root}  \PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{sbin}\PYG{o}{/}\PYG{n}{kpropd}  \PYG{n}{kpropd}
\end{sphinxVerbatim}

kpropd can also run as a standalone daemon, backgrounding itself and
waiting for connections on port 754 (or the port specified with the
\sphinxstylestrong{-P} option if given).  Standalone mode is required for incremental
propagation.  Starting in release 1.11, kpropd automatically detects
whether it was run from inetd and runs in standalone mode if it is
not.  Prior to release 1.11, the \sphinxstylestrong{-S} option is required to run
kpropd in standalone mode; this option is now accepted for backward
compatibility but does nothing.

Incremental propagation may be enabled with the \sphinxstylestrong{iprop\_enable}
variable in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}.  If incremental propagation is
enabled, the replica periodically polls the primary KDC for updates, at
an interval determined by the \sphinxstylestrong{iprop\_replica\_poll} variable.  If the
replica receives updates, kpropd updates its log file with any updates
from the primary.  {\hyperref[\detokenize{admin/admin_commands/kproplog:kproplog-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kproplog}}}} can be used to view a summary of
the update entry log on the replica KDC.  If incremental propagation
is enabled, the principal \sphinxcode{kiprop/replicahostname@REALM} (where
\sphinxstyleemphasis{replicahostname} is the name of the replica KDC host, and \sphinxstyleemphasis{REALM} is
the name of the Kerberos realm) must be present in the replica’s
keytab file.

{\hyperref[\detokenize{admin/admin_commands/kproplog:kproplog-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kproplog}}}} can be used to force full replication when iprop is
enabled.


\subsection{OPTIONS}
\label{\detokenize{admin/admin_commands/kpropd:options}}\begin{description}
\item[{\sphinxstylestrong{-r} \sphinxstyleemphasis{realm}}] \leavevmode
Specifies the realm of the primary server.

\item[{\sphinxstylestrong{-A} \sphinxstyleemphasis{admin\_server}}] \leavevmode
Specifies the server to be contacted for incremental updates; by
default, the primary admin server is contacted.

\item[{\sphinxstylestrong{-f} \sphinxstyleemphasis{file}}] \leavevmode
Specifies the filename where the dumped principal database file is
to be stored; by default the dumped database file is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/from\_master}.

\item[{\sphinxstylestrong{-F} \sphinxstyleemphasis{kerberos\_db}}] \leavevmode
Path to the Kerberos database file, if not the default.

\item[{\sphinxstylestrong{-p}}] \leavevmode
Allows the user to specify the pathname to the {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}}
program; by default the pathname used is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{SBINDIR}}}}\sphinxcode{/kdb5\_util}.

\item[{\sphinxstylestrong{-D}}] \leavevmode
In this mode, kpropd will not detach itself from the current job
and run in the background.  Instead, it will run in the
foreground.

\item[{\sphinxstylestrong{-d}}] \leavevmode
Turn on debug mode.  kpropd will print out debugging messages
during the database propogation and will run in the foreground
(implies \sphinxstylestrong{-D}).

\item[{\sphinxstylestrong{-P}}] \leavevmode
Allow for an alternate port number for kpropd to listen on.  This
is only useful in combination with the \sphinxstylestrong{-S} option.

\item[{\sphinxstylestrong{-a} \sphinxstyleemphasis{acl\_file}}] \leavevmode
Allows the user to specify the path to the kpropd.acl file; by
default the path used is {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/kpropd.acl}.

\item[{\sphinxstylestrong{\textendash{}pid-file}=\sphinxstyleemphasis{pid\_file}}] \leavevmode
In standalone mode, write the process ID of the daemon into
\sphinxstyleemphasis{pid\_file}.

\item[{\sphinxstylestrong{-s} \sphinxstyleemphasis{keytab\_file}}] \leavevmode
Path to a keytab to use for acquiring acceptor credentials.

\item[{\sphinxstylestrong{-x} \sphinxstyleemphasis{db\_args}}] \leavevmode
Database-specific arguments.  See {\hyperref[\detokenize{admin/admin_commands/kadmin_local:dboptions}]{\sphinxcrossref{\DUrole{std,std-ref}{Database Options}}}} in {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} for supported arguments.

\end{description}


\subsection{FILES}
\label{\detokenize{admin/admin_commands/kpropd:files}}\begin{description}
\item[{kpropd.acl}] \leavevmode
Access file for kpropd; the default location is
\sphinxcode{/usr/local/var/krb5kdc/kpropd.acl}.  Each entry is a line
containing the principal of a host from which the local machine
will allow Kerberos database propagation via {\hyperref[\detokenize{admin/admin_commands/kprop:kprop-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop}}}}.

\end{description}


\subsection{ENVIRONMENT}
\label{\detokenize{admin/admin_commands/kpropd:environment}}
See \DUrole{xref,std,std-ref}{kerberos(7)} for a description of Kerberos environment
variables.


\subsection{SEE ALSO}
\label{\detokenize{admin/admin_commands/kpropd:see-also}}
{\hyperref[\detokenize{admin/admin_commands/kprop:kprop-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop}}}}, {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}}, {\hyperref[\detokenize{admin/admin_commands/krb5kdc:krb5kdc-8}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5kdc}}}},
\DUrole{xref,std,std-ref}{kerberos(7)}, inetd(8)


\section{kproplog}
\label{\detokenize{admin/admin_commands/kproplog:kproplog}}\label{\detokenize{admin/admin_commands/kproplog:kproplog-8}}\label{\detokenize{admin/admin_commands/kproplog::doc}}

\subsection{SYNOPSIS}
\label{\detokenize{admin/admin_commands/kproplog:synopsis}}
\sphinxstylestrong{kproplog} {[}\sphinxstylestrong{-h}{]} {[}\sphinxstylestrong{-e} \sphinxstyleemphasis{num}{]} {[}-v{]}
\sphinxstylestrong{kproplog} {[}-R{]}


\subsection{DESCRIPTION}
\label{\detokenize{admin/admin_commands/kproplog:description}}
The kproplog command displays the contents of the KDC database update
log to standard output.  It can be used to keep track of incremental
updates to the principal database.  The update log file contains the
update log maintained by the {\hyperref[\detokenize{admin/admin_commands/kadmind:kadmind-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmind}}}} process on the primary
KDC server and the {\hyperref[\detokenize{admin/admin_commands/kpropd:kpropd-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kpropd}}}} process on the replica KDC
servers.  When updates occur, they are logged to this file.
Subsequently any KDC replica configured for incremental updates will
request the current data from the primary KDC and update their log
file with any updates returned.

The kproplog command requires read access to the update log file.  It
will display update entries only for the KDC it runs on.

If no options are specified, kproplog displays a summary of the update
log.  If invoked on the primary, kproplog also displays all of the
update entries.  If invoked on a replica KDC server, kproplog displays
only a summary of the updates, which includes the serial number of the
last update received and the associated time stamp of the last update.


\subsection{OPTIONS}
\label{\detokenize{admin/admin_commands/kproplog:options}}\begin{description}
\item[{\sphinxstylestrong{-R}}] \leavevmode
Reset the update log.  This forces full resynchronization.  If
used on a replica then that replica will request a full resync.
If used on the primary then all replicas will request full
resyncs.

\item[{\sphinxstylestrong{-h}}] \leavevmode
Display a summary of the update log.  This information includes
the database version number, state of the database, the number of
updates in the log, the time stamp of the first and last update,
and the version number of the first and last update entry.

\item[{\sphinxstylestrong{-e} \sphinxstyleemphasis{num}}] \leavevmode
Display the last \sphinxstyleemphasis{num} update entries in the log.  This is useful
when debugging synchronization between KDC servers.

\item[{\sphinxstylestrong{-v}}] \leavevmode
Display individual attributes per update.  An example of the
output generated for one entry:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{Update} \PYG{n}{Entry}
   \PYG{n}{Update} \PYG{n}{serial} \PYG{c+c1}{\PYGZsh{} : 4}
   \PYG{n}{Update} \PYG{n}{operation} \PYG{p}{:} \PYG{n}{Add}
   \PYG{n}{Update} \PYG{n}{principal} \PYG{p}{:} \PYG{n}{test}\PYG{n+nd}{@EXAMPLE}\PYG{o}{.}\PYG{n}{COM}
   \PYG{n}{Update} \PYG{n}{size} \PYG{p}{:} \PYG{l+m+mi}{424}
   \PYG{n}{Update} \PYG{n}{committed} \PYG{p}{:} \PYG{k+kc}{True}
   \PYG{n}{Update} \PYG{n}{time} \PYG{n}{stamp} \PYG{p}{:} \PYG{n}{Fri} \PYG{n}{Feb} \PYG{l+m+mi}{20} \PYG{l+m+mi}{23}\PYG{p}{:}\PYG{l+m+mi}{37}\PYG{p}{:}\PYG{l+m+mi}{42} \PYG{l+m+mi}{2004}
   \PYG{n}{Attributes} \PYG{n}{changed} \PYG{p}{:} \PYG{l+m+mi}{6}
         \PYG{n}{Principal}
         \PYG{n}{Key} \PYG{n}{data}
         \PYG{n}{Password} \PYG{n}{last} \PYG{n}{changed}
         \PYG{n}{Modifying} \PYG{n}{principal}
         \PYG{n}{Modification} \PYG{n}{time}
         \PYG{n}{TL} \PYG{n}{data}
\end{sphinxVerbatim}

\end{description}


\subsection{ENVIRONMENT}
\label{\detokenize{admin/admin_commands/kproplog:environment}}
See \DUrole{xref,std,std-ref}{kerberos(7)} for a description of Kerberos environment
variables.


\subsection{SEE ALSO}
\label{\detokenize{admin/admin_commands/kproplog:see-also}}
{\hyperref[\detokenize{admin/admin_commands/kpropd:kpropd-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kpropd}}}}, \DUrole{xref,std,std-ref}{kerberos(7)}


\section{ktutil}
\label{\detokenize{admin/admin_commands/ktutil:ktutil-1}}\label{\detokenize{admin/admin_commands/ktutil::doc}}\label{\detokenize{admin/admin_commands/ktutil:ktutil}}

\subsection{SYNOPSIS}
\label{\detokenize{admin/admin_commands/ktutil:synopsis}}
\sphinxstylestrong{ktutil}


\subsection{DESCRIPTION}
\label{\detokenize{admin/admin_commands/ktutil:description}}
The ktutil command invokes a command interface from which an
administrator can read, write, or edit entries in a keytab.  (Kerberos
V4 srvtab files are no longer supported.)


\subsection{COMMANDS}
\label{\detokenize{admin/admin_commands/ktutil:commands}}

\subsubsection{list}
\label{\detokenize{admin/admin_commands/ktutil:list}}\begin{quote}

\sphinxstylestrong{list} {[}\sphinxstylestrong{-t}{]} {[}\sphinxstylestrong{-k}{]} {[}\sphinxstylestrong{-e}{]}
\end{quote}

Displays the current keylist.  If \sphinxstylestrong{-t}, \sphinxstylestrong{-k}, and/or \sphinxstylestrong{-e} are
specified, also display the timestamp, key contents, or enctype
(respectively).

Alias: \sphinxstylestrong{l}


\subsubsection{read\_kt}
\label{\detokenize{admin/admin_commands/ktutil:read-kt}}\begin{quote}

\sphinxstylestrong{read\_kt} \sphinxstyleemphasis{keytab}
\end{quote}

Read the Kerberos V5 keytab file \sphinxstyleemphasis{keytab} into the current keylist.

Alias: \sphinxstylestrong{rkt}


\subsubsection{write\_kt}
\label{\detokenize{admin/admin_commands/ktutil:write-kt}}\begin{quote}

\sphinxstylestrong{write\_kt} \sphinxstyleemphasis{keytab}
\end{quote}

Write the current keylist into the Kerberos V5 keytab file \sphinxstyleemphasis{keytab}.

Alias: \sphinxstylestrong{wkt}


\subsubsection{clear\_list}
\label{\detokenize{admin/admin_commands/ktutil:clear-list}}\begin{quote}

\sphinxstylestrong{clear\_list}
\end{quote}

Clear the current keylist.

Alias: \sphinxstylestrong{clear}


\subsubsection{delete\_entry}
\label{\detokenize{admin/admin_commands/ktutil:delete-entry}}\begin{quote}

\sphinxstylestrong{delete\_entry} \sphinxstyleemphasis{slot}
\end{quote}

Delete the entry in slot number \sphinxstyleemphasis{slot} from the current keylist.

Alias: \sphinxstylestrong{delent}


\subsubsection{add\_entry}
\label{\detokenize{admin/admin_commands/ktutil:add-entry}}\begin{quote}

\sphinxstylestrong{add\_entry} \{\sphinxstylestrong{-key}\textbar{}\sphinxstylestrong{-password}\} \sphinxstylestrong{-p} \sphinxstyleemphasis{principal}
\sphinxstylestrong{-k} \sphinxstyleemphasis{kvno} {[}\sphinxstylestrong{-e} \sphinxstyleemphasis{enctype}{]} {[}\sphinxstylestrong{-f}\textbar{}\sphinxstylestrong{-s} \sphinxstyleemphasis{salt}{]}
\end{quote}

Add \sphinxstyleemphasis{principal} to keylist using key or password.  If the \sphinxstylestrong{-f} flag
is specified, salt information will be fetched from the KDC; in this
case the \sphinxstylestrong{-e} flag may be omitted, or it may be supplied to force a
particular enctype.  If the \sphinxstylestrong{-f} flag is not specified, the \sphinxstylestrong{-e}
flag must be specified, and the default salt will be used unless
overridden with the \sphinxstylestrong{-s} option.

Alias: \sphinxstylestrong{addent}


\subsubsection{list\_requests}
\label{\detokenize{admin/admin_commands/ktutil:list-requests}}\begin{quote}

\sphinxstylestrong{list\_requests}
\end{quote}

Displays a listing of available commands.

Aliases: \sphinxstylestrong{lr}, \sphinxstylestrong{?}


\subsubsection{quit}
\label{\detokenize{admin/admin_commands/ktutil:quit}}\begin{quote}

\sphinxstylestrong{quit}
\end{quote}

Quits ktutil.

Aliases: \sphinxstylestrong{exit}, \sphinxstylestrong{q}


\subsection{EXAMPLE}
\label{\detokenize{admin/admin_commands/ktutil:example}}\begin{quote}

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{ktutil}\PYG{p}{:}  \PYG{n}{add\PYGZus{}entry} \PYG{o}{\PYGZhy{}}\PYG{n}{password} \PYG{o}{\PYGZhy{}}\PYG{n}{p} \PYG{n}{alice}\PYG{n+nd}{@BLEEP}\PYG{o}{.}\PYG{n}{COM} \PYG{o}{\PYGZhy{}}\PYG{n}{k} \PYG{l+m+mi}{1} \PYG{o}{\PYGZhy{}}\PYG{n}{e}
    \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}
\PYG{n}{Password} \PYG{k}{for} \PYG{n}{alice}\PYG{n+nd}{@BLEEP}\PYG{o}{.}\PYG{n}{COM}\PYG{p}{:}
\PYG{n}{ktutil}\PYG{p}{:}  \PYG{n}{add\PYGZus{}entry} \PYG{o}{\PYGZhy{}}\PYG{n}{password} \PYG{o}{\PYGZhy{}}\PYG{n}{p} \PYG{n}{alice}\PYG{n+nd}{@BLEEP}\PYG{o}{.}\PYG{n}{COM} \PYG{o}{\PYGZhy{}}\PYG{n}{k} \PYG{l+m+mi}{1} \PYG{o}{\PYGZhy{}}\PYG{n}{e}
    \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}
\PYG{n}{Password} \PYG{k}{for} \PYG{n}{alice}\PYG{n+nd}{@BLEEP}\PYG{o}{.}\PYG{n}{COM}\PYG{p}{:}
\PYG{n}{ktutil}\PYG{p}{:}  \PYG{n}{write\PYGZus{}kt} \PYG{n}{alice}\PYG{o}{.}\PYG{n}{keytab}
\PYG{n}{ktutil}\PYG{p}{:}
\end{sphinxVerbatim}
\end{quote}


\subsection{ENVIRONMENT}
\label{\detokenize{admin/admin_commands/ktutil:environment}}
See \DUrole{xref,std,std-ref}{kerberos(7)} for a description of Kerberos environment
variables.


\subsection{SEE ALSO}
\label{\detokenize{admin/admin_commands/ktutil:see-also}}
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}, {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}}, \DUrole{xref,std,std-ref}{kerberos(7)}


\section{k5srvutil}
\label{\detokenize{admin/admin_commands/k5srvutil:k5srvutil-1}}\label{\detokenize{admin/admin_commands/k5srvutil::doc}}\label{\detokenize{admin/admin_commands/k5srvutil:k5srvutil}}

\subsection{SYNOPSIS}
\label{\detokenize{admin/admin_commands/k5srvutil:synopsis}}
\sphinxstylestrong{k5srvutil} \sphinxstyleemphasis{operation}
{[}\sphinxstylestrong{-i}{]}
{[}\sphinxstylestrong{-f} \sphinxstyleemphasis{filename}{]}
{[}\sphinxstylestrong{-e} \sphinxstyleemphasis{keysalts}{]}


\subsection{DESCRIPTION}
\label{\detokenize{admin/admin_commands/k5srvutil:description}}
k5srvutil allows an administrator to list keys currently in
a keytab, to obtain new keys for a principal currently in a keytab,
or to delete non-current keys from a keytab.

\sphinxstyleemphasis{operation} must be one of the following:
\begin{description}
\item[{\sphinxstylestrong{list}}] \leavevmode
Lists the keys in a keytab, showing version number and principal
name.

\item[{\sphinxstylestrong{change}}] \leavevmode
Uses the kadmin protocol to update the keys in the Kerberos
database to new randomly-generated keys, and updates the keys in
the keytab to match.  If a key’s version number doesn’t match the
version number stored in the Kerberos server’s database, then the
operation will fail.  If the \sphinxstylestrong{-i} flag is given, k5srvutil will
prompt for confirmation before changing each key.  If the \sphinxstylestrong{-k}
option is given, the old and new keys will be displayed.
Ordinarily, keys will be generated with the default encryption
types and key salts.  This can be overridden with the \sphinxstylestrong{-e}
option.  Old keys are retained in the keytab so that existing
tickets continue to work, but \sphinxstylestrong{delold} should be used after
such tickets expire, to prevent attacks against the old keys.

\item[{\sphinxstylestrong{delold}}] \leavevmode
Deletes keys that are not the most recent version from the keytab.
This operation should be used some time after a change operation
to remove old keys, after existing tickets issued for the service
have expired.  If the \sphinxstylestrong{-i} flag is given, then k5srvutil will
prompt for confirmation for each principal.

\item[{\sphinxstylestrong{delete}}] \leavevmode
Deletes particular keys in the keytab, interactively prompting for
each key.

\end{description}

In all cases, the default keytab is used unless this is overridden by
the \sphinxstylestrong{-f} option.

k5srvutil uses the {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} program to edit the keytab in
place.


\subsection{ENVIRONMENT}
\label{\detokenize{admin/admin_commands/k5srvutil:environment}}
See \DUrole{xref,std,std-ref}{kerberos(7)} for a description of Kerberos environment
variables.


\subsection{SEE ALSO}
\label{\detokenize{admin/admin_commands/k5srvutil:see-also}}
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}, {\hyperref[\detokenize{admin/admin_commands/ktutil:ktutil-1}]{\sphinxcrossref{\DUrole{std,std-ref}{ktutil}}}}, \DUrole{xref,std,std-ref}{kerberos(7)}


\section{sserver}
\label{\detokenize{admin/admin_commands/sserver:sserver-8}}\label{\detokenize{admin/admin_commands/sserver::doc}}\label{\detokenize{admin/admin_commands/sserver:sserver}}

\subsection{SYNOPSIS}
\label{\detokenize{admin/admin_commands/sserver:synopsis}}
\sphinxstylestrong{sserver}
{[} \sphinxstylestrong{-p} \sphinxstyleemphasis{port} {]}
{[} \sphinxstylestrong{-S} \sphinxstyleemphasis{keytab} {]}
{[} \sphinxstyleemphasis{server\_port} {]}


\subsection{DESCRIPTION}
\label{\detokenize{admin/admin_commands/sserver:description}}
sserver and \DUrole{xref,std,std-ref}{sclient(1)} are a simple demonstration client/server
application.  When sclient connects to sserver, it performs a Kerberos
authentication, and then sserver returns to sclient the Kerberos
principal which was used for the Kerberos authentication.  It makes a
good test that Kerberos has been successfully installed on a machine.

The service name used by sserver and sclient is sample.  Hence,
sserver will require that there be a keytab entry for the service
\sphinxcode{sample/hostname.domain.name@REALM.NAME}.  This keytab is generated
using the {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} program.  The keytab file is usually
installed as {\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{DEFKTNAME}}}}.

The \sphinxstylestrong{-S} option allows for a different keytab than the default.

sserver is normally invoked out of inetd(8), using a line in
\sphinxcode{/etc/inetd.conf} that looks like this:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{sample} \PYG{n}{stream} \PYG{n}{tcp} \PYG{n}{nowait} \PYG{n}{root} \PYG{o}{/}\PYG{n}{usr}\PYG{o}{/}\PYG{n}{local}\PYG{o}{/}\PYG{n}{sbin}\PYG{o}{/}\PYG{n}{sserver} \PYG{n}{sserver}
\end{sphinxVerbatim}

Since \sphinxcode{sample} is normally not a port defined in \sphinxcode{/etc/services},
you will usually have to add a line to \sphinxcode{/etc/services} which looks
like this:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{sample}          \PYG{l+m+mi}{13135}\PYG{o}{/}\PYG{n}{tcp}
\end{sphinxVerbatim}

When using sclient, you will first have to have an entry in the
Kerberos database, by using {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}, and then you have to get
Kerberos tickets, by using \DUrole{xref,std,std-ref}{kinit(1)}.  Also, if you are running
the sclient program on a different host than the sserver it will be
connecting to, be sure that both hosts have an entry in /etc/services
for the sample tcp port, and that the same port number is in both
files.

When you run sclient you should see something like this:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{sendauth} \PYG{n}{succeeded}\PYG{p}{,} \PYG{n}{reply} \PYG{o+ow}{is}\PYG{p}{:}
\PYG{n}{reply} \PYG{n+nb}{len} \PYG{l+m+mi}{32}\PYG{p}{,} \PYG{n}{contents}\PYG{p}{:}
\PYG{n}{You} \PYG{n}{are} \PYG{n}{nlgilman}\PYG{n+nd}{@JIMI}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}
\end{sphinxVerbatim}


\subsection{COMMON ERROR MESSAGES}
\label{\detokenize{admin/admin_commands/sserver:common-error-messages}}\begin{enumerate}
\item {} 
kinit returns the error:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{kinit}\PYG{p}{:} \PYG{n}{Client} \PYG{o+ow}{not} \PYG{n}{found} \PYG{o+ow}{in} \PYG{n}{Kerberos} \PYG{n}{database} \PYG{k}{while} \PYG{n}{getting}
       \PYG{n}{initial} \PYG{n}{credentials}
\end{sphinxVerbatim}

This means that you didn’t create an entry for your username in the
Kerberos database.

\item {} 
sclient returns the error:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{unknown} \PYG{n}{service} \PYG{n}{sample}\PYG{o}{/}\PYG{n}{tcp}\PYG{p}{;} \PYG{n}{check} \PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{services}
\end{sphinxVerbatim}

This means that you don’t have an entry in /etc/services for the
sample tcp port.

\item {} 
sclient returns the error:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{connect}\PYG{p}{:} \PYG{n}{Connection} \PYG{n}{refused}
\end{sphinxVerbatim}

This probably means you didn’t edit /etc/inetd.conf correctly, or
you didn’t restart inetd after editing inetd.conf.

\item {} 
sclient returns the error:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{sclient}\PYG{p}{:} \PYG{n}{Server} \PYG{o+ow}{not} \PYG{n}{found} \PYG{o+ow}{in} \PYG{n}{Kerberos} \PYG{n}{database} \PYG{k}{while} \PYG{n}{using}
         \PYG{n}{sendauth}
\end{sphinxVerbatim}

This means that the \sphinxcode{sample/hostname@LOCAL.REALM} service was not
defined in the Kerberos database; it should be created using
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}, and a keytab file needs to be generated to make
the key for that service principal available for sclient.

\item {} 
sclient returns the error:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{sendauth} \PYG{n}{rejected}\PYG{p}{,} \PYG{n}{error} \PYG{n}{reply} \PYG{o+ow}{is}\PYG{p}{:}
    \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{No such file or directory}\PYG{l+s+s2}{\PYGZdq{}}
\end{sphinxVerbatim}

This probably means sserver couldn’t find the keytab file.  It was
probably not installed in the proper directory.

\end{enumerate}


\subsection{ENVIRONMENT}
\label{\detokenize{admin/admin_commands/sserver:environment}}
See \DUrole{xref,std,std-ref}{kerberos(7)} for a description of Kerberos environment
variables.


\subsection{SEE ALSO}
\label{\detokenize{admin/admin_commands/sserver:see-also}}
\DUrole{xref,std,std-ref}{sclient(1)}, \DUrole{xref,std,std-ref}{kerberos(7)}, services(5), inetd(8)


\chapter{MIT Kerberos defaults}
\label{\detokenize{mitK5defaults:mitk5defaults}}\label{\detokenize{mitK5defaults::doc}}\label{\detokenize{mitK5defaults:mit-kerberos-defaults}}

\section{General defaults}
\label{\detokenize{mitK5defaults:general-defaults}}

\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|T|}
\hline
\sphinxstylethead{\sphinxstyletheadfamily 
Description
\unskip}\relax &\sphinxstylethead{\sphinxstyletheadfamily 
Default
\unskip}\relax &\sphinxstylethead{\sphinxstyletheadfamily 
Environment
\unskip}\relax \\
\hline
\DUrole{xref,std,std-ref}{keytab\_definition} file
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{DEFKTNAME}}}}
&
\sphinxstylestrong{KRB5\_KTNAME}
\\
\hline
Client \DUrole{xref,std,std-ref}{keytab\_definition} file
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{DEFCKTNAME}}}}
&
\sphinxstylestrong{KRB5\_CLIENT\_KTNAME}
\\
\hline
Kerberos config file {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}
&
\sphinxcode{/etc/krb5.conf}\sphinxcode{:}{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{SYSCONFDIR}}}}\sphinxcode{/krb5.conf}
&
\sphinxstylestrong{KRB5\_CONFIG}
\\
\hline
KDC config file {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}}
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/kdc.conf}
&
\sphinxstylestrong{KRB5\_KDC\_PROFILE}
\\
\hline
GSS mechanism config file
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{SYSCONFDIR}}}}\sphinxcode{/gss/mech}
&
\sphinxstylestrong{GSS\_MECH\_CONFIG}
\\
\hline
KDC database path (DB2)
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/principal}
&\\
\hline
Master key \DUrole{xref,std,std-ref}{stash\_definition}
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/.k5.}\sphinxstyleemphasis{realm}
&\\
\hline
Admin server ACL file {\hyperref[\detokenize{admin/conf_files/kadm5_acl:kadm5-acl-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kadm5.acl}}}}
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/kadm5.acl}
&\\
\hline
OTP socket directory
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{RUNSTATEDIR}}}}\sphinxcode{/krb5kdc}
&\\
\hline
Plugin base directory
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LIBDIR}}}}\sphinxcode{/krb5/plugins}
&\\
\hline
\DUrole{xref,std,std-ref}{rcache\_definition} directory
&
\sphinxcode{/var/tmp}
&
\sphinxstylestrong{KRB5RCACHEDIR}
\\
\hline
Master key default enctype
&
\sphinxcode{aes256-cts-hmac-sha1-96}
&\\
\hline
Default {\hyperref[\detokenize{admin/conf_files/kdc_conf:keysalt-lists}]{\sphinxcrossref{\DUrole{std,std-ref}{keysalt list}}}}
&
\sphinxcode{aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal}
&\\
\hline
Permitted enctypes
&
\sphinxcode{aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac}
&\\
\hline
KDC default port
&
88
&\\
\hline
Admin server port
&
749
&\\
\hline
Password change port
&
464
&\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}


\section{Replica KDC propagation defaults}
\label{\detokenize{mitK5defaults:replica-kdc-propagation-defaults}}
This table shows defaults used by the {\hyperref[\detokenize{admin/admin_commands/kprop:kprop-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop}}}} and
{\hyperref[\detokenize{admin/admin_commands/kpropd:kpropd-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kpropd}}}} programs.


\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|T|}
\hline
\sphinxstylethead{\sphinxstyletheadfamily 
Description
\unskip}\relax &\sphinxstylethead{\sphinxstyletheadfamily 
Default
\unskip}\relax &\sphinxstylethead{\sphinxstyletheadfamily 
Environment
\unskip}\relax \\
\hline
kprop database dump file
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/replica\_datatrans}
&\\
\hline
kpropd temporary dump file
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/from\_master}
&\\
\hline
kdb5\_util location
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{SBINDIR}}}}\sphinxcode{/kdb5\_util}
&\\
\hline
kprop location
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{SBINDIR}}}}\sphinxcode{/kprop}
&\\
\hline
kpropd ACL file
&
{\hyperref[\detokenize{mitK5defaults:paths}]{\sphinxcrossref{\DUrole{std,std-ref}{LOCALSTATEDIR}}}}\sphinxcode{/krb5kdc}\sphinxcode{/kpropd.acl}
&\\
\hline
kprop port
&
754
&
KPROP\_PORT
\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}


\section{Default paths for Unix-like systems}
\label{\detokenize{mitK5defaults:paths}}\label{\detokenize{mitK5defaults:default-paths-for-unix-like-systems}}
On Unix-like systems, some paths used by MIT krb5 depend on parameters
chosen at build time.  For a custom build, these paths default to
subdirectories of \sphinxcode{/usr/local}.  When MIT krb5 is integrated into an
operating system, the paths are generally chosen to match the
operating system’s filesystem layout.


\begin{savenotes}\sphinxattablestart
\centering
\begin{tabulary}{\linewidth}[t]{|T|T|T|T|}
\hline
\sphinxstylethead{\sphinxstyletheadfamily 
Description
\unskip}\relax &\sphinxstylethead{\sphinxstyletheadfamily 
Symbolic name
\unskip}\relax &\sphinxstylethead{\sphinxstyletheadfamily 
Custom build path
\unskip}\relax &\sphinxstylethead{\sphinxstyletheadfamily 
Typical OS path
\unskip}\relax \\
\hline
User programs
&
BINDIR
&
\sphinxcode{/usr/local/bin}
&
\sphinxcode{/usr/bin}
\\
\hline
Libraries and plugins
&
LIBDIR
&
\sphinxcode{/usr/local/lib}
&
\sphinxcode{/usr/lib}
\\
\hline
Parent of KDC state dir
&
LOCALSTATEDIR
&
\sphinxcode{/usr/local/var}
&
\sphinxcode{/var}
\\
\hline
Parent of KDC runtime dir
&
RUNSTATEDIR
&
\sphinxcode{/usr/local/var/run}
&
\sphinxcode{/run}
\\
\hline
Administrative programs
&
SBINDIR
&
\sphinxcode{/usr/local/sbin}
&
\sphinxcode{/usr/sbin}
\\
\hline
Alternate krb5.conf dir
&
SYSCONFDIR
&
\sphinxcode{/usr/local/etc}
&
\sphinxcode{/etc}
\\
\hline
Default ccache name
&
DEFCCNAME
&
\sphinxcode{FILE:/tmp/krb5cc\_\%\{uid\}}
&
\sphinxcode{FILE:/tmp/krb5cc\_\%\{uid\}}
\\
\hline
Default keytab name
&
DEFKTNAME
&
\sphinxcode{FILE:/etc/krb5.keytab}
&
\sphinxcode{FILE:/etc/krb5.keytab}
\\
\hline
Default PKCS11 module
&
PKCS11\_MODNAME
&
\sphinxcode{opensc-pkcs11.so}
&
\sphinxcode{opensc-pkcs11.so}
\\
\hline
\end{tabulary}
\par
\sphinxattableend\end{savenotes}

The default client keytab name (DEFCKTNAME) typically defaults to
\sphinxcode{FILE:/usr/local/var/krb5/user/\%\{euid\}/client.keytab} for a custom
build.  A native build will typically use a path which will vary
according to the operating system’s layout of \sphinxcode{/var}.


\chapter{Environment variables}
\label{\detokenize{admin/env_variables:environment-variables}}\label{\detokenize{admin/env_variables::doc}}
This content has moved to \DUrole{xref,std,std-ref}{kerberos(7)}.


\chapter{Troubleshooting}
\label{\detokenize{admin/troubleshoot:troubleshoot}}\label{\detokenize{admin/troubleshoot::doc}}\label{\detokenize{admin/troubleshoot:troubleshooting}}

\section{Trace logging}
\label{\detokenize{admin/troubleshoot:trace-logging}}\label{\detokenize{admin/troubleshoot:id1}}
Most programs using MIT krb5 1.9 or later can be made to provide
information about internal krb5 library operations using trace
logging.  To enable this, set the \sphinxstylestrong{KRB5\_TRACE} environment variable
to a filename before running the program.  On many operating systems,
the filename \sphinxcode{/dev/stdout} can be used to send trace logging output
to standard output.

Some programs do not honor \sphinxstylestrong{KRB5\_TRACE}, either because they use
secure library contexts (this generally applies to setuid programs and
parts of the login system) or because they take direct control of the
trace logging system using the API.

Here is a short example showing trace logging output for an invocation
of the \DUrole{xref,std,std-ref}{kvno(1)} command:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{shell}\PYG{o}{\PYGZpc{}} \PYG{n}{env} \PYG{n}{KRB5\PYGZus{}TRACE}\PYG{o}{=}\PYG{o}{/}\PYG{n}{dev}\PYG{o}{/}\PYG{n}{stdout} \PYG{n}{kvno} \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{KRBTEST}\PYG{o}{.}\PYG{n}{COM}
\PYG{p}{[}\PYG{l+m+mi}{9138}\PYG{p}{]} \PYG{l+m+mf}{1332348778.823276}\PYG{p}{:} \PYG{n}{Getting} \PYG{n}{credentials} \PYG{n}{user}\PYG{n+nd}{@KRBTEST}\PYG{o}{.}\PYG{n}{COM} \PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZgt{}}
    \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{KRBTEST}\PYG{o}{.}\PYG{n}{COM}\PYG{n+nd}{@KRBTEST}\PYG{o}{.}\PYG{n}{COM} \PYG{n}{using} \PYG{n}{ccache}
    \PYG{n}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{me}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{/}\PYG{n}{build}\PYG{o}{/}\PYG{n}{testdir}\PYG{o}{/}\PYG{n}{ccache}
\PYG{p}{[}\PYG{l+m+mi}{9138}\PYG{p}{]} \PYG{l+m+mf}{1332348778.823381}\PYG{p}{:} \PYG{n}{Retrieving} \PYG{n}{user}\PYG{n+nd}{@KRBTEST}\PYG{o}{.}\PYG{n}{COM} \PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZgt{}}
    \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{KRBTEST}\PYG{o}{.}\PYG{n}{COM}\PYG{n+nd}{@KRBTEST}\PYG{o}{.}\PYG{n}{COM} \PYG{k+kn}{from}
    \PYG{n+nn}{FILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{me}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{/}\PYG{n}{build}\PYG{o}{/}\PYG{n}{testdir}\PYG{o}{/}\PYG{n}{ccache} \PYG{k}{with} \PYG{n}{result}\PYG{p}{:} \PYG{l+m+mi}{0}\PYG{o}{/}\PYG{n}{Unknown} \PYG{n}{code} \PYG{l+m+mi}{0}
\PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{KRBTEST}\PYG{o}{.}\PYG{n}{COM}\PYG{n+nd}{@KRBTEST}\PYG{o}{.}\PYG{n}{COM}\PYG{p}{:} \PYG{n}{kvno} \PYG{o}{=} \PYG{l+m+mi}{1}
\end{sphinxVerbatim}


\section{List of errors}
\label{\detokenize{admin/troubleshoot:list-of-errors}}

\subsection{Frequently seen errors}
\label{\detokenize{admin/troubleshoot:frequently-seen-errors}}\begin{enumerate}
\item {} 
{\hyperref[\detokenize{admin/troubleshoot:init-creds-etype-nosupp}]{\sphinxcrossref{\DUrole{std,std-ref}{KDC has no support for encryption type while getting initial credentials}}}}

\item {} 
{\hyperref[\detokenize{admin/troubleshoot:cert-chain-etype-nosupp}]{\sphinxcrossref{\DUrole{std,std-ref}{credential verification failed: KDC has no support for encryption type}}}}

\item {} 
{\hyperref[\detokenize{admin/troubleshoot:err-cert-chain-cert-expired}]{\sphinxcrossref{\DUrole{std,std-ref}{Cannot create cert chain: certificate has expired}}}}

\end{enumerate}


\subsection{Errors seen by admins}
\label{\detokenize{admin/troubleshoot:errors-seen-by-admins}}\phantomsection\label{\detokenize{admin/troubleshoot:prop-failed-start}}\begin{enumerate}
\item {} 
{\hyperref[\detokenize{admin/troubleshoot:kprop-no-route}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop: No route to host while connecting to server}}}}

\item {} 
{\hyperref[\detokenize{admin/troubleshoot:kprop-con-refused}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop: Connection refused while connecting to server}}}}

\item {} 
{\hyperref[\detokenize{admin/troubleshoot:kprop-sendauth-exchange}]{\sphinxcrossref{\DUrole{std,std-ref}{kprop: Server rejected authentication (during sendauth exchange) while authenticating to server}}}}

\end{enumerate}
\phantomsection\label{\detokenize{admin/troubleshoot:prop-failed-end}}

\bigskip\hrule\bigskip



\subsubsection{KDC has no support for encryption type while getting initial credentials}
\label{\detokenize{admin/troubleshoot:kdc-has-no-support-for-encryption-type-while-getting-initial-credentials}}\label{\detokenize{admin/troubleshoot:init-creds-etype-nosupp}}

\subsubsection{credential verification failed: KDC has no support for encryption type}
\label{\detokenize{admin/troubleshoot:credential-verification-failed-kdc-has-no-support-for-encryption-type}}\label{\detokenize{admin/troubleshoot:cert-chain-etype-nosupp}}
This most commonly happens when trying to use a principal with only
DES keys, in a release (MIT krb5 1.7 or later) which disables DES by
default.  DES encryption is considered weak due to its inadequate key
size.  If you cannot migrate away from its use, you can re-enable DES
by adding \sphinxcode{allow\_weak\_crypto = true} to the {\hyperref[\detokenize{admin/conf_files/krb5_conf:libdefaults}]{\sphinxcrossref{\DUrole{std,std-ref}{{[}libdefaults{]}}}}}
section of {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}}.


\subsubsection{Cannot create cert chain: certificate has expired}
\label{\detokenize{admin/troubleshoot:cannot-create-cert-chain-certificate-has-expired}}\label{\detokenize{admin/troubleshoot:err-cert-chain-cert-expired}}
This error message indicates that PKINIT authentication failed because
the client certificate, KDC certificate, or one of the certificates in
the signing chain above them has expired.

If the KDC certificate has expired, this message appears in the KDC
log file, and the client will receive a “Preauthentication failed”
error.  (Prior to release 1.11, the KDC log file message erroneously
appears as “Out of memory”.  Prior to release 1.12, the client will
receive a “Generic error”.)

If the client or a signing certificate has expired, this message may
appear in {\hyperref[\detokenize{admin/troubleshoot:trace-logging}]{\sphinxcrossref{trace\_logging}}} output from \DUrole{xref,std,std-ref}{kinit(1)} or, starting in
release 1.12, as an error message from kinit or another program which
gets initial tickets.  The error message is more likely to appear
properly on the client if the principal entry has no long-term keys.


\subsubsection{kprop: No route to host while connecting to server}
\label{\detokenize{admin/troubleshoot:kprop-no-route}}\label{\detokenize{admin/troubleshoot:kprop-no-route-to-host-while-connecting-to-server}}
Make sure that the hostname of the replica KDC (as given to kprop) is
correct, and that any firewalls between the primary and the replica
allow a connection on port 754.


\subsubsection{kprop: Connection refused while connecting to server}
\label{\detokenize{admin/troubleshoot:kprop-connection-refused-while-connecting-to-server}}\label{\detokenize{admin/troubleshoot:kprop-con-refused}}
If the replica KDC is intended to run kpropd out of inetd, make sure
that inetd is configured to accept krb5\_prop connections.  inetd may
need to be restarted or sent a SIGHUP to recognize the new
configuration.  If the replica is intended to run kpropd in standalone
mode, make sure that it is running.


\subsubsection{kprop: Server rejected authentication (during sendauth exchange) while authenticating to server}
\label{\detokenize{admin/troubleshoot:kprop-sendauth-exchange}}\label{\detokenize{admin/troubleshoot:kprop-server-rejected-authentication-during-sendauth-exchange-while-authenticating-to-server}}
Make sure that:
\begin{enumerate}
\item {} 
The time is synchronized between the primary and replica KDCs.

\item {} 
The master stash file was copied from the primary to the expected
location on the replica.

\item {} 
The replica has a keytab file in the default location containing a
\sphinxcode{host} principal for the replica’s hostname.

\end{enumerate}


\chapter{Advanced topics}
\label{\detokenize{admin/advanced/index:advanced-topics}}\label{\detokenize{admin/advanced/index::doc}}

\section{Retiring DES}
\label{\detokenize{admin/advanced/retiring-des:retiring-des}}\label{\detokenize{admin/advanced/retiring-des::doc}}\label{\detokenize{admin/advanced/retiring-des:id1}}
Version 5 of the Kerberos protocol was originally implemented using
the Data Encryption Standard (DES) as a block cipher for encryption.
While it was considered secure at the time, advancements in computational
ability have rendered DES vulnerable to brute force attacks on its 56-bit
keyspace.  As such, it is now considered insecure and should not be
used (\index{RFC!RFC 6649}\sphinxhref{https://tools.ietf.org/html/rfc6649.html}{\sphinxstylestrong{RFC 6649}}).


\subsection{History}
\label{\detokenize{admin/advanced/retiring-des:history}}
DES was used in the original Kerberos implementation, and was the
only cryptosystem in krb5 1.0.  Partial support for triple-DES (3DES) was
added in version 1.1, with full support following in version 1.2.
The Advanced Encryption Standard (AES), which supersedes DES, gained
partial support in version 1.3.0 of krb5 and full support in version 1.3.2.
However, deployments of krb5 using Kerberos databases created with older
versions of krb5 will not necessarily start using strong crypto for
ordinary operation without administrator intervention.

MIT krb5 began flagging deprecated encryption types with release 1.17,
and removed DES (single-DES) support in release 1.18.  As a
consequence, a release prior to 1.18 is required to perform these
migrations.


\subsection{Types of keys}
\label{\detokenize{admin/advanced/retiring-des:types-of-keys}}\begin{itemize}
\item {} 
The database master key:  This key is not exposed to user requests,
but is used to encrypt other key material stored in the kerberos
database.  The database master key is currently stored as \sphinxcode{K/M}
by default.

\item {} 
Password-derived keys:  User principals frequently have keys
derived from a password.  When a new password is set, the KDC
uses various string2key functions to generate keys in the database
for that principal.

\item {} 
Keytab keys:  Application server principals generally use random
keys which are not derived from a password.  When the database
entry is created, the KDC generates random keys of various enctypes
to enter in the database, which are conveyed to the application server
and stored in a keytab.

\item {} 
Session keys:  These are short-term keys generated by the KDC while
processing client requests, with an enctype selected by the KDC.

\end{itemize}

For details on the various enctypes and how enctypes are selected by the KDC
for session keys and client/server long-term keys, see {\hyperref[\detokenize{admin/enctypes:enctypes}]{\sphinxcrossref{\DUrole{std,std-ref}{Encryption types}}}}.
When using the {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} interface to generate new long-term keys,
the \sphinxstylestrong{-e} argument can be used to force a particular set of enctypes,
overriding the KDC default values.

\begin{sphinxadmonition}{note}{Note:}
When the KDC is selecting a session key, it has no knowledge about the
kerberos installation on the server which will receive the service ticket,
only what keys are in the database for the service principal.
In order to allow uninterrupted operation to
clients while migrating away from DES, care must be taken to ensure that
kerberos installations on application server machines are configured to
support newer encryption types before keys of those new encryption types
are created in the Kerberos database for those server principals.
\end{sphinxadmonition}


\subsection{Upgrade procedure}
\label{\detokenize{admin/advanced/retiring-des:upgrade-procedure}}
This procedure assumes that the KDC software has already been upgraded
to a modern version of krb5 that supports non-DES keys, so that the
only remaining task is to update the actual keys used to service requests.
The realm used for demonstrating this procedure, ZONE.MIT.EDU,
is an example of the worst-case scenario, where all keys in the realm
are DES.  The realm was initially created with a very old version of krb5,
and \sphinxstylestrong{supported\_enctypes} in {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} was set to a value
appropriate when the KDC was installed, but was not updated as the KDC
was upgraded:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{realms}\PYG{p}{]}
        \PYG{n}{ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
                \PYG{p}{[}\PYG{o}{.}\PYG{o}{.}\PYG{o}{.}\PYG{p}{]}
                \PYG{n}{master\PYGZus{}key\PYGZus{}type} \PYG{o}{=} \PYG{n}{des}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{crc}
                \PYG{n}{supported\PYGZus{}enctypes} \PYG{o}{=} \PYG{n}{des}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{crc}\PYG{p}{:}\PYG{n}{normal} \PYG{n}{des}\PYG{p}{:}\PYG{n}{normal} \PYG{n}{des}\PYG{p}{:}\PYG{n}{v4} \PYG{n}{des}\PYG{p}{:}\PYG{n}{norealm} \PYG{n}{des}\PYG{p}{:}\PYG{n}{onlyrealm} \PYG{n}{des}\PYG{p}{:}\PYG{n}{afs3}
        \PYG{p}{\PYGZcb{}}
\end{sphinxVerbatim}

This resulted in the keys for all principals in the realm being forced
to DES-only, unless specifically requested using {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}}.

Before starting the upgrade, all KDCs were running krb5 1.11,
and the database entries for some “high-value” principals were:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} kadmin.local \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}q \PYGZsq{}getprinc krbtgt/ZONE.MIT.EDU\PYGZsq{}}
\PYG{p}{[}\PYG{o}{.}\PYG{o}{.}\PYG{o}{.}\PYG{p}{]}
\PYG{n}{Number} \PYG{n}{of} \PYG{n}{keys}\PYG{p}{:} \PYG{l+m+mi}{1}
\PYG{n}{Key}\PYG{p}{:} \PYG{n}{vno} \PYG{l+m+mi}{1}\PYG{p}{,} \PYG{n}{des}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{crc}\PYG{p}{:}\PYG{n}{v4}
\PYG{p}{[}\PYG{o}{.}\PYG{o}{.}\PYG{o}{.}\PYG{p}{]}
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} kadmin.local \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}q \PYGZsq{}getprinc kadmin/admin\PYGZsq{}}
\PYG{p}{[}\PYG{o}{.}\PYG{o}{.}\PYG{o}{.}\PYG{p}{]}
\PYG{n}{Number} \PYG{n}{of} \PYG{n}{keys}\PYG{p}{:} \PYG{l+m+mi}{1}
\PYG{n}{Key}\PYG{p}{:} \PYG{n}{vno} \PYG{l+m+mi}{15}\PYG{p}{,} \PYG{n}{des}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{crc}
\PYG{p}{[}\PYG{o}{.}\PYG{o}{.}\PYG{o}{.}\PYG{p}{]}
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} kadmin.local \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}q \PYGZsq{}getprinc kadmin/changepw\PYGZsq{}}
\PYG{p}{[}\PYG{o}{.}\PYG{o}{.}\PYG{o}{.}\PYG{p}{]}
\PYG{n}{Number} \PYG{n}{of} \PYG{n}{keys}\PYG{p}{:} \PYG{l+m+mi}{1}
\PYG{n}{Key}\PYG{p}{:} \PYG{n}{vno} \PYG{l+m+mi}{14}\PYG{p}{,} \PYG{n}{des}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{crc}
\PYG{p}{[}\PYG{o}{.}\PYG{o}{.}\PYG{o}{.}\PYG{p}{]}
\end{sphinxVerbatim}

The \sphinxcode{krbtgt/REALM} key appears to have never been changed since creation
(its kvno is 1), and all three database entries have only a des-cbc-crc key.


\subsubsection{The krbtgt key and KDC keys}
\label{\detokenize{admin/advanced/retiring-des:the-krbtgt-key-and-kdc-keys}}
Perhaps the biggest single-step improvement in the security of the cell
is gained by strengthening the key of the ticket-granting service principal,
\sphinxcode{krbtgt/REALM}—if this principal’s key is compromised, so is the
entire realm.  Since the server that will handle service tickets
for this principal is the KDC itself, it is easy to guarantee that it
will be configured to support any encryption types which might be
selected.  However, the default KDC behavior when creating new keys is to
remove the old keys, which would invalidate all existing tickets issued
against that principal, rendering the TGTs cached by clients useless.
Instead, a new key can be created with the old key retained, so that
existing tickets will still function until their scheduled expiry
(see {\hyperref[\detokenize{admin/database:changing-krbtgt-key}]{\sphinxcrossref{\DUrole{std,std-ref}{Changing the krbtgt key}}}}).

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} enctypes=aes256\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha1\PYGZhy{}96:normal,\PYGZbs{}}
\PYG{o}{\PYGZgt{}} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}\PYG{p}{:}\PYG{n}{normal}\PYG{p}{,}\PYG{n}{des3}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{p}{:}\PYG{n}{normal}\PYG{p}{,}\PYG{n}{des}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{crc}\PYG{p}{:}\PYG{n}{normal}
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} kadmin.local \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}q \PYGZdq{}cpw \PYGZhy{}e \PYGZdl{}\PYGZob{}enctypes\PYGZcb{} \PYGZhy{}randkey \PYGZbs{}}
\PYG{o}{\PYGZgt{}} \PYG{o}{\PYGZhy{}}\PYG{n}{keepold} \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{l+s+s2}{\PYGZdq{}}
\PYG{n}{Authenticating} \PYG{k}{as} \PYG{n}{principal} \PYG{n}{root}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{password}\PYG{o}{.}
\PYG{n}{Key} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{krbtgt/ZONE.MIT.EDU@ZONE.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{randomized}\PYG{o}{.}
\end{sphinxVerbatim}

\begin{sphinxadmonition}{note}{Note:}
The new \sphinxcode{krbtgt@REALM} key should be propagated to replica KDCs
immediately so that TGTs issued by the primary KDC can be used to
issue service tickets on replica KDCs.  Replica KDCs will refuse
requests using the new TGT kvno until the new krbtgt entry has
been propagated to them.
\end{sphinxadmonition}

It is necessary to explicitly specify the enctypes for the new database
entry, since \sphinxstylestrong{supported\_enctypes} has not been changed.  Leaving
\sphinxstylestrong{supported\_enctypes} unchanged makes a potential rollback operation
easier, since all new keys of new enctypes are the result of explicit
administrator action and can be easily enumerated.
Upgrading the krbtgt key should have minimal user-visible disruption other
than that described in the note above, since only clients which list the
new enctypes as supported will use them, per the procedure
in {\hyperref[\detokenize{admin/enctypes:session-key-selection}]{\sphinxcrossref{\DUrole{std,std-ref}{Session key selection}}}}.
Once the krbtgt key is updated, the session and ticket keys for user
TGTs will be strong keys, but subsequent requests
for service tickets will still get DES keys until the service principals
have new keys generated.  Application service
remains uninterrupted due to the key-selection procedure on the KDC.

After the change, the database entry is now:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} kadmin.local \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}q \PYGZsq{}getprinc krbtgt/ZONE.MIT.EDU\PYGZsq{}}
\PYG{p}{[}\PYG{o}{.}\PYG{o}{.}\PYG{o}{.}\PYG{p}{]}
\PYG{n}{Number} \PYG{n}{of} \PYG{n}{keys}\PYG{p}{:} \PYG{l+m+mi}{5}
\PYG{n}{Key}\PYG{p}{:} \PYG{n}{vno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}
\PYG{n}{Key}\PYG{p}{:} \PYG{n}{vno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}
\PYG{n}{Key}\PYG{p}{:} \PYG{n}{vno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{des3}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}
\PYG{n}{Key}\PYG{p}{:} \PYG{n}{vno} \PYG{l+m+mi}{2}\PYG{p}{,} \PYG{n}{des}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{crc}
\PYG{n}{Key}\PYG{p}{:} \PYG{n}{vno} \PYG{l+m+mi}{1}\PYG{p}{,} \PYG{n}{des}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{crc}\PYG{p}{:}\PYG{n}{v4}
\PYG{p}{[}\PYG{o}{.}\PYG{o}{.}\PYG{o}{.}\PYG{p}{]}
\end{sphinxVerbatim}

Since the expected disruptions from rekeying the krbtgt principal are
minor, after a short testing period, it is
appropriate to rekey the other high-value principals, \sphinxcode{kadmin/admin@REALM}
and \sphinxcode{kadmin/changepw@REALM}. These are the service principals used for
changing user passwords and updating application keytabs.  The kadmin
and password-changing services are regular kerberized services, so the
session-key-selection algorithm described in {\hyperref[\detokenize{admin/enctypes:session-key-selection}]{\sphinxcrossref{\DUrole{std,std-ref}{Session key selection}}}}
applies.  It is particularly important to have strong session keys for
these services, since user passwords and new long-term keys are conveyed
over the encrypted channel.

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} enctypes=aes256\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha1\PYGZhy{}96:normal,\PYGZbs{}}
\PYG{o}{\PYGZgt{}} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}\PYG{p}{:}\PYG{n}{normal}\PYG{p}{,}\PYG{n}{des3}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{p}{:}\PYG{n}{normal}
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} kadmin.local \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}q \PYGZdq{}cpw \PYGZhy{}e \PYGZdl{}\PYGZob{}enctypes\PYGZcb{} \PYGZhy{}randkey \PYGZbs{}}
\PYG{o}{\PYGZgt{}} \PYG{n}{kadmin}\PYG{o}{/}\PYG{n}{admin}\PYG{l+s+s2}{\PYGZdq{}}
\PYG{n}{Authenticating} \PYG{k}{as} \PYG{n}{principal} \PYG{n}{root}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{password}\PYG{o}{.}
\PYG{n}{Key} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{kadmin/admin@ZONE.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{randomized}\PYG{o}{.}
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} kadmin.local \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}q \PYGZdq{}cpw \PYGZhy{}e \PYGZdl{}\PYGZob{}enctypes\PYGZcb{} \PYGZhy{}randkey \PYGZbs{}}
\PYG{o}{\PYGZgt{}} \PYG{n}{kadmin}\PYG{o}{/}\PYG{n}{changepw}\PYG{l+s+s2}{\PYGZdq{}}
\PYG{n}{Authenticating} \PYG{k}{as} \PYG{n}{principal} \PYG{n}{root}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{password}\PYG{o}{.}
\PYG{n}{Key} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{kadmin/changepw@ZONE.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{randomized}\PYG{o}{.}
\end{sphinxVerbatim}

It is not necessary to retain a single-DES key for these services, since
password changes are not part of normal daily workflow, and disruption
from a client failure is likely to be minimal.  Furthermore, if a kerberos
client experiences failure changing a user password or keytab key,
this indicates that that client will become inoperative once services
are rekeyed to non-DES enctypes.  Such problems can be detected early
at this stage, giving more time for corrective action.


\subsubsection{Adding strong keys to application servers}
\label{\detokenize{admin/advanced/retiring-des:adding-strong-keys-to-application-servers}}
Before switching the default enctypes for new keys over to strong enctypes,
it may be desired to test upgrading a handful of services with the
new configuration before flipping the switch for the defaults.  This
still requires using the \sphinxstylestrong{-e} argument in {\hyperref[\detokenize{admin/admin_commands/kadmin_local:kadmin-1}]{\sphinxcrossref{\DUrole{std,std-ref}{kadmin}}}} to get non-default
enctypes:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} enctypes=aes256\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha1\PYGZhy{}96:normal,\PYGZbs{}}
\PYG{o}{\PYGZgt{}} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}\PYG{p}{:}\PYG{n}{normal}\PYG{p}{,}\PYG{n}{des3}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{p}{:}\PYG{n}{normal}\PYG{p}{,}\PYG{n}{des}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{crc}\PYG{p}{:}\PYG{n}{normal}
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} kadmin \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}p zephyr/zephyr@ZONE.MIT.EDU \PYGZhy{}k \PYGZhy{}t \PYGZbs{}}
\PYG{o}{\PYGZgt{}} \PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}  \PYG{o}{\PYGZhy{}}\PYG{n}{q} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{ktadd \PYGZhy{}e \PYGZdl{}}\PYG{l+s+si}{\PYGZob{}enctypes\PYGZcb{}}\PYG{l+s+s2}{ }\PYG{l+s+se}{\PYGZbs{}}
\PYG{l+s+s2}{\PYGZgt{} \PYGZhy{}k /etc/zephyr/krb5.keytab zephyr/zephyr@ZONE.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}}
\PYG{n}{Authenticating} \PYG{k}{as} \PYG{n}{principal} \PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{zephyr}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{keytab} \PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{zephyr}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{4}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{zephyr}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{4}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{zephyr}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{4}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{des3}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{zephyr}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{4}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{des}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{crc} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\end{sphinxVerbatim}

Be sure to remove the old keys from the application keytab, per best
practice.

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} k5srvutil \PYGZhy{}f /etc/zephyr/krb5.keytab delold}
\PYG{n}{Authenticating} \PYG{k}{as} \PYG{n}{principal} \PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{zephyr}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{keytab} \PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{zephyr}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{3} \PYG{n}{removed} \PYG{k+kn}{from} \PYG{n+nn}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{zephyr}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\end{sphinxVerbatim}


\subsubsection{Adding strong keys by default}
\label{\detokenize{admin/advanced/retiring-des:adding-strong-keys-by-default}}
Once the high-visibility services have been rekeyed, it is probably
appropriate to change {\hyperref[\detokenize{admin/conf_files/kdc_conf:kdc-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{kdc.conf}}}} to generate keys with the new
encryption types by default.  This enables server administrators to generate
new enctypes with the \sphinxstylestrong{change} subcommand of {\hyperref[\detokenize{admin/admin_commands/k5srvutil:k5srvutil-1}]{\sphinxcrossref{\DUrole{std,std-ref}{k5srvutil}}}},
and causes user password
changes to add new encryption types for their entries.  It will probably
be necessary to implement administrative controls to cause all user
principal keys to be updated in a reasonable period of time, whether
by forcing password changes or a password synchronization service that
has access to the current password and can add the new keys.

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{realms}\PYG{p}{]}
        \PYG{n}{ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
                \PYG{n}{supported\PYGZus{}enctypes} \PYG{o}{=} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}\PYG{p}{:}\PYG{n}{normal} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}\PYG{p}{:}\PYG{n}{normal} \PYG{n}{des3}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{p}{:}\PYG{n}{normal} \PYG{n}{des3}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{p}{:}\PYG{n}{normal} \PYG{n}{des}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{crc}\PYG{p}{:}\PYG{n}{normal}
\end{sphinxVerbatim}

\begin{sphinxadmonition}{note}{Note:}
The krb5kdc process must be restarted for these changes to take effect.
\end{sphinxadmonition}

At this point, all service administrators can update their services and the
servers behind them to take advantage of strong cryptography.
If necessary, the server’s krb5 installation should be configured and/or
upgraded to a version supporting non-DES keys.  See {\hyperref[\detokenize{admin/enctypes:enctypes}]{\sphinxcrossref{\DUrole{std,std-ref}{Encryption types}}}} for
krb5 version and configuration settings.
Only when the service is configured to accept non-DES keys should
the key version number be incremented and new keys generated
(\sphinxcode{k5srvutil change \&\& k5srvutil delold}).

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{n}{root}\PYG{n+nd}{@dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{p}{:}\PYG{o}{\PYGZti{}}\PYG{c+c1}{\PYGZsh{} k5srvutil change}
\PYG{n}{Authenticating} \PYG{k}{as} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{keytab} \PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{3}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{AES}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{256} \PYG{n}{CTS} \PYG{n}{mode} \PYG{k}{with} \PYG{l+m+mi}{96}\PYG{o}{\PYGZhy{}}\PYG{n}{bit} \PYG{n}{SHA}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{1} \PYG{n}{HMAC} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{3}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{AES}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{128} \PYG{n}{CTS} \PYG{n}{mode} \PYG{k}{with} \PYG{l+m+mi}{96}\PYG{o}{\PYGZhy{}}\PYG{n}{bit} \PYG{n}{SHA}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{1} \PYG{n}{HMAC} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{3}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{Triple} \PYG{n}{DES} \PYG{n}{cbc} \PYG{n}{mode} \PYG{k}{with} \PYG{n}{HMAC}\PYG{o}{/}\PYG{n}{sha1} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{3}\PYG{p}{,} \PYG{n}{encryption} \PYG{n+nb}{type} \PYG{n}{DES} \PYG{n}{cbc} \PYG{n}{mode} \PYG{k}{with} \PYG{n}{CRC}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{32} \PYG{n}{added} \PYG{n}{to} \PYG{n}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{root}\PYG{n+nd}{@dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{p}{:}\PYG{o}{\PYGZti{}}\PYG{c+c1}{\PYGZsh{} klist \PYGZhy{}e \PYGZhy{}k \PYGZhy{}t /etc/krb5.keytab}
\PYG{n}{Keytab} \PYG{n}{name}\PYG{p}{:} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}
\PYG{n}{KVNO} \PYG{n}{Timestamp}         \PYG{n}{Principal}
\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}} \PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}} \PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}\PYG{o}{\PYGZhy{}}
   \PYG{l+m+mi}{2} \PYG{l+m+mi}{10}\PYG{o}{/}\PYG{l+m+mi}{10}\PYG{o}{/}\PYG{l+m+mi}{12} \PYG{l+m+mi}{17}\PYG{p}{:}\PYG{l+m+mi}{03}\PYG{p}{:}\PYG{l+m+mi}{59} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{p}{(}\PYG{n}{DES} \PYG{n}{cbc} \PYG{n}{mode} \PYG{k}{with} \PYG{n}{CRC}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{32}\PYG{p}{)}
   \PYG{l+m+mi}{3} \PYG{l+m+mi}{12}\PYG{o}{/}\PYG{l+m+mi}{12}\PYG{o}{/}\PYG{l+m+mi}{12} \PYG{l+m+mi}{15}\PYG{p}{:}\PYG{l+m+mi}{31}\PYG{p}{:}\PYG{l+m+mi}{19} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{p}{(}\PYG{n}{AES}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{256} \PYG{n}{CTS} \PYG{n}{mode} \PYG{k}{with} \PYG{l+m+mi}{96}\PYG{o}{\PYGZhy{}}\PYG{n}{bit} \PYG{n}{SHA}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{1} \PYG{n}{HMAC}\PYG{p}{)}
   \PYG{l+m+mi}{3} \PYG{l+m+mi}{12}\PYG{o}{/}\PYG{l+m+mi}{12}\PYG{o}{/}\PYG{l+m+mi}{12} \PYG{l+m+mi}{15}\PYG{p}{:}\PYG{l+m+mi}{31}\PYG{p}{:}\PYG{l+m+mi}{19} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{p}{(}\PYG{n}{AES}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{128} \PYG{n}{CTS} \PYG{n}{mode} \PYG{k}{with} \PYG{l+m+mi}{96}\PYG{o}{\PYGZhy{}}\PYG{n}{bit} \PYG{n}{SHA}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{1} \PYG{n}{HMAC}\PYG{p}{)}
   \PYG{l+m+mi}{3} \PYG{l+m+mi}{12}\PYG{o}{/}\PYG{l+m+mi}{12}\PYG{o}{/}\PYG{l+m+mi}{12} \PYG{l+m+mi}{15}\PYG{p}{:}\PYG{l+m+mi}{31}\PYG{p}{:}\PYG{l+m+mi}{19} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{p}{(}\PYG{n}{Triple} \PYG{n}{DES} \PYG{n}{cbc} \PYG{n}{mode} \PYG{k}{with} \PYG{n}{HMAC}\PYG{o}{/}\PYG{n}{sha1}\PYG{p}{)}
   \PYG{l+m+mi}{3} \PYG{l+m+mi}{12}\PYG{o}{/}\PYG{l+m+mi}{12}\PYG{o}{/}\PYG{l+m+mi}{12} \PYG{l+m+mi}{15}\PYG{p}{:}\PYG{l+m+mi}{31}\PYG{p}{:}\PYG{l+m+mi}{19} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{p}{(}\PYG{n}{DES} \PYG{n}{cbc} \PYG{n}{mode} \PYG{k}{with} \PYG{n}{CRC}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{32}\PYG{p}{)}
\PYG{n}{root}\PYG{n+nd}{@dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{p}{:}\PYG{o}{\PYGZti{}}\PYG{c+c1}{\PYGZsh{} k5srvutil delold}
\PYG{n}{Authenticating} \PYG{k}{as} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{keytab} \PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\PYG{n}{Entry} \PYG{k}{for} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{dr}\PYG{o}{\PYGZhy{}}\PYG{n}{willy}\PYG{o}{.}\PYG{n}{xvm}\PYG{o}{.}\PYG{n}{mit}\PYG{o}{.}\PYG{n}{edu}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{kvno} \PYG{l+m+mi}{2} \PYG{n}{removed} \PYG{k+kn}{from} \PYG{n+nn}{keytab} \PYG{n}{WRFILE}\PYG{p}{:}\PYG{o}{/}\PYG{n}{etc}\PYG{o}{/}\PYG{n}{krb5}\PYG{o}{.}\PYG{n}{keytab}\PYG{o}{.}
\end{sphinxVerbatim}

When a single service principal is shared by multiple backend servers in
a load-balanced environment, it may be necessary to schedule downtime
or adjust the population in the load-balanced pool in order to propagate
the updated keytab to all hosts in the pool with minimal service interruption.


\subsubsection{Removing DES keys from usage}
\label{\detokenize{admin/advanced/retiring-des:removing-des-keys-from-usage}}
This situation remains something of a testing or transitory state,
as new DES keys are still being generated, and will be used if requested
by a client.  To make more progress removing DES from the realm, the KDC
should be configured to not generate such keys by default.

\begin{sphinxadmonition}{note}{Note:}
An attacker posing as a client can implement a brute force attack against
a DES key for any principal, if that key is in the current (highest-kvno)
key list.  This attack is only possible if \sphinxstylestrong{allow\_weak\_crypto = true}
is enabled on the KDC.  Setting the \sphinxstylestrong{+requires\_preauth} flag on a
principal forces this attack to be an online attack, much slower than
the offline attack otherwise available to the attacker.  However, setting
this flag on a service principal is not always advisable; see the entry in
{\hyperref[\detokenize{admin/admin_commands/kadmin_local:add-principal}]{\sphinxcrossref{\DUrole{std,std-ref}{add\_principal}}}} for details.
\end{sphinxadmonition}

The following KDC configuration will not generate DES keys by default:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{realms}\PYG{p}{]}
        \PYG{n}{ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{o}{=} \PYG{p}{\PYGZob{}}
                \PYG{n}{supported\PYGZus{}enctypes} \PYG{o}{=} \PYG{n}{aes256}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}\PYG{p}{:}\PYG{n}{normal} \PYG{n}{aes128}\PYG{o}{\PYGZhy{}}\PYG{n}{cts}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{o}{\PYGZhy{}}\PYG{l+m+mi}{96}\PYG{p}{:}\PYG{n}{normal} \PYG{n}{des3}\PYG{o}{\PYGZhy{}}\PYG{n}{cbc}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{p}{:}\PYG{n}{normal} \PYG{n}{des3}\PYG{o}{\PYGZhy{}}\PYG{n}{hmac}\PYG{o}{\PYGZhy{}}\PYG{n}{sha1}\PYG{p}{:}\PYG{n}{normal}
\end{sphinxVerbatim}

\begin{sphinxadmonition}{note}{Note:}
As before, the KDC process must be restarted for this change to take
effect.  It is best practice to update kdc.conf on all KDCs, not just the
primary, to avoid unpleasant surprises should the primary fail and a
replica need to be promoted.
\end{sphinxadmonition}

It is now appropriate to remove the legacy single-DES key from the
\sphinxcode{krbtgt/REALM} entry:

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} kadmin.local \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}q \PYGZdq{}cpw \PYGZhy{}randkey \PYGZhy{}keepold \PYGZbs{}}
\PYG{o}{\PYGZgt{}} \PYG{n}{krbtgt}\PYG{o}{/}\PYG{n}{ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU}\PYG{l+s+s2}{\PYGZdq{}}
\PYG{n}{Authenticating} \PYG{k}{as} \PYG{n}{principal} \PYG{n}{host}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ATHENA}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{password}\PYG{o}{.}
\PYG{n}{Key} \PYG{k}{for} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{krbtgt/ZONE.MIT.EDU@ZONE.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{randomized}\PYG{o}{.}
\end{sphinxVerbatim}

After the maximum ticket lifetime has passed, the old database entry
should be removed.

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
\PYG{p}{[}\PYG{n}{root}\PYG{n+nd}{@casio} \PYG{n}{krb5kdc}\PYG{p}{]}\PYG{c+c1}{\PYGZsh{} kadmin.local \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}q \PYGZsq{}purgekeys krbtgt/ZONE.MIT.EDU\PYGZsq{}}
\PYG{n}{Authenticating} \PYG{k}{as} \PYG{n}{principal} \PYG{n}{root}\PYG{o}{/}\PYG{n}{admin}\PYG{n+nd}{@ZONE}\PYG{o}{.}\PYG{n}{MIT}\PYG{o}{.}\PYG{n}{EDU} \PYG{k}{with} \PYG{n}{password}\PYG{o}{.}
\PYG{n}{Old} \PYG{n}{keys} \PYG{k}{for} \PYG{n}{principal} \PYG{l+s+s2}{\PYGZdq{}}\PYG{l+s+s2}{krbtgt/ZONE.MIT.EDU@ZONE.MIT.EDU}\PYG{l+s+s2}{\PYGZdq{}} \PYG{n}{purged}\PYG{o}{.}
\end{sphinxVerbatim}

After the KDC is restarted with the new \sphinxstylestrong{supported\_enctypes},
all user password changes and application keytab updates will not
generate DES keys by default.

\fvset{hllines={, ,}}%
\begin{sphinxVerbatim}[commandchars=\\\{\}]
contents\PYGZhy{}vnder\PYGZhy{}pressvre:\PYGZti{}\PYGZgt{} kpasswd zonetest@ZONE.MIT.EDU
Password for zonetest@ZONE.MIT.EDU:  [enter old password]
Enter new password:                  [enter new password]
Enter it again:                      [enter new password]
Password changed.
contents\PYGZhy{}vnder\PYGZhy{}pressvre:\PYGZti{}\PYGZgt{} kadmin \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}q \PYGZsq{}getprinc zonetest\PYGZsq{}
[...]
Number of keys: 3
Key: vno 9, aes256\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha1\PYGZhy{}96
Key: vno 9, aes128\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha1\PYGZhy{}96
Key: vno 9, des3\PYGZhy{}cbc\PYGZhy{}sha1
[...]

[kaduk@glossolalia \PYGZti{}]\PYGZdl{} kadmin \PYGZhy{}p kaduk@ZONE.MIT.EDU \PYGZhy{}r ZONE.MIT.EDU \PYGZhy{}k \PYGZbs{}
\PYGZgt{} \PYGZhy{}t kaduk\PYGZhy{}zone.keytab \PYGZhy{}q \PYGZsq{}ktadd \PYGZhy{}k kaduk\PYGZhy{}zone.keytab kaduk@ZONE.MIT.EDU\PYGZsq{}
Authenticating as principal kaduk@ZONE.MIT.EDU with keytab kaduk\PYGZhy{}zone.keytab.
Entry for principal kaduk@ZONE.MIT.EDU with kvno 3, encryption type aes256\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha1\PYGZhy{}96 added to keytab WRFILE:kaduk\PYGZhy{}zone.keytab.
Entry for principal kaduk@ZONE.MIT.EDU with kvno 3, encryption type aes128\PYGZhy{}cts\PYGZhy{}hmac\PYGZhy{}sha1\PYGZhy{}96 added to keytab WRFILE:kaduk\PYGZhy{}zone.keytab.
Entry for principal kaduk@ZONE.MIT.EDU with kvno 3, encryption type des3\PYGZhy{}cbc\PYGZhy{}sha1 added to keytab WRFILE:kaduk\PYGZhy{}zone.keytab.
\end{sphinxVerbatim}

Once all principals have been re-keyed, DES support can be disabled on the
KDC (\sphinxstylestrong{allow\_weak\_crypto = false}), and client machines can remove
\sphinxstylestrong{allow\_weak\_crypto = true} from their {\hyperref[\detokenize{admin/conf_files/krb5_conf:krb5-conf-5}]{\sphinxcrossref{\DUrole{std,std-ref}{krb5.conf}}}} configuration
files, completing the migration.  \sphinxstylestrong{allow\_weak\_crypto} takes precedence over
all places where DES enctypes could be explicitly configured.  DES keys will
not be used, even if they are present, when \sphinxstylestrong{allow\_weak\_crypto = false}.


\subsubsection{Support for legacy services}
\label{\detokenize{admin/advanced/retiring-des:support-for-legacy-services}}
If there remain legacy services which do not support non-DES enctypes
(such as older versions of AFS), \sphinxstylestrong{allow\_weak\_crypto} must remain
enabled on the KDC.  Client machines need not have this setting,
though—applications which require DES can use API calls to allow
weak crypto on a per-request basis, overriding the system krb5.conf.
However, having \sphinxstylestrong{allow\_weak\_crypto} set on the KDC means that any
principals which have a DES key in the database could still use those
keys.  To minimize the use of DES in the realm and restrict it to just
legacy services which require DES, it is necessary to remove all other
DES keys.  The realm has been configured such that at password and
keytab change, no DES keys will be generated by default.  The task
then reduces to requiring user password changes and having server
administrators update their service keytabs.  Administrative outreach
will be necessary, and if the desire to eliminate DES is sufficiently
strong, the KDC administrators may choose to randkey any principals
which have not been rekeyed after some timeout period, forcing the
user to contact the helpdesk for access.


\subsection{The Database Master Key}
\label{\detokenize{admin/advanced/retiring-des:the-database-master-key}}
This procedure does not alter \sphinxcode{K/M@REALM}, the key used to encrypt key
material in the Kerberos database.  (This is the key stored in the stash file
on the KDC if stash files are used.)  However, the security risk of
a single-DES key for \sphinxcode{K/M} is minimal, given that access to material
encrypted in \sphinxcode{K/M} (the Kerberos database) is generally tightly controlled.
If an attacker can gain access to the encrypted database, they likely
have access to the stash file as well, rendering the weak cryptography
broken by non-cryptographic means.  As such, upgrading \sphinxcode{K/M} to a stronger
encryption type is unlikely to be a high-priority task.

Is is possible to upgrade the master key used for the database, if
desired.  Using {\hyperref[\detokenize{admin/admin_commands/kdb5_util:kdb5-util-8}]{\sphinxcrossref{\DUrole{std,std-ref}{kdb5\_util}}}}’s \sphinxstylestrong{add\_mkey}, \sphinxstylestrong{use\_mkey}, and
\sphinxstylestrong{update\_princ\_encryption} commands, a new master key can be added
and activated for use on new key material, and the existing entries
converted to the new master key.


\chapter{Various links}
\label{\detokenize{admin/various_envs:various-links}}\label{\detokenize{admin/various_envs::doc}}

\section{Whitepapers}
\label{\detokenize{admin/various_envs:whitepapers}}\begin{enumerate}
\item {} 
\sphinxurl{https://kerberos.org/software/whitepapers.html}

\end{enumerate}


\section{Tutorials}
\label{\detokenize{admin/various_envs:tutorials}}\begin{enumerate}
\item {} 
Fulvio Ricciardi  \textless{}\sphinxurl{https://www.kerberos.org/software/tutorial.html}\textgreater{}\_

\end{enumerate}


\section{Troubleshooting}
\label{\detokenize{admin/various_envs:troubleshooting}}\begin{enumerate}
\item {} 
\sphinxurl{https://wiki.ncsa.illinois.edu/display/ITS/Windows+Kerberos+Troubleshooting}

\item {} 
\sphinxurl{https://www.shrubbery.net/solaris9ab/SUNWaadm/SYSADV6/p27.html}

\item {} 
\sphinxurl{https://docs.oracle.com/cd/E19253-01/816-4557/trouble-1/index.html}

\item {} 
\sphinxurl{https://docs.microsoft.com/en-us/previous-versions/tn-archive/bb463167(v=technet.10})\#EBAA

\item {} 
\sphinxurl{https://bugs.launchpad.net/ubuntu/+source/libpam-heimdal/+bug/86528}

\end{enumerate}



\renewcommand{\indexname}{Index}
\printindex
\end{document}