asked on Webdav authentication works only via browser
Hi experts,
I hope that some of you have more experience with Webdav servers than me.
Please only answer when you know this very problem and have solved it.
Windows 10 users of domain A want to access a webdav server of domain B. In the browser this works, but of course they can only read the files in the browser. Thus, for write access, they want to use Webdav in Windows Explorer and create a desktop shortcut for this purpose with the target
\\webdavserver.domain\Folder or \\webdavserver.domain@SSL\Folder - that makes no difference and everything works so far.
Problem:
After a reboot, Windows asks for authentication when using that shortcut , which fails despite correct input!
But if he uses a browser for this, it asks for authentication as well, which succeeds AND THEN the desktop shortcut is also usable!
This is reproducible at any time.
If I test the whole thing with a user from domain B (the domain of the Webdav server), this phenomenon does not occur!
What needs to be done to avoid using the browser?
I hope that some of you have more experience with Webdav servers than me.
Please only answer when you know this very problem and have solved it.
Windows 10 users of domain A want to access a webdav server of domain B. In the browser this works, but of course they can only read the files in the browser. Thus, for write access, they want to use Webdav in Windows Explorer and create a desktop shortcut for this purpose with the target
\\webdavserver.domain\Folder or \\webdavserver.domain@SSL\Folder - that makes no difference and everything works so far.
Problem:
After a reboot, Windows asks for authentication when using that shortcut , which fails despite correct input!
But if he uses a browser for this, it asks for authentication as well, which succeeds AND THEN the desktop shortcut is also usable!
This is reproducible at any time.
If I test the whole thing with a user from domain B (the domain of the Webdav server), this phenomenon does not occur!
What needs to be done to avoid using the browser?
Windows OS
Last Comment
McKnife
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
After a reboot, check the stored credentials (cmdkey.exe /list). Remove existing WebDAV credentials. In some scenarios I have seen credentials set by an application with different permissions, so that during normal user operations the credentials could no longer be changed.
And what kind of authentication (Windows integrated or separate credentials)?
Any proxies involved? This can include AV/security software acting on user agent information/detection failing.
And what kind of authentication (Windows integrated or separate credentials)?
Any proxies involved? This can include AV/security software acting on user agent information/detection failing.
ASKER
Before we dig into those: do you know that problem, have you had it, was it solved by that registry entry?
The things I had with apache and WebDav at the other end:
- AV proxies filtering for "normal" HTTP.
- Untrusted zones.
- Not having the correct authentication modules activated.
- AV proxies filtering for "normal" HTTP.
- Untrusted zones.
- Not having the correct authentication modules activated.
ASKER
Did you ever need that registry key?
Only for testing a development setup, switched to use a different tool afterwards.
ASKER
Ok, regarding your questions:
cmdkey /list is empty for that user
"And what kind of authentication (Windows integrated or separate credentials)?" - windows integrated
"Any proxies involved?" - none.
cmdkey /list is empty for that user
"And what kind of authentication (Windows integrated or separate credentials)?" - windows integrated
"Any proxies involved?" - none.
hmm, I would think authentication is not working as intended from the server-side. Something delegation related, SPN or so.
ASKER
Oh, this is bad... the users we work with may not write to that registry branch and their admins (Bundeswehr-IT) are usually very, very hard to work with. This might take weeks to test 🙄
ASKER
ste5an, we still have no access to test systems at the partner's site, so this stalls. Will update when ready.
ASKER
They finally tried it and it works with the described AuthForwardServerList entries. Thanks!
Hm, "AuthForwardServerList" rings a bell here, so I am afraid this was already tried before, but in the afternoon we'll have time to retry this.