When processing a request, current tgs_make_reply uses the requested
set of addrs of the request to establish the set of addresses to
associate with the ticket in reply.
However, when the request input set of addrs is NULL, it reverts to
using the TGT set of addresses instead. As a result, it is not
possible to acquire an addressless TGS (or forwarded TGT) using a
TGT that is addressed.
This patch remove the fallback ensuring that a TGS_REQ with a set
of addrs set to NULL enables to acquire an addressless ticket.
A KVNO is unsigned and this is reflected in the internal
interfaces. However, for compatibility reasons its encoding
is signed and this creates a pointer mismatch when passing a
kvno pointer to _kdc_db_fetch.
Signed-off-by: Uri Simchoni <uri@samba.org>
A backend can return this if asked with HDB_F_GET_CLIENT|HDB_F_FOR_AS_REQ
for a KRB5_NT_ENTERPRISE_PRINCIPAL record or for HDB_F_GET_SERVER | HDB_F_FOR_TGS_REQ.
entry_ex->entry.principal->realm needs to return the real realm of the principal
(or at least a the realm of the next cross-realm trust hop).
This is needed to route enterprise principals between AD domain trusts.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
The checking of the KDC signature is more complex than it looks, it may be of a different
enc type to that which the ticket is encrypted with, and may even be prefixed
with the RODC number.
This is better handled in the plugin which can easily look up the DB for the
correct key to verify this with, and can also quickly determine if this is
an interdomain trust, which we cannot verify the PAC for.
Andrew Bartlett
This fixes a segfault if the _kdc_db_fetch function does not find
the entry in the database (the entry pointer will be NULL if entry
is not found).
Signed-off-by: Samuel Cabrero <scabrero@zentyal.com>
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
This handles referrals for SPNs of the form
E3514235-4B06-11D1-AB04-00C04FC2DCD2/NTDSGUID/REALM, which are
used during DRS replication when we don't know the dnsHostName of the
target DC (which we don't know until the first replication from that
DC completes).
We use the 3rd part of the SPN directly as the realm name in the
referral.
Pair-Programmed-With: Andrew Bartlett <abartlet@samba.org>
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.
The default heimdal KDC chokes when trying to encrypt a ticket with a weak
server key that has a different type than the session key. The problem
happens in the krb5_crypto_init function called from the _kdc_encode_reply
function.
The existing work-around of the problem temporarily enabled the weak
enctype in case it was disabled but the principal was on the (hard-coded)
exception list.
Unfortunately the code used the keytype of the key encoded in the ticked
(the session key) instead of the keytype of the key used to encrypt the ticket
(the serverkey) thus enabling the incorrect encryption type if those two
are different, for instance des-cbc-md5 and des-cbc-crc.
Change-Id: Ia55dc344e3e5fc9ec1eb93c9e8ebb0a58c673d57
Different ticket session key enctype selection options should
distinguish between target principal type (krbtgt vs. not), not
between KDC request types.
We can't test the key rollover support in the TGS in the x-realm
path using just Heimdal because the krb5_get_creds() path will try a
referral, which will produce a cross-realm TGT that has the
enc_part.kvno set. But we can test this for the plain TGT case.
AD issues x-realm TGTs with kvno 0. On key x-realm trust key change
we need to be able to try current and previous keys for trust, else
we will have some failures.
We were using the enctype from the PA-TGS-REQ's AP-REQ's Ticket to
decide what key from the service's realm's krbtgt principal to use.
This breaks when: a) we're doing cross-realm, b) the service's
realm's krbtgt principal doesn't have keys for the enctype used in
the cross-realm TGT.
The fix is to pick the correct key (strongest or first, per-config)
from the service's realm's krbtgt principal.
The previous fix was incomplete. But it also finally uncovered an
old check-des problem that I'd had once and which may have gotten
papered over by changing the default of one of the *strongest* KDC
parameters. The old problem is that we were passing the wrong
enctype to _kdc_encode_reply(): we were passing the session key
enctype where the ticket enc-part key's enctype was expected.
The whole enctype being passed in is superfluous anyways. Let's
clean that up next.
When I added support for configuring how the KDC selects session,
reply, and ticket enc-part keys I accidentally had the KDC use the
session key selection algorithm for selecting the ticket enc-part
key. This becomes a problem when using a Heimdal KDC with an MIT
KDB as the HDB backend and when the krbtgt keys are not in
strongest-to-weakest order, in which case forwardable tickets minted
by the Heimdal KDC will not be accepted by MIT KDCs with the same
KDB.
We don't need a cast in that case.
Before commit 1124c4872d
(KVNOs are krb5uint32 in RFC4120, make it so),
we compared krb5int32 casted to size_t with unsigned int,
which resulted in the following problem:
Casting krb5int32 to (size_t) is wrong, as sizeof(int)==4 != sizeof(size_t)== 8.
If you cast negative int values to size_t you'll get this:
int ival = -5000; // 0xFFFFEC78
size_t sval = (size_t)ival; // this will be 0xFFFFFFFFFFFFEC78
So we better compare while casting to (unsigned int).
This is important for Active Directory RODC support,
which adds a random number into the higher 16-bits of the
32-bit kvno value.
metze
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
We need to use the name that the HDB entry returned, otherwise we
will not canonicalise the reply if requested.
Andrew Bartlett
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
A service should use S4U2Self instead of S4U2Proxy.
Windows servers allow S4U2Proxy only to explicitly configured
target principals.
metze
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
This way we can compare the already canonicalized principals,
while still passing the client specified target principal down
to the backend specific constrained_delegation() hook.
metze
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
Depending on S4U2Proxy the principal name for the resulting
ticket is not the principal of the client ticket.
metze
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
For a normal TGS-REQ they're both signed with krbtgt key.
But for S4U2Proxy requests which ask for contrained delegation,
the keys differ.
metze
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
most of these warnings are not problems because of ample
use of abort() calls. However, the large number of warnings
makes it difficult to identify real problems. Initialize
the variables to shut up the compilers.
Change-Id: I8477c11b17c7b6a7d9074c721fdd2d7303b186a8
By checking the client principal here, we compare the realm based on
the normalised realm, but do so early enough to validate the PAC (and
regenerate it if required).
Andrew Bartlett
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
