IIS 7 and Above
WebDAV to access a file share from the Internet
Last post Dec 05, 2017 06:20 AM by email@example.com
Feb 05, 2017 06:24 PM|krisvg|LINK
Can anyone please confirm whether the following is possible:
Windows 7 or later client, out on the Internet, not domain joined.
Windows 2012R2 or 2016 server with IIS as WebDAV server (member of a domain)
Windows 2012R2 or 2016 file server (different from the IIS server, member of the same domain)
The aim is for a user with an account in the domain to use his/her Windows machine (i.e. non-domain joined machine) to access the WebDAV server to get to a fileshare on the file server. The user needs to use his/her credentials so that unauthorized access to
parts of the file server is avoided.
Just to be sure:
Authenticating from a non-domain-joined machines means "Basic Authentication" is a must, right?
The real question: can you have someone who authenticated using "Basic Authentication" being redirected to a file server using his/her credentials (i.e. NOT the credentials of the application pool, that would make distinguishing different users impossible
for the file server)?
Feb 06, 2017 09:39 AM|Yuk Ding|LINK
The basic authentication also need the machines in the same domain. So I think if you need to use basic authentication out of domain, you could try to enable form authentication with Active directory.
Feb 06, 2017 05:12 PM|krisvg|LINK
Hello Yuk Ding,
Thanks for the reply. Small question though: what makes you think that "Basic Authentication" requires a domain-joined (client) machine?
Feb 09, 2017 09:05 AM|Yuk Ding|LINK
Apologize for my misunderstanding of basic authentication. The basic authentication doesn't need server and client in the same domain.
Feb 18, 2017 10:04 AM|krisvg|LINK
Here's my conclusion: WebDAV is unsuitable for offering file access to users. At best you might subdivide your users in a relatively limited number of subcategories, say 10, so that you can offer file access using 10 different WebDAV sites. This can hardly
be called a manageable solution.
I'll try DirectAccess in combination with WindowsToGo.
Feb 22, 2017 08:12 AM|Yuk Ding|LINK
Thanks for sharing your experience.
Mar 12, 2017 07:08 PM|krisvg|LINK
I have to admit: I was mistaking when I wrote "WebDAV is unsuitable for offering file access to users".
The trick is that you shouldn't configure anything! (Ok, almost nothing)
I did the following:
* I set up an IIS site (WebDAV enabled on the server)
* Installed a server certificate and bound https to the site (on a custom port, but that's another story)
* set the site authorization rules: allow all users (think that's the default setting)
* set the WebDAV authorizing rule: Authenticated Users Read Write and Source access
* Created a virtual directory pointing to a DFS namespace
That's it: A domain user can now map a network drive to the url that was bound to the site (net use z: https://FileAccess.MyDomain.Wherever) and browse the folders that are referred to by the DFS links (with file explorer, not a webbrowser of course).
Note 1: I'm using three servers for this:
Domain controller for authentication (and hosts DFS roots)
Webserver: for access from outside the organization via WebDAV
File Server: hosting the folders that are referred to by DFS
Note 2: I didn't set any specific WebDAV authorizing rules on the virtual directorie(s)
Note 3: This also works for "other" client OSes (in casu a Mac running OS X-something)
I never thought this could work because of the infamous "second hop problem", but since authentication is basic, the username and password are passed to the webserver which reuses them to access resources on the file server. You only have a second hop problem
if you require robust and reliable authentication (i.e. kerberos), in my environment basic authentication "protected" by https is acceptable.
Users are limited in their possibilities by the NTFS permissions on the file server, exactly as they are when logging on to a machine on premises.
Hope this is useful for someone,
Nov 26, 2017 12:28 PMfirstname.lastname@example.org|LINK
I'm a bit noob when it comes to IIS related configuration and my understanding is very poor due to the lack of experience in this area - please bear with me. ;(
I basically followed a few blogs to the best of my knowledge but it seems that I couldn't access my file share when I click on browse "URL on "Ip address:80 (HTTP). when i click on it, it will just loop in the username and password prompt whenever I enter
I also have the following questions:
Looking forward to your response.
Nov 26, 2017 08:28 PM|krisvg|LINK
Unfortunately I'm not a website specialist either (I do systems management).
To answer your question 1: I don't think there is a reason to separate the webserver and the file server. I tend to separate roles whenever resources and licences allow me so that removing a service doesn't interfere too much with other services when required.
To answer question 2: I suppose you mean "domain member" or "workgroup". I prefer domain joined machines because they make authentication a lot easier. However, if you have the webserver and file server on the same machine and you use accounts of that machine
to authenticate then you should be OK (accounts will be something like MyServer\MyAccount instead of MyDomain\MyAccount).
To answer question 3: Permissions will be limited by every mechanism separately (web access, share folder access and NTFS permissions). To make it easy for myself I usually give liberal access rights on share permissions ("Change" right, NOT "Full Control")
and then restrict further as necessary with the NTFS permissions.
Hope this helps a little.
Nov 27, 2017 07:29 AMemail@example.com|LINK
Thanks a lot for your response.
I'm about to set it up right now.
we'll let you know how it goes.
Nov 28, 2017 11:29 AMfirstname.lastname@example.org|LINK
done with the setup by following your hi-level steps. I also used SSL and bound the site withit.
so far it works with the following concerns though...
Nov 28, 2017 08:11 PM|krisvg|LINK
Like I said: I'm no web-specialist so I'm afraid I won't be able to be of much assistance.
For your first question: I've never experienced this but if you say at what size you start experiencing problems I can do a small test.
For your second question: I can't help you here. I instructed my users to map the network drive whenever they need access to the file share and they disconnect whenever they no longer need it. I work in a (very) small environment for the moment so this doesn't
pose any problems.
For your third question: I can't tel for sure but it seems highly unlikely that this could work. How are you going to link an Azure credential to an account of your server that's not even domain joined? On the other hand, I don't have any experience with
multi factor authentication in Azure so I hope someone else will correct me and give an elaborate explanation of how it's done :)
Nov 29, 2017 08:13 AMemail@example.com|LINK
The size of the folder is 90 GB in total and I am still trying to find out which among the file is causing this error in the end.
all the other folders seems to work fine.
When you say disconnect, how would you do that? I can't seem to find a disconnect option on the mapped network drive.
Nov 30, 2017 05:55 PM|krisvg|LINK
https://support.microsoft.com/en-us/help/900900/folder-copy-error-message-when-downloading-a-file-that-is-larger-than the default file size limit is 50MB. The article describes how you can change that.
Concerning the disconnect problem: I simply right-click and select "disconnect". If for some obscure reason you don't have that option you can try a "net use x: /d" command where x: is the drive letter you used when mapping the drive to your WebDAV server.
Hope you succeed in solving your problems.
Dec 03, 2017 08:57 AMfirstname.lastname@example.org|LINK
Thanks a lot for you quick response as usual. Sorry I wasn't able to acknowledge your email as it was a holiday here in UAE for the past 3 days.
anyway, I will give that link a shot! also the reason why I didn't see the "Disconnect Button" is because I mapped WebDAV using map a "Network Location" option instead of mapping it as a Network Drive. :P
Dec 05, 2017 06:20 AMemail@example.com|LINK
I just wanted to thank you for helping by clearing some of the things out.
anyway, I just want to update you that the issue of accessing a folder with large files was gone.
To make things short, I simply pointed the physical path on my WebDAV settings to the file server hosted in Azure.
note: I have DFS-R configured between an on-premise file server and Azure VM fileserver with site-to-site VPN in between.
I think the VPN in between and some NSG Rules were causing the time-out issue of that certain folder which I was talking about.