2

(Intranet) I'm trying to setup a website which will serve up files from a network share (\\servername\folder\file). Only users who have access to the network folder through active directory groups should be able to download the files through the website.

This is the setup I have now: enter image description here

Site:

AppPool: DefaultAppPool

Authentication: Windows Authentication

Subsite:

AppPool: DefaultAppPool

Authentication: Windows Authentication

Virtual Directory:

Physical Path: \\servername\Folder

Physical Path Credentials: Application user (pass-through authentication)

Logon Type: ClearText

enter image description here

When I try to navigate to the site with a link like this: http://webserver/subsite/virtualdirectory/folder/file.xls, I get repeatedly prompted for credentials even though the credentials I enter should be valid. In the Virtual Directory setup, if I change it from pass-through to "specific user", it works but that bypasses the security of the active directory groups.

Am I configuring something incorrectly here?

Note, I already looked at Pass-through authentication not working. IIS 7

Kieran Quinn
  • 1,085
  • 2
  • 22
  • 49

2 Answers2

3

There are two separate authentications going on:

  1. The user is authenticating to your website.
  2. IIS is authenticating to the file share.

Those are completely separate operations.

I believe you're running into the double hop problem: You can use the user's credentials to authenticate on your server, but you cannot (by default) send those credentials to another server. To enable that, you might be able to setup Kerberos delegation in Active Directory, which can get complicated.

If setting up delegation is not an option, then you will have to find another way to serve those files to the user.

I agree this is a difficult problem to solve if you really want the share permissions of the share to dictate who can download the file through the site. One option is a direct link to the share (if the user's computer has network access to the server):

<a href="file://servername/Folder/somefile.txt">Download</a>

That works in IE, but not in Chrome because Chrome specifically disables file:// links (unless you enable it via plugin).

Another, more complicated option is to pipe the file through your application. Your application can access the file and enumerate the share permissions to see if the user has access, then allow the download if so. But NTFS permissions are notoriously difficult to wade through.

Or just ignore the share permissions and find some other way to determine whether the person should have access (one specific security group, for example) instead of relying on the share permissions.

Gabriel Luci
  • 38,328
  • 4
  • 55
  • 84
  • Thanks for this information. Confirms a lot of what I suspected. We are using specific groups for access, the problem is that I had planned to use WebDav to allow saving updates back to the original file location rather than downloading a local copy. – Kieran Quinn Sep 10 '19 at 15:00
  • What I don't understand though, is how I get the desired outcome if I just use a regular "Shared" folder for the virtual directory rather than a "Network Drive". I can set it up for "pass-through" and users who are not in the group I specify cannot access the file, and those who are in the group can access it... – Kieran Quinn Sep 10 '19 at 15:02
  • I'm not sure what you mean by a "regular shared folder" – Gabriel Luci Sep 10 '19 at 15:06
  • If I right click on a folder and share it... those types of folders seem to act differently, everything works fine – Kieran Quinn Sep 10 '19 at 15:10
  • If you share a drive in the way you just described, then it can be accessed by `\\servername\share`. A "network drive" is usually just a shared folder that is mapped to a drive letter. – Gabriel Luci Sep 10 '19 at 15:15
  • The difference I can see between the two, is that the "network drive" folders don't have a "Share" tab in the properties. Maybe its an internal policy. The permissions for accessing the folders are governed by the "Security" tab, rather than typical "Share" permissions – Kieran Quinn Sep 10 '19 at 15:19
  • Since a "network drive" is a folder from a different server mapped to a drive letter on the current computer, then no, you won't see a "Share" tab since you cannot modify those settings from that location. If you login to the server where that folder is shared, find the folder, and right-click, you will see the "Share" tab there. – Gabriel Luci Sep 10 '19 at 15:22
  • Both permissions apply: The share configuration has permissions, but also the NTFS permissions, and both are enforced. Both have to allow the person access for them to be able to get in. Personally, I usually allow 'Everyone' full access in the share permissions, and just leave the NTFS permission to actually restrict access. – Gabriel Luci Sep 10 '19 at 15:23
  • `that's what "pass-through" means - it "passes through" the app pool credentials` this is incorrect – Kelly Elton Sep 29 '20 at 23:01
  • @KellyElton Feel free to elaborate. – Gabriel Luci Sep 30 '20 at 14:09
  • @GabrielLuci It passes through the credentials of the user that's visiting the site. See https://stackoverflow.com/a/5307330/222054 and https://forums.iis.net/t/1177252.aspx and https://serverfault.com/a/38290/95590 . This means that most of the assertions in this answer are incorrect. – Kelly Elton Oct 08 '20 at 19:56
  • 1
    @KellyElton I updated my answer to remove that portion, but the rest of it is still valid. The problem is likely the double-hop problem. If the files being shared were on the same server as the website, it would probably work just fine. – Gabriel Luci Oct 09 '20 at 12:51
1

I'm afraid specify user is the only way to achieve this.

I built a share folder like \\server\shared. When I monitor the NTLM authentication, I also notice that if I specify the user to Pass-through, then IIS will try to access Path with Upper case \\SERVER\SHARED and get access denied.

However, if I specify user for the authentication, NTLM works fine and the worker process will not do the same operation. I also notice the user identity for working and non-working operation are the same.

I tried it in both workstation and domain environment. However, result for NTLM and Kerberos are the same. So I think you may need to accept the specific user as a workaround.

Jokies Ding
  • 3,374
  • 1
  • 5
  • 10
  • Specific user isn't a workaround though since it bypasses the security implementation of the AD Group – Kieran Quinn Sep 10 '19 at 07:56
  • I have very same experience. When set user for my virtual directory in IIS directly, it works. If I use pass-through authentication, access denied. – KUTlime Feb 24 '21 at 08:32