Bug 1372005

"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)

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.

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

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