[PATCH] s4:kdc: add aes key support for trusted domains

[Andrew Bartlett]

On Tue, 2015-03-10 at 16:23 +0100, Stefan (metze) Metzmacher wrote:
> Am 10.03.2015 um 04:55 schrieb Andrew Bartlett:
> > On Thu, 2014-12-18 at 21:12 +0100, Stefan (metze) Metzmacher wrote:
> >> Hi,
> >>
> >> here's a patch to add support to provide aes key for cross-forest
> >> kerberos tickets.
> >>
> >> Please review and push.
> > 
> > G'Day,
> > 
> > This patch was merged into master as
> > 8dd37327b02eaea33915a9cd206667981b8df872
> > 
> > I've been looking over this so that I can include it as part of bug
> > 11142 (because doing so allows all the other patches to land cleanly,
> > without manual fixups), and in doing a by-eye review, I think I've found
> > a regression.  
> > 
> > The patch changes where we call 
> > krb5_principal_set_realm(context, entry_ex->entry.principal, realm);
> > from at the bottom of the function, to just BEFORE this block:
> > 
> >        if (direction == INBOUND) {
> >                 password_val = ldb_msg_find_ldb_val(msg, "trustAuthIncoming");
> > 
> >         } else { /* OUTBOUND */
> >                 dnsdomain = ldb_msg_find_attr_as_string(msg, "trustPartner", NULL);
> >                 /* replace realm */
> >                 realm = strupper_talloc(mem_ctx, dnsdomain);
> >                 password_val = ldb_msg_find_ldb_val(msg, "trustAuthOutgoing");
> >         }
> > 
> > Was this deliberate?  
> 
> No, but seems to have no effect, as we use the raw given 'principal'
> variable in order to calculate the salt.
> 
> I guess I'll provide a patch to fix this.
> 
> But while testing I found some additional problems with enterprise
> principals,
> see the attached patches.
> 
> I'll do more testing in the next days.
> 
> I've integrated your attached fixes to my master4-forest branch
> and added some more for rpc.lsa.forest.trust.
> 
> > I'm thinking this really needs an automated test, like the krb5.kdc
> > tests.  The attached two patches should help us add a test like krb5.kdc
> > in the rpc.lsa.trusted.domains test.  
> > 
> > My thought is to work out which trust types produce Kerberos principals
> > we can obtain tickets to, and then get at least an arcfour-hmac-md5
> > ticket to them, validating the result with krb5_rd_req() against a
> > keyblock.
> 
> I'm a bit lost looking at source4/torture/krb5/kdc.c
> and source4/torture/krb5/kdc-canon.c...

I agree those tests are some of the most complex I've built, and we
probably went overboard.  They are both combinational and
callback-heavy, and it kept on being too each to just add an extra test
to the end rather than break it out into more parts. 

However, for this particular test, I would suggest just doing:
 - override the send/recv to control the target server
 - do the kerberos calls
 - but not the per-packet validation stuff (overkill here, I think). 

I'm going to try that out today.

> I'll first try to get my ~300 patches squashed and ready.

That's understandable.  I would similarly like to see tests for the new
passdb get/set trustdom password code.  These could be done in python,
that sets over RPC (per join.py) and over passdb, and confirms
vice/verca. 

> Then we can think about direct kdc tests, but I'm not
> sure how we could tests the OUTBOUND case in
> samba_kdc_trust_message2entry in such a
> test, as it would require a remote kdc to generate a referral ticket.
> But I'll need help on that...

I'm very glad to help.  I was assuming we could make it give us a ticket
to any name the db-glue layer would respond to, but I guess it might
(correctly) have some restrictions here.

The other way to additionally test these paths in the KDC would be to
extract a 'keytab' for the entries (via passdb/cli_credentials) and
compare expected values, vs the interface samba-tool exportkeytab has. 

Ideally we get a helper function to match keytab values, and grab them
from both interfaces.  That would show the bug I think we have in the
random UTF16 password has, because the password will be wrong for the
arcfour-hmac-md5 case, as it isn't overridden and forced back to be
MD4(blob) in cli_credentials for kinit or keytab use. 

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba


-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba