Note that this has a slight behavior change to c89d3f3b in order to continue
allow kadmin in local mode to bypass password quality checks. Password quality
checks are always bypassed if the *client* kadmin principal is kadmin/admin,
i.e. that of the kadmin service itself. This is the case when running kadmin in
local mode. As this is the equivalent of a superuser account, one would
anticipate that deployments would use specific administrator instances for
appropriate ACLs for day-to-day administration; operations by these will be
subject to password quality checks if enforce_on_admin_set is TRUE, or if the
user is changing their own password.
This patch adds the "enforce_on_admin_set" configuration knob in the
[password_quality] section. When this is enabled, administrative password
changes via the kadmin or kpasswd protocols will be subject to password quality
checks. (An administrative password change is one where the authenticating
principal is different to the principal whose password is being changed.)
Note that kadmin running in local mode (-l) is unaffected by this patch.
The ipropd_slave will log its status to /var/heimdal/ipropd-slave-status
if its connecting, up to date, or disconnected.
The master will now also confirm to slaves that are are in fact up to date
if they just restart, before there was no confirmation, the slave just didn't
get any deltas.
Rephrase and reword the PKINIT setup documentation to be in somewhat
more idiomatic English. There should be no changes to the substance
of the documentation.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
Expand the transit policy section considerably, with additional
examples and explanation of the examples. Separate allowing
cross-realm transits from configuring clients to do cross-realm
transits. Add a separate example section for an Active Directory
forest.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
Be clearer in the info documentation that the part of the policy
name before the colon is the name of the module, not the static
string "module". State explicitly that "builtin" can be used as the
module name to identify built-in policies.
Use the same terminology in kadm5_pwcheck(3) as the info documentation,
changing test-name to policy-name and vendor to module-name. State
explicitly how the module name and policy name are used to select which
policies to run.
Rephrase a few sentences, add a paragraph break, and fix a few typos
for clarity.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
