[20183] in Kerberos_V5_Development
Re: Large pac causes gss_accept_sec_context to fail
daemon@ATHENA.MIT.EDU (Simo Sorce)
Wed Oct 14 15:05:17 2020
Message-ID: <524721f8b7b2b9752e3140f87b5df789310ee618.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com>,
"krbdev@mit.edu" <krbdev@mit.edu>
Date: Wed, 14 Oct 2020 15:04:37 -0400
In-Reply-To: <d644f494-6278-eae4-0d34-f08b97273faf@prodrive-technologies.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
