We introduce a notion of soft vs. hard aliases.
Soft aliases are aliases of WELLKNOWN/REFERRALS/TARGET@$some_realm,
where $some_realm is the realm we want the KDC to issue referrals to.
Hard aliases are all other aliases, where if the client requested
canonicalization then the KDC should update the names in the responses,
or else if the client did not request canonicalization, then the KDC
should treat the alias as a distinct principal with the same keys as the
alias' canonical name.
The logic for dealing with these is entirely located in the HDB
backends.
An HDB backend can implement hard aliases by replacing a found
HDB_entry's principal with the name used to look it up.
An HDB backend can implement soft aliases by returning
HDB_ERR_WRONG_REALM to trigger the AS or TGS to return a referral.
Currently only in-tree HDB backends support this feature that use
_hdb_fetch_kvno() as their hdb_fetch_kvno() method implementation.
That's all HDB backends other than SQLite3.
Out-of-tree backends should be unaffected.
We've added a decoration field to HDB_entry: aliased -- an int
(boolean). This is only used internally in libhdb at this time.
Out-of-tree HDB backends could have a use for this decoration, but we
have not decided whether it is a public interface yet.
krb5_kt_get_entry() allows a NULL principal to be given ("match all").
The get method of the HDB-as-keytab keytab did not know this, and could
dereference a NULL as a result.
Remove hdb_entry_ex and revert to the original design of hdb_entry (except with
an additional context member in hdb_entry which is managed by the free_entry
method in HDB).
Decorate HDB_entry with context and move free_entry callback into HDB structure
itself. Requires updating hdb_free_entry() signature to include HDB parameter.
A follow-up commit will consolidate hdb_entry_ex (which has a single hdb_entry
member) into hdb_entry.
This is a large commit that adds several features:
- Revamps and moves virtual host-based service principal functionality
from kdc/ to lib/hdb/ so that it may be automatically visible to
lib/kadm5/, as well as kadmin(1)/kadmind(8) and ktutil(1).
The changes are backwards-incompatible.
- Completes support for documenting a service principal's supported
enctypes in its HDB entry independently of its long-term keys. This
will reduce HDB bloat by not requiring that service principals have
more long-term keys than they need just to document the service's
supported enctypes.
- Adds support for storing krb5.conf content in principals' HDB
entries. This may eventually be used for causing Heimdal KDC
services to reconfigure primary/secondary roles automatically by
discovering the configured primary in an HDB entry for the realm.
For now this will be used to help reduce the amount of configuration
needed by clients of an upcoming HTTP binding of the kadmin service.
The use of the wrong value for the length of ":mkey=" was identified
by Brian May and reported via github:
https://github.com/heimdal/heimdal/issues/40
Change-Id: I0aed86a5bb0359b7a266369076fde5e62f23b5fe
We turn on a few extra warnings and fix the fallout that occurs
when building with --enable-developer. Note that we get different
warnings on different machines and so this will be a work in
progress. So far, we have built on NetBSD/amd64 5.99.64 (which
uses gcc 4.5.3) and Ubuntu 10.04.3 LTS (which uses gcc 4.4.3).
Notably, we fixed
1. a lot of missing structure initialisers,
2. unchecked return values for functions that glibc
marks as __attribute__((warn-unused-result)),
3. made minor modifications to slc and asn1_compile
which can generate code which generates warnings,
and
4. a few stragglers here and there.
We turned off the extended warnings for many programs in appl/ as
they are nearing the end of their useful lifetime, e.g. rsh, rcp,
popper, ftp and telnet.
Interestingly, glibc's strncmp() macro needed to be worked around
whereas the function calls did not.
We have not yet tried this on 32 bit platforms, so there will be
a few more warnings when we do.
This should allow master key rollover.
(but the real reason is to allow multiple krbtgt accounts, as used by
Active Directory to implement RODC support)
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
The issue was that we would free the entry after the database, not
knowing that the entry was a talloc child of the database.
Andrew Bartlett
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
This extends the hdb_keytab code to allow enumeration of all the keys.
The plan is to allow ktutil's copy command to copy from Samba4's
hdb_samba4 into a file-based keytab used in wireshark.
From Andrew Bartlett
hdb_entry_ex might still contain links to the database that it expects
to use.
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@18267 ec53bebd-3082-4978-b11e-865c3cabbd6b
principal is being sought, thereby allowing the usage of multiple
databases, however they need to be specified in /etc/krb5.conf since
all the programs using this keytab do not read kdc.conf
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@9008 ec53bebd-3082-4978-b11e-865c3cabbd6b
