Large pac causes gss_accept_sec_context to fail

[Simo Sorce]

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://access.redhat.com/solutions/969123.
> 
> 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 wonder if there is a bug in your kernel that actually truncated the
token.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc