1KRB5.CONF(5) File Formats Manual KRB5.CONF(5)
2
6 krb5.conf - Kerberos configuration file
7
9 krb5.conf contains configuration information needed by the Kerberos V5
10 library. This includes information describing the default Kerberos
11 realm, and the location of the Kerberos key distribution centers for
12 known realms.
13 The krb5.conf file uses an INI-style format. Sections are delimited by
15 square braces; within each section, there are relations where tags can
16 be assigned to have specific values. Tags can also contain a subsec‐
17 tion, which contains further relations or subsections. A tag can be
18 assigned to multiple values. Here is an example of the INI-style for‐
19 mat used by krb5.conf:
20 [section1]
23 tag1 = value_a
24 tag1 = value_b
25 tag2 = value_c
26 [section 2]
28 tag3 = {
29 subtag1 = subtag_value_a
30 subtag1 = subtag_value_b
31 subtag2 = subtag_value_c
32 }
33 tag4 = {
34 subtag1 = subtag_value_d
35 subtag2 = subtag_value_e
36 }
37 krb5.conf can include other files using the directives "include FILE‐
41 NAME" or "includedir DIRNAME", which must occur at the beginning of a
42 line. FILENAME or DIRNAME should be an absolute path. The named file
43 or directory must exist and be readable. Including a directory
44 includes all files within the directory whose names consist solely of
45 alphanumeric characters, dashes, or underscores. Included profile
46 files are syntactically independent of their parents, so each included
47 file must begin with a section header.
48 krb5.conf can cause configuration to be obtained from a loadable pro‐
51 file module by placing the directive "module MODULEPATH:RESIDUAL" at
52 the beginning of a line before any section headers. MODULEPATH may be
53 relative to the library path of the krb5 installation, or it may be an
54 absolute path. RESIDUAL is provided to the module at initialization
55 time. If krb5.conf uses a module directive, kdc.conf should also use
56 one if it exists.
57 The following sections are currently used in the krb5.conf file:
60 [libdefaults]
62 Contains various default values used by the Kerberos V5 library.
63 [login]
66 Contains default values used by the Kerberos V5 login program,
67 login.krb5(8).
68 [appdefaults]
71 Contains default values that can be used by Kerberos V5 applica‐
72 tions.
73 [realms]
76 Contains subsections keyed by Kerberos realm names which
77 describe where to find the Kerberos servers for a particular
78 realm, and other realm-specific information.
79 [domain_realm]
82 Contains relations which map subdomains and domain names to Ker‐
83 beros realm names. This is used by programs to determine what
84 realm a host should be in, given its fully qualified domain
85 name.
86 [logging]
89 Contains relations which determine how Kerberos entities are to
90 perform their logging.
91 [capaths]
94 Contains the authentication paths used with non-hierarchical
95 cross-realm. Entries in the section are used by the client to
96 determine the intermediate realms which may be used in cross-
97 realm authentication. It is also used by the end-service when
98 checking the transited field for trusted intermediate realms.
99 [dbdefaults]
102 Contains default values for database specific parameters.
103 [dbmodules]
106 Contains database specific parameters used by the database
107 library.
108 [plugins]
111 Contains plugin module registration and filtering parameters.
112 Each of these sections will be covered in more details in the following
114 sections.
115
117 The following relations are defined in the [libdefaults] section:
118 default_keytab_name
121 This relation specifies the default keytab name to be used by
122 application severs such as telnetd and rlogind. The default is
123 "/etc/krb5.keytab". This formerly defaulted to "/etc/v5srvtab",
124 but was changed to the current value.
125 default_realm
128 This relation identifies the default realm to be used in a
129 client host's Kerberos activity.
130 default_tgs_enctypes
133 This relation identifies the supported list of session key
134 encryption types that should be returned by the KDC. The list
135 may be delimited with commas or whitespace.
136 default_tkt_enctypes
139 This relation identifies the supported list of session key
140 encryption types that should be requested by the client, in the
141 same format.
142 permitted_enctypes
145 This relation identifies the permitted list of session key
146 encryption types.
147 allow_weak_crypto
150 If this is set to 0 (for false), then weak encryption types will
151 be filtered out of the previous three lists. The default value
152 for this tag is false, which may cause authentication failures
153 in existing Kerberos infrastructures that do not support strong
154 crypto. Users in affected environments should set this tag to
155 true until their infrastructure adopts stronger ciphers.
156 clockskew
159 This relation sets the maximum allowable amount of clockskew in
160 seconds that the library will tolerate before assuming that a
161 Kerberos message is invalid. The default value is 300 seconds,
162 or five minutes.
163 ignore_acceptor_hostname
166 When accepting GSSAPI or krb5 security contexts for host-based
167 service principals, ignore any hostname passed by the calling
168 application and allow any service principal present in the
169 keytab which matches the service name and realm name (if given).
170 This option can improve the administrative flexibility of server
171 applications on multi-homed hosts, but can compromise the secu‐
172 rity of virtual hosting environments. The default value is
173 false.
174 k5login_authoritative
177 If the value of this relation is true (the default), principals
178 must be listed in a local user's k5login file to be granted
179 login access, if a k5login file exists. If the value of this
180 relation is false, a principal may still be granted login access
181 through other mechanisms even if a k5login file exists but does
182 not list the principal.
183 k5login_directory
186 If set, the library will look for a local user's k5login file
187 within the named directory, with a filename corresponding to the
188 local username. If not set, the library will look for k5login
189 files in the user's home directory, with the filename .k5login.
190 For security reasons, k5login files must be owned by the local
191 user or by root.
192 kdc_timesync
195 If the value of this relation is non-zero (the default), the
196 library will compute the difference between the system clock and
197 the time returned by the KDC and in order to correct for an
198 inaccurate system clock. This corrective factor is only used by
199 the Kerberos library.
200 kdc_req_checksum_type
203 For compatibility with DCE security servers which do not support
204 the default CKSUMTYPE_RSA_MD5 used by this version of Kerberos.
205 Use a value of 2 to use the CKSUMTYPE_RSA_MD4 instead. This
206 applies to DCE 1.1 and earlier. This value is only used for DES
207 keys; other keys use the preferred checksum type for those keys.
208 ap_req_checksum_type
211 If set this variable controls what ap-req checksum will be
212 used in authenticators. This variable should be unset so the
213 appropriate checksum for the encryption key in use will be used.
214 This can be set if backward compatibility requires a specific
215 checksum type.
216 safe_checksum_type
219 This allows you to set the preferred keyed-checksum type for use
220 in KRB_SAFE messages. The default value for this type is CKSUM‐
221 TYPE_RSA_MD5_DES. For compatibility with applications linked
222 against DCE version 1.1 or earlier Kerberos libraries, use a
223 value of 3 to use the CKSUMTYPE_RSA_MD4_DES instead. This field
224 is ignored when its value is incompatible with the session key
225 type.
226 preferred_preauth_types
229 This allows you to set the preferred preauthentication types
230 which the client will attempt before others which may be adver‐
231 tised by a KDC. The default value for this setting is "17, 16,
232 15, 14", which forces libkrb5 to attempt to use PKINIT if it is
233 supported.
234 ccache_type
237 User this parameter on systems which are DCE clients, to specify
238 the type of cache to be created by kinit, or when forwarded
239 tickets are received. DCE and Kerberos can share the cache, but
240 some versions of DCE do not support the default cache as created
241 by this version of Kerberos. Use a value of 1 on DCE 1.0.3a sys‐
242 tems, and a value of 2 on DCE 1.1 systems.
243 dns_lookup_kdc
246 Indicate whether DNS SRV records should be used to locate the
247 KDCs and other servers for a realm, if they are not listed in
248 the information for the realm. The default is to use these
249 records.
250 dns_lookup_realm
253 Indicate whether DNS TXT records should be used to determine the
254 Kerberos realm of a host. The default is not to use these
255 records.
256 dns_fallback
259 General flag controlling the use of DNS for Kerberos informa‐
260 tion. If both of the preceding options are specified, this
261 option has no effect.
262 realm_try_domains
265 Indicate whether a host's domain components should be used to
266 determine the Kerberos realm of the host. The value of this
267 variable is an integer: -1 means not to search, 0 means to try
268 the host's domain itself, 1 means to also try the domain's imme‐
269 diate parent, and so forth. The library's usual mechanism for
270 locating Kerberos realms is used to determine whether a domain
271 is a valid realm--which may involve consulting DNS if
272 dns_lookup_kdc is set. The default is not to search domain com‐
273 ponents.
274 extra_addresses
277 This allows a computer to use multiple local addresses, in order
278 to allow Kerberos to work in a network that uses NATs. The
279 addresses should be in a comma-separated list.
280 udp_preference_limit
283 When sending a message to the KDC, the library will try using
284 TCP before UDP if the size of the message is above "udp_prefer‐
285 ence_limit". If the message is smaller than "udp_prefer‐
286 ence_limit", then UDP will be tried before TCP. Regardless of
287 the size, both protocols will be tried if the first attempt
288 fails.
289 verify_ap_req_nofail
292 If this flag is set, then an attempt to get initial credentials
293 will fail if the client machine does not have a keytab. The
294 default for the flag is false.
295 ticket_lifetime
298 The value of this tag is the default lifetime for initial tick‐
299 ets. The default value for the tag is 1 day (1d).
300 renew_lifetime
303 The value of this tag is the default renewable lifetime for ini‐
304 tial tickets. The default value for the tag is 0.
305 noaddresses
308 Setting this flag causes the initial Kerberos ticket to be
309 addressless. The default for the flag is true.
310 forwardable
313 If this flag is set, initial tickets by default will be forward‐
314 able. The default value for this flag is false.
315 proxiable
318 If this flag is set, initial tickets by default will be proxi‐
319 able. The default value for this flag is false.
320 rdns If set to false, prevent the use of reverse DNS resolution when
323 translating hostnames into service principal names. Defaults to
324 true. Setting this flag to false is more secure, but may force
325 users to exclusively use fully qualified domain names when
326 authenticating to services.
327 plugin_base_dir
330 If set, determines the base directory where krb5 plugins are
331 located. The default value is the "krb5/plugins" subdirectory
332 of the krb5 library directory.
333
336 Each tag in the [appdefaults] section names a Kerberos V5 application
337 or an option that is used by some Kerberos V5 application[s]. The four
338 ways that you can set values for options are as follows, in decreasing
339 order of precedence:
340 #1)
343 application = {
344 realm1 = {
345 option = value
346 }
347 realm2 = {
348 option = value
349 }
350 }
351 #2)
352 application = {
353 option1 = value
354 option2 = value
355 }
356 #3)
357 realm = {
358 option = value
359 }
360 #4)
361 option = value
362
366 The [login] section is used to configure the behavior of the Kerberos
367 V5 login program, login.krb5(8). Refer to the manual entry for
368 login.krb5 for a description of the relations allowed in this section.
369
371 Each tag in the [realms] section of the file names a Kerberos realm.
372 The value of the tag is a subsection where the relations in that sub‐
373 section define the properties of that particular realm. For example:
374 [realms]
377 ATHENA.MIT.EDU = {
378 admin_server = KERBEROS.MIT.EDU
379 default_domain = MIT.EDU
380 database_module = ldapconf
381 v4_instance_convert = {
382 mit = mit.edu
383 lithium = lithium.lcs.mit.edu
384 }
385 v4_realm = LCS.MIT.EDU
386 }
387 For each realm, the following tags may be specified in the realm's sub‐
390 section:
391 kdc The value of this relation is the name of a host running a KDC
394 for that realm. An optional port number (preceded by a colon)
395 may be appended to the hostname. This tag should generally be
396 used only if the realm administrator has not made the informa‐
397 tion available through DNS.
398 admin_server
401 This relation identifies the host where the administration
402 server is running. Typically this is the Master Kerberos
403 server.
404 database_module
407 This relation indicates the name of the configuration section
408 under dbmodules for database specific parameters used by the
409 loadable database library.
410 default_domain
413 This relation identifies the default domain for which hosts in
414 this realm are assumed to be in. This is needed for translating
415 V4 principal names (which do not contain a domain name) to V5
416 principal names (which do).
417 v4_instance_convert
420 This subsection allows the administrator to configure exceptions
421 to the default_domain mapping rule. It contains V4 instances
422 (the tag name) which should be translated to some specific host‐
423 name (the tag value) as the second component in a Kerberos V5
424 principal name.
425 v4_realm
428 This relation is used by the krb524 library routines when con‐
429 verting a V5 principal name to a V4 principal name. It is used
430 when V4 realm name and the V5 realm are not the same, but still
431 share the same principal names and passwords. The tag value is
432 the Kerberos V4 realm name.
433 auth_to_local_names
436 This subsection allows you to set explicit mappings from princi‐
437 pal names to local user names. The tag is the mapping name, and
438 the value is the corresponding local user name.
439 auth_to_local
442 This tag allows you to set a general rule for mapping principal
443 names to local user names. It will be used if there is not an
444 explicit mapping for the principal name that is being trans‐
445 lated. The possible values are:
446 DB:<filename>
448 The principal will be looked up in the database <file‐
449 name>. Support for this is not currently compiled in
450 by default.
451 RULE:<exp>
452 The local name will be formulated from <exp>.
453 DEFAULT
454 The principal name will be used as the local name. If
455 the principal has more than one component or is not in
456 the default realm, this rule is not applicable and the
457 conversion will fail.
458
461 The [domain_realm] section provides a translation from a hostname to
462 the Kerberos realm name for the services provided by that host.
463 The tag name can be a hostname, or a domain name, where domain names
465 are indicated by a prefix of a period ('.') character. The value of
466 the relation is the Kerberos realm name for that particular host or
467 domain. Host names and domain names should be in lower case.
468 If no translation entry applies, the host's realm is considered to be
470 the hostname's domain portion converted to upper case. For example,
471 the following [domain_realm] section:
472 [domain_realm]
475 .mit.edu = ATHENA.MIT.EDU
476 mit.edu = ATHENA.MIT.EDU
477 dodo.mit.edu = SMS_TEST.MIT.EDU
478 .ucsc.edu = CATS.UCSC.EDU
479 maps dodo.mit.edu into the SMS_TEST.MIT.EDU realm, all other hosts in
481 the MIT.EDU domain to the ATHENA.MIT.EDU realm, and all hosts in the
482 UCSC.EDU domain into the CATS.UCSC.EDU realm. ucbvax.berkeley.edu
483 would be mapped by the default rules to the BERKELEY.EDU realm, while
484 sage.lcs.mit.edu would be mapped to the LCS.MIT.EDU realm.
485
488 The [logging] section indicates how a particular entity is to perform
489 its logging. The relations specified in this section assign one or
490 more values to the entity name.
491 Currently, the following entities are used:
493 kdc These entries specify how the KDC is to perform its logging.
495 admin_server
497 These entries specify how the administrative server is to per‐
498 form its logging.
499 default
501 These entries specify how to perform logging in the absence of
502 explicit specifications otherwise.
503 Values are of the following forms:
505 FILE=<filename>
507 FILE:<filename>
509 This value causes the entity's logging messages to go to the
510 specified file. If the = form is used, then the file is over‐
511 written. Otherwise, the file is appended to.
512 STDERR This value causes the entity's logging messages to go to its
514 standard error stream.
515 CONSOLE
517 This value causes the entity's logging messages to go to the
518 console, if the system supports it.
519 DEVICE=<devicename>
521 This causes the entity's logging messages to go to the specified
522 device.
523 SYSLOG[:<severity>[:<facility>]]
525 This causes the entity's logging messages to go to the system
526 log.
527 The severity argument specifies the default severity of system
529 log messages. This may be any of the following severities sup‐
530 ported by the syslog(3) call minus the LOG_ prefix: LOG_EMERG,
531 LOG_ALERT, LOG_CRIT, LOG_ERR, LOG_WARNING, LOG_NOTICE, LOG_INFO,
532 and LOG_DEBUG. For example, to specify LOG_CRIT severity, one
533 would use CRIT for severity.
534 The facility argument specifies the facility under which the
536 messages are logged. This may be any of the following facili‐
537 ties supported by the syslog(3) call minus the LOG_ prefix:
538 LOG_KERN, LOG_USER, LOG_MAIL, LOG_DAEMON, LOG_AUTH, LOG_LPR,
539 LOG_NEWS, LOG_UUCP, LOG_CRON, and LOG_LOCAL0 through LOG_LOCAL7.
540 If no severity is specified, the default is ERR, and if no
542 facility is specified, the default is AUTH.
543 In the following example, the logging messages from the KDC will go to
545 the console and to the system log under the facility LOG_DAEMON with
546 default severity of LOG_INFO; and the logging messages from the admin‐
547 istrative server will be appended to the file /var/adm/kadmin.log and
548 sent to the device /dev/tty04.
549 [logging]
551 kdc = CONSOLE
552 kdc = SYSLOG:INFO:DAEMON
553 admin_server = FILE:/var/adm/kadmin.log
554 admin_server = DEVICE=/dev/tty04
555
559 Cross-realm authentication is typically organized hierarchically. This
560 hierarchy is based on the name of the realm, which thus imposes
561 restrictions on the choice of realm names, and on who may participate
562 in a cross-realm authentication. A non hierarchical organization may be
563 used, but requires a database to construct the authentication paths
564 between the realms. This section defines that database.
565 A client will use this section to find the authentication path between
567 its realm and the realm of the server. The server will use this section
568 to verify the authentication path used be the client, by checking the
569 transited field of the received ticket.
570 There is a tag name for each participating realm, and each tag has sub‐
572 tags for each of the realms. The value of the subtags is an intermedi‐
573 ate realm which may participate in the cross-realm authentication. The
574 subtags may be repeated if there is more then one intermediate realm. A
575 value of "." means that the two realms share keys directly, and no
576 intermediate realms should be allowed to participate.
577 There are n**2 possible entries in this table, but only those entries
579 which will be needed on the client or the server need to be present.
580 The client needs a tag for its local realm, with subtags for all the
581 realms of servers it will need to authenticate with. A server needs a
582 tag for each realm of the clients it will serve.
583 For example, ANL.GOV, PNL.GOV, and NERSC.GOV all wish to use the ES.NET
585 realm as an intermediate realm. ANL has a sub realm of TEST.ANL.GOV
586 which will authenticate with NERSC.GOV but not PNL.GOV. The [capath]
587 section for ANL.GOV systems would look like this:
588 [capaths]
590 ANL.GOV = {
591 TEST.ANL.GOV = .
592 PNL.GOV = ES.NET
593 NERSC.GOV = ES.NET
594 ES.NET = .
595 }
596 TEST.ANL.GOV = {
597 ANL.GOV = .
598 }
599 PNL.GOV = {
600 ANL.GOV = ES.NET
601 }
602 NERSC.GOV = {
603 ANL.GOV = ES.NET
604 }
605 ES.NET = {
606 ANL.GOV = .
607 }
608 The [capath] section of the configuration file used on NERSC.GOV sys‐
610 tems would look like this:
611 [capaths]
613 NERSC.GOV = {
614 ANL.GOV = ES.NET
615 TEST.ANL.GOV = ES.NET
616 TEST.ANL.GOV = ANL.GOV
617 PNL.GOV = ES.NET
618 ES.NET = .
619 }
620 ANL.GOV = {
621 NERSC.GOV = ES.NET
622 }
623 PNL.GOV = {
624 NERSC.GOV = ES.NET
625 }
626 ES.NET = {
627 NERSC.GOV = .
628 }
629 TEST.ANL.GOV = {
630 NERSC.GOV = ANL.GOV
631 NERSC.GOV = ES.NET
632 }
633 In the above examples, the ordering is not important, except when the
635 same subtag name is used more then once. The client will use this to
636 determine the path. (It is not important to the server, since the tran‐
637 sited field is not sorted.)
638 If this section is not present, or if the client or server cannot find
640 a client/server path, then normal hierarchical organization is assumed.
641 This feature is not currently supported by DCE. DCE security servers
643 can be used with Kerberized clients and servers, but versions prior to
644 DCE 1.1 did not fill in the transited field, and should be used with
645 caution.
646
649 The [dbdefaults] section indicates default values for the database spe‐
650 cific parameters. It can also specify the configuration section under
651 dbmodules for database specific parameters used by the loadable data‐
652 base library.
653 The following tags are used in this section:
656 database_module
658 This relation indicates the name of the configuration section
659 under dbmodules for database specific parameters used by the
660 loadable database library.
661 ldap_kerberos_container_dn
664 This LDAP specific tag indicates the DN of the container object
665 where the realm objects will be located. This value is used if
666 no object DN is mentioned in the configuration section under
667 dbmodules.
668 ldap_kdc_dn
671 This LDAP specific tag indicates the default bind DN for the KDC
672 server. The KDC server does a login to the directory as this
673 object. This value is used if no object DN is mentioned in the
674 configuration section under dbmodules.
675 ldap_kadmind_dn
678 This LDAP specific tag indicates the default bind DN for the
679 Administration server. The Administration server does a login to
680 the directory as this object. This value is used if no object DN
681 is mentioned in the configuration section under dbmodules.
682 ldap_service_password_file
685 This LDAP specific tag indicates the file containing the stashed
686 passwords for the objects used for starting the Kerberos
687 servers. This value is used if no service password file is men‐
688 tioned in the configuration section under dbmodules.
689 ldap_servers
692 This LDAP specific tag indicates the list of LDAP servers. The
693 list of LDAP servers is whitespace-separated. The LDAP server is
694 specified by a LDAP URI. This value is used if no LDAP servers
695 are mentioned in the configuration section under dbmodules.
696 ldap_conns_per_server
699 This LDAP specific tag indicates the number of connections to be
700 maintained per LDAP server. This value is used if the number of
701 connections per LDAP server are not mentioned in the configura‐
702 tion section under dbmodules. The default value is 5.
703
706 Each tag in the [dbmodules] section of the file names a configuration
707 section for database specific parameters that can be referred to by a
708 realm. The value of the tag is a subsection where the relations in
709 that subsection define the database specific parameters.
710 For each section, the following tags may be specified in the subsec‐
713 tion:
714 database_name
717 This DB2-specific tag indicates the location of the database in
718 the filesystem.
719 db_library
722 This tag indicates the name of the loadable database library.
723 The value should be db2 for db2 database and kldap for LDAP
724 database.
725 disable_last_success
728 If set to true, suppresses KDC updates to the "Last successful
729 authentication" field of principal entries requiring preauthen‐
730 tication. Setting this flag may improve performance. (Princi‐
731 pal entries which do not require preauthentication never update
732 the "Last successful authentication" field.)
733 disable_lockout
736 If set to true, suppresses KDC updates to the "Last failed
737 authentication" and "Failed password attempts" fields of princi‐
738 pal entries requiring preauthentication. Setting this flag may
739 improve performance, but also disables account lockout.
740 ldap_kerberos_container_dn
743 This LDAP specific tag indicates the DN of the container object
744 where the realm objects will be located.
745 ldap_kdc_dn
748 This LDAP specific tag indicates the bind DN for the KDC server.
749 The KDC does a login to the directory as this object.
750 ldap_kadmind_dn
753 This LDAP specific tag indicates the bind DN for the Administra‐
754 tion server. The Administration server does a login to the
755 directory as this object.
756 ldap_service_password_file
759 This LDAP specific tag indicates the file containing the stashed
760 passwords for the objects used for starting the Kerberos
761 servers.
762 ldap_servers
765 This LDAP specific tag indicates the list of LDAP servers. The
766 list of LDAP servers is whitespace-separated. The LDAP server is
767 specified by a LDAP URI.
768 ldap_conns_per_server
771 This LDAP specific tag indicates the number of connections to be
772 maintained per LDAP server.
773
776 Tags in the [plugins] section can be used to register dynamic plugin
777 modules and to turn modules on and off. Not every krb5 pluggable
778 interface uses the [plugins] section; the ones that do are documented
779 here.
780 Each pluggable interface corresponds to a subsection of [plugins]. All
783 subsections support the same tags:
784 module This tag may have multiple values. Each value is a string of
787 the form "modulename:pathname", which causes the shared object
788 located at pathname to be registered as a dynamic module named
789 modulename for the pluggable interface. If pathname is not an
790 absolute path, it will be treated as relative to the plugin base
791 directory.
792 enable_only
795 This tag may have multiple values. If there are values for this
796 tag, then only the named modules will be enabled for the plug‐
797 gable interface.
798 disable
801 This tag may have multiple values. If there are values for this
802 tag, then the named modules will be disabled for the pluggable
803 interface.
804 The following subsections are currently supported within the [plugins]
807 section:
808 pwqual interface
811 The pwqual subsection controls modules for the password quality inter‐
812 face, which is used to reject weak passwords when passwords are
813 changed. In addition to any registered dynamic modules, the following
814 built-in modules exist (and may be disabled with the disable tag):
815 dict Checks against the realm dictionary file
818 empty Rejects empty passwords
821 hesiod Checks against user information stored in Hesiod (only if Ker‐
824 beros was built with Hesiod support)
825 princ Checks against components of the principal name
828 kadm5_hook interface
831 The kadm5_hook interface provides plugins with information on principal
832 creation, modification, password changes and deletion. This interface
833 can be used to write a plugin to synchronize MIT Kerberos with another
834 database such as Active Directory. No plugins are built in for this
835 interface.
836 clpreauth and kdcpreauth interfaces
839 The clpreauth and kdcpreauth interfaces allow plugin modules to provide
840 client and KDC preauthentication mechanisms. The following built-in
841 modules exist for these interfaces:
842 pkinit This module implements the PKINIT preauthentication mechanism.
845 encrypted_challenge
848 This module implements the encrypted challenge FAST factor.
849 encrypted_timestamp
852 This module implements the encrypted timestamp mechanism.
853
856 /etc/krb5.conf
857
859 syslog(3)
860 KRB5.CONF(5)