For Samba the fast key is not stored in the replicated DB, so
this helps Samba find it in the Samba hdb module.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
In a strict Samba build with -Werror=strict-overflow on Ubuntu 18.04
with gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
we see
../../source4/heimdal/lib/roken/resolve.c: In function ‘rk_dns_srv_order’:
../../source4/heimdal/lib/roken/resolve.c:639:7: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if(num_srv == 0)
^
cc1: all warnings being treated as errors
This avoids the issue by additionally setting a distinct flag.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
In acquire_mech_cred(), treat a credential store with no elements as equivalent
to GSS_C_NO_CRED_STORE, allowing a mechanism's gss_acquire_cred()
implementation to be called.
GM_USE_MG_NAME was not honored in the case where the mechanism emitted a name,
but the caller of gss_accept_sec_context() did not request it be returned. This
would result in m->gm_release_name() being called on the mechglue name, which
would crash either because that function pointer was NULL or because it would
have expected a mechanism name.
To avoid future regressions such as the one corrected in 0dd19003, make
IS_DCE_STYLE() an inline function (rather than a macro) so that its
argument is typed.
4b543b7 introduced a regression in the krb5 mechanism's gss_unwrap for
DCE applications, owing to IS_DCE_STYLE() being called with a krb5
instead of mechanism context handle.
On Ubuntu 20.04 with gcc version 9.3.0 during a strict
Samba build with -Werror=maybe-uninitialized we get:
../../source4/heimdal/lib/hdb/hdb.c: In function ‘hdb_create’:
../../source4/heimdal/lib/hdb/hdb.c:831:13: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
831 | if (*db && ret == 0)
| ~~~~^~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Samba compiles Heimdal internally without HAVE_DLOPEN to keep
to internally supplied mechanisms and plugins.
Samba compiles with strict warning flags and on Ubuntu 20.04
with gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) we see:
../../source4/heimdal/lib/gssapi/mech/gss_mech_switch.c: In function ‘_gss_load_mech’:
../../source4/heimdal/lib/gssapi/mech/gss_mech_switch.c:462:1: error: label ‘out’ defined but not used [-Werror=unused-label]
462 | out:
| ^~~
cc1: all warnings being treated as errors
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
This is useful for services that need not be clients. For example, an
untrusted service that need only accept authentication from clients,
but not initiate authentication to other services.
krb5_get_next() and krb5_get_cache_next() do not check for krb5_kcm_call()
returning non-zero before accessing the repsonse data; they only handle the
case where the return value is KRB5_CC_END.
Return immediately if the return value of krb5_kcm_call() is not KRB5_CC_END or
0. This was fixed in the Apple code.
Some compilers with -Wstring-concatenation enabled warned about a suspicious
concatenation of string literals in the initialization of the GSS-API error
message array.
At the expense of a long line, avoid this warning but explicitly concatenating
the offending string literal.
Fixes: #775
vis.h is not built on platforms (such as macOS) that already have
that header, which resulted in prototypes for Heimdal-specific
vis.h extensions being absent.
Move those prototypes to a separate header, vis-extras.h, which
must be explicitly included in order to use the Heimdal extensions.
If a DB does not already exist, ipropd-slave will use the compiled
default, which is not necessarily what is desired or configured in
`[kdc]`.
This change makes `hdb_default_db()` return the first dbanme in the
`[kdc]` configuration, falling back on `HDB_DEFAULT_DB`.
Also, this adds a `--database` option to `ipropd-slave`.
The codegen backend is faster than the template backend, even for
modules that don't use IOS. On x64 we see the template backend being
4% slower for TGS requests using the kdc-tester program.
So let's build both, libasn1 (codegen) and libasn1template when
configured with --disable-asn1-templating, but make sure that the
asn1_print utility is linked with libasn1template.
Eventually we'll want to either optimize the template backend better,
or add IOS and JSON printing support to the codegen backend.
While Ken Hornstein's FAQ was useful in its day, much of its content
is no longer relevant (e.g., Kerberos 4) or even actively harmful
(e.g., the latest version of MIT krb5 is not 1.2.1). It was also
somewhat MIT-krb5-focused, especially relating to configuration file
snippets, which is not necessarily a great fit for the Heimdal
documentation.
Replace it with a tutorial hosted on kerberos.org and the classic
"dialogue" from Bill Bryant.
Fixes: #766
This adds support for using a Heimdal-specific PKIX extension to derive
a maximum Kerberos ticket lifetime from a client's PKINIT certificate.
KDC configuration parameters:
- pkinit_max_life_from_cert_extension
- pkinit_max_life_bound
If `pkinit_max_life_from_cert_extension` is set to true then the
certificate extension or EKU will be checked.
If `pkinit_max_life_bound` is set to a positive relative time, then that
will be the upper bound of maximum Kerberos ticket lifetime derived from
these extensions.
The KDC config `pkinit_ticket_max_life_from_cert` that was added earlier
has been renamed to `pkinit_max_life_from_cert`.
See lib/hx509 and lib/krb5/krb5.conf.5.
This adds support for using a Heimdal-specific PKIX extension to derive
a maximum Kerberos ticket lifetime from a client's PKINIT certificate:
- a `--pkinit-max-life` to the `hxtool ca` command
- `hx509_ca_tbs_set_pkinit_max_life()`
- `hx509_cert_get_pkinit_max_life()`
- `HX509_CA_TEMPLATE_PKINIT_MAX_LIFE`
There are two extensions. One is an EKU, which if present means that
the maximum ticket lifetime should be derived from the notAfter minus
notBefore. The other is a certificate extension whose value is a
maximum ticket lifetime in seconds. The latter is preferred.
