Large pac causes gss_accept_sec_context to fail
ghudson at mit.edu
Wed Oct 14 15:46:03 EDT 2020
On 10/14/20 2:24 PM, Martijn de Gouw wrote:
> I've found a redhat article about
> disabling pac data: https://access.redhat.com/solutions/969123.
I don't have access to read that, unfortunately.
> The token is very big for those users (~7k). I did some tracing in the
> krb5 library to see what really goes wrong here, since the error is not
> very descriptive. I was able to dig down in
> src/lib/krb5/asn.1/asn1_encode.c, where the token is decoded. There is a
> lot of decode_atype() performed on the token, until finally omit_atype()
> returns ASN1_MISSING_FIELD, called by get_tag() for a->type =
> atype_sequence (embedded in a type atype_tagged_thing tag, I think?).
What kind of object is being decoded? That is, in the stack trace, what
is the entry point into the ASN.1 code? It would have a name like
In src/lib/krb5/asn.1/README.asn1 there is a section on debugging at the
end. It provides a (laborious) process for determining where an error
like this is occurring within the ASN.1 type definition.
> Now I'm wondering is MS is really doing something wrong here, or krb5 is
> unable to handle this PAC data. the 'net ads kerberos pac dump' does not
> complain or show any errors when dumping PAC data for any user.
PAC data isn't encoded in ASN.1; the code to process it lives in
src/lib/krb5/krb/pac.c. The issue is likely in the surrounding Kerberos
protocol object. It could be a truncation issue as Simo hypothesizes,
although I would expect that to normally yield a different error like
More information about the krbdev