A question about S4U2Self with MIT KDC

Alexander Bokovoy ab at samba.org
Thu Feb 7 11:49:40 UTC 2019


On to, 07 helmi 2019, Isaac Boukris via samba-technical wrote:
> Hi Andreas & Alexander,
> 
> On Wed, Feb 6, 2019 at 1:49 PM Andreas Schneider <asn at samba.org> wrote:
> >
> > Yes we should verify it as Heimdal does. For that you need to extend the KDB
> > plugin API from MIT Kerberos to pass down the required tgt-client principal
> > name.
> 
> Thank you for confirming this, I'll submit a PR upstream, update the
> patch accordingly, add comments and get back here.
> 
> > > principal and signatures, but so far I have not succeeded joining as a
> > > DC to a Windows domain. I'm getting WERR_DS_NO_CROSSREF_FOR_NC error
> > > against w2k8 and w2k16 - any help on this will be appreciated as well.
> >
> > Maybe metze can help here. He implemented support for it iirc.
> 
> Meanwhile, I found "samba-tool drs clone-dc-database
> --include-secrets", which lets me steal the keys so I should be able
> to play with TGT.
> 
> On Thu, Feb 7, 2019 at 11:50 AM Alexander Bokovoy <ab at samba.org> wrote:
> >
> > On ke, 06 helmi 2019, Isaac Boukris via samba-technical wrote:
> >
> > > $ echo -n pwd | kinit apache at ACME.COM --no-request-pac && kvno
> > > -Uuser at abc@ACME.COM apache at ACME.COM
> >
> > According to MS-PAC 4.1.2 Authorization Validation and Filtering,
> ...
> > My reading of this is that it implies PAC validation cross-realm.
> 
> The example I used is a bit misleading as it is not a cross-realm
> request just an enterprise name from current realm (kvno -U assumes
> enterprise).
> 
> I think the section you quoted is only relevant when a KDC copies the
> PAC from the TGT to the ticket (or to the next referral TGT). My
> question was about the case when the KDC creates a new PAC not based
> on the old one, where the verification of the old one seem useless as
> no authorization decision is done upon it (this happens with S4U2Self,
> both in-realm and cross-realm scenarios).
> 
> The relevant doc is in MS-SFU 3.2.5.x - but I can't make sense of it :(
3.2.5.1.2 is clear: 

-----

If the KDC supports the Privilege Attribute Certificate Data Structure
[MS-PAC], the KDC, when populating the KERB_VALIDATION_INFO Structure
([MS-KILE] section 3.3.5.6.4.1), MUST NOT include the
AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY SID ([MS-DTYP] section
2.4.2.4) in the ExtraSids field and SHOULD add the
SERVICE_ASSERTED_IDENTITY SID ([MS-DTYP] section 2.4.2.4) instead.

-----

Also 3.2.5.2 is clear:

-----

Service 1's KDC verifies both server ([MS-PAC] section 2.8.1) and KDC
([MS-PAC] section 2.8.2) signatures of the PAC. If Service 2 is in
another domain, then its KDC verifies only the KDC signature
of the PAC. If verification fails, the KDC MUST return
KRB-AP-ERR-MODIFIED.

-----

These both require verification. For 3.2.5.1, KDC has to do verification
of the PAC in the referral TGT:

-----

If the KDC supports the Privilege Attribute Certificate Data Structure
[MS-PAC], a referral TGT is received and a PAC is provided, the Name
field in the PAC_CLIENT_INFO structure MUST have the form of "client
name at client realm".

-----

So I think the end result is that verification of PAC has to happen for
both in-realm and cross-realm operations. MS-KILE and MS-SFU are written
in a such way that non-AD implementations are allowed to get away with
no MS-PAC tickets but AD itself assumes always producing MS-PAC in the
tickets and thus performing verification of its content.

-- 
/ Alexander Bokovoy



More information about the samba-technical mailing list