Node: Adding or Modifying Principals, Next: Deleting Principals, Previous: Privileges, Up: Principals

### Adding or Modifying Principals

To add a principal to the database, use the kadmin `add_principal` command, which requires the "add" administrative privilege. This function creates the new principal, prompting twice for a password, and, if neither the -policy nor -clearpolicy options are specified and the policy "default" exists, assigns it that policy. The syntax is:

         kadmin: add_principal [options] principal

To modify attributes of a principal, use the kadmin `modify_principal` command, which requires the "modify" administrative privilege. The syntax is:

         kadmin: modify_principal [options] principal

`add_principal` has the aliases `addprinc` and `ank` 1. `modify_principal` has the alias `modprinc`.

The `add_principal` and `modify_principal` commands take the following switches:

-expire date
  Sets the expiration date of the principal to date.
-pwexpire date
  Sets the expiration date of the password to date.
-maxlife maxlife
  Sets the maximum ticket life of the principal to maxlife.
-maxrenewlife maxrenewlife
  Sets the maximum renewable life of tickets for the principal to maxrenewlife.
-kvno number
  Explicity sets the key version number to number. MIT does not recommend doing this unless there is a specific reason.
-policy policy
  Sets the policy used by this principal. (See Policies.) With `modify_principal`, the current policy assigned to the principal is set or changed. With `add_principal`, if this option is not supplied, the -clearpolicy is not specified, and the policy "default" exists, that policy is assigned. If a principal is created with no policy, `kadmin` will print a warning message.
-clearpolicy
  For `modify_principal`, removes the current policy from a principal. For `add_principal`, suppresses the automatic assignment of the policy "default".
{-|+}allow_postdated
  The "-allow_postdated" option prohibits this principal from obtaining postdated tickets. "+allow_postdated" clears this flag. In effect, "-allow_postdated" sets the KRB5_KDB_DISALLOW_POSTDATED flag on the principal in the database.
{-|+}allow_forwardable
  The "-allow_forwardable" option prohibits this principal from obtaining forwardable tickets. "+allow_forwardable" clears this flag. In effect, "-allow_forwardable" sets the KRB5_KDB_DISALLOW_FORWARDABLE flag on the principal in the database.
{-|+}allow_renewable
  The "-allow_renewable" option prohibits this principal from obtaining renewable tickets. "+allow_renewable" clears this flag. In effect, "-allow_renewable" sets the KRB5_KDB_DISALLOW_RENEWABLE flag on the principal in the database.
{-|+}allow_proxiable
  The "-allow_proxiable" option prohibits this principal from obtaining proxiable tickets. "+allow_proxiable" clears this flag. In effect, "-allow_proxiable" sets the
  KRB5_KDB_DISALLOW_PROXIABLE flag. on the principal in the database.
{-|+}allow_dup_skey
  The "-allow_dup_skey" option disables user-to-user authentication for this principal by prohibiting this principal from obtaining a session key for another user. "+allow_dup_skey" clears this flag. In effect, "-allow_dup_skey" sets the
  KRB5_KDB_DISALLOW_DUP_SKEY flag on the principal in the database.
{-|+}requires_preauth
  The "+requires_preauth" option requires this principal to preauthenticate before being allowed to kinit. -requires_preauth clears this flag. In effect, +requires_preauth sets the KRB5_KDB_REQUIRES_PRE_AUTH flag on the principal in the database.
{-|+}requires_hwauth
  The "+requires_hwauth" flag requires the principal to preauthenticate using a hardware device before being allowed to kinit. "-requires_hwauth" clears this flag. In effect, "+requires_hwauth" sets the KRB5_KDB_REQUIRES_HW_AUTH flag on the principal in the database.
{-|+}allow_svr
  The "-allow_svr" flag prohibits the issuance of service tickets for this principal. "+allow_svr" clears this flag. In effect, "-allow_svr" sets the
  KRB5_KDB_DISALLOW_SVR flag on the principal in the database.
{-|+}allow_tgs_req
  The "-allow_tgs_req" option specifies that a Ticket-Granting Service (TGS) request for a service ticket for this principal is not permitted. You will probably never need to use this option. "+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 the principal in the database.
{-|+}allow_tix
  The "-allow_tix" option forbids the issuance of any tickets for this principal. "+allow_tix" clears this flag. The default is "+allow_tix". In effect, "-allow_tix" sets the
  KRB5_KDB_DISALLOW_ALL_TIX flag on the principal in the database.
{-|+}needchange
  The "+needchange" option 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_REQUIRES_PWCHANGE flag on the principal in the database.
{-|+}password_changing_service
  The "+password_changing_service" option sets a flag in the attributes field marking this principal as a password change service. (Again, you will probably never need to use this option.) "-password_changing_service" clears the flag. The default is "-password_changing_service". In effect, the "+password_changing_service" option sets the KRB5_KDB_PWCHANGE_SERVICE flag on the principal in the database.
-randkey
  Sets the key for the principal to a random value (`add_principal` only). MIT recommends using this option for host keys.
-pw password
  Sets the key of the principal to the specified string and does not prompt for a password (`add_principal` only). MIT does not recommend using this option.
-e enc:salt...
  Uses the specified list of enctype-salttype pairs for setting the key of the principal. The quotes are necessary if there are multiple enctype-salttype pairs. This will not function against kadmin daemons earlier than krb5-1.2. See Supported Encryption Types and Salts for available types.

If you want to just use the default values, all you need to do is:

         kadmin: addprinc jennifer
         WARNING: no policy specified for "jennifer@ATHENA.MIT.EDU";
         defaulting to no policy.
         Enter password for principal jennifer@ATHENA.MIT.EDU:  <= Type the password.
         Re-enter password for principal jennifer@ATHENA.MIT.EDU:  <=Type it again.
         Principal "jennifer@ATHENA.MIT.EDU" created.
         kadmin:

If, on the other hand, you want to set up an account that expires on January 1, 2000, that uses a policy called "stduser", with a temporary password (which you want the user to change immediately), you would type the following. (Note: each line beginning with => is a continuation of the previous line.)

         kadmin: addprinc david -expire "1/1/2000 12:01am EST" -policy stduser
         =>  +needchange
         Enter password for principal david@ATHENA.MIT.EDU:  <= Type the password.
         Re-enter password for principal
         david@ATHENA.MIT.EDU:  <= Type it again.
         Principal "david@ATHENA.MIT.EDU" created.
         kadmin:

If you will need cross-realm authentication, you need to add principals for the other realm's TGT to each realm. For example, if you need to do cross-realm authentication between the realms ATHENA.MIT.EDU and EXAMPLE.COM, you would need to add the principals
`krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU` and `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 Cross-realm Authentication for more details.

#### Footnotes

1. `ank` was the short form of the equivalent command using the deprecated `kadmin5` database administrative tool. It has been kept