This is krb5-admin.info, produced by makeinfo version 4.5 from
admin.texinfo.

INFO-DIR-SECTION Kerberos
START-INFO-DIR-ENTRY
* krb5-admin: (krb5-admin).             Kerberos V5 Administrator's Guide
END-INFO-DIR-ENTRY


File: krb5-admin.info,  Node: Restoring a Kerberos Database from a Dump File,  Next: Creating a Stash File,  Prev: Dumping a Kerberos Database to a File,  Up: Global Operations on the Kerberos Database

Restoring a Kerberos Database from a Dump File
----------------------------------------------

To restore a Kerberos database dump from a file, use the `kdb5_util'
`load' command on one of the KDCs.  The syntax is:

     kdb5_util load [-old] [-b6] [-b7] [-ov] [-verbose]
     [-update] [-hash] dumpfilename dbname [admin_dbname]

The `kdb5_util load' command takes the following options:

-old
     requires the dump to be in the Kerberos 5 Beta 5 and earlier dump
     format ("kdb5_edit load_dump version 2.0").

-b6
     requires the dump to be in the Kerberos 5 Beta 6 format ("kdb5_edit
     load_dump version 3.0").

-b7
     requires the dump to be in the Kerberos 5 Beta 7 format ("kdb5_edit
     load_dump version 4").

-ov
     requires the dump to be in ovsec_adm_export format.

-verbose
     causes the name of each principal and policy to be printed as it is
     loaded.

-update
     causes records from the dump file to be updated in or added to the
     existing database.  This is useful in conjunction with an
     ovsec_adm_export format dump if you want to preserve per-principal
     policy information, since the current default format does not
     contain this data.

-hash
     causes the database to be stored as a hash rather than a binary
     tree.

For example:

     shell% kdb5_util load dumpfile principal
     shell%

     shell% kdb5_util load -update dumpfile principal
     shell%

If the database file exists, and the -update flag was not given,
`kdb5_util' will overwrite the existing database.


File: krb5-admin.info,  Node: Creating a Stash File,  Next: Creating and Destroying a Kerberos Database,  Prev: Restoring a Kerberos Database from a Dump File,  Up: Global Operations on the Kerberos Database

Creating a Stash File
---------------------

A stash file allows a KDC to authenticate itself to the database
utilities, such as `kadmin', `kadmind', `krb5kdc', and `kdb5_util'.

To create a stash file, use the `kdb5_util' `stash' command.  The
syntax is:

     kdb5_util stash [-f keyfile]

For example:

     shell% kdb5_util stash
     kdb5_util: Cannot find/read stored master key while reading master key
     kdb5_util: Warning: proceeding without master key
     Enter KDC database master key:  <= Type the KDC database master password.
     shell%

If you do not specify a stash file, `kdb5_util' will stash the key in
the file specified in your `kdc.conf' file.


File: krb5-admin.info,  Node: Creating and Destroying a Kerberos Database,  Prev: Creating a Stash File,  Up: Global Operations on the Kerberos Database

Creating and Destroying a Kerberos Database
-------------------------------------------

If you need to create a new Kerberos database, use the `kdb5_util'
`create' command.  The syntax is:

     kdb5_util create [-s]

If you specify the `-s' option, `kdb5_util' will stash a copy of the
master key in a stash file.  (*Note Creating a Stash File::.)  For
example:

     shell% /usr/local/sbin/kdb5_util -r ATHENA.MIT.EDU create -s
     kdb5_util: No such file or directory while setting active database to
     => '/usr/local/var/krb5kdc/principal'
     Initializing database '/usr/local/var/krb5kdc/principal' for
     => realm 'ATHENA.MIT.EDU',
     master key name 'K/M@ATHENA.MIT.EDU'
     You will be prompted for the database Master Password.
     It is important that you NOT FORGET this password.
     Enter KDC database master key:  <= Type the master password.
     Re-enter KDC database master key to verify:  <= Type it again.
     shell%

If you need to destroy the current Kerberos database, use the
`kdb5_util' `destroy' command.  The syntax is:

     kdb5_util destroy [-f]

The `destroy' command destroys the database, first overwriting the disk
sectors and then unlinking the files.  If you specify the `-f' option,
`kdb5_util' will not prompt you for a confirmation before destroying
the database.

     shell% /usr/local/sbin/kdb5_util -r ATHENA.MIT.EDU destroy
     kdb5_util: Deleting KDC database stored in /usr/local/var/krb5kdc/principal, are you sure
     (type yes to confirm)? <== yes
     OK, deleting database '/usr/local/var/krb5kdc/principal'...
     
     shell%


File: krb5-admin.info,  Node: Global Operations on the Kerberos LDAP Database,  Next: Cross-realm Authentication,  Prev: Global Operations on the Kerberos Database,  Up: Administrating the Kerberos Database

Global Operations on the Kerberos LDAP Database
===============================================

The `kdb5_ldap_util' is the primary tool for administrating the
Kerberos LDAP database. It allows an administrator to manage realms,
Kerberos services ( KDC and Admin Server) and ticket policies.

The syntax is:
     kdb5_ldap_util [-D user_dn [-w passwd]] [-H ldap_uri] command [command_options]

-D user_dn
     Specifies the Distinguished Name (DN) of the user who has
     sufficient rights to perform the operation on the LDAP server.

-w passwd
     Specifies the password of user_dn. This option is not recommended.

-H ldap_uri
     Specifies the URI of the LDAP server. It is recommended to use
     ldapi:// or ldaps:// to connect to the LDAP server.

* Menu:

* Creating a Kerberos Realm::
* Modifying a Kerberos Realm::
* Retrieving Information about a Kerberos Realm::
* Destroying a Kerberos Realm::
* Listing available Kerberos Realms::
* Stashing Service Object's Password::
* Creating and Modifying a Ticket Policy::
* Retrieving Information About a Ticket Policy::
* Destroying a Ticket Policy::
* Listing available Ticket Policies::
* Creating a Service Object (eDirectory)::
* Modifying a Service Object (eDirectory)::
* Retrieving Service Object Information (eDirectory)::
* Destroying a Service Object (eDirectory)::
* Listing Available Service Objects (eDirectory)::
* Passwords for Service Objects (eDirectory)::


File: krb5-admin.info,  Node: Creating a Kerberos Realm,  Next: Modifying a Kerberos Realm,  Prev: Global Operations on the Kerberos LDAP Database,  Up: Global Operations on the Kerberos LDAP Database

Creating a Kerberos Realm
-------------------------

If you need to create a new realm, use the command as follows:

     create  [-r realm]  [-subtrees subtree_dn_list] [-sscope search_scope] [-containerref container_reference_dn]
     [-k  mkeytype] [-m|-P password][-sf stashlename] [-s] [-maxtktlife max_ticket_life]
     [-maxrenewlife  max_renewable_ticket_life] [ticket_flags]

Options to create realm in directory are as follows:

-r realm
     Specifies the Kerberos realm of the database; by default the realm
     returned by `krb5_default_local_realm' (3) is used.

-subtrees subtree_dn_list
     Specifies the list of subtrees containing principals of a realm.
     The list contains the DN of the subtree objects separated by
     colon(:).

-sscope search_scope
     Specifies the scope for searching the principals under the
     subtree. The possible values are 1 or one (one level), 2 or sub
     (subtree).

-containerref container_reference_dn
     Specfies 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.

-k mkeytype
     Specifies the key type of the master key in the database; the
     default is that given in `kdc.conf'.

-m
     Specifies that the master database password should be read from
     the TTY rather than fetched from a file on disk.

-p password
     Specifies the master database password. This option is not
     recommended.

-sf stashfilename
     Specifies the stash file of the master database password.

-s
     Specifies that the stash file is to be created.

-maxtktlife max_ticket_life
     Specifies maximum ticket life for principals in this realm. This
     value is used, if it is not set on the principal.

-maxrenewlife max_renewable_ticket_life
     Specifies maximum renewable life of tickets for principals in this
     realm. This value is used, if it is not set on the principal.

ticket_flags
     Specifies the ticket flags. If this option is not specified, by
     default, none of the flags are set. This means all the ticket
     options will be allowed and no restriction will be set. This value
     is used, if it is not set on the principal.

     The various flags are:
    {-|+}allow_postdated
          `-allow_postdated' prohibits principals from obtaining
          postdated tickets. (Sets the `KRB5_KDB_DISALLOW_POSTDATED'
          flag.).`+allow_postdated' clears this flag.

    {-|+}allow_forwardable
          `-allow_forwardable' prohibits principals from obtaining
          forwardable tickets. (Sets the
          `KRB5_KDB_DISALLOW_FORWARDABLE' flag.) `+allow_forwardable'
          clears this flag.

    {-|+}allow_renewable
          `-allow_renewable' prohibits principals from obtaining
          renewable tickets. (Sets the `KRB5_KDB_DISALLOW_RENEWABLE'
          flag.) `+allow_renewable' clears this flag.

    {-|+}allow_proxiable
          `-allow_proxiable' prohibits principals from obtaining
          proxiable tickets. (Sets the `KRB5_KDB_DISALLOW_PROXABLE'
          flag.) `+allow_proxiable' clears this flag.

    {-|+}allow_dup_skey
          `-allow_dup_skey' disables user-to-user authentication for
          principals by prohibiting principals from obtaining a
          sessions key for another user.  (Sets the
          `KRB5_KDB_DISALLOW_DUP_SKEY' flag.)  `+allow_dup_skey' clears
          this flag.

    {-|+}requires_preauth
          `+requires_preauth' requires principals to preauthenticate
          before being allowed to kinit. (Sets the
          `KRB5_KDB_REQURES_PRE_AUTH' flag.) `-requires_preauth' clears
          this flag.

    {-|+}requires_hwauth
          `+requires_hwauth' requires principals to preauthenticate
          using a hardware device before being allowed to kinit. (Sets
          the `KRB5_KDB_REQURES_HW_AUTH' flag.)  `-requires_hwauth'
          clears this flag.

    {-|+}ok_as_delegate
          `+ok_as_delegate' sets the OK-AS-DELEGATE flag on tickets
          issued for use with this principal as the service, which
          clients may use as a hint that credentials can and should be
          delegated when authenticating to the service.  (Sets the
          `KRB5_KDB_OK_AS_DELEGATE' flag.) `-ok_as_delegate' clears
          this flag.

    {-|+}allow_svr
          `-allow_svr' prohibits the issuance of service tickets for
          principals. (Sets the `KRB5_KDB_DISALLOW_SVR' flag.)
          `+allow_svr' clears this flag.

    {-|+}allow_tgs_req
          `-allow_tgs_req' specifies that a "Ticket-Granting Service
          (TGS)" request for a service ticket for principals is not
          permitted. This option is useless for most
          things.`+allow_tgs_req' clears this flag.  The default is
          `+allow_tgs_req'. In effect, `-allow_tgs_req' sets the
          `KRB5_KDB_DISALLOW_TGT_BASED' flag on principals in the
          database.

    {-|+}allow_tix
          `-allow_tix' forbids the issuance of any tickets for
          principals. `+allow_tix' clears this flag. The default is
          `+allow_tix'.  In effect, `-allow_tix' sets the
          `KRB5_KDB_DISALLOW_ALL_TIX' flag on principals in the
          database.

    {-|+}needchange
          `+needchange' sets a flag in attributes field to force a
          password change; `-needchange' clears it. The default is
          `-needchange'. In effect, `+needchange' sets the
          `KRB5_KDB_REQURES_PWCHANGE' flag on principals in the
          database.

    {-|+}password_changing_service
          `+password_changing_service' sets a flag in the attributes
          field marking principal as a password change service
          principal (useless for most things).
          `-password_changing_service' clears the flag. This flag
          intentionally has a long name. The default is
          `-password_changing_service'. In effect,
          `+password_changing_service' sets the
          `KRB5_KDB_PWCHANGE_SERVICE' flag on principals in the
          database.



     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu create -sscope 2
     -subtree ou=users,dc=example,dc=com -r ATHENA.MIT.EDU
     Password for "cn=admin,dc=example,dc=com":
     Initializing database for realm 'ATHENA.MIT.EDU'
     You will be prompted for the database Master Password.
     It is important that you NOT FORGET this password.
     Enter KDC database master key:
     Re-enter KDC database master key to verify:
     shell%

* Menu:

* eDirectory Options (Creating a Kerberos Realm)::


File: krb5-admin.info,  Node: eDirectory Options (Creating a Kerberos Realm),  Prev: Creating a Kerberos Realm,  Up: Creating a Kerberos Realm

eDirectory Options
..................

-kdcdn kdc_servce_list
     Specifies the list of KDC service objects serving the realm. The
     list contains the DNs of the KDC service objects separated by
     colon(:).

-admindn admin_service_list
     Specifies the  list of Administration service objects serving the
     realm. The list contains the DNs of the Administration service
     objects separated by colon(:).

     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu create -sscope 2
     -subtree ou=users,dc=example,dc=com -kdcdn cn=krbkdc,dc=example,dc=com -admindn cn=krbadmin,dc=example,dc=com -r ATHENA.MIT.EDU
     Password for "cn=admin,dc=example,dc=com":
     Initializing database for realm 'ATHENA.MIT.EDU'
     You will be prompted for the database Master Password.
     It is important that you NOT FORGET this password.
     Enter KDC database master key:
     Re-enter KDC database master key to verify:
     shell%


File: krb5-admin.info,  Node: Modifying a Kerberos Realm,  Next: Retrieving Information about a Kerberos Realm,  Prev: Creating a Kerberos Realm,  Up: Global Operations on the Kerberos LDAP Database

Modifying a Kerberos Realm
--------------------------

If you need to modify a realm, use the command as follows:


     modify  [-r realm] [-subtrees subtree_dn] [-sscope search_scope][-containerref container_reference_dn]
     [-maxtktlifemax_ticket_life][-maxrenewlife max_renewable_ticket_life] [-ticket_flags]
Options to modify realm in directory are as follows:

-r realm
     Specifies the Kerberos realm of the database; by default the realm
     returned by krb5_default_local_realm (3) is used.

-subtrees subtree_dn_list
     Specifies the list of subtrees containing principal objects in the
     realm.The list contains the DN of the subtree objects separated by
     colon(:). This list replaces the existing list.

-sscope search_scope
     Specifies the scope for searching the principals under the
     subtrees. The possible values are 1 or one (one level), 2 or sub
     (subtrees).

-containerref container_reference_dn
     Specifies the Distinguished Name (DN) of the container object in
     which the principals of a realm will be created.

-maxtktlife max_ticket_life
     Specifies maximum ticket life for principals in this realm. This
     value is used, if it is not set on the principal.

-maxrenewlife max_renewable_ticket_life
     Specifies maximum renewable life of tickets for principals in this
     realm.  This value is used, if it is not set on the principal.

-ticket_flags
     Specifies the ticket flags. If this option is not specified, by
     default, none of the flags are set. This means all the ticket
     options will be allowed and no restriction will be set.  This
     value is used, if it is not set on the principal.

     The various flags are:
    {-|+}allow_postdated
          `-allow_postdated' prohibits principals from obtaining
          postdated tickets. (Sets the `KRB5_KDB_DISALLOW_POSTDATED'
          flag.).`+allow_postdated' clears this flag.

    {-|+}allow_forwardable
          `-allow_forwardable' prohibits principals from obtaining
          forwardable tickets.  (Sets the
          `KRB5_KDB_DISALLOW_FORWARDABLE' flag.) `+allow_forwardable'
          clears this flag.

    {-|+}allow_renewable
          `-allow_renewable' prohibits principals from obtaining
          renewable tickets. (Sets the `KRB5_KDB_DISALLOW_RENEWABLE'
          flag.) `+allow_renewable' clears this flag.

    {-|+}allow_proxiable
          `-allow_proxiable' prohibits principals from obtaining
          proxiable tickets. (Sets the `KRB5_KDB_DISALLOW_PROXABLE'
          flag.) `+allow_proxiable' clears this flag.

    {-|+}allow_dup_skey
          `-allow_dup_skey' Disables user-to-user authentication for
          principals by prohibiting principals from obtaining a
          sessions key for another user. (Sets the
          `KRB5_KDB_DISALLOW_DUP_SKEY' flag.). `+allow_dup_skey' clears
          This flag.

    {-|+}requires_preauth
          `+requires_preauth' requires principals to preauthenticate
          before being allowed to kinit. Sets the
          `KRB5_KDB_REQURES_PRE_AUTH' flag.`-requires_preauth' clears
          this flag.

    {-|+}requires_hwauth
          `+requires_hwauth' requires principals to preauthenticate
          using a hardware device before being allowed to kinit. (Sets
          the `KRB5_KDB_REQURES_HW_AUTH' flag.)`-requires_hwauth'
          clears this flag.

    {-|+}allow_svr
          `-allow_svr' prohibits the issuance of service tickets for
          principals. (Sets the `KRB5_KDB_DISALLOW_SVR' flag.)
          `+allow_svr' clears This flag.

    {-|+}allow_tgs_req
          `-allow_tgs_req' specifies that a "Ticket-Granting Service
          (TGS)" request for a service ticket for principals is not
          permitted. This option is useless for most
          things.`+allow_tgs_req' clears this flag.  The default is.
          `+allow_tgs_req'.  In effect, `-allow_tgs_req' sets the
          `KRB5_KDB_DISALLOW_TGT_BASED' flag on principals in the
          database.

    {-|+}allow_tix
          `-allow_tix' forbids the issuance of any tickets for
          principals. `+allow_tix' clears this flag. The default is
          `+allow_tix'.  In effect, `-allow_tix' sets the
          `KRB5_KDB_DISALLOW_ALL_TIX' flag on principals in the
          database.

    {-|+}needchange
          `+needchange' sets a flag in attributes field to force a
          password change; `-needchange' clears it.  The default is
          `-needchange'.  In effect,`+needchange' sets the
          `KRB5_KDB_REQURES_PWCHANGE' flag on principals in the
          database.

    {-|+}password_changing_service
          `+password_changing_service' sets a flag in the attributes
          field marking principal as a password change service
          principal (useless for most
          things).`-password_changing_service' clears the flag. This
          flag intentionally has a long name. The default is
          `-password_changing_service' In effect,
          `+password_changing_service' sets the
          `KRB5_KDB_PWCHANGE_SERVICE' flag on principals in the
          database.


     For example:
          shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu
          modify -r ATHENA.MIT.EDU +requires_preauth
          Password for "cn=admin,dc=example,dc=com":
          shell%

     * Menu:
     
     * eDirectory Options (Modifying a Kerberos Realm)::



File: krb5-admin.info,  Node: eDirectory Options (Modifying a Kerberos Realm),  Prev: Modifying a Kerberos Realm,  Up: Modifying a Kerberos Realm

eDirectory Options
..................

-kdcdn kdc_service_list
     Specifies the list of KDC service objects serving the realm. The
     list contains the DNs of the KDC service objects separated by a
     colon (:). This list replaces the existing list.

-clearkdcdn kdc_service_list
     Specifies the list of KDC service objects that need to be removed
     from the existing list. The list contains the DNs of the KDC
     service objects separated by a colon (:).

-addkdcdn kdc_service_list
     Specifies the list of KDC service objects that need to be added to
     the existing list. The list contains the DNs of the KDC service
     objects separated by a colon (:).

-admindn admin_service_list
     Specifies the list of Administration service objects serving the
     realm. The list contains the DNs of the Administration service
     objects separated by a colon (:). This list replaces the existing
     list.

-clearadmindn admin_service_list
     Specifies the list of Administration service objects that need to
     be removed from the existing list. The list contains the DNs of
     the Administration service objects separated by a colon (:).

-addadmindn admin_service_list
     Specifies the list of Administration service objects that need to
     be added to the existing list. The list contains the DNs of the
     Administration service objects separated by a colon (:).



File: krb5-admin.info,  Node: Retrieving Information about a Kerberos Realm,  Next: Destroying a Kerberos Realm,  Prev: Modifying a Kerberos Realm,  Up: Global Operations on the Kerberos LDAP Database

Retrieving Information about a Kerberos Realm
---------------------------------------------

view [-r realm]
     Displays the attributes of a realm. Option is as follows:

-r realm
     specifies the Kerberos realm of the database; by default the realm
     returned by krb5_default_local_realm (3)is used.

For example:
     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu view -r ATHENA.MIT.EDU
     Password for "cn=admin,dc=example,dc=com":
     Realm Name: ATHENA.MIT.EDU
     Subtree: ou=users,dc=example,dc=com
     Subtree: ou=servers,dc=example,dc=com
     SearchScope: ONE
     Maximum ticket life: 0 days 01:00:00
     Maximum renewable life: 0 days 10:00:00
     Ticket flags: DISALLOW_FORWARDABLE
     shell%


File: krb5-admin.info,  Node: Destroying a Kerberos Realm,  Next: Listing available Kerberos Realms,  Prev: Retrieving Information about a Kerberos Realm,  Up: Global Operations on the Kerberos LDAP Database

Destroying a Kerberos Realm
---------------------------

destroy [-f] [-r realm]
     Destroys an existing realm. Options are as follows:
    -f
          If specified, will not prompt the user for confirmation.

    -r realm
          specifies the Kerberos realm of the database; by default the
          realm returned by `krb5_default_local_realm' (3)is used.


For example:
     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldap-server1.mit.edu destroy -r ATHENA.MIT.EDU
     Password for "cn=admin,dc=example,dc=com":
     Deleting KDC database of 'ATHENA.MIT.EDU', are you sure?
     type 'yes' to confirm)? Yes
     OK, deleting database of 'ATHENA.MIT.EDU'...
     shell%


File: krb5-admin.info,  Node: Listing available Kerberos Realms,  Next: Stashing Service Object's Password,  Prev: Destroying a Kerberos Realm,  Up: Global Operations on the Kerberos LDAP Database

Listing available Kerberos Realms
---------------------------------

list
     This option lists the name of the realms.

For example:
     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu list
     Password for "cn=admin,dc=example,dc=com":
     ATHENA.MIT.EDU
     OPENLDAP.MIT.EDU
     MEDIA-LAB.MIT.EDU
     shell%


File: krb5-admin.info,  Node: Stashing Service Object's Password,  Next: Creating and Modifying a Ticket Policy,  Prev: Listing available Kerberos Realms,  Up: Global Operations on the Kerberos LDAP Database

Stashing Service Object's Password
----------------------------------

stashsrvpw [-f filename] servicedn

This command allows an administrator to store the password of service
object in a file. The KDC and Administration server uses this password
to authenticate to the LDAP server.

Options are as follows:

-f filename
     Specifies the complete path of the service password file. By
     default, `/usr/local/var/service_passwd' is used.

servicedn
     Specifies the Distinguished Name (DN) of the service object whose
     password is to be stored in file.

For example:
     shell% kdb5_ldap_util stashsrvpw -f /home/andrew/conf_keyle cn=service-kdc,dc=example,dc=com
     Password for "cn=service-kdc,dc=example,dc=com":
     Re-enter password for "cn=service-kdc,dc=example,dc=com":
     shell%


File: krb5-admin.info,  Node: Creating and Modifying a Ticket Policy,  Next: Retrieving Information About a Ticket Policy,  Prev: Stashing Service Object's Password,  Up: Global Operations on the Kerberos LDAP Database

Creating and Modifying a Ticket Policy
--------------------------------------

This command creates a ticket policy in directory.

     create_policy [-r realm] [-maxrenewlife max_renewable_ticket_life] [ticket_flags] policy_name
Ticket policy objects are created under the realm container.

This command modifies a ticket policy in directory.
     modify_policy [-r realm] [-maxrenewlife max_renewable_ticket_life] [ticket_flags] policy_name

Options are as follows:

-r realm
     Specifies the Kerberos realm of the database; by default the realm
     returned by krb5_default_local_realm(3) is used.

-maxtktlife max_ticket_life
     specifies maximum ticket life for principals.

-maxrenewlife max_renewable_ticket_life
     specifies maximum renewable life of tickets for principals.

ticket_flags
     Specifies the ticket flags. If this option is not specified, by
     default, none of the flags are set. This means all the ticket
     options will be allowed and no restriction will be set.

     The various flags are:
    {-|+}allow_postdated
          `-allow_postdated' prohibits principals from obtaining
          postdated tickets. (Sets the `KRB5_KDB_DISALLOW_POSTDATED'
          flag.).`+allow_postdated' clears this flag.

    {-|+}allow_forwardable
          `-allow_forwardable' prohibits principals from obtaining
          forwardable tickets. (Sets the
          `KRB5_KDB_DISALLOW_FORWARDABLE' flag.) `+allow_forwardable'
          clears this flag.

    {-|+}allow_renewable
          `-allow_renewable' prohibits principals from obtaining
          renewable tickets. (Sets the `KRB5_KDB_DISALLOW_RENEWABLE'
          flag.) `+allow_renewable' clears this flag.

    {-|+}allow_proxiable
          `-allow_proxiable' prohibits principals from obtaining
          proxiable tickets. (Sets the `KRB5_KDB_DISALLOW_PROXABLE'
          flag.) `+allow_proxiable' clears this flag.

    {-|+}allow_dup_skey
          `-allow_dup_skey' Disables user-to-user authentication for
          principals by prohibiting principals from obtaining a
          sessions key for another user. (Sets the
          `KRB5_KDB_DISALLOW_DUP_SKEY' flag.). `+allow_dup_skey' clears
          This flag.

    {-|+}requires_preauth
          `+requires_preauth' requires principals to preauthenticate
          before being allowed to kinit. (Sets the
          `KRB5_KDB_REQURES_PRE_AUTH' flag.)  `-requires_preauth'
          clears this flag.

    {-|+}requires_hwauth
          `+requires_hwauth' requires principals to preauthenticate
          using a hardware device before being allowed to kinit. (Sets
          the `KRB5_KDB_REQURES_HW_AUTH' flag.)  `-requires_hwauth'
          clears this flag.

    {-|+}allow_svr
          `-allow_svr' prohibits the issuance of service tickets for
          principals. (Sets the `KRB5_KDB_DISALLOW_SVR' flag.)
          `+allow_svr' clears This flag.

    {-|+}allow_tgs_req
          `-allow_tgs_req' specifies that a "Ticket-Granting Service
          (TGS)" request for a service ticket for principals is not
          permitted. This option is useless for most
          things.`+allow_tgs_req' clears this flag.  The default is
          `+allow_tgs_req'.  In effect, `-allow_tgs_req' sets the
          `KRB5_KDB_DISALLOW_TGT_BASED' flag on principals in the
          database.

    {-|+}allow_tix
          `-allow_tix' forbids the issuance of any tickets for
          principals.  `+allow_tix' clears this flag.  The default is
          `+allow_tix'.  In effect, `-allow_tix' sets the
          `KRB5_KDB_DISALLOW_ALL_TIX' flag on principals in the
          database.

    {-|+}needchange
          `+needchange' sets a flag in attributes field to force a
          password change; `-needchange' clears it. The default is
          `-needchange'.  In effect, `+needchange' sets the
          `KRB5_KDB_REQURES_PWCHANGE' flag on principals in the
          database.

    {-|+}password_changing_service
          `+password_changing_service' sets a flag in the attributes
          field marking principal as a password change service
          principal (useless for most things).
          `-password_changing_service' clears the flag.  This flag
          intentionally has a long name.  The default is
          `-password_changing_service'.  In effect,
          `+password_changing_service' sets the
          `KRB5_KDB_PWCHANGE_SERVICE' flag on principals in the
          database.

policy_name
     Specifies the name of the ticket policy.


For example:
     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu create_policy
     -r ATHENA.MIT.EDU -maxtktlife "1 day" -maxrenewlife "1 week" -allow_forwardable usertktpolicy
     Password for "cn=admin,dc=example,dc=com":
     shell%


File: krb5-admin.info,  Node: Retrieving Information About a Ticket Policy,  Next: Destroying a Ticket Policy,  Prev: Creating and Modifying a Ticket Policy,  Up: Global Operations on the Kerberos LDAP Database

Retrieving Information About a Ticket Policy
--------------------------------------------

     view_policy [-r realm] policy_name

view_policy
     This option displays the attributes of a ticket policy. Option is
     as follows:

-r realm
     Specifies the Kerberos realm of the database; by default the realm
     returned by krb5_default_local_realm(3) is used.

policy_name
     Specifies the name of the ticket policy.

For example:
     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu view_policy
     -r ATHENA.MIT.EDU usertktpolicy
     Password for "cn=admin,dc=example,dc=com":
     Ticket policy: usertktpolicy
     Maxmum ticket life: 0 days 01:00:00
     Maxmum renewable life: 0 days 10:00:00
     Ticket flags: DISALLOW_FORWARDABLE REQUIRES_PWCHANGE
     shell%


File: krb5-admin.info,  Node: Destroying a Ticket Policy,  Next: Listing available Ticket Policies,  Prev: Retrieving Information About a Ticket Policy,  Up: Global Operations on the Kerberos LDAP Database

Destroying a Ticket Policy
--------------------------

destroy_policy [-force] [-r realm] policy_name
     Destroys an existing ticket policy. Options are as follows:

    -force
          Forces the deletion of the policy object. If not specified,
          will be prompted for confirmation while deleting the policy.
          Enter yes to confirm the deletion.

    -r realm
          Specifies the Kerberos realm of the database; by default the
          realm returned by krb5_default_local_realm(3) is used.

    policy_name
          Specifies the name of the ticket policy.

For example:
     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu
     destroy_policy -r ATHENA.MIT.EDU usertktpolicy
     Password for "cn=admin,dc=example,dc=com":
     This will delete the policy object 'usertktpolicy', are you sure?
     (type 'yes' to confirm)? Yes
     ** policy object 'usertktpolicy' deleted.
     shell%


File: krb5-admin.info,  Node: Listing available Ticket Policies,  Next: Creating a Service Object (eDirectory),  Prev: Destroying a Ticket Policy,  Up: Global Operations on the Kerberos LDAP Database

Listing available Ticket Policies
---------------------------------

list_policy [-r realm]
     Lists the name of ticket policies in a realm.

     Option are as follows:

-r realm
     Specifies the Kerberos realm of the database; by default the realm
     returned by krb5_default_local_realm(3) is used.


For example:
     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu list_policy -r ATHENA.MIT.EDU
     Password for "cn=admin,dc=example,dc=com":
     usertktpolicy
     tempusertktpolicy
     krbtktpolicy
     shell%


File: krb5-admin.info,  Node: Creating a Service Object (eDirectory),  Next: Modifying a Service Object (eDirectory),  Prev: Listing available Ticket Policies,  Up: Global Operations on the Kerberos LDAP Database

Creating a Service Object (eDirectory)
--------------------------------------

     create_service -kdc|-admin|-pwd [-servicehost service_host_list] [-realm realm_list] [-randpw|
     -fileonly] [-filename] service_dn

Creates a service object in directory and assigns appropriate rights on
the container holding kerberos data.

Options are as follows:

-kdc
     Specifies the KDC service

-admin
     Specifies the Administration service

-pwd
     Specifies the Password service

-servicehost service_host_list
     Specifies the list of entries separated by a colon (:). Each entry
     consists of the hostname or IP address of the server hosting the
     service, transport protocol and the port number of the service
     separated by a pound sign (#).

     For example,
          server1#tcp#88:server2#udp#89.

-realm realm_list
     Specifies the list of realms that are to be associated with this
     service. The list contains the name of the realms separated by a
     colon (:).

-randpw
     Generates and sets a random password. This option is used to set
     the random password for the service object in directory and also
     to store it in the file. `-fileonly' option cannot be used with
     `-randpw' option.

-fileonly
     Stores the password only in a file and not in directory. The
     `-randpw' option can not be used when `-fileonly' option is
     specified.

-f filename
     Specifies the complete path of the file where the service object
     password is stashed. If this option is not specified, the default
     file will be /usr/local/var/service_passwd

service_dn
     Specifies the Distinguished Name (DN) of the Kerberos service to
     be created.

     For example:
          shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu
          create_service -kdc -randpw -f /home/andrew/service_passwd cn=service-kdc,dc=example,dc=com
          Password for "cn=admin,dc=example,dc=com":
          File does not exist. Creating the file /home/andrew/service_passwd...
          shell%


File: krb5-admin.info,  Node: Modifying a Service Object (eDirectory),  Next: Retrieving Service Object Information (eDirectory),  Prev: Creating a Service Object (eDirectory),  Up: Global Operations on the Kerberos LDAP Database

Modifying a Service Object (eDirectory)
---------------------------------------

     modify_service [-servicehost service_host_list |[-clearservicehost service_host_list] [-addservicehost service_host_list]] [-realm realm_list | [-clearrealm realm_list] [-addrealm realm_list]] service_dn

Modifies the attributes of a service and assigns appropriate rights, if
realm associations are changed.

Options are as follows:

-servicehost service_host_list
     List of entries separated by a colon (:) where each entry consists
     of host name or IP address of the server hosting the service,
     transport protocol, and port number of the service separated by a
     pound sign (#). This list replaces the existing list.  For example,
          server1#tcp#88:server2#udp#89

-clearservicehost service_host_list
     Specifies the list of servicehost entries to be removed from the
     existing list. This is a colon separated list.

-addservicehost service_host_list
     Specifies the list of servicehost entries to be added to the
     existing list. This is a colon separated list.

-realm realm_list
     Specifies the list of realms that are to be associated with this
     service. The list contains the name of the realms separated by a
     colon (:). This list replaces the existing list.

-clearrealm realm_list
     Specifies the list of realms to be removed from the existing list.
     The list contains the name of the realms separated by a colon (:).

-addrealm realm_list
     Specifies the list of realms to be added to the existing list. The
     list contains the name of the realms separated by a colon (:).

service_dn
     Specifies the Distinguished Name (DN) of the Kerberos service to
     be modified.


For example:

     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu
     modify_service -realm ATHENA.MIT.EDU cn=service-kdc,dc=example,dc=com
     Password for "cn=admin,dc=example,dc=com":
     Changing rights for the service object. Please wait ... done
     shell%


File: krb5-admin.info,  Node: Retrieving Service Object Information (eDirectory),  Next: Destroying a Service Object (eDirectory),  Prev: Modifying a Service Object (eDirectory),  Up: Global Operations on the Kerberos LDAP Database

Retrieving Service Object Information (eDirectory)
--------------------------------------------------

view_service service_dn
     Displays the attributes of a service. Options are as follows:

service_dn
     Specifies the Distinguished name (DN) of the Kerberos service to
     be viewed.

For example:
     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu
     view_service cn=service-kdc,dc=example,dc=com
     Password for "cn=admin,dc=example,dc=com":
     Service dn: cn=service-kdc,dc=example,dc=com
     Service type: kdc
     Service host list:
     Realm DN list: cn=ATHENA.MIT.EDU,cn=Kerberos,dc=example,dc=com
     shell%


File: krb5-admin.info,  Node: Destroying a Service Object (eDirectory),  Next: Listing Available Service Objects (eDirectory),  Prev: Retrieving Service Object Information (eDirectory),  Up: Global Operations on the Kerberos LDAP Database

Destroying a Service Object (eDirectory)
----------------------------------------

     destroy_service [-force] [-f stashfilename] service_dn

Destroys an existing service. Options are as follows :

-force
     If specified, will not prompt for user's confirmation, instead
     will force destruction of service.

-f stashfilename
     Complete path of the service password file from where the entry
     corresponding to the service_dn needs to be removed.

service_dn
     Distinguished Name (DN) of the Kerberos service to be destroyed.

For example:
     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu
     destroy_service cn=service-kdc,dc=example,dc=com
     Password for "cn=admin,dc=example,dc=com":
     This will delete the service object 'cn=service-kdc,dc=example,dc=com', are you sure?
     (type 'yes' to confirm)? Yes
     ** service object 'cn=service-kdc,dc=example,dc=com' deleted.
     shell%


File: krb5-admin.info,  Node: Listing Available Service Objects (eDirectory),  Next: Passwords for Service Objects (eDirectory),  Prev: Destroying a Service Object (eDirectory),  Up: Global Operations on the Kerberos LDAP Database

Listing Available Service Objects (eDirectory)
----------------------------------------------

list_service [-basedn base_dn]
     Lists the name of services under a given base in directory.
     Options is as follows:

-basedn base_dn
     Specifies the base DN for searching the policies, limiting the
     search to a particular subtree. If this option is not provided,
     LDAP Server specific search base will be used. For e.g., in the
     case of OpenLDAP, value of `defaultsearchbase' from `slapd.conf'
     file will be used, where as in the case of eDirectory, the default
     value for the base DN is Root.

For example:
     shell% kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu list_service
     Password for "cn=admin,dc=example,dc=com":
     cn=service-kdc,dc=example,dc=com
     cn=service-adm,dc=example,dc=com
     cn=service-pwd,dc=example,dc=com
     shell%


File: krb5-admin.info,  Node: Passwords for Service Objects (eDirectory),  Prev: Listing Available Service Objects (eDirectory),  Up: Global Operations on the Kerberos LDAP Database

Passwords for Service Objects (eDirectory)
------------------------------------------

setsrvpw [-randpw|-fileonly][-f  filename] service_dn

Allows an administrator to set password for service objects such as KDC
and Administration server in eDirectory and store them in a file. The
`-fileonly' command stores the password in a file and not in the
eDirectory object.  Options are as follows:
-randpw
     Generates and sets a random password on the directory object and
     stores it in the file. The `-fileonly' option can not be used if
     `-randpw' option is already specified.

-fileonly
     Stores the password only in a file and not in eDirectory. The
     `-randpw' option can not be used when `-fileonly' option is
     specified.

-f filename
     Specifies the complete path of the file where the service object
     password is stashed. If this option is not specified, the default
     file will be /usr/local/var/service_passwd.

service_dn
     Specifies the Distinguished Name (DN) of the service object whose
     password is to be set.


For example:

     shell% kdb5_ldap_util setsrvpw -D cn=admin,dc=example,dc=com -H ldaps://ldap-server1.mit.edu
     setsrvpw -f /home/andrew/conf_keyfile cn=service-kdc,dc=example,dc=com
     Password for "cn=admin,dc=example,dc=com":
     Password for "cn=service-kdc,dc=example,dc=com":
     Re-enter password for "cn=service-kdc,dc=example,dc=com":
     shell%


File: krb5-admin.info,  Node: Cross-realm Authentication,  Next: Changing the krbtgt Key,  Prev: Global Operations on the Kerberos LDAP Database,  Up: Administrating the Kerberos Database

Cross-realm Authentication
==========================

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 realms.
These principals should all have the same passwords, key version
numbers, and encryption types.  For example, if the administrators of
ATHENA.MIT.EDU and EXAMPLE.COM wanted to authenticate across the
realms, they would run the following commands on the KDCs in both
realms:

     shell%: kadmin.local -e "des3-hmac-sha1:normal des-cbc-crc:v4"
     kadmin: addprinc -requires_preauth krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM
     Enter password for principal krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM:
     Re-enter password for principal krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM:
     kadmin: addprinc -requires_preauth krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU
     Enter password for principal krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU:
     Enter password for principal krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU:
     kadmin:

Even if most principals in a realm are generally created with the
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.

It is also very important that these principals have good passwords.
MIT recommends that TGT principal passwords be at least 26 characters
of random ASCII text.


File: krb5-admin.info,  Node: Changing the krbtgt Key,  Prev: Cross-realm Authentication,  Up: Administrating the Kerberos Database

Changing the krbtgt Key
=======================

A Kerberos Ticket Granting Ticket (TGT) is a service ticket for the
principal 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 `kadmin change_password' command
would invalidate any previously issued TGTs.  Therefore, when changing
this key, normally one should use the -keepold flag to
`change_password' to retain the previous key in the database as well as
the new key.  For example:

     kadmin: change_password -randkey -keepold krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU

There is currently no way to remove the old key without running
`change_password' without the -keepold flag (and thereby invalidating
all existing TGTs).  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, it's therefore
currently necessary to declare a flag day, run `change_password'
without the -keepold flag, and force all users to acquire new tickets.

