1372005 – neon built with gnuTLS causes NTLM authentication errors on davfs mounts

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1372005 - neon built with gnuTLS causes NTLM authentication errors on davfs mounts

Summary: neon built with gnuTLS causes NTLM authentication errors on davfs mounts

Keywords:
Status:	CLOSED NEXTRELEASE
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	neon
Sub Component:
Version:	7.2
Hardware:	x86_64
OS:	Linux
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Joe Orton
QA Contact:	RHEL Stacks Subsystem QE
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1400961 1472751
TreeView+	depends on / blocked

Reported:	2016-08-31 16:33 UTC by Michael Watters
Modified:	2020-01-17 16:10 UTC (History)
CC List:	2 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2020-01-17 16:10:07 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Michael Watters 2016-08-31 16:33:58 UTC

Description of problem:

neon is built using libgnutls which causes NTLM authentication to fail.  This bug is also discussed at the following URL.

http://savannah.nongnu.org/support/?107060
 
Version-Release number of selected component (if applicable):

0.30.0

How reproducible:

Always

Steps to Reproduce:
1.  Install davfs2 package
2.  Attempt to mount sharepoint URL.  For example:

mount -t davfs http://teams.example.com/sites/ENG/EVC/EIDLibrary/CurrentEID /var/mnt/eid


Actual results:

Mounting fails with the following error message.

/sbin/mount.davfs: Mounting failed.
Could not authenticate to server: ignored NTLM challenge


Expected results:

The share is mounted.

Additional info:

Mounting the same URL via davfs2 works in Fedora.  neon and davfs2 are built without gnutls on that platform.

Comment 2 Joe Orton 2016-08-31 17:51:36 UTC

"Could not authenticate to server: ignored NTLM challenge"

This is how I'd expect it to fail if using a version of davfs2 without Ruediger's patches from the bug you linked to:

http://savannah.nongnu.org/support/?107060#comment0

I'd guess the version of davfs2 in EPEL7 is older than the version in Fedora, and doesn't contain that patch, maybe you can confirm?  (davfs2 is not in RHEL so Red Hat does not support it)

Comment 3 Michael Watters 2016-08-31 20:28:21 UTC

The davfs2 packages in Fedora and EPEL7 are the same however the issue appears to be in the libneon library which is used for SSL support.  When neon is linked against libgnutls NTLM authentication fails, without libgnutls authentication works properly. 

The SRPMs for neon in Fedora 20 and Redhat 7 appear to be the same however there is a difference shown when I check the .so file with ldd as follows.

CentOS 7:

ldd /usr/lib64/libneon.so.27.3.0 
	linux-vdso.so.1 =>  (0x00007ffee10f2000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fbb9cc16000)
	libgnutls.so.28 => /lib64/libgnutls.so.28 (0x00007fbb9c8e1000)
	libpakchois.so.0 => /lib64/libpakchois.so.0 (0x00007fbb9c6d9000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fbb9c48d000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fbb9c1a8000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fbb9bf75000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fbb9bd71000)
	libproxy.so.1 => /lib64/libproxy.so.1 (0x00007fbb9bb50000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fbb9b925000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbb9b709000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fbb9b347000)
	libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007fbb9b100000)
	libtspi.so.1 => /lib64/libtspi.so.1 (0x00007fbb9ae8f000)
	libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007fbb9ac7b000)
	libnettle.so.4 => /lib64/libnettle.so.4 (0x00007fbb9aa49000)
	libhogweed.so.2 => /lib64/libhogweed.so.2 (0x00007fbb9a822000)
	libgmp.so.10 => /lib64/libgmp.so.10 (0x00007fbb9a5ab000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fbb9a3a6000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fbb9a197000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fbb99f93000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fbb99d78000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fbb9d066000)
	libmodman.so.1 => /lib64/libmodman.so.1 (0x00007fbb99b70000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fbb99868000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fbb99565000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbb9934f000)
	libffi.so.6 => /lib64/libffi.so.6 (0x00007fbb99147000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fbb98d5e000)
	libssl.so.10 => /lib64/libssl.so.10 (0x00007fbb98af1000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fbb988cc000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fbb9866a000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fbb98445000)

Fedora 20:

ldd /usr/lib64/libneon.so.27.3.1
	linux-vdso.so.1 =>  (0x00007ffcd6109000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fe66ed97000)
	libssl.so.10 => /lib64/libssl.so.10 (0x00007fe66eb2b000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fe66e743000)
	libpakchois.so.0 => /lib64/libpakchois.so.0 (0x00007fe66e53c000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fe66e2f2000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fe66e012000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fe66dddd000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fe66dbd9000)
	libproxy.so.1 => /lib64/libproxy.so.1 (0x00007fe66d9b8000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fe66d78e000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe66d571000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fe66d1b3000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fe66cfaf000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fe66cda1000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fe66cb9d000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fe66c983000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fe66f1d9000)
	libmodman.so.1 => /lib64/libmodman.so.1 (0x00007fe66c77b000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fe66c473000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fe66c16c000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe66bf56000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fe66bd32000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fe66bacc000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fe66b8a7000)

I also checked a Fedora 24 system which shows no mention of gnutls either.

In the past I've been able to get NTLM authentication working in CentOS by recompiling neon using the --with-ssl=openssl compile option and then linking davfs2 against *that* version of neon which was then able to login and access Sharepoint shares without an issue.

I'm not certain why there's a difference in CentOS but it definitely affects our ability to access WebDAV shares from Sharepoint.

Comment 4 Joe Orton 2016-09-01 08:07:51 UTC

Ah, my mistake, you're completely correct, the NTLM support is only built for OpenSSL.  It would be possible in theory to port that neon code to libgcrypt in RHEL7, but we'd need a support ticket to be able to prioritize that work.

If this issue is critical or in any way time sensitive, please raise a ticket through the regular Red Hat support channels to ensure it receives the proper attention and prioritization to assure a timely resolution. 

For information on how to contact the Red Hat production support team, please visit:
    https://www.redhat.com/support/process/production/#howto

Comment 11 Joe Orton 2020-01-17 16:10:07 UTC

We have no plans to address this RFE in RHEL7.  neon builds against OpenSSL in RHEL8 so the issue should be fixed there.

Note You need to log in before you can comment on or make changes to this bug.