eUPN and Kerberos PAC issues
Andrew Bartlett
abartlet at samba.org
Tue Mar 10 23:18:43 MDT 2015
On Wed, 2015-03-11 at 05:28 +0100, Stefan (metze) Metzmacher wrote:
> Am 11.03.2015 um 05:07 schrieb Andrew Bartlett:
> > On Wed, 2015-03-11 at 16:41 +1300, Andrew Bartlett wrote:
> >> On Wed, 2015-03-11 at 14:01 +1300, Andrew Bartlett wrote:
> >>> On Wed, 2015-03-11 at 00:43 +0100, Stefan (metze) Metzmacher wrote:
> >>>> Am 10.03.2015 um 23:28 schrieb Andrew Bartlett:
> >>>>> On Tue, 2015-03-10 at 16:23 +0100, Stefan (metze) Metzmacher wrote:
> >>>>>
> >>>>>> But while testing I found some additional problems with enterprise
> >>>>>> principals,
> >>>>>> see the attached patches.
> >>>>>
> >>>>> Thanks. What did you do to trigger these? Did it happen on the server,
> >>>>> or (as I'm assuming) on the client? Does it trigger against Windows as
> >>>>> the server, or Samba? Unless canonicalise was forced off (like I do in
> >>>>> the krb5.kdc tests), how do we get an enterprise principal in the PAC?
> >>>>
> >>>> I did the following:
> >>>>
> >>>> kinit -E administrator at W2012R2-L4.BASE
> >>>> kvno cifs/ub1204-161.s4xdom.base
> >>>>
> >>>> => that generated an error "realm found in 'short' principal"
> >>>> Because the windows kdc added administrator at W2012R2-L4.BASE in the PAC.
> >>>>
> >>>> While
> >>>>
> >>>> kinit administrator at W2012R2-L4.BASE
> >>>> kvno cifs/ub1204-161.s4xdom.base
> >>>>
> >>>> worked fine, as there's only "administrator" in the PAC.
> >>>>
> >>>> I'd also another bug.
> >>>>
> >>>> kinit -E administrator at S4XDOM.BASE
> >>>> kvno cifs/w2012r2-183.w2012r2-l4.base
> >>>> failed with message altered.
> >>>>
> >>>> While it worked with
> >>>> kinit -C -E administrator at S4XDOM.BASE
> >>>> kvno cifs/w2012r2-183.w2012r2-l4.base
> >>>>
> >>>> and
> >>>> kinit administrator at S4XDOM.BASE
> >>>> kvno cifs/w2012r2-183.w2012r2-l4.base
> >>>>
> >>>> Maybe this is also fixed, but I need to retest that.
> >>>>
> >>>>> In the meantime, I'll follow though and finish the tests by making our
> >>>>> code validate the tickets being obtained.
> >>>>
> >>>
> >>> Thanks for the detailed explanation metze, that gives me the right
> >>> information to build the test with.
> >>>
> >>> One question: How did the patch help, as it was against Heimdal and
> >>> kvno is only in MIT?
> >>>
> >>> Or did you fix it in your local MIT and port that to Heimdal, or
> >>> something else?
> >>
> >> Ahh! Now I understand it. You were hitting a check in the MIT krb5
> >> client, that you then fixed in the server, and in turn fixed in the
> >> client to match, even if that wasn't triggered in your testing. The
> >> tests I include in the patches attached prove this your changes are
> >> indeed correct (tested by reverting them). These tests also pass
> >> against Win2012R2.
>
> No, the failures are generated in the samba/heimdal kdc
> and I've indeed tested with fedora 20 and MIT krb5 1.12.2-9.fc20.x86_64
>
> The PAC was generated wrong in the AS-REP, once this is fixed
> the TGS-REQ will trigger the 2nd bug.
>
> So the old code worked when we have only samba/heimdal kdcs,
> as the 2 bugs neutralize each other.
A very good reason to update our collection of saved PAC values, and put
one of these in there!
> I noticed it only because the PAC in the AS-REP and referral ticket where
> generated by a Windows 2012R2 KDC and the samba/heimdal kdc
> fails to verify the PAC in the TGS-REQ.
>
> I'll have a look at the patches later, thanks!
>
> metze
>
Thanks. It seems I broke samba4.local.pac, so I'll investigate that
tomorrow if it isn't obvious to you.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150311/5e2cef64/attachment.pgp>
More information about the samba-technical
mailing list