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 The following sections are currently used in the krb5.conf file:
41 [libdefaults]
43 Contains various default values used by the Kerberos V5 library.
44 [login]
47 Contains default values used by the Kerberos V5 login program,
48 login.krb5(8).
49 [appdefaults]
52 Contains default values that can be used by Kerberos V5 applica‐
53 tions.
54 [realms]
57 Contains subsections keyed by Kerberos realm names which
58 describe where to find the Kerberos servers for a particular
59 realm, and other realm-specific information.
60 [domain_realm]
63 Contains relations which map subdomains and domain names to Ker‐
64 beros realm names. This is used by programs to determine what
65 realm a host should be in, given its fully qualified domain
66 name.
67 [logging]
70 Contains relations which determine how Kerberos entities are to
71 perform their logging.
72 [capaths]
75 Contains the authentication paths used with non-hierarchical
76 cross-realm. Entries in the section are used by the client to
77 determine the intermediate realms which may be used in cross-
78 realm authentication. It is also used by the end-service when
79 checking the transited field for trusted intermediate realms.
80 [dbdefaults]
83 Contains default values for database specific parameters.
84 [dbmodules]
87 Contains database specific parameters used by the database
88 library.
89 Each of these sections will be covered in more details in the following
91 sections.
92
94 The following relations are defined in the [libdefaults] section:
95 default_keytab_name
98 This relation specifies the default keytab name to be used by
99 application severs such as telnetd and rlogind. The default is
100 "/etc/krb5.keytab". This formerly defaulted to "/etc/v5srvtab",
101 but was changed to the current value.
102 default_realm
105 This relation identifies the default realm to be used in a
106 client host's Kerberos activity.
107 default_tgs_enctypes
110 This relation identifies the supported list of session key
111 encryption types that should be returned by the KDC. The list
112 may be delimited with commas or whitespace.
113 default_tkt_enctypes
116 This relation identifies the supported list of session key
117 encryption types that should be requested by the client, in the
118 same format.
119 permitted_enctypes
122 This relation identifies the permitted list of session key
123 encryption types.
124 allow_weak_crypto
127 If this is set to 0 (for false), then weak encryption types will
128 be filtered out of the previous three lists. The default value
129 for this tag is false, which may cause authentication failures
130 in existing Kerberos infrastructures that do not support strong
131 crypto. Users in affected environments should set this tag to
132 true until their infrastructure adopts stronger ciphers.
133 clockskew
136 This relation sets the maximum allowable amount of clockskew in
137 seconds that the library will tolerate before assuming that a
138 Kerberos message is invalid. The default value is 300 seconds,
139 or five minutes.
140 k5login_authoritative
143 If the value of this relation is true (the default), principals
144 must be listed in a local user's k5login file to be granted
145 login access, if a k5login file exists. If the value of this
146 relation is false, a principal may still be granted login access
147 through other mechanisms even if a k5login file exists but does
148 not list the principal.
149 k5login_directory
152 If set, the library will look for a local user's k5login file
153 within the named directory, with a filename corresponding to the
154 local username. If not set, the library will look for k5login
155 files in the user's home directory, with the filename .k5login.
156 For security reasons, k5login files must be owned by the local
157 user or by root.
158 kdc_timesync
161 If the value of this relation is non-zero (the default), the
162 library will compute the difference between the system clock and
163 the time returned by the KDC and in order to correct for an
164 inaccurate system clock. This corrective factor is only used by
165 the Kerberos library.
166 kdc_req_checksum_type
169 For compatibility with DCE security servers which do not support
170 the default CKSUMTYPE_RSA_MD5 used by this version of Kerberos.
171 Use a value of 2 to use the CKSUMTYPE_RSA_MD4 instead. This
172 applies to DCE 1.1 and earlier. This value is only used for DES
173 keys; other keys use the preferred checksum type for those keys.
174 ap_req_checksum_type
177 If set this variable controls what ap-req checksum will be
178 used in authenticators. This variable should be unset so the
179 appropriate checksum for the encryption key in use will be used.
180 This can be set if backward compatibility requires a specific
181 checksum type.
182 safe_checksum_type
185 This allows you to set the preferred keyed-checksum type for use
186 in KRB_SAFE messages. The default value for this type is CKSUM‐
187 TYPE_RSA_MD5_DES. For compatibility with applications linked
188 against DCE version 1.1 or earlier Kerberos libraries, use a
189 value of 3 to use the CKSUMTYPE_RSA_MD4_DES instead. This field
190 is ignored when its value is incompatible with the session key
191 type.
192 preferred_preauth_types
195 This allows you to set the preferred preauthentication types
196 which the client will attempt before others which may be adver‐
197 tised by a KDC. The default value for this setting is "17, 16,
198 15, 14", which forces libkrb5 to attempt to use PKINIT if it is
199 supported.
200 ccache_type
203 User this parameter on systems which are DCE clients, to specify
204 the type of cache to be created by kinit, or when forwarded
205 tickets are received. DCE and Kerberos can share the cache, but
206 some versions of DCE do not support the default cache as created
207 by this version of Kerberos. Use a value of 1 on DCE 1.0.3a sys‐
208 tems, and a value of 2 on DCE 1.1 systems.
209 dns_lookup_kdc
212 Indicate whether DNS SRV records shoud be used to locate the
213 KDCs and other servers for a realm, if they are not listed in
214 the information for the realm. The default is to use these
215 records.
216 dns_lookup_realm
219 Indicate whether DNS TXT records should be used to determine the
220 Kerberos realm of a host. The default is not to use these
221 records.
222 dns_fallback
225 General flag controlling the use of DNS for Kerberos informa‐
226 tion. If both of the preceding options are specified, this
227 option has no effect.
228 realm_try_domains
231 Indicate whether a host's domain components should be used to
232 determine the Kerberos realm of the host. The value of this
233 variable is an integer: -1 means not to search, 0 means to try
234 the host's domain itself, 1 means to also try the domain's imme‐
235 diate parent, and so forth. The library's usual mechanism for
236 locating Kerberos realms is used to determine whether a domain
237 is a valid realm--which may involve consulting DNS if
238 dns_lookup_kdc is set. The default is not to search domain com‐
239 ponents.
240 extra_addresses
243 This allows a computer to use multiple local addresses, in order
244 to allow Kerberos to work in a network that uses NATs. The
245 addresses should be in a comma-separated list.
246 udp_preference_limit
249 When sending a message to the KDC, the library will try using
250 TCP before UDP if the size of the message is above "udp_prefer‐
251 ence_limit". If the message is smaller than "udp_prefer‐
252 ence_limit", then UDP will be tried before TCP. Regardless of
253 the size, both protocols will be tried if the first attempt
254 fails.
255 verify_ap_req_nofail
258 If this flag is set, then an attempt to get initial credentials
259 will fail if the client machine does not have a keytab. The
260 default for the flag is false.
261 ticket_lifetime
264 The value of this tag is the default lifetime for initial tick‐
265 ets. The default value for the tag is 1 day (1d).
266 renew_lifetime
269 The value of this tag is the default renewable lifetime for ini‐
270 tial tickets. The default value for the tag is 0.
271 noaddresses
274 Setting this flag causes the initial Kerberos ticket to be
275 addressless. The default for the flag is true.
276 forwardable
279 If this flag is set, initial tickets by default will be forward‐
280 able. The default value for this flag is false.
281 proxiable
284 If this flag is set, initial tickets by default will be proxi‐
285 able. The default value for this flag is false.
286
289 Each tag in the [appdefaults] section names a Kerberos V5 application
290 or an option that is used by some Kerberos V5 application[s]. The four
291 ways that you can set values for options are as follows, in decreasing
292 order of precedence:
293 #1)
296 application = {
297 realm1 = {
298 option = value
299 }
300 realm2 = {
301 option = value
302 }
303 }
304 #2)
305 application = {
306 option1 = value
307 option2 = value
308 }
309 #3)
310 realm = {
311 option = value
312 }
313 #4)
314 option = value
315
319 The [login] section is used to configure the behavior of the Kerberos
320 V5 login program, login.krb5(8). Refer to the manual entry for
321 login.krb5 for a description of the relations allowed in this section.
322
324 Each tag in the [realms] section of the file names a Kerberos realm.
325 The value of the tag is a subsection where the relations in that sub‐
326 section define the properties of that particular realm. For example:
327 [realms]
330 ATHENA.MIT.EDU = {
331 admin_server = KERBEROS.MIT.EDU
332 default_domain = MIT.EDU
333 database_module = ldapconf
334 v4_instance_convert = {
335 mit = mit.edu
336 lithium = lithium.lcs.mit.edu
337 }
338 v4_realm = LCS.MIT.EDU
339 }
340 For each realm, the following tags may be specified in the realm's sub‐
343 section:
344 kdc The value of this relation is the name of a host running a KDC
347 for that realm. An optional port number (preceded by a colon)
348 may be appended to the hostname. This tag should generally be
349 used only if the realm administrator has not made the informa‐
350 tion available through DNS.
351 admin_server
354 This relation identifies the host where the administration
355 server is running. Typically this is the Master Kerberos
356 server.
357 database_module
360 This relation indicates the name of the configuration section
361 under dbmodules for database specific parameters used by the
362 loadable database library.
363 default_domain
366 This relation identifies the default domain for which hosts in
367 this realm are assumed to be in. This is needed for translating
368 V4 principal names (which do not contain a domain name) to V5
369 principal names (which do).
370 v4_instance_convert
373 This subsection allows the administrator to configure exceptions
374 to the default_domain mapping rule. It contains V4 instances
375 (the tag name) which should be translated to some specific host‐
376 name (the tag value) as the second component in a Kerberos V5
377 principal name.
378 v4_realm
381 This relation is used by the krb524 library routines when con‐
382 verting a V5 principal name to a V4 principal name. It is used
383 when V4 realm name and the V5 realm are not the same, but still
384 share the same principal names and passwords. The tag value is
385 the Kerberos V4 realm name.
386 auth_to_local_names
389 This subsection allows you to set explicit mappings from princi‐
390 pal names to local user names. The tag is the mapping name, and
391 the value is the corresponding local user name.
392 auth_to_local
395 This tag allows you to set a general rule for mapping principal
396 names to local user names. It will be used if there is not an
397 explicit mapping for the principal name that is being trans‐
398 lated. The possible values are:
399 DB:<filename>
401 The principal will be looked up in the database <file‐
402 name>. Support for this is not currently compiled in
403 by default.
404 RULE:<exp>
405 The local name will be formulated from <exp>.
406 DEFAULT
407 The principal name will be used as the local name. If
408 the principal has more than one component or is not in
409 the default realm, this rule is not applicable and the
410 conversion will fail.
411
414 The [domain_realm] section provides a translation from a hostname to
415 the Kerberos realm name for the services provided by that host.
416 The tag name can be a hostname, or a domain name, where domain names
418 are indicated by a prefix of a period ('.') character. The value of
419 the relation is the Kerberos realm name for that particular host or
420 domain. Host names and domain names should be in lower case.
421 If no translation entry applies, the host's realm is considered to be
423 the hostname's domain portion converted to upper case. For example,
424 the following [domain_realm] section:
425 [domain_realm]
428 .mit.edu = ATHENA.MIT.EDU
429 mit.edu = ATHENA.MIT.EDU
430 dodo.mit.edu = SMS_TEST.MIT.EDU
431 .ucsc.edu = CATS.UCSC.EDU
432 maps dodo.mit.edu into the SMS_TEST.MIT.EDU realm, all other hosts in
434 the MIT.EDU domain to the ATHENA.MIT.EDU realm, and all hosts in the
435 UCSC.EDU domain into the CATS.UCSC.EDU realm. ucbvax.berkeley.edu
436 would be mapped by the default rules to the BERKELEY.EDU realm, while
437 sage.lcs.mit.edu would be mapped to the LCS.MIT.EDU realm.
438
441 The [logging] section indicates how a particular entity is to perform
442 its logging. The relations specified in this section assign one or
443 more values to the entity name.
444 Currently, the following entities are used:
446 kdc These entries specify how the KDC is to perform its logging.
448 admin_server
450 These entries specify how the administrative server is to per‐
451 form its logging.
452 default
454 These entries specify how to perform logging in the absence of
455 explicit specifications otherwise.
456 Values are of the following forms:
458 FILE=<filename>
460 FILE:<filename>
462 This value causes the entity's logging messages to go to the
463 specified file. If the = form is used, then the file is over‐
464 written. Otherwise, the file is appended to.
465 STDERR This value causes the entity's logging messages to go to its
467 standard error stream.
468 CONSOLE
470 This value causes the entity's logging messages to go to the
471 console, if the system supports it.
472 DEVICE=<devicename>
474 This causes the entity's logging messages to go to the specified
475 device.
476 SYSLOG[:<severity>[:<facility>]]
478 This causes the entity's logging messages to go to the system
479 log.
480 The severity argument specifies the default severity of system
482 log messages. This may be any of the following severities sup‐
483 ported by the syslog(3) call minus the LOG_ prefix: LOG_EMERG,
484 LOG_ALERT, LOG_CRIT, LOG_ERR, LOG_WARNING, LOG_NOTICE, LOG_INFO,
485 and LOG_DEBUG. For example, to specify LOG_CRIT severity, one
486 would use CRIT for severity.
487 The facility argument specifies the facility under which the
489 messages are logged. This may be any of the following facili‐
490 ties supported by the syslog(3) call minus the LOG_ prefix:
491 LOG_KERN, LOG_USER, LOG_MAIL, LOG_DAEMON, LOG_AUTH, LOG_LPR,
492 LOG_NEWS, LOG_UUCP, LOG_CRON, and LOG_LOCAL0 through LOG_LOCAL7.
493 If no severity is specified, the default is ERR, and if no
495 facility is specified, the default is AUTH.
496 In the following example, the logging messages from the KDC will go to
498 the console and to the system log under the facility LOG_DAEMON with
499 default severity of LOG_INFO; and the logging messages from the admin‐
500 istrative server will be appended to the file /var/adm/kadmin.log and
501 sent to the device /dev/tty04.
502 [logging]
504 kdc = CONSOLE
505 kdc = SYSLOG:INFO:DAEMON
506 admin_server = FILE:/var/adm/kadmin.log
507 admin_server = DEVICE=/dev/tty04
508
512 Cross-realm authentication is typically organized hierarchically. This
513 hierarchy is based on the name of the realm, which thus imposes
514 restrictions on the choice of realm names, and on who may participate
515 in a cross-realm authentication. A non hierarchical orgization may be
516 used, but requires a database to construct the authentication paths
517 between the realms. This section defines that database.
518 A client will use this section to find the authentication path between
520 its realm and the realm of the server. The server will use this section
521 to verify the authentication path used be the client, by checking the
522 transited field of the received ticket.
523 There is a tag name for each participating realm, and each tag has sub‐
525 tags for each of the realms. The value of the subtags is an intermedi‐
526 ate realm which may participate in the cross-realm authentication. The
527 subtags may be repeated if there is more then one intermediate realm. A
528 value of "." means that the two realms share keys directly, and no
529 intermediate realms should be allowed to participate.
530 There are n**2 possible entries in this table, but only those entries
532 which will be needed on the client or the server need to be present.
533 The client needs a tag for its local realm, with subtags for all the
534 realms of servers it will need to authenticate with. A server needs a
535 tag for each realm of the clients it will serve.
536 For example, ANL.GOV, PNL.GOV, and NERSC.GOV all wish to use the ES.NET
538 realm as an intermediate realm. ANL has a sub realm of TEST.ANL.GOV
539 which will authenticate with NERSC.GOV but not PNL.GOV. The [capath]
540 section for ANL.GOV systems would look like this:
541 [capaths]
543 ANL.GOV = {
544 TEST.ANL.GOV = .
545 PNL.GOV = ES.NET
546 NERSC.GOV = ES.NET
547 ES.NET = .
548 }
549 TEST.ANL.GOV = {
550 ANL.GOV = .
551 }
552 PNL.GOV = {
553 ANL.GOV = ES.NET
554 }
555 NERSC.GOV = {
556 ANL.GOV = ES.NET
557 }
558 ES.NET = {
559 ANL.GOV = .
560 }
561 The [capath] section of the configuration file used on NERSC.GOV sys‐
563 tems would look like this:
564 [capaths]
566 NERSC.GOV = {
567 ANL.GOV = ES.NET
568 TEST.ANL.GOV = ES.NET
569 TEST.ANL.GOV = ANL.GOV
570 PNL.GOV = ES.NET
571 ES.NET = .
572 }
573 ANL.GOV = {
574 NERSC.GOV = ES.NET
575 }
576 PNL.GOV = {
577 NERSC.GOV = ES.NET
578 }
579 ES.NET = {
580 NERSC.GOV = .
581 }
582 TEST.ANL.GOV = {
583 NERSC.GOV = ANL.GOV
584 NERSC.GOV = ES.NET
585 }
586 In the above examples, the ordering is not important, except when the
588 same subtag name is used more then once. The client will use this to
589 determing the path. (It is not important to the server, since the tran‐
590 sited field is not sorted.)
591 If this section is not present, or if the client or server cannot find
593 a client/server path, then normal hierarchical orginization is assumed.
594 This feature is not currently supported by DCE. DCE security servers
596 can be used with Kerberized clients and servers, but versions prior to
597 DCE 1.1 did not fill in the transited field, and should be used with
598 caution.
599
602 The [dbdefaults] section indicates default values for the database spe‐
603 cific parameters. It can also specify the configuration section under
604 dbmodules for database specific parameters used by the loadable data‐
605 base library.
606 The following tags are used in this section:
609 database_module
611 This relation indicates the name of the configuration section
612 under dbmodules for database specific parameters used by the
613 loadable database library.
614 ldap_kerberos_container_dn
617 This LDAP specific tag indicates the DN of the container object
618 where the realm objects will be located. This value is used if
619 no object DN is mentioned in the configuration section under
620 dbmodules.
621 ldap_kdc_dn
624 This LDAP specific tag indicates the default bind DN for the KDC
625 server. The KDC server does a login to the directory as this
626 object. This value is used if no object DN is mentioned in the
627 configuration section under dbmodules.
628 ldap_kadmind_dn
631 This LDAP specific tag indicates the default bind DN for the
632 Administration server. The Administration server does a login to
633 the directory as this object. This value is used if no object DN
634 is mentioned in the configuration section under dbmodules.
635 ldap_service_password_file
638 This LDAP specific tag indicates the file containing the stashed
639 passwords for the objects used for starting the Kerberos
640 servers. This value is used if no service password file is men‐
641 tioned in the configuration section under dbmodules.
642 ldap_servers
645 This LDAP specific tag indicates the list of LDAP servers. The
646 list of LDAP servers is whitespace-separated. The LDAP server is
647 specified by a LDAP URI. This value is used if no LDAP servers
648 are mentioned in the configuration section under dbmodules.
649 ldap_conns_per_server
652 This LDAP specific tag indicates the number of connections to be
653 maintained per LDAP server. This value is used if the number of
654 connections per LDAP server are not mentioned in the configura‐
655 tion section under dbmodules. The default value is 5.
656
659 Each tag in the [dbmodules] section of the file names a configuration
660 section for database specific parameters that can be referred to by a
661 realm. The value of the tag is a subsection where the relations in
662 that subsection define the database specific parameters.
663 For each section, the following tags may be specified in the subsec‐
666 tion:
667 db_library
670 This tag indicates the name of the loadable database library.
671 The value should be db2 for db2 database and kldap for LDAP
672 database.
673 ldap_kerberos_container_dn
676 This LDAP specific tag indicates the DN of the container object
677 where the realm objects will be located.
678 ldap_kdc_dn
681 This LDAP specific tag indicates the bind DN for the KDC server.
682 The KDC does a login to the directory as this object.
683 ldap_kadmind_dn
686 This LDAP specific tag indicates the bind DN for the Administra‐
687 tion server. The Administration server does a login to the
688 directory as this object.
689 ldap_service_password_file
692 This LDAP specific tag indicates the file containing the stashed
693 passwords for the objects used for starting the Kerberos
694 servers.
695 ldap_servers
698 This LDAP specific tag indicates the list of LDAP servers. The
699 list of LDAP servers is whitespace-separated. The LDAP server is
700 specified by a LDAP URI.
701 ldap_conns_per_server
704 This LDAP specific tag indicates the number of connections to be
705 maintained per LDAP server.
706
708 /etc/krb5.conf
709
711 syslog(3)
712 KRB5.CONF(5)