WebDAV
WebDAV
I want to say that this is a feature people asked for but I don't use. That means that despite my testing, the likelihood of a bug is higher with this feature. Please let me know if you have any issues.
Additional Notes:
1. I have found most WebDAV issues are related to secure connections. So my suggestion is to first try a non-encrypted WebDAV connection if the server you are connecting to supports http WebDAV connections, then try a https WebDAV connection through Windows Explorer's Map Network Drive. If you can't get it to work through Explorer, it's not going to work though NDC.
2. Be aware that encrypted connections, regardless of whether they are WebDAV or SMB, will be slower than non-encrypted connections. So if you are on a LAN, say to a NAS in your house over cabling, you might consider which you value more, speed for large data transfers or encryption. The last time I tested my QNAP server throughput, which has dual 10Gbps ports connected to my development PC which has a 5Gbps ethernet port, I saw a pretty substantial throughput hit, on the order of 25%, when I require encryption despite the CPU's in both the server and my development PC supporting the Advanced Encryption Standard (AES) and New Instructions (AES-NI) in hardware.
3. If you are unsuccessful at getting NDC to make a WebDAv connection, I would suggest you try to make the connection manually using Net Use from a Command Line prompt. If you can't get that to work, then NDC will not work. The advantage of debugging with the Net Use command line is any error codes if the connection fails will come up in the command window, thus saving a lot of time over turning on NDC's logging and searching the log file. The Net Use syntax is
net use <DeviceName> <ServerPath> /persistent:no
in which case you will be prompted for the UserID and password, or
net use <DeviceName> <ServerPath> <Password> /user:<UserName> /persistent:no
Depending on the WebDAV server, "<UserName>" may need to be "<DomainName>\<UserName>".
My first comment on WebDAV is that if you are using it to encrypt network traffic on a local area network to a NAS, if you can, your life will be a lot easier using SMB 3.0, have SMB encryption turned on & the NAS set to require encryption. If you are trying to map a server that is out on the Internet, and want the communication to the drive encrypted, I personally use SFTP using WebDrive. I have just not found Windows implementation of WebDAV to be easy to work with and it seems to have a lot of issues even when used via Net Use from a command line.
NDC is using the Windows Networking (WNet) API which includes native Windows WebDAV client implementation, and if connecting to a WebDAV server, how NDC will behave will depend on how the WebDAV server is configured and how Windows is configured & whether Windows uses the WebDAV redirector, which it may automatically. The security & interface restrictions (e.g. whether a given Windows PC allows unsecure WebDAV via http or requires https) are determined by Windows defaults and/or Administrator imposed policies and how the server is configured. WebDAV connections via the WNet API can also be sensitive to whether your PC classifies the network it is on as a Home, Work or Public network, as well as how the various Windows security zones are configured (Control Panel → Internet Options → Security tab). Other settings (Control Panel → Internet Options → Advanced tab) can also affect how Windows treats a WebDAV connection. Clear as mud, eh? So the bottom line is there are a huge number of factors as to whether a WebDAV connection to a specific WebDAV server can be made.
The most common errors which can arise from these Windows or Administration configuration settings are Error 67, which means Windows does not recognize the server path, Error 1790 which usually means the security certificate of the server isn't recognized as valid by Windows, and Error 1244 which means Windows could not successfully authenticate the user with the server. You will only know if these errors occur by turning on logging & looking in the NDC log files, or debugging via the Net Use command as mentioned above. In all cases while these are issues with Windows, other 3rd party software may still be able to map the drive particularly if that software isn't using the any Windows WebDAV software but instead is using their own WebDAV routines. I will say upfront that I am not likely to change how NCD interfaces with Windows Networking, but hopefully NDC will do what you need it to. If you do not need NDC's network sensitive mapping and just need utilities for performing drive mapping with more options than Windows Explorer's "Map network drive" menu selection provides (such as FTP & SFTP support), the commercial products WebDrive, NetDrive or MountainDuck may do what you want.
WebDAV Caching
Since WebDAV relies on http or https, it can cache local copies of files. This can give WebDAV the appearance of being more responsive than SMB, CIFS or Netbios, but that is only because you are seeing it interact with it's cache and the server is being updated in the background. Users should be aware of this when disconnecting drives or shutting down their computer, as the cache may not get flushed and so the server may not be up-to-date. The cache can also be examined later or during the connection to the server, so even with an encrypted connection, the cache itself is not encrypted. Since I don't use WebDAV myself, I have not delved into the details of how Windows deals with this issue nor whether it represents a local security issue. Since I am using the Windows Networking (WNet) API which includes native Windows WebDAV client implementation, I am not directly utilizing the Windows WebDAV API and I do not know the details of how the Windows Networking (WNet) API interacts with it. This is not likely to change.
Secure Connections in WebDAV
For Windows to make a secure connection to a WebDAV server, Windows needs to consider the server's security certificate to be valid, just as it does when you go to a website via a https URL. When you surf the web, all of those websites have security certificates issued by a major trusted Certificate Authority (CA), similar to the security certificate I use to code sign NDC. So generally if you are using WebDAV to connect to a server with a real domain name and it supports WebDAV via https, then Windows should already recognize the validity of it's security certificate.
If however, you are trying to connect to something like a NAS in your home or small office using WebDAV via https, the NAS will almost certainly be using a self generated security certificate which Windows won't recognize. One way you can check this is to see if you can map the drive using WebDAV via https in Windows explorer directly using WIndows map network drive. If it won't work there, then it won't work in NDC. What you then need to do is manually download the NAS's security certificate and import it into Windows. At the bottom of this page are a few links to common NAS's with the instructions for downloading the security certificate and installing it in your Windows system. They basically have the same steps.
1. Configure the NAS for WebDAV with https. (As part of this, make sure your NAS supports secure WebDAV connections. Not all do.)
2. Export the NAS self generated security certificate. See your NAS manufacturer's website for instructions, or look on their forums.
3. Import the NAS self generated security certificate into every Windows PC that you want to connect using secure WebDAV. (See "Import a Security Certificate into Windows" below.)
Import a Security Certificate into Windows
In order to import the certificate you need to access it from the Microsoft Management Console (MMC).
- Open the MMC (Start > Run > MMC).
- Go to File > Add / Remove Snap In
- Double Click Certificates
- Select Computer Account > Next
- Select Local Computer > Finish
- Click OK to exit the Snap-In window.
- Click [>] next to Certificates > Personal > Certificates
- Right click on Certificates and select All Tasks > Import
- Click Next
- Click Browse
- Select the .cer, .crt, or .pfx you would like to import. Click Open.
- Click Next
- Select "Automatically select the certificate store based on the type of certificate".
- Click Next
- Click Finish & OK
Note: If your NAS updates its firmware or software, it's self-generated certificate may change too, so be prepared to have to re-import the NAS's certificate after a software/firmware update.
WebDAV Syntax
The specific syntax for making a WebDAV connection depends on how the WebDAV sever is configured. It is important to determine the port numbers used by the specific WebDAV server you are attempting to connect to. The default port number for unsecured (http) connections is usually 5000, with the default port number for secured connections is usually 5001.
For an unsecure http connection, a typical syntax to a NAS on the local network would be in the form:
http://xxx.xxx.xxx.xxx:5000/Folder/ where xxx.xxx.xxx.xxx is the IP address of the NAS on the local network, 5000 is the WebDAV server port number (e.g. Something like http://192.168.67.100:5000/Fred/ )
For an secure https connection, a typical syntax to a NAS on the local network would be in the form
https://xxx.xxx.xxx.xxx:5001/Folder/ where xxx.xxx.xxx.xxx is the IP address of the NAS on the local network, 5001 is the WebDAV server port number (e.g. Something like https://192.168.67.100:5001/Fred/ )
Additional Info on secure WebDAV for some common brands of NAS*:
QNAP (The Windows 7 is better at showing how to export the QNAP's self generated certificate.)
"Connect to WebDAV shared folders on QNAP NAS from Windows 7"
"Connect to WebDAV shared folders on QNAP NAS from Windows 10"
Connecting to WebDAV shared folders on a QNAP NAS in Windows 10 | QNAP (US)
Synology
"What to Know Before Using Windows' Map Network Drive"
* If you come across articles for configuring other brands, please feel free to email them to me for inclusion above.