Lines Matching +full:master +full:- +full:side
11 program has its own command-line interface, to which you type the
16 database master key, and to stash a copy of the key so that the
31 ticket for either service principal and the **-c** ccache option is
33 the **-p** and **-k** options are used to specify the client Kerberos
45 ----------
52 with the ``+requires_preauth -allow_svr`` options to help mitigate
55 kadmin: addprinc +requires_preauth -allow_svr alice
57 Re-enter password for principal "alice@KRBTEST.COM":
60 instead by created with the ``-nokey`` option:
62 kadmin: addprinc -nokey alice
64 Service principals can be created with the ``-nokey`` option;
65 long-term keys will be added when a keytab is generated::
67 kadmin: addprinc -nokey host/foo.mit.edu
68 kadmin: ktadd -k foo.keytab host/foo.mit.edu
69 …Entry for principal host/foo.mit.edu with kvno 1, encryption type aes256-cts-hmac-sha1-96 added to…
70 …Entry for principal host/foo.mit.edu with kvno 1, encryption type aes128-cts-hmac-sha1-96 added to…
75 kadmin: modprinc -expire tomorrow alice
100 --------
109 kadmin: addpol -maxlife "1 year" -history 3 stduser
116 **modify_principal** command with the **-policy** option:
118 kadmin: modprinc -policy stduser alice
142 kadmin: change_password -randkey kadmin/history
144 This command will fail if you specify the **-keepold** flag. Only one
149 master key instead of the history key, and implementing proper
156 ----------
175 -----------------------------------
182 To create a stash file using the master password (because the database
183 was not created with one using the ``create -s`` flag, or after
188 kdb5_util: Cannot find/read stored master key while reading master key
189 kdb5_util: Warning: proceeding without master key
190 Enter KDC database master key: <= Type the KDC database master password.
212 $ kbd5_util dump -verbose dumpfile
222 $ kdb5_util dump -verbose someprincs K/M@ATHENA.MIT.EDU kadmin/admin@ATHENA.MIT.EDU
232 only some principals, use the ``-update`` flag::
234 $ kdb5_util load -update someprincs
238 If the database file exists, and the *-update* flag was not
244 Updating the master key
247 Starting with release 1.7, :ref:`kdb5_util(8)` allows the master key
249 availability. To roll over the master key, follow these steps:
252 current master key version number (KVNO). If you have never rolled
253 over the master key before, this will likely be version 1::
256 Master keys for Principal: K/M@KRBTEST.COM
257 KVNO: 1, Enctype: aes256-cts-hmac-sha384-192, Active on: Thu Jan 01 00:00:00 UTC 1970 *
260 master key activation list is present in the database. This step
264 #. On the primary KDC, run ``kdb5_util add_mkey -s`` to create a new
265 master key and write it to the stash file. Enter a secure password
267 master key, the new key will have version 2. The new master key
275 the new master key is present, and then ``kdb5_util stash`` to
276 write the new master key to the replica KDC's stash file.
279 new master key. Replace ``2`` with the version of the new master
281 master key to become active; by default, it will become active
286 This command will iterate over the database and re-encrypt all keys
287 in the new master key. If the database is large and uses DB2, the
291 instead run ``kdb5_util -x unlockiter update_princ_encryption`` to
300 old master key.
306 -------------------------------
322 $ kdb5_ldap_util modify -maxtktlife "10 hours"
352 $ kdb5_ldap_util create_policy -maxrenewlife "2 days" users
356 with the **-x tktpolicy=**\ *policy* option::
358 $ kadmin.local modprinc -x tktpolicy=users alice
363 $ kadmin.local modprinc -x tktpolicy= alice
374 $ kdb5_ldap_util modify_policy -allow_svr +requires_preauth users
395 Cross-realm authentication
396 --------------------------
401 For example, if you need to do cross-realm authentication between the realms
407 the key version number with the **-kvno** option.
409 In the ATHENA.MIT.EDU and EXAMPLE.COM cross-realm case, the administrators
412 shell%: kadmin.local -e "aes256-cts:normal"
413 kadmin: addprinc -requires_preauth krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM
415 Re-enter password for principal krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM:
416 kadmin: addprinc -requires_preauth krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU
425 desirable on cross-realm authentication keys because doing
427 service-by-service basis. Disabling it as in the example
440 -----------------------
452 **-keepold** flag to change_password to retain the previous key in the
455 kadmin: change_password -randkey -keepold krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
467 ticket-granting tickets. However, the set of encryption types present
470 :ref:`session_key_selection`). Because non-MIT Kerberos clients
475 specifying any **-e** option when changing the krbtgt key, or by
488 --------------------------------
506 Incremental propagation uses the following entries in the per-realm
515 …sed, or the file name is specified in the *dbmodules* section, then the hard-coded default for *da…
520 fully-qualified, canonical name for the host) registered in the
526 On the primary KDC side, the ``kiprop/hostname`` principal must be
530 On the replica KDC side, :ref:`kpropd(8)` should be run. When
540 and invoke a one-time kprop propagation, with special options to also
547 updates to every replica. To do this, run ``kadmind -proponly`` on
548 each intermediate replica, and ``kpropd -A upstreamhostname`` on
554 - The incremental update protocol does not transport changes to policy
557 - The replica's KDB module must support locking; it cannot be using the
559 - The primary and replica must be able to initiate TCP connections in
583 The Sun implementation hard-codes pathnames in ``/var/krb5`` for the
584 update log and the per-replica kprop dump files. In the MIT
586 config file, and the per-replica dump files are stored in