MIT AD Trust PAC handling

[Michael B Allen <miallen@ioplex.com>]

I'm curious to know how the PAC in an MIT <-> AD trust is supposed
to work.

Setup: MIT has a trust with AD. A service account is in MIT. Users are
in AD.

Procedure: The client gets a TGT for AD. Somehow it determines that the
service's realm is not AD so it asks AD for a TGT for MIT. It then asks
MIT for the service ticket.

PAC handling: A TGT from AD has a PAC. Normally a Windows server would
validate this, add domain local group SIDs and re-sign it but MIT has
no concept of a SID so I assume it just copies the authorization-data
section into the service ticket.

Is my understanding correct?

So is it possible to simply copy the authorization-data without breaking
the PAC signatures?

If yes, then either something is wrong with MIT or something is wrong
with Heimdal's PAC validation code.

If no, then what do implementations have to do to maintain the validity
of the PAC signatures?

Does Heidmal's PAC validation code use a different signing digest
algorithm depending on the enctype of the ticket? If yes and AD used RC4
and MIT uses MD5 then that could be a problem? Either MIT would have to
resign the PAC with MD5 (not!) or Heimdal should use (or be configured
to use) a fixed digest algorithm for validating the PAC.

Mike

On Sun, 9 Dec 2007 12:49:14 -0000
"Markus Moeller" <huaraz@moeller.plus.com> wrote:

> Thank you.
> Markus
> 
> BTW Would the cross realm have worked with a Heimdal kdc instead of MIT ?
> 
> 
> 
> "Love H_rnquist _strand" <lha@kth.se> wrote in message 
> 03A7ED3C-357C-402A-AB68-BA564F407F9F@kth.se">news:03A7ED3C-357C-402A-AB68-BA564F407F9F@kth.se...
> > Hello Markus,
> >
> > I added an option to trunk to disable the PAC check, but since my  change 
> > require ABI change I've not pulled it up to the release branch.
> >
> > [libdefaults]
> > check_pac = no
> >
> > Love
> >
> >
> >
> > 7 dec 2007 kl. 14.51 skrev Markus Moeller:
> >
> >> A small update on this:
> >>
> >> The environment is based on a cross-realm between a w2k3 kdc and a  MIT 
> >> kdc.
> >> Clients are in w2k3 and the HTTP service principal on MIT.  (sorry for
> >> missing out on this details)
> >>
> >> The issue I experience seems to be related to the crosss realm setup  and 
> >> how
> >> MIT treats the pac data.
> >>
> >> Markus
> >>
> >> "Markus Moeller" <huaraz@moeller.plus.com> wrote in message
> >> news:fh08tb$qk5$1@ger.gmane.org...
> >>> I used mod_spnego for some time successfully with heimdall 0.7.2.  After
> >>> upgrading to heimdal 1.0.1 I get the following error:
> >>>
> >>> [Thu Nov 08 23:31:04 2007] [error] [client 192.168.1.10] mod_spnego:
> >>> gss_accept_sec_context failed; GSS-API: continuation call to routine
> >>> required)
> >>> [Thu Nov 08 23:31:04 2007] [error] [client 192.168.1.10] mod_spnego:
> >>> gss_accept_sec_context failed; GSS-API mechanism: unknown mech-code  0 
> >>> for
> >>> mech unknown)
> >>>
> >>>
> >>> Why does gss_accept_sec_context  now require a continuation ?
> >>>
> >>> Markus

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/