Large pac causes gss_accept_sec_context to fail
Martijn de Gouw
martijn.de.gouw at prodrive-technologies.com
Wed Oct 14 16:12:28 EDT 2020
On 14-10-2020 21:46, Greg Hudson wrote:
> On 10/14/20 2:24 PM, Martijn de Gouw wrote:
>> I've found a redhat article about
>> disabling pac data: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F969123&data=02%7C01%7C%7C24b64a9b529a43211e6508d87079cf9c%7C612607c95af74e7f8976faf1ae77be60%7C0%7C0%7C637383015898191640&sdata=dZryZnj8pxkrb77aSeKJWJhsP4s9PrBBJ64zc0Q%2FXFM%3D&reserved=0.
> I don't have access to read that, unfortunately.
You can create a free RHEL Developer Subscription. But it boils down to
rpc.svcgssd being replaced by gssproxy, which handles the (very) large
kerberos tickes much better. RH suggests to disable the PAC data so the
tickets remain much smaller.
>> 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
The entry point is:
From there is a hundreds of calls to get_tag() and decode_atype() and
> 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
It's a good pointer pointer indeed. I'm going to try to the check of the
token is the same on both client and server as well.
Martijn de Gouw
Mobile: +31 63 17 76 161
Phone: +31 40 26 76 200
More information about the krbdev