- omits from the link line all the libraries included solely because the
- Kerberos libraries depend on them and instead links the programs only
- against libraries whose APIs are called directly. This will only work
- with shared Kerberos libraries and will only work on platforms where
- shared libraries properly encode their own dependencies (such as Linux).
- It is intended primarily for building packages for Linux distributions
- to avoid encoding unnecessary shared library dependencies that make
- shared library migrations more difficult. If none of the above made any
- sense to you, don't bother with this flag.
-
-CONFIGURATION
-
- First, build and install either a CrackLib dictionary as described in
- REQUIREMENTS above, or build a CDB dictionary with cdbmake-wordlist.
- (Or both.) The CrackLib dictionary will consist of three files, one
- each ending in *.hwm, *.pwd, and *.pwi. The CDB dictionary will consist
- of a single file ending in *.cdb. Install those files somewhere on your
- system. Then, follow the relevant instructions below for either Heimdal
- or MIT Kerberos.
-
- See "Other Settings" below for additional krb5.conf setting supported by
- both Heimdal and MIT Kerberos.
-
- Heimdal
-
- There are two options: using an external password check program, or
- using the plugin. I recommend the external password check program
- unless you encounter speed problems with that approach that cause
- kpasswd to time out.
-
- For either approach, first add a stanza like the following to the
- [appdefaults] section of your /etc/krb5.conf (or wherever your krb5.conf
- file is located):
-
- krb5-strength = {
- password_dictionary = /path/to/cracklib/dictionary
- password_dictionary_cdb = /path/to/cdb/dictionary.cdb
- }
-
- The first setting configures a CrackLib dictionary and the second a CDB
- dictionary. The provided path should be the full path to the dictionary
- files, omitting the trailing *.hwm, *.pwd, and *.pwi extensions for the
- CrackLib dictionary. You can use either or both settings. If you use
- both, CrackLib will be checked first, and then CDB. When checking a CDB
- database, the password, all printable ASCII passwords within edit
- distance one of the password, and the password with the first and last
- characters removed, the first two characters removed, and the last two
- characters removed will all be checked against the dictionary.
-
- Then, for the external password checking program, add a new section (or
- modify the existing [password_quality] section) to look like the
- following:
-
- [password_quality]
- policies = external-check
- external_program = /usr/local/bin/heimdal-strength
-
- You can, of course, combine this policy with others. Replace the path
- with the full path to wherever you have installed heimdal-strength. You
- can put this section in your kdc.conf instead of krb5.conf if you
- prefer.
-
- If you want to instead use the module, use the following section
- instead:
-
- [password_quality]
- policies = krb5-strength
- policy_libraries = /usr/local/lib/krb5/plugins/pwqual/strength.so
-
- in either krb5.conf or kdc.conf. Note that some older versions of
- Heimdal have a bug in the support for loading modules when
- policy_libraries is set. If you get an error like:
-
- didn't find `kadm5_password_verifier' symbol in `(null)'
-
- you may have to omit policy_libraries in your configuration and instead
- pass the --check-library argument to kpasswdd specifying the library to
- load.
-
- Additional configuration is required to use the history implementation.
- Ensure that its dependencies are installed, and then examine the local
- configuration settings at the top of the heimdal-history program. By
- default, it requires a _history user and _history group be present on
- the system, and all history information will be read and written as that
- user and group. It also requires a nobody user and nogroup group to be
- present, and all strength checking will be done as that user and group.
- It uses various files in /var/lib/heimdal-history to store history and
- statistical information by default, so if using the defaults, create
- that directory and ensure it is writable by the _history user.
-
- Once that setup is done, change your [password_quality] configuration
- to:
-
- [password_quality]
- policies = external-check
- external_program = /usr/local/bin/heimdal-history
-
- The heimdal-history program will automatically also run heimdal-strength
- as well, looking for it in /usr/local/bin, /usr/bin, and /bin. Change
- the PATH setting at the top of the script if you have different
- requirements. You should continue to configure heimdal-strength as if
- you were running it directly.
-
- MIT Kerberos
-
- To add this module to the list of password quality checks, add a section
- to krb5.conf (or to a separate kdc.conf if you use that) like:
-
- [plugins]
- pwqual = {
- module = strength:/usr/local/lib/krb5/plugins/pwqual/strength.so
- }
-
- to register the plugin.
-
- There are two ways to tell where the dictionary is. One option is to
- use krb5.conf (and in this case you must use krb5.conf, even if you use
- a separate kdc.conf file). For this approach, add the following to the
- [appdefaults] section:
-
- krb5-strength = {
- password_dictionary = /path/to/cracklib/dictionary
- password_dictionary_cdb = /path/to/cdb/dictionary.cdb
- }
-
- The first setting configures a CrackLib dictionary and the second a CDB
- dictionary. The provided path should be the full path to the dictionary
- files, omitting the trailing *.hwm, *.pwd, and *.pwi extensions for the
- CrackLib dictionary. You can use either or both settings. If you use
- both, CrackLib will be checked first, and then CDB. When checking a CDB
- database, the password, all printable ASCII passwords within edit
- distance one of the password, and the password with the first and last
- characters removed, the first two characters removed, and the last two
- characters removed will all be checked against the dictionary.
-
- The second option is to use the normal dict_path setting. In the
- [realms] section of your krb5.conf kdc.conf, under the appropriate realm
- or realms, specify the path to the dictionary:
-
- dict_file = /path/to/cracklib/dictionary
-
- This will be taken as a CrackLib dictionary path, the same as the
- setting for password_dictionary above. The provided path should be the
- full path to the dictionary files, omitting the trailing *.hwm, *.pwd,
- or *.pwi extension. However, be aware that, if you use this approach,
- you will probably want to disable the built-in standard dict pwqual
- plugin by adding the line:
-
- disable = dict
-
- to the pwqual block of the [plugins] section as shown above. Otherwise,
- it will also try to load a dictionary at the same path to do simple
- dictionary matching.
-
- You can also mix and match these settings, by using dict_path for the
- CrackLib dictionary path and krb5.conf for the CDB dictionary path. If
- both settings are used, krb5.conf overrides the dict_path setting (so
- that dict_path can be used for other password quality modules). There
- is no way to specify a CDB dictionary via the dict_path setting.
-
- Other Settings
-
- The following additional settings are supported in the [appdefaults]
- section of krb5.conf when running under either Heimdal or MIT Kerberos.
-
- minimum_length
-
- If set to a numeric value, passwords with fewer than that number of
- characters will be rejected, independent of any length restrictions
- in CrackLib. Note that this setting does not bypass the minimum
- length requirements in CrackLib itself (which, for the version
- embedded in this package, is eight characters).
-
- require_ascii_printable
-
- If set to a true boolean value, rejects any password that contains
- non-ASCII characters or ASCII control characters. Spaces are
- allowed; tabs are not (at least assuming the POSIX C locale). No
- canonicalization or character set is defined for Kerberos passwords
- in general, so you may want to reject non-ASCII characters to avoid
- interoperability problems with computers with different default
- character sets or Unicode normalization forms. Also be aware that,
- when testing passwords within edit distance one against a CDB
- database, only characters in the printable ASCII character set will
- be attempted.
-
- require_classes
-
- This option allows specification of more complex character class
- requirements. The value of this parameter should be one or more
- whitespace-separated rule. Each rule has the syntax:
-
- [<min>-<max>:]<class>[,<class>...]
-
- where <class> is one of "upper", "lower", "digit", or "symbol"
- (without the quote marks). The symbol class includes all characters
- other than alphanumeric characters, including space. The listed
- classes must appear in the password. Separate multiple required
- classes with a comma (and no space).
-
- The character class checks will be done in whatever locale the
- plugin or password check program is run in, which will normally be
- the POSIX C locale but may be different depending on local
- configuration.
-
- A simple example:
-
- require_classes = upper,lower,digit
-
- This requires all passwords contain at least one uppercase letter,
- at least one lowercase letter, and at least one digit.
-
- If present, <min> and <max> specify the minimum password length and
- maximum password length to which this rule applies. This allows one
- to specify character class requirements that change with password
- length. So, for example:
-
- require_classes = 8-19:upper,lower 8-15:digit 8-11:symbol
-
- requires all passwords from 8 to 11 characters long contain all four
- character classes, passwords from 12 to 15 characters long contain
- upper and lower case and a digit, and passwords from 16 to 19
- characters long contain both upper and lower case. Passowrds longer
- than 20 characters have no character class restrictions. (This
- example is probably used in conjunction with minimum_length = 8.)
-
- require_non_letter
-
- If set to a true boolean value, the password must contain at least
- one character that is not a letter (uppercase or lowercase) or a
- space. This may be helpful in combination with passphrases; users
- may choose a stock English phrase, and this will force at least some
- additional complexity.