Now that we use krb5_copy_context() via kadm5_c_dup_context(), we see
occasional skew errors in the tests because context->max_skew was not
being initialized, so it was set to 0s of skew, and krb5_rd_priv() or
others could fail.
Texinfo in the GitHub OS X runners must be ancient. Even Texinfo 5.1
can handle UTF-8.
```
MAKEINFO /Users/runner/work/heimdal/heimdal/doc/heimdal.info
/Users/runner/work/heimdal/heimdal/doc/hx509.texi:11: warning: unrecognized encoding name `UTF-8'.
/Users/runner/work/heimdal/heimdal/doc/heimdal.texi:12: warning: unrecognized encoding name `UTF-8'.
/Users/runner/work/heimdal/heimdal/doc//setup.texi:380: Next field of node `Using soft aliases for configuring referrals' not pointed to (perhaps incorrect sectioning?).
/Users/runner/work/heimdal/heimdal/doc//setup.texi:404: This node (Checking the setup) has the bad Prev.
/Users/runner/work/heimdal/heimdal/doc//setup.texi:350: Prev field of node `Using hard aliases for realm migration' not pointed to.
/Users/runner/work/heimdal/heimdal/doc//setup.texi:310: This node (Using namespaces and synthetic principals to keep the database small) has the bad Next.
makeinfo: Removing output file `/Users/runner/work/heimdal/heimdal/doc/heimdal.info' due to errors; use --force to preserve.
make[1]: *** [/Users/runner/work/heimdal/heimdal/doc/heimdal.info] Error 1
```
Any callback of kadm5_iter_principals() that wants to call other kadm5
functions (such as kadm5_get_principal()) needs to do so on a different
kadm5 handle than the one used for kadm5_iter_principals().
0878a568f9 fixed a warning from Texinfo 6.7:
doc/whatis.texi:33: warning: redefining Texinfo language command: @sub
but the fix makes the doc build fail w/ Texinfo 5.1.
There may still be other problems when using Texinfo 5.1.
One user had an entry with duplicate aliases. This happened with an
earlier version of Heimdal.
This commit does not remove the duplicates, but it does tolerate them.
This is an attempt to make sure we test realm migration aliases by doing
kinit w/ a hard alias name in a different realm, and that we can get
service tickets for services in the same and other realms some of which
are hard aliases in one direction, and some in the other.
The online LIST interrupt message is a NOP, but it's expected to not
have a reply (the server doesn't send one if it receives it before the
LIST finishes).
However, if the interrupt message arrives after the LIST finished, then
it does get a reply, and this causes the client to get out of step with
the server.
Fixes include:
1) flavor the interrupt NOP to make sure it never gets a reply,
2) introduce a new kadm_list_interrtupt message that is like a NOP that
produces no reply
3) always consume -after the LIST ends- a reply to any list interrupt
NOP on the client side.
This implements (1).
The `inmsg` field of the client structure is malloc/realloc'ed in `handle_read` but never free'ed in `maybe_close`.
Seems like Apple already fixed that with this.
Now that we have a properly working API for listing principals in an
online way, and a server-side implementation of it, use it.
This should work with old and new servers, but it will only be online
and fast when talking to new servers.
(Old servers have a bug though that prevents LIST from working.)
Implement a variation on the op for listing principals where if the
client indicates support for the new variation then we stream the list
instead of collecting it into one reply. This is the server-side
version of the associated, preceding commit:
kadm5: Add online kadm5_iter_principals()
kadm5_get_principals() is not online. If you have... many principals,
it will be slow. At least it's no longer quadratic, but it, it's still
slow. Time to add a version that uses a callback:
kadm5_ret_t
kadm5_iter_principals(void *server_handle,
const char *expression,
int (*cb)(void *, const char *),
void *cbdata)
The callback gets called with the given callback data and one principal
name (unparsed).
Note that the callback MUST NOT re-enter the kadm5 library with the
*same* kadm handle. For example, the kadmin protocol doesn't really
multiplex requests well, though it could pipeline them, but it can't
pipeline when LIST is running, not with the protocol implemented here,
so a separate connection is needed, and that requires a separate kadm
handle. We add kadm5_dup_context() to deal with this.
Not sure why we ever needed the run-kadmind-for-one-operation approach
to testing. Anyways, we probably don't. Ditching that and using the
--detach mechanism of daemonization means we don't need to sleep in the
test (except when we need to restart kadmind with different options).
Seeing "End of file" errors from kadm5 client calls which were the
result of not sending back errors in many error paths in
kadmin/server.c:kadmind_dispatch().
We introduced a notion of soft vs. hard aliases in the previous commit
(hdb: Distinguish soft and hard principal aliases).
This commit corrects existing test cases and adds new test cases.
Soft aliases allow for the configuration of referrals using HDB entries.
Hard aliases are like copies of the aliased HDB entries. These are
useful for renaming principals (and realms).
See the preceding commit.
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.
INTxx_MIN plus a positive integer of the same type will always be
negative, and so the result will always compare less than a positive
integer. Fix this check so that we produce the correct result when
adding two negative time_t values.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
In a cross-realm situation the client KDC exchange may use on orphaned
strengthen_key (from the previous exchange) if the current KDC
doesn't not support FAST and the previous KDC supported it.
Otherwise init_creds_step() or fast_tgs_strengthen_key()
generate the reply key.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15005
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Since plugins no longer have a way of accessing the 'ek' member of the
request structure, this function provides a way for a plugin to add
encrypted padata to the response.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
This allows these functions to be used with PACs obtained from KDC
accessor functions such as kdc_request_get_pac().
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
With HDB_ERR_WRONG_REALM the backend needs to expose the
principal, so we should not free the entry otherwise
the main kdc code will crash.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
PAC_TYPE_CLIENT_CLAIMS_INFO and PAC_TYPE_DEVICE_CLAIMS_INFO are
of zero length unless any claims are actually defined.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Closes: #969
PAC_TYPE_CLIENT_CLAIMS_INFO and PAC_TYPE_DEVICE_CLAIMS_INFO are
of zero length unless any claims are actually defined.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
