SYNOPSIS
--------
-.. _kadmin_synopsys:
+.. _kadmin_synopsis:
**kadmin**
[**-O**\|\ **-N**]
[**-m**]
[**-x** *db_args*]
-.. _kadmin_synopsys_end:
+.. _kadmin_synopsis_end:
DESCRIPTION
Retrieves all or some policy names. *expression* is a shell-style
glob expression that can contain the wild-card characters ``?``,
-``*``, and ``[]'`. All policy names matching the expression are
+``*``, and ``[]``. All policy names matching the expression are
printed. If no expression is provided, all existing policy names are
printed.
SYNOPSIS
--------
-.. _kdb5_util_synopsys:
+.. _kdb5_util_synopsis:
**kdb5_util**
[**-r** *realm*]
[**-m**]
*command* [*command_options*]
-.. _kdb5_util_synopsys_end:
+.. _kdb5_util_synopsis_end:
DESCRIPTION
-----------
-.. _conf_firewall_label:
+.. _conf_firewall:
Configuring your firewall to work with Kerberos V5
==================================================
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 :ref:`add_mod_del_princs_label`), 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.
+database (see :ref:`add_mod_del_princs`), 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.
.. toctree::
:maxdepth: 2
**default_realm**
Identifies the default Kerberos realm for the client. Set its
value to your Kerberos realm. If this is not specified and the
- TXT record lookup is enabled (see :ref:`udns_label`), then that
+ TXT record lookup is enabled (see :ref:`using_dns`), then that
information will be used to determine the default realm. If this
tag is not set in this configuration file and there is no DNS
information found, then an error will be returned.
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 (see
- :ref:`udns_label`).
+ :ref:`using_dns`).
**kpasswd_server**
Points to the server where all the password changes are performed.
The default is false.
-.. _krb5_conf_sample_label:
-
Sample krb5.conf file
---------------------
:ref:`krb5_conf_sample_label`.
8. Create the realm using :ref:`kdb5_ldap_util(8)` (see
- :ref:`ldap_create_realm_label`)::
+ :ref:`ldap_create_realm`)::
kdb5_ldap_util -D cn=admin,dc=example,dc=com create -subtrees ou=users,dc=example,dc=com -r EXAMPLE.COM -s
exist underneath the realm container, omit the **-subtrees** option
and do not worry about creating the principal subtree.
- For more information, refer to the section
- :ref:`ops_on_ldap_label`.
+ For more information, refer to the section :ref:`ops_on_ldap`.
The realm object is created under the
**ldap_kerberos_container_dn** specified in the configuration file.
9. Stash the password of the service object used by the KDC and
Administration service to bind to the LDAP server using the
:ref:`kdb5_ldap_util(8)` **stashsrvpw** command (see
- :ref:`stash_ldap_label`). The object DN should be the same as
+ :ref:`stash_ldap`). The object DN should be the same as
**ldap_kdc*_dn* and **ldap_kadmind_dn** values specified in the
:ref:`krb5.conf(5)` file::
-.. _db_operations_label:
+.. _db_operations:
Operations on the Kerberos database
===================================
the Kerberos database.
.. include:: ../../admin_commands/kdb5_util.rst
- :start-after: _kdb5_util_synopsys:
- :end-before: _kdb5_util_synopsys_end:
+ :start-after: _kdb5_util_synopsis:
+ :end-before: _kdb5_util_synopsis_end:
**OPTIONS**
following options:
.. include:: ../admin_commands/kadmin_local.rst
- :start-after: kadmin_synopsys:
- :end-before: kadmin_synopsys_end:
+ :start-after: kadmin_synopsis:
+ :end-before: kadmin_synopsis_end:
**OPTIONS**
-.. _db_policies_label:
-
Policies
========
-.. _add_mod_del_princs_label:
+.. _add_mod_del_princs:
Adding, modifying and deleting principals
============================================
``krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM`` to both databases. You need to
be sure the passwords and the key version numbers (kvno) are the same
in both databases. This may require explicitly setting the kvno with
-the **-kvno** option. See :ref:`xrealm_authn_label` for more details.
+the **-kvno** option. See :ref:`xrealm_authn` for more details.
If you want to delete a principal ::
-.. _privileges_label:
+.. _privileges:
Privileges
==========
L disallows the listing of principals or policies in the database.
m allows the modification of principals or policies in the database.
M disallows the modification of principals or policies in the database.
-p allow the propagation of the principal database (Used in :ref:`incr_db_prop_label`).
-P disallow the propagation of the principal database (Used in :ref:`incr_db_prop_label`).
+p allow the propagation of the principal database (used in :ref:`incr_db_prop`).
+P disallow the propagation of the principal database (used in :ref:`incr_db_prop`).
s allows the explicit setting of the key for a principal
S disallows the explicit setting of the key for a principal
\* All privileges (admcil).
-.. _incr_db_prop_label:
+.. _incr_db_prop:
Incremental database propagation
================================
On the master KDC side, the ``kiprop/hostname`` principal must be
listed in the kadmind ACL file kadm5.acl, and given the **p**
-privilege (See :ref:`privileges_label`)
+privilege (see :ref:`privileges`).
On the slave KDC side, :ref:`kpropd(8)` should be run. When
incremental propagation is enabled, it will connect to the kadmind on
-.. _edir_create_realm_label:
+.. _edir_create_realm:
eDir: Creating a Kerberos realm
===============================
-See :ref:`ldap_create_realm_label`
+See :ref:`ldap_create_realm`
The following are the eDirectory specific options:
Re-enter KDC database master key to verify:
shell%
-.. _edir_mod_realm_label:
+.. _edir_mod_realm:
eDir: Modifying a Kerberos realm
================================
-See :ref:`ldap_mod_realm_label`
+See :ref:`ldap_mod_realm`
.. include:: ../../admin_commands/kdb5_ldap_util.rst
:start-after: _kdb5_ldap_util_modify_edir:
-.. _edir_mod_realm_label:
+.. _edir_mod_realm:
eDir: Modifying a Kerberos realm
=================================
-See :ref:`ldap_mod_realm_label`
+See :ref:`ldap_mod_realm`
The following are the eDirectory specific options
-.. _ops_on_ldap_label:
+.. _ops_on_ldap:
Operations on the LDAP database
===============================
-.. _ldap_create_realm_label:
+.. _ldap_create_realm:
Creating a Kerberos realm
=========================
:start-after: _kdb5_ldap_util_create:
:end-before: _kdb5_ldap_util_create_end:
-.. seealso:: :ref:`edir_create_realm_label`
+.. seealso:: :ref:`edir_create_realm`
Feedback
-.. _ldap_mod_realm_label:
+.. _ldap_mod_realm:
Modifying a Kerberos realm
==========================
:start-after: _kdb5_ldap_util_modify:
:end-before: _kdb5_ldap_util_modify_end:
-.. seealso:: :ref:`edir_mod_realm_label`
+.. seealso:: :ref:`edir_mod_realm`
Feedback
-.. _stash_ldap_label:
+.. _stash_ldap:
Stashing service object's password
==================================
-.. _xrealm_authn_label:
+.. _xrealm_authn:
Cross-realm authentication
==========================
-.. _udns_label:
+.. _using_dns:
Using DNS
=========
additions to krb5-bugs@mit.edu. Your contribution is
greatly appreciated.
-See :ref:`mapping_hn_label`
+See :ref:`mapping_hostnames`
-See :ref:`kdc_hn_label`
+See :ref:`kdc_hostnames`
Feedback
sign-on capability.
-.. _kt_file_label:
+.. _keytab_file:
The 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
``/etc/krb5.keytab``. The keytab file is an encrypted, local, on-disk
-copy of the host's key. The keytab file, like the stash file (See
-:ref:`create_db_label`) 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 itself.
+copy of the host's key. The keytab file, like the stash file (see
+:ref:`create_db`) 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 itself.
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 :ref:`add_mod_del_princs_label`.
-(See :ref:`slave_host_key_label` for a brief description.) The keytab
-is generated by running :ref:`kadmin(1)` and issuing the :ref:`ktadd`
+the database is described fully in :ref:`add_mod_del_princs`. (See
+:ref:`slave_host_key` for a brief description.) The keytab is
+generated by running :ref:`kadmin(1)` and issuing the :ref:`ktadd`
command.
For example, to generate a keytab file to allow the host
-.. _admin_acl_label:
+.. _admin_acl:
Add administrators to the ACL file
==================================
files for this command to succeed.)
The administrative principals you create should be the ones you added
-to the ACL file. (See :ref:`admin_acl_label`.)
+to the ACL file (see :ref:`admin_acl`).
In the following example, the administrative principal ``admin/admin``
is created::
-.. _create_db_label:
+.. _create_db:
Create the database
===================
**-s** option.
For more information on administrating Kerberos database see
-:ref:`db_operations_label`.
+:ref:`db_operations`.
Feedback
Once your KDCs are set up and running, you are ready to use
:ref:`kadmin(1)` to load principals for your users, hosts, and other
services into the Kerberos database. This procedure is described
-fully in the :ref:`add_mod_del_princs_label`. The keytab is generated
-by running kadmin and issuing the :ref:`ktadd` command.
+fully in the :ref:`add_mod_del_princs`. The keytab is generated by
+running kadmin and issuing the :ref:`ktadd` command.
You may occasionally want to use one of your slave KDCs as the master.
This might happen if you are upgrading the master KDC, or if your
done
You will need to set up a cron job to run this script at the intervals
-you decided on earlier (See :ref:`db_prop_label` and
-:ref:`incr_db_prop_label`.) The dump can also be used as a save file.
-Once the operation succeeded, connect to slaves and start thier KDCs.
+you decided on earlier (See :ref:`db_prop` and :ref:`incr_db_prop`.)
+The dump can also be used as a save file. Once the operation
+succeeded, connect to slaves and start thier KDCs.
Now that the slave KDC has a copy of the Kerberos database, you can
start the krb5kdc daemon::
Once your KDCs are set up and running, you are ready to use
:ref:`kadmin(1)` to load principals for your users, hosts, and other
services into the Kerberos database. This procedure is described
-fully in the :ref:`add_mod_del_princs_label`. The keytab is generated
-by running kadmin and issuing the ktadd command.
+fully in the :ref:`add_mod_del_princs`. The keytab is generated by
+running kadmin and issuing the ktadd command.
Propagation failed?
krb5.conf
---------
-If you are not using DNS TXT records (see :ref:`mapping_hn_label`),
+If you are not using DNS TXT records (see :ref:`mapping_hostnames`),
you must specify the **default_realm** in the :ref:`libdefaults`
section. If you are not using DNS SRV records (see
-:ref:`kdc_hn_label`), you must include the **kdc** tag for each
+:ref:`kdc_hostnames`), you must include the **kdc** tag for each
*realm* in the :ref:`realms` section. To communicate with the kadmin
server in each realm, the **admin_server** tag must be set in the
:ref:`realms` section. If your domain name and realm name are not the
-.. _slave_host_key_label:
+.. _slave_host_key:
Setting up slave KDCs
=====================
authenticate the KDC to itself automatically before starting the
:ref:`kadmind(8)` and :ref:`krb5kdc(8)` daemons (e.g., as part of the
machine's boot sequence). The stash file, like the keytab file (see
-:ref:`kt_file_label` for more information) is a potential
-point-of-entry for a break-in, and if compromised, would allow
-unrestricted access to the Kerberos database. If you choose to
-install a stash file, it should be readable only by root, and should
-exist only on the KDC'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 master password itself.
+:ref:`keytab_file`) is a potential point-of-entry for a break-in, and
+if compromised, would allow unrestricted access to the Kerberos
+database. If you choose to install a stash file, it should be
+readable only by root, and should exist only on the KDC'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
+master password itself.
.. 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.
-.. _db_prop_label:
+.. _db_prop:
Database propagation
====================
one set of slaves, and then have each of these slaves propagate the
database to additional slaves.
-See also :ref:`incr_db_prop_label`
+See also :ref:`incr_db_prop`
Feedback
-.. _kdc_hn_label:
+.. _kdc_hostnames:
Hostnames for KDCs
==================
ports, as long as they are specified in each host's ``/etc/services``
and :ref:`krb5.conf(5)` files, and the :ref:`kdc.conf(5)` file on each
KDC. For a more thorough treatment of port numbers used by the
-Kerberos V5 programs, refer to the :ref:`conf_firewall_label`.
+Kerberos V5 programs, refer to the :ref:`conf_firewall`.
Feedback
--------
-.. _mapping_hn_label:
+.. _mapping_hostnames:
Mapping hostnames onto Kerberos realms
**--enable-dns-for-realm**\r
Enable the use of DNS to look up a host's Kerberos realm, or a\r
realm's KDCs, if the information is not provided in\r
- :ref:`krb5.conf(5)`. See :ref:`kdc_hn_label` for information\r
- about using DNS to locate the KDCs, and :ref:`mapping_hn_label`\r
+ :ref:`krb5.conf(5)`. See :ref:`kdc_hostnames` for information\r
+ about using DNS to locate the KDCs, and :ref:`mapping_hostnames`\r
for information about using DNS to determine the default realm.\r
By default, DNS lookups are enabled for the former but not for the\r
latter.\r
-.. _gatya_label:
+.. _grant_access:
Granting access to your account
===============================
or log into other hosts as you--and no one will be able to tell the
difference. For this reason, it is important that you choose a good
password, and keep it secret. If you need to give access to your
-account to someone else, you can do so through Kerberos. (See
-:ref:`gatya_label`.) You should never tell your password to anyone,
+account to someone else, you can do so through Kerberos (see
+:ref:`grant_access`). You should never tell your password to anyone,
including your system administrator, for any reason. You should
change your password frequently, particularly any time you think
someone may have found out what it is.
-.. _otwk_labal:
+.. _obtain_tkt
Obtaining tickets with kinit
============================
Note that kinit does not tell you that it obtained forwardable
tickets; you can verify this using the :ref:`klist(1)` command (see
-:ref:`vytwk_label`).
+:ref:`view_tkt`).
Normally, your tickets are good for your system's default ticket
lifetime, which is ten hours on many systems. You can specify a
-.. _vytwk_label:
+.. _view_tkt:
Viewing tickets with klist
==========================
The Kerberos V5 network programs allow you the options of forwarding
your tickets to the remote host (if you obtained forwardable tickets
-with the :ref:`kinit(1)` program; see :ref:`otwk_labal`), and
+with the :ref:`kinit(1)` program; see :ref:`obtain_tkt`), and
encrypting data transmitted between you and the remote host.
The Kerberos V5 applications are versions of existing UNIX network
(e.g., the user *joeadmin* might want to use his admin instance.)
-c specifies the location of your Kerberos credentials cache (ticket file).
-k tells ksu not to destroy your Kerberos tickets when ksu is finished.
--f requests forwardable tickets. (See :ref:`otwk_labal`.)
+-f requests forwardable tickets. (See :ref:`obtain_tkt`.)
This is only applicable if ksu needs to obtain tickets.
--l *lifetime* sets the ticket lifetime. (See :ref:`otwk_labal`.) i
+-l *lifetime* sets the ticket lifetime. (See :ref:`obtain_tkt`.)
This is only applicable if ksu needs to obtain tickets.
-z tells ksu to copy your Kerberos tickets only if the UID you are switching
is the same as the Kerberos primary
projects / krb5.git / commitdiff