Re: MIT AD Trust PAC handling

["Markus Moeller" <huaraz@moeller.plus.com>]

"Michael B Allen" <miallen@ioplex.com> wrote in message 
20071210225810.01ffa1db.miallen@ioplex.com">news:20071210225810.01ffa1db.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?
>

That is my understanding too

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

I guess no why I hit the problem.

> 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?
>

I guess they need to change some realm details inside the PAC.

> 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/
>