eUPN and Kerberos PAC issues

Andrew Bartlett abartlet at samba.org
Wed Mar 18 03:30:33 MDT 2015


On Wed, 2015-03-18 at 08:47 +0100, Stefan (metze) Metzmacher wrote:
> Am 18.03.2015 um 05:13 schrieb Andrew Bartlett:
> > On Mon, 2015-03-16 at 10:35 +0100, Stefan (metze) Metzmacher wrote:
> >> Am 16.03.2015 um 01:48 schrieb Andrew Bartlett:
> >>> On Sun, 2015-03-15 at 22:55 +0100, Stefan (metze) Metzmacher wrote:
> >>>> Hi Andrew,
> >>>>
> >>>>>>> I don't see the additional tests in your autobuild.  Are you planning on
> >>>>>>> pushing those later?
> >>>>>>
> >>>>>> There was a problem with the s4member env.
> >>>>>>
> >>>>>> I've fixed the bug, see
> >>>>>> https://git.samba.org/?p=metze/samba-autobuild/.git;a=commitdiff;h=272ab25b540f8e2a718fbdff5acc6e73798fc415
> >>>>>> and pushed everything.
> >>>>>
> >>>>> Thank you so much for looking into this, and sorry for the bother!
> >>>>>
> >>>>> I'm really pleased with how the KDC and our AD support is improving, and
> >>>>> being validated.  Thanks for all your efforts in this area.
> >>>>
> >>>> What about the following two patches.
> >>>
> >>> The gensec_gssapi patch looks reasonable, pushed.
> >>>
> >>> The second I would still really like a test for, because of how fragile
> >>> this area is.
> >>
> >> What happens currently is the following:
> >>
> >> The given principal by the caller of samba_kdc_trust_message2entry() is
> >> "krbtgt/S4XDOM.BASE at W2012R2-L4.BASE"
> >> and we set entry_ex->entry.principal to "krbtgt/S4XDOM.BASE at S4XDOM.BASE".
> >>
> >> The main _kdc_tgs_rep() uses krbtgt->entry->principal in tgs_build_reply(),
> >> like this:
> >>
> >> 1763        /* Now refetch the primary krbtgt, and get the current kvno (the
> >> 1764         * sign check may have been on an old kvno, and the server may
> >> 1765         * have been an incoming trust) */
> >> 1766        ret = krb5_make_principal(context, &krbtgt_principal,
> >> 1767
> >> krb5_principal_get_comp_string(context,
> >> 1768
> >> krbtgt->entry.principal,
> >> 1769                                                                 1),
> >> 1770                                  KRB5_TGS_NAME,
> >> (gdb) l
> >> 1771
> >> krb5_principal_get_comp_string(context,
> >> 1772
> >> krbtgt->entry.principal,
> >> 1773                                                                 1),
> >> NULL);
> >> 1774        if(ret) {
> >> 1775            kdc_log(context, config, 0,
> >> 1776                        "Failed to generate krbtgt principal");
> >> 1777            goto out;
> >> 1778        }
> >> 1779
> >> 1780        ret = _kdc_db_fetch(context, config, krbtgt_principal,
> >> HDB_F_GET_KRBTGT, NULL, NULL, &krbtgt_out);
> >>
> >> krbtgt_principal is "krbtgt/S4XDOM.BASE at S4XDOM.BASE",
> >> the realm of krbtgt->entry->principal doesn't matter.
> >>
> >> krbtgt_out->entry.principal is also "krbtgt/S4XDOM.BASE at S4XDOM.BASE",
> >> which is used to sign the PAC. While krbtgt->entry was used to validate
> >> the PAC.
> >>
> >> The only thing that differs seem to be confusing log messages and
> >> confusing values seen within a debugger.
> >> I don't know how we could test this automatically.
> > 
> > I'm just looking for something that checks we can get that ticket at
> > all, and (if possible for a ticket in that direction) that it has the
> > right value by decrypting it.  
> 
> We'll get that when we have tests which run against two environments
> which trust each other. But we need a lot of other patches before.
> 
> In the meantime can we please just push this fix for this simple regression?
> So that we don't block the backport you proposed for 4.2.

OK.  That's fine.

Reviewed-by: Andrew Bartlett <abartlet at samba.org>

I would still like a standalone (unit rather than integration) test, but
we would need to fix up the lsa forest tests properly to host those. 

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




More information about the samba-technical mailing list