Each KDC is a kx509 server. The service principal must be of the
form
kca_service/<localhost.domain>@<DEFAULT_REALM>
where localhost.domain is the hostname returned by gethostname()
and <DEFAULT_REALM> is one of the realms for which the KDC has a service
principal "kca_service/<localhost.domain>".
The matching code was broken by a5e77c578e
when krb5_sname_to_principal() began to always return a referral
principal.
Since the second component is a host name update the default principal
type for service "kca_service" to be KRB5_NT_SRV_HST.
Change-Id: I6bd5f90b674ebb7220d8efafa6d339fdc21e1a07
When building the lib/krb5 tests link against HEIMBASE in order to
make use of heim_abort() and friends.
Change-Id: Ifaf54177bbb14cddf0f3544add370cda158783d1
In krb5_parse_name_flags(), if the principal name is not an enterprise
name, is one component in length and contains an '@', set the principal
type to NT-SMTP-NAME as specified by RFC 4120.
Treat principals of type NT-UNKNOWN as NT-SRV-HST if the first component
of the principal name is "host".
Change-Id: I28fb619379daac827436040e701d4ab7b279852b
This is part of the fix to #173. MSFT RODCs insist on the name type for
krbtgt principals be set to KRB5_NT_SRV_INST.
Commentary from Jeffrey Altman <jaltman@secure-endpoints.com>
As reported by David Mulder of Dell's Quest, Active Directory will
return a BAD_INTEGRITY error when a request for a krbtgt service
ticket is received with principal type NT-PRINCIPAL instead of NT-SRV-INST
as required by RFC 4120.
[Nico: RFC4120 does not require this. See the description of the
name-type field of PrincipalName on page 55.]
ERROR: VAS_ERR_KRB5: Failed to obtain credentials.
Client: SLED10-32$@F.QAS,
Service: SLED10-32$@F.QAS, Server: ad2-f.f.qas
Caused by: KRB5KRB_AP_ERR_BAD_INTEGRITY (-1765328353): Decrypt integrity check failed
Microsoft began enforcing principal type checking for RODCs in 2008R2.
Microsoft does state that ALL krgtgt/REALM tickets SHOULD be sent using
principal name type of KRB5_NT_SRV_INST instead of KRB5_NT_PRINCIPAL.
From Microsoft:
"I believe we discovered the problem. There isn't a bug in Windows.
There's been a code change to address another issue which puts in additional
checks for Kerberos tickets. The problem is with the Unix clients when the
client request a TGT. The Unix clients are using Name-type Principal
[KRB_NT_PRINCIPAL (1)] instead of using Name-type Service and Instance
[KRB_NT_SRV_INST (2)]...."
This change assigns the NT-SRV-INST principal type each time a krbtgt
service principal is created. Unlike Microsoft, the Heimdal mostly does
not care about the name-type of any principals, with the exception of
referrals, where the name type is needed to decide how to find a
next-hop realm.
Instead of imposing a default 10 hour ticket lifetime and 1 month renew
lifetime when requesting tickets, increase the default lifetime and
renew lifetime to 2147483647 seconds. This ensures that in the absence
of any other configuration or command line parameters that the KDC will
determine the ticket lifetime and renew lifetime.
Change-Id: I52b6eeac1ee830a9bf4d0130e8f4ec7b70bc8694
Signed-off-by: Nicolas Williams <nico@twosigma.com>
The original motivation was to avoid extra timeouts when the network is
broken. However this doesn't avoid one of the timeouts and adds
complexity and introduced bugs.
To really suppress search lists use ndots.
Apending '.' to the hostname passed to `getaddrinfo()` is good for
avoiding extra timeouts when the search list is non-empty and the
network is broken, but searches in /etc/hosts are typically inhibited
then. The fix is to try again without the trailing '.' if the first
lookup failed for any reason other than a timeout.
When reading configuration file, keep an extra copy of
the encryption types, and use this when resetting the
encryption types to default.
GSSAPI always resets the enctypes to default before obtaining
a TGS, because the enctypes might have previously altered,
so this prevents changing the etypes from the configured ones
to the full set of supported etypes.
Signed-off-by: Uri Simchoni <uri@samba.org>
Also implement KDC hierarchical transit policy checks. The "hier_capaths"
parameter defaults to "yes" in [libdefaults] or can be set explicitly in
[realms] per-realm.
The function, found in lib/krb5/mit_glue.c, is currently using
krb5_generate_random_keyblock(). This compiles because warning-level is
not high enough, but does not work. At runtime the
krb5_generate_random_keyblock() interprets the second argument as the
krb5_enctype (rather than a length of anything) and tries to verify it.
When the length does not match any known enctype, as usually happens, the
function fails and returns an error. If the length happened to correspond
to an enctype, the function would likely crash due to misinterpreting its
third argument as a valid krb5_keyblock.
The change uses krb5_generate_random_block() instead. This function does
not return anything -- upon detecting failure it will cause the entire
application to exist instead...
Change-Id: I865a360037a513ce91abc7abba1dc554f844b464
Follow Apple's lead and do not fail krb5_set_config_files() simply
because one of the files in the profile list fails to parse correctly.
Doing so can lead to hard to find failures and could lead to an end
user shooting themselves in the foot and no longer be able to login
to their system to fix it.
Parse as many of the files as we can. Only fail krb5_set_config_files()
if init_context_from_config_file() fails.
Change-Id: I122664c6d707a5f926643808ba414bf4f681f8b8
When storing credentials whose ticket principal is not equal to the
requested principal, store the ticket under both names not only when
the original realm is the referral realm, but more generally for any
difference at all. This matches MIT behaviour.
Allow explicit name_canon rules to specify a realm to go with the
canonicalized hostname, if that realm is empty the effect is the
same "use-referrals"
Also fix segfault when no creds and debugging
On OS X anyways, since Heimdal cannot be built to replace the system
Kerberos implementation in OS X (even though it's based on Heimdal).
Heimdal plugins other than the CCAPI plugins have private ABIs with
strong coupling to the internals of the Heimdal libraries, thus using
system plugins in a non-system Heimdal is likely to end in tears (e.g.,
segfaults).
This means, for example, that OS X's plugins for PAC creation and
verification cannot be used by Heimdal.
For consistency make "-I" part of the macro value set by autoconf.
For now, don't attempt to handle OpenSSL rpath in cf/crypto.m4.
That's much easier by just setting LDFLAGS when running configure.
Otherwise too many Makefiles to edit and libtool and automake do
their best to undo the rpath.
