In the previous implementation when .k5login or .k5login.d existed
and k5login_authoritative was false, no further plugins were tried.
Also when k5login_authoritative was true and .k5login did not match,
the directory was never tried.
mechanism credentials created by dynamically loaded mechanisms do not work
because the gm_mech_oid field is unset for such mechanisms (instead, only
gm_mech.gm_mech_oid is).
In order to support plugins for kadmin that use libkadm5srv, the
libkadm5clnt library has to be versioned to avoid hijacking all
of the function calls that should go to the server library. Omit
the _kadm5_ clients from the public interface, and version
everything else.
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
kx509 fails to create certs for principals with slashes in them. For
example:
client% kinit foo/admin
foo/admin@EXAMPLE.COM's Password:
client% kx509
Timed out waiting on KCA
The KCA reports: "Principal is not a user." However, there is a use
case set out in this post:
https://thestaticvoid.com/post/2012/10/25/protecting-puppet-with-kerberos/
that would create a kx509 cert for a host principal for authenticating
against a secure HTTP service. This commit modifies the certificate
creation code to allow principals with slashes in them.
The TGS was incorrectly using authtime to compute renew_till for new
tickets, which was in turn leading to endtime potentially being equal to
starttime, which caused the TGS to return KRB5KDC_ERR_NEVER_VALID.
This happens when the TGT renewal lifetime is longer than the max renew
lifetime of any other services, after that much time (target services'
max renew life) passes. The TGT is still good but TGS-REQs fail.
This makes it easier to install Heimdal and MIT kerberos on
the same system by just providing the heimdal-krb5.pc file;
the krb5.pc file is provided by both.
This is similar to what's done with heimdal-gssapi.pc/krb5-gssapi.pc.
Signed-off-by: Jelmer Vernooij <jelmer@samba.org>
The first enctype RFC3961 prf output length's bytes are correct because
the little- and big-endian representations of unsigned zero are the
same. The second block of output was wrong because the counter was not
being encoded as big-endian.
This change could break applications. But those applications would not
have been interoperating with other implementations anyways (in
particular: MIT's).
