These forums are read-only and considered to be an archive. Please use the new Community for future interaction and posts.

Using Digest Auth and Public links

Hi,

I'm trying out your FileVista product, but I have some issues that I need to work through (if possible)...

I read your comments of July 23, 2010 here:

http://www.gleamtech.com/support/forums/1577/active-directory-authentication

And I have setup the web.config file to use impersonation as per your instructions. I have also enabled Digest Auth. I am able to login using an administrator level AD account, but not as an normal user.

Also, when I tried to add a root folder that refers to a UNC path (i.e. \\server\share) and then click the "Load" button I receive the message "Access to path ... is denied". Is is possible to add UNC paths as root folders? If so, how?

Finally, while I can create a public link to a document in a root folder, IIS challenges for credentials because the website has anonymous auth disabled and only Digest Auth enabled. In other words, having Digest Auth enabled breaks anonymous access to public links.

Thanks!
Alan Osborne 2/7/2013 6:55 PM
Hi Alan,
Yes, UNC paths are supported.

Please add the below settings under <system.web> tag in web.config:

<authentication mode="Windows" />
<identity impersonate="true" /> 

Then you should be able to access a UNC path like \\server\share

Regarding public links, you can exclude them from Digest Auth by using a location setting under <configuration> tag like this:

<location path="public">
    <system.web>
        <authentication mode="None"/>
        <identity impersonate="false"/>
    </system.web>
    <system.webServer>
        <security>
            <authentication>
                <anonymousAuthentication enabled="true" />
                <digestAuthentication enabled="false" />
            </authentication>
        </security>
    </system.webServer>
</location>

Let me know.
Cem Alacayir 2/7/2013 7:29 PM
I have not heard back from Alan but for future reference, I will make a correction. The setting I posted above may cause a web.config error.

Here is what should be done to make AD authentication with Public Links to work correctly:

1. Enable "Anonymous Authentication" in IIS for FileVista folder. Don’t worry, browser’s own login dialog will still display and work after we apply the Web.config settings below.

2. Add these settings to Web.config:

  <system.web>
  
    <authentication mode="Windows" />
    <authorization>
      <deny users="?" />
    </authorization>
    <identity impersonate="true" />

  </system.web>

  <location path="public">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>      
  </location>


Now, IIS will challenge for credentials on only FileVista pages and not public links.
Note that when accessing the public links, FileVista will run under the context of application pool identity as there are no AD credentials available. That's why you should either 

1. Give Read permission on your root folders for this identity,
2. Or create a separate AD user (eg. Domain\FileVistaPublicUser), give Read permission for that user on root folders and impersonate that user by adding this additional setting:

    <identity impersonate="true" userName="Domain\FileVistaPublicUser" password="Password"/>

after these  lines:

   <location path="public">
      <system.web>
Cem Alacayir 8/12/2013 4:50 PM
Hi Cem,

Thank you for following up on these issues and being so transparent.  This is now working for me; however, it causes some trouble with password-protected public links which display a form that references some CSS via resource.ashx.  Chrome prompts for HTTP auth due to HTTP 401 being returned upon GETs to resource.ashx.  This URI is, obviously, not configured for pass-through like the /public URIs are.  Is it safe to allow unauthenticated access to resource.ashx?
Mike 9/16/2013 1:49 PM
Hi Mike,
You are correct about resource.ashx, I forgot about that. Yes it's safe to allow unauthenticated access to resource.ashx just like public links. You can do this by adding this additional location setting:

  <location path="resource.ashx">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>      
  </location>

Let me know if this fixes the problem with password-protected public links.
Cem Alacayir 9/16/2013 2:17 PM
Hi Cem,

There are two other URIs as well: publiclinkerror.aspx and WebResource.axd -- are these also safe to allow access to?

Thanks!
Mike 9/16/2013 3:02 PM
Yes, you can also add publiclinkerror.aspx.

WebResource.axd is ASP.NET related and maybe it is automatically allowed unauthenticated access by ASP.NET but I am not sure. If it's not allowed automatically then you can add it.

Sorry for having to add multiple location settings. Unfortunately you can't add multiple URIs to path property of one location element.
Hopefully in future versions we will support AD authentication without turning on IIS Authentication, i.e. you will use FileVista's login screen instead of browser's challenge/response dialog. Then these settings will not be required as your site will be always anonymous.
Cem Alacayir 9/16/2013 3:43 PM
Hi Cem,

Adding the three additional exclusions cleared up my issue.  I did have to add one for WebResource.axd -- I tried without it and still received 401s.

+1 on the feature for integrated AD support.  I'd like to see that feature in the future.

Thank you for your swift response!
Mike 9/16/2013 4:00 PM