user_saml
user_saml copied to clipboard
nextcloud
Kerberos SSO, WebDAV, Windows and MS Office
Sorry if this intro is a bit verbose.
We have been working over the past few weeks to integrate Nextcloud into a client's environment. Part of this integration was providing "mapped drive" like access to files/folders stored in Nextcloud. To make this as seamless as possible we used Apache and Kerberos for SSO.
We encountered a few issues along the way and made some code modifications to mitigate them. These code modifications get the job done but aren't of a quality you would accept as a pull request. Maybe someone can pick up where I leave off and use them to improve the awesome Nextcloud software. Failing that, it might allow someone to not have to repeat my steps to replicate my result.
Ultimately, there were two issues that needed code changes:
- Kerberos authentication doesn't work properly for WebDAV clients
- Microsoft Office applications implement their own WebDAV client and this client prompts for credentials unless some specific conditions are met.
Kerberos authentication doesn't work properly for WebDAV clients
I found that in apps/user_saml/lib/UserBackend.php for the function "getCurrentUserId", for requests that arrived via remote.php, the variable $this->session->get('user_saml.samlUserData'); is not populated. This results in this function always failing with WebDAV clients because it expects to be able to reference the REMOTE_USER value from this variable.
I added a fudge that checks to see if this variable is empty, if $_SERVER['REMOTE_USER'] is not empty and then pushes $_SERVER into the variable:
if (!is_array($samlData)) {
if (strlen($uidMapping) > 0) {
if (isset($_SERVER[$uidMapping])) {
$this->session->set('user_saml.samlUserData', $_SERVER);
$samlData = $this->session->get('user_saml.samlUserData');
}
}
}
Obviously, the true fix is finding where this variable SHOULD have been populated.
Microsoft Office applications prompt for credentials
Per this document: https://support.microsoft.com/en-au/help/2019105/authentication-requests-when-you-open-office-documents
Microsoft Office applications expect to be able to make an anonymous OPTIONS request to the root of the WebDAV URL (https://next.cloud.server/remote.php/webdav) and if it gets a 401 response, it pops up a credential prompt.
I simply added an exception just before the return to lib/private/legacy/user.php function "loginWithApache" that checks the URL and HTTP_USER_AGENT and returns true if it's MS Office:
if (preg_match("/Microsoft Office/i", $_SERVER['HTTP_USER_AGENT'])) {
if (($_SERVER['REQUEST_URI'] = '/remote.php/webdav/') && ($_SERVER['REQUEST_METHOD'] = 'OPTIONS')) {
return true;
}
}
Steps to reproduce
- Install Nextcloud (Ubuntu + Apache + mod_auth_kerb + Samba + LDAP/AD integration) per the Nextcloud documentation
- Configure Windows client (add nextcloud server to "Local Intranet" zone, set AuthForwardServerList in registry, ensure "Desktop Experience" is installed)
- Attempt to map a drive to https://next.cloud.server/remote.php/webdav
- Attempt to open Documents/About.odt in Microsoft Word
Expected behavior
- Using the "Map Network Drive" wizard to map a WebDAV drive in Windows should not prompt for credentials.
- Opening a Microsoft Office document (e.g. .docx in Word) should not prompt for credentials.
Actual behavior
- Kerberos authentication fails and Windows prompts for basic authentication credentials
- MS Office prompts for credentials when opening the document
Server configuration
Operating system: Ubuntu 16.04.3 LTS
Web server: Apache/2.4.18 (Ubuntu)
Database: PostgreSQL
PHP version: 7.0.22-0ubuntu0.16.04.1
Nextcloud version: 12.0.4
Where did you install Nextcloud from:
List of activated apps:
- activity: 2.5.2
- bruteforcesettings: 1.0.3
- comments: 1.2.0
- dav: 1.3.0
- federatedfilesharing: 1.2.0
- federation: 1.2.0
- files: 1.7.2
- files_accesscontrol: 1.2.5
- files_external: 1.3.0
- files_pdfviewer: 1.1.1
- files_sharing: 1.4.0
- files_texteditor: 2.4.1
- files_trashbin: 1.2.0
- files_versions: 1.5.0
- files_videoplayer: 1.1.0
- firstrunwizard: 2.1
- gallery: 17.0.0
- groupfolders: 1.2.0
- logreader: 2.0.0
- lookup_server_connector: 1.0.0
- nextcloud_announcements: 1.1
- notifications: 2.0.0
- oauth2: 1.0.5
- password_policy: 1.2.2
- provisioning_api: 1.2.0
- quota_warning: 1.1.1
- serverinfo: 1.2.0
- sharebymail: 1.2.0
- survey_client: 1.0.0
- systemtags: 1.2.0
- theming: 1.3.0
- twofactor_backupcodes: 1.1.1
- updatenotification: 1.2.0
- user_ldap: 1.2.1
- user_saml: 1.4.0
- workflowengine: 1.2.0
Nextcloud configuration:
{
"system": {
"instanceid": "oclx5d4tg8vp",
"objectstore": {
"class": "OC\\Files\\ObjectStore\\S3",
"arguments": {
"bucket": "nextcloud",
"autocreate": true,
"key": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"hostname": "nextcloud-data.domain.local",
"port": 9000,
"use_ssl": false,
"region": "optional",
"use_path_style": true,
"legacy_auth": true
}
},
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"localhost",
"nextcloud.domain.com",
"nextcloud-new.domain.local",
"dev-nextcloud.domain.local",
"dev-nextcloud.domain.com"
],
"datadirectory": "\/var\/www\/nextcloud\/data",
"dbtype": "pgsql",
"version": "12.0.4.3",
"dbname": "nextcloud",
"dbhost": "localhost",
"dbport": "",
"dbtableprefix": "oc_",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"memcache.local": "\\OC\\Memcache\\APCu",
"memcache.locking": "\\OC\\Memcache\\Redis",
"redis": {
"host": "localhost",
"port": 6379
},
"cache_path": "\/var\/www\/nextcloud\/data\/user-local-cache",
"mail_from_address": "nextcloud",
"mail_smtpmode": "php",
"mail_smtpauthtype": "LOGIN",
"mail_domain": "domain.com",
"ldapIgnoreNamingRules": false,
"ldapProviderFactory": "\\OCA\\User_LDAP\\LDAPProviderFactory",
"maintenance": false,
"theme": "",
"loglevel": 1,
"overwrite.cli.url": "https:\/\/nextcloud.domain.com",
"overwriteprotocol": "https"
}
}
Client configuration
Browser:
- Microsoft Internet Explorer 11
- Microsoft Windows WebDAV mini-redirector (Windows Server 2012R2)
- Microsoft Office 2013 applications
Operating system: Windows Server 2012R2
Logs
Nextcloud log (data/owncloud.log)
N/A
Browser log
N/A
The ms office OPTION request handling is something that should be fairly straight forward to generalize. (sending the expected 401 for all unauthorized option requests to the dav root).
As for the dav/kerberos one some debuging needs to be done to determine where the session data should be saved
@icewind1991 Did you work on the 2nd part as well? Do you think this could be finished today or tomorrow? Thanks!
Added code for the 2nd part to #188
Note that I haven't been able to test it with a real office
Thanks @icewind1991 Our testing was unfortunately not successful yet. Could you review the attached logs and error details?
First attempt:
Apache config:
<Location "/index.php/apps/user_saml/saml/login"> AuthType Kerberos AuthName "Kerberos Login" KrbServiceName HTTP/[email protected] KrbMethodNegotiate On KrbMethodK5Passwd Off KrbSaveCredentials Off KrbVerifyKDC On KrbAuthRealms XXXXX.DE KrbLocalUserMapping On Krb5KeyTab /etc/apache2/keytabs/xxxxxxxxxxx.keytab Require valid-user </Location>
tail -f /var/log/apache2/access.log
172.16.x.x - - [15/Mar/2018:15:54:43 +0100] "OPTIONS /remote.php/webdav HTTP/1.1" 200 6822 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.x.x - - [15/Mar/2018:15:54:43 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1317 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601"
Second Attempt:
**Location set to /
Apache config 2**
<Location "/"> AuthType Kerberos AuthName "Kerberos Login" KrbServiceName HTTP/[email protected] KrbMethodNegotiate On KrbMethodK5Passwd Off KrbSaveCredentials Off KrbVerifyKDC On KrbAuthRealms XXXXX.DE KrbLocalUserMapping On Krb5KeyTab /etc/apache2/keytabs/xxxxxxxxxxx.keytab Require valid-user </Location>
tail -f /var/log/apache2/access.log
172.16.X.X - - [15/Mar/2018:16:09:54 +0100] "OPTIONS /remote.php/webdav HTTP/1.1" 401 6550 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:54 +0100] "OPTIONS /remote.php/webdav HTTP/1.1" 200 1301 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - - [15/Mar/2018:16:09:55 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 6550 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:55 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 207 2426 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:55 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:55 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:55 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:55 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:55 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:55 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:56 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:56 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:56 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:56 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:56 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601" 172.16.X.X - meier [15/Mar/2018:16:09:56 +0100] "PROPFIND /remote.php/webdav HTTP/1.1" 401 1717 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601"
Result: Login Prompt both from within Windows Explorer and CMD line tool (net use). note: The prerequisites (Certificate, Registry mods and Local Intranet setting) are satisfied.
@icewind1991 should this commit https://github.com/nextcloud/user_saml/pull/188/com work on Nextcloud 13.0.1.1? I am trying, but till now I have some issues.
Is there any progress on this? I am using nextcloud 17.0.2 and I can SSO using the browser, but when i try to map the network drive by GUI or CLI ( net use ) I am still prompted for my username and password. ( And even typing them does not work ). If i disable the saml app, I can login by typing the username and password on GUI or CLI.
This is my code in apache:
<Location /index.php/apps/user_saml/saml/login>
AuthType GSSAPI
AuthName "Login"
GssapiCredStore keytab:/etc/sso-drive.keytab
Require valid-user
Session On
SessionCookieName gssapi_session path=/;httponly;secure;
GssapiNegotiateOnce Off
GssapiAllowedMech krb5
GssapiLocalName On
GssapiBasicAuth On
Allow from All
</Location>
Hi there, I am a little further in this matter:
My client Environment is Windows 10 and a Server 2016 acting as DC. SSO Login with IE as well as Firefox works flawlessly. Only Issue is, that MS Office (2019) pops up the credential window for the reason already discussed. I can, how ever, simply cancel this username & password pop up and continue loading the file.
This Apache2 config works for me:
<Location />
AuthName "Kerberos Login"
AuthType Kerberos
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbAuthRealms DOMAIN.TLD
KrbServiceName HTTP/[email protected]
Krb5Keytab /etc/apache2/kerberos.keytab
require valid-user
</Location>
How ever, I am struggling with the MS Office Workarround above, which simply doesn't work:
I simply added an exception just before the return to lib/private/legacy/user.php function "loginWithApache" that checks the URL and HTTP_USER_AGENT and returns true if it's MS Office:
if (preg_match("/Microsoft Office/i", $_SERVER['HTTP_USER_AGENT'])) { if (($_SERVER['REQUEST_URI'] = '/remote.php/webdav/') && ($_SERVER['REQUEST_METHOD'] = 'OPTIONS')) { return true; } }
Where exactly is that code meant to be inserted?
Her's the answer to myself: The code above is superseded, the problem has been merged into the NC code already. How ever It appears, that with MS Office 2016 a new "modern authentication" has been introduced and set to mandatory, so that (what ever the previous way - legacy? - was named) the patch above, does not work anymore. See https://www.peters.com/blog/modern-authentication-part-2/
So the work around for that is a registry key:
reg add HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Identity /v EnableADAL /t REG_DWORD /d 0
Hope, that helps.
Can you map the webdav drive in windows without being prompted for authentication ?
I was able to, but there came updates to nextcloud.... and now I'm back to where SSO for FF and IE works perfectly, but webdav doesn't. And I made the observation, that as soon, as I map a webdav network drive, no username is sent do the webserver. So maybe it is not nextcloud's issue, but something's chanced in Windows 10 Webdav behavior... Have you made any progress?
Hi everyone! seams to me, as things are going backwards... WebDav isn't working at all since Upgrade to NC 18. I have included the patch from Shaun Maher in UserBackend.php, but still not possible to login via WebDAV. Although, It works with Internet Explorer. So from that point of view I'd say, that the Windows-Settings regarding Zone-Settings are correctly set. As mentioned above, if I try to connect the network drive (Gui/net use), the username is not sent to the server. I have to explicitly use the /user parameter on the CLI (net use) or use the password prompt in the GUI. What also surprises me, that if I supply the correct user and password, I get an apache2 logs that would suggest, that first I was able to be authenticated and later the correct Webdav URL could not be found:
` [Tue Aug 18 14:40:37.871562 2020] [ssl:debug] [pid 25748] ssl_engine_kernel.c(383): [client 1.2.3.4:50439] AH02034: Subsequent (No.6) HTTPS request received for child 7 (server my.nextcloud.local:443) [Tue Aug 18 14:40:37.871933 2020] [authz_core:debug] [pid 25748] mod_authz_core.c(809): [client 1.2.3.4:50439] AH01626: authorization result of Require valid-user : denied (no authenticated user yet) [Tue Aug 18 14:40:37.871960 2020] [authz_core:debug] [pid 25748] mod_authz_core.c(809): [client 1.2.3.4:50439] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet) [Tue Aug 18 14:40:37.871978 2020] [auth_kerb:debug] [pid 25748] src/mod_auth_kerb.c(1965): [client 1.2.3.4:50439] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Tue Aug 18 14:40:37.871996 2020] [auth_kerb:debug] [pid 25748] src/mod_auth_kerb.c(1298): [client 1.2.3.4:50439] Acquiring creds for HTTP/[email protected] [Tue Aug 18 14:40:37.872578 2020] [auth_kerb:debug] [pid 25748] src/mod_auth_kerb.c(1721): [client 1.2.3.4:50439] Verifying client data using KRB5 GSS-API with our SPNEGO lib [Tue Aug 18 14:40:37.872869 2020] [auth_kerb:debug] [pid 25748] src/mod_auth_kerb.c(1737): [client 1.2.3.4:50439] Client didn't delegate us their credential [Tue Aug 18 14:40:37.872893 2020] [auth_kerb:debug] [pid 25748] src/mod_auth_kerb.c(1756): [client 1.2.3.4:50439] GSS-API token of length 181 bytes will be sent back [Tue Aug 18 14:40:37.873056 2020] [auth_kerb:debug] [pid 25748] src/mod_auth_kerb.c(1871): [client 1.2.3.4:50439] kerb_authenticate_a_name_to_local_name [email protected] -> username [Tue Aug 18 14:40:37.873083 2020] [authz_core:debug] [pid 25748] mod_authz_core.c(809): [client 1.2.3.4:50439] AH01626: authorization result of Require valid-user : granted [Tue Aug 18 14:40:37.873092 2020] [authz_core:debug] [pid 25748] mod_authz_core.c(809): [client 1.2.3.4:50439] AH01626: authorization result of <RequireAny>: granted [Tue Aug 18 14:40:37.873186 2020] [authz_core:debug] [pid 25748] mod_authz_core.c(809): [client 1.2.3.4:50439] AH01626: authorization result of Require valid-user : denied (no authenticated user yet) [Tue Aug 18 14:40:37.873207 2020] [authz_core:debug] [pid 25748] mod_authz_core.c(809): [client 1.2.3.4:50439] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet) [Tue Aug 18 14:40:37.873218 2020] [auth_kerb:debug] [pid 25748] src/mod_auth_kerb.c(1965): [client 1.2.3.4:50439] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Tue Aug 18 14:40:37.873227 2020] [auth_kerb:debug] [pid 25748] src/mod_auth_kerb.c(1903): [client 1.2.3.4:50439] matched previous auth request [Tue Aug 18 14:40:37.873307 2020] [auth_kerb:debug] [pid 25748] src/mod_auth_kerb.c(1871): [client 1.2.3.4:50439] kerb_authenticate_a_name_to_local_name [email protected] -> username [Tue Aug 18 14:40:37.873333 2020] [authz_core:debug] [pid 25748] mod_authz_core.c(809): [client 1.2.3.4:50439] AH01626: authorization result of Require valid-user : granted [Tue Aug 18 14:40:37.873342 2020] [authz_core:debug] [pid 25748] mod_authz_core.c(809): [client 1.2.3.4:50439] AH01626: authorization result of <RequireAny>: granted
==> /var/log/apache2/my.nextcloud.local-access.log <== 1.2.3.4 - username [18/Aug/2020:14:40:37 +0200] "PROPFIND /remote.php/dav/files/username HTTP/1.1" 401 1807 ` I have also tried to connect using davfs2 on the linux-shell using my username and password. Even then it is not working. I hate to beg, but I'd really appreciate, if anyone could help me, sorting things out here.
Thanks a lot!
I have the same problem with 19.0.1, debian 10, mod_auth_gssapi
SSO in browser works fine, but we need access to remote.php/dav/* using GSSAPI (Negotiate).
I've enabled kerberos auth (both Negotiate and Basic) for Location /remote.php/dav/
I've created test.md file in the root of test1 user (uid is samaccountname: test1)
Now, I'm trying to reach this file without http-auth and getting Apache's 401:
# curl -u: https://domain/remote.php/dav/files/test1/test.md
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Unauthorized</title>
</head><body>
<h1>Unauthorized</h1>
<p>This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
</body></html>
Ok, that is absolutely correct. Now I'm using Negotiate auth and getting Nextcloud's 401:
# curl -u: --negotiate https://domain/remote.php/dav/files/test1/test.md
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\NotAuthenticated</s:exception>
<s:message>No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured</s:message>
</d:error>
This means that apache's auth works fine and I can reach nextcloud. But nextcloud doesn't honor REMOTE_USER (which is set, I can see it in the apache logs with this 401 error code from nextcloud). As I understand we need to add Authorization: Negotiate to the list of supported auth types?
With Basic auth all works fine. But that is obvious, since basic kerberos password is the same as LDAP password, and curl's Authorization: Basic is successfully passed to the Nextcloud via Apache.
# curl -utest1 https://domain/remote.php/dav/files/test1/test.md
Enter host password for user 'test1':
test content
So, how could we make Negotiate work with remote.php/dav/?
Here is the fix for my problem: https://github.com/nextcloud/user_saml/pull/407
Hi Urusha! Have I understood correctly, all I have to do is to replace beforeMethod with beforeMethod:* in apps/user_saml/lib/DavPlugin.php? Because that seams not to have changed anything. As I am not sure if explicitly required, I have added to my apache2 config also Location /remote.php/dav/ with kerberos auth. Can you elaborate on how you fixed the problem? regards,
Urusha, could you share your kerberos <Location> Stanza in apache2 config? thanks!
Have I understood correctly, all I have to do is to replace beforeMethod with beforeMethod:* in apps/user_saml/lib/DavPlugin.php?
Yes
Because that seams not to have changed anything. As I am not sure if explicitly required, I have added to my apache2 config also Location /remote.php/dav/ with kerberos auth. Urusha, could you share your kerberos Stanza in apache2 config?
DocumentRoot /var/www/nextcloud
<Directory /var/www/nextcloud/>
Options +FollowSymlinks
AllowOverride All
<IfModule mod_dav.c>
Dav off
</IfModule>
SetEnv HOME /var/www/nextcloud
SetEnv HTTP_HOME /var/www/nextcloud
php_value memory_limit 512M
</Directory>
<Location "/index.php/apps/user_saml/saml/login">
AuthName "DAV Login"
AuthType GSSAPI
Require valid-user
GssapiCredStore keytab:/etc/krb5.http.keytab
GssapiAllowedMech krb5
GssapiLocalName on
GssapiBasicAuth on
</Location>
<Location "/remote.php/dav/">
AuthName "DAV Login"
AuthType GSSAPI
Require valid-user
GssapiCredStore keytab:/etc/krb5.http.keytab
GssapiAllowedMech krb5
GssapiLocalName on
GssapiBasicAuth on
</Location>
With this config I have working SSO:
- chrome/edge (domain should be added to
Local intranetinInternet Options) - firefox (domain should be added to
about:confignetwork.negotiate-auth.trusted-uris) - thunderbird is working with calendars with GSSAPI (domain should be added to
about:confignetwork.negotiate-auth.trusted-uris) - windows explorer network dav drives work and don't ask for password (domain should be added to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\AuthForwardServerList, see https://support.microsoft.com/en-us/help/943280/prompt-for-credentials-when-you-access-webdav-based-fqdn-sites-in-wind).
Happy new year! It been a while, since I had time for this issue: Still not working - how ever, I followed urusha's debugging approach with curl. It turn's out, curl --negotiate works as a charm - so it looks like, it's a Windows Dav issue - how ever, I was not able to make it work even with the registry setting in place. I also deactivated basic auth in apache to avoid any username popup. Still no luck. It's weird, it works fine with firefox and IE, using methods mentioned above, but webdav is a hard one... I'd appreciate, if anyone has some dazzling idea, on how to make it work. thanks, regards, Felix
One more thing: i have set GssapiBasicAuth Off to avoid problems mentioned in the KB-Article concerning AuthForwardList - still the Credential Window pops up...
Issue resolved for me. I had misspelled the Servername in AuthForwardServerList and overseen to restart the WebClient Service or to reboot the client... So thanks to Urusha for pointing the KB-Article out. There is, BTW, a related KB Article (the original one, the one that introduces the new WebDAV Client) which is very useful, as it describes all registry parameters. https://docs.microsoft.com/en-us/iis/publish/using-webdav/using-the-webdav-redirector