Large pac causes gss_accept_sec_context to fail

[Martijn de Gouw]

Hi,

On 14-10-2020 21:04, Simo Sorce wrote:
> On Wed, 2020-10-14 at 18:24 +0000, Martijn de Gouw wrote:
>> Hi,
>>
>> I'm trying to get NFSv4 to work with kerberos in our environment. The
>> KDC is a MS Active Directory (Windows server 2019). The Linux nfs server
>> and clients are all Debian 10.6. I'm using gssproxy on the nfs server.
>>
>> I'm able to mount the nfs share on the client. But some users can access
>> the directory and others can't, all having valid kerberos tickets,
>> created during login or with kinit. 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%7Ccc05b92ae4cc4348400a08d87074041c%7C612607c95af74e7f8976faf1ae77be60%7C0%7C0%7C637382991596424955&sdata=ge0zPhmXGysnViSDdSU1cctkLWjf71oW1ND8fzNphjE%3D&reserved=0.
>>
>> Enabling NO_AUTH_DATA_REQUIRED works, but not in the way described in
>> the article. The mentioned 'Suppress exported_composite_name for the
>> kernel' code in gssproxy is not even hit yet, because
>> gss_accept_sec_context() returns an error on users that are in many
>> groups: GSSX_RES_ACCEPT_SEC_CONTEXT( status: { 851968 <None> 100001
>> "Unspecified GSS failure.  Minor code may provide more information"
>> "Success" [  ] } context_handle: <Null> output_token: <Null>
>> delegated_cred_handle: <Null> )
>>
>> 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?).
>>
>> 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.
>>
>> If krb5 is not able to handle the (faulty?) pac data, would it be
>> possible for gssproxy to tell gss_accept_sec_context to ignore the pac
>> data anyway? Since I have only limited access to the AD, it is very
>> cumbersome if I have to set NO_AUTH_DATA_REQUIRED for all Linux nfs servers.
>>
>> I'm using gssproxy 0.8.3 and krb5 1.17.1.
>>
>> Regards, Martijn
> 
> If you take a network trace (maybe via wireshark) can you confirm that
> the kernel handles the whole GSS token to user space ?

I created traces on both the client and server, I'm not sure what to 
look for, but when I set the filter to Kerberos in wireshark I see the 
following:

Clnt -> AD: AS-REQ (224 bytes)
AD -> Clnt: KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED
Clnt -> AD: AS-REQ (224 bytes)
AD -> Clnt: KRB Error: KRB5KRB_ERR_RESPONSE_TO_BIG
Clnt -> AD: AS-REQ (319 bytes)
AD -> Clnt: AS-REP (1439 bytes)
Clnt -> AD: TGS-REQ
AD -> Clnt: TGS-REP

Clnt -> Srv: V4 NULL Call -> GSS Token Length: 7102.
Clnt -> Srv: V4 NULL Call -> GSS Token Length: 7102.

This token length matches with the token length that gssproxy prints.

The token is printed by gssproxy, can I compare this token to something 
on the client (a file or kerberos tcpdump?)

> 
> I wonder if there is a bug in your kernel that actually truncated the
> token.

Both server and client run kernel 5.7.10

Regards, Martijn

> 
> Simo.
> 

-- 
Martijn de Gouw
Designer
Prodrive Technologies
Mobile: +31 63 17 76 161
Phone:  +31 40 26 76 200