Link to home
Create AccountLog in
Avatar of McKnife
McKnifeFlag for Germany

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?
ASKER CERTIFIED SOLUTION
Avatar of ste5an
ste5an
Flag of Germany image

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Avatar of McKnife

ASKER

Hi Ste5an.

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.
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.
Avatar of McKnife

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.
Avatar of McKnife

ASKER

Did you ever need that registry key?
Only for testing a development setup, switched to use a different tool afterwards.
Avatar of McKnife

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.
hmm, I would think authentication is not working as intended from the server-side. Something delegation related, SPN or so.
Avatar of McKnife

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 🙄
Avatar of McKnife

ASKER

ste5an, we still have no access to test systems at the partner's site, so this stalls. Will update when ready.
Avatar of McKnife

ASKER

They finally tried it and it works with the described AuthForwardServerList entries. Thanks!