Microsoft PAC field

[Markus Moeller]

Sam,

I get now some authorisation data on the server after krb5_rd_req, but I
still cannot get the MS details. From the below I would think the
tkt->enc_part2->authorisation_data.contents could be associated with the
PACTYPE structure, but  it doesn't fit (meaning cBuffers and version values
don't make sense). In my case tkt->enc_part2->authorisation_data.ad_type is
1 which I think is the "IF-RELEVANT (ID 1) portion of the authorization
data".  Is the authorisation_data.contents still encoded ? I didn't find
anything about "encoded KERB_AUTH_DATA_PAC".

Thanks
Markus
>The PAC itself is included in the IF-RELEVANT (ID 1) portion of the
authorization data in a ticket. Within the IF-RELEVANT portion, it is
>encoded KERB_AUTH_DATA_PAC with ID 128.
>
>The PAC is defined as a C data type, with integers encoded in little-endian
order. The PAC itself is made up of several layers. The outer
>structure, contained directly in the authorization data, is as follows. The
top-level structure is the PACTYPE structure:





"Sam Hartman" <hartmans at MIT.EDU> wrote in message
news:tslacy0opr6.fsf at cz.mit.edu...
> >>>>> "Markus" == Markus Moeller <huaraz at moeller.plus.com> writes:
>
>     Markus> Sam the document
>     Markus>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnkerb/html/MSDN_PAC.asp
>     Markus> says:
>
>     Markus> The PAC is generated by the KDC under the following
>     Markus> conditions:
>
>     Markus>   a.. During an AS request that has been validated with
>     Markus> pre-authentication.  b.. During a TGS request when the
>     Markus> client has no PAC and the target is a service in the
>     Markus> domain or a ticket granting service (referral ticket).
>     Markus> which I interpret that the authorisation data are send as
>     Markus> part of an AS-REP or TGS-REP and if it is an AS-REP stored
>     Markus> in the credential cache. I can see that the size of my
>     Markus> credential cache is much bigger after a kinit with PAC
>     Markus> enabled compared to PAC disabled and it increases if I am
>     Markus> a member of more groups. So I would expect to read the
>     Markus> authorisation data from the cache
>
> Sure, but to actually use the authorization data you need to decrypt
> it.  Which would be easy if you had the krbtgt key in which it is
> encrypted.
>
>     Markus> and since the
>     Markus> authorisation data is signed there shouldn't be any threat
>     Markus> from a spoofed kdc, when this data is forwarded to a
>     Markus> server.
>
> But a client that tried to read the data without getting a service
> ticket for itself could be fooled by a spoofed KDC.
>
> Only after calling krb5_rd_req will you be able to read the
> authorization data.
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>