Settings for Windows Auth

Having a problem getting the current version working with Active Directory accounts.

I have changed the web.config file:

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

The domain user accounts are setup as FileVista users using syntax DOMAIN\username
I'm using that same syntax to login to FileVista
I have disabled anonymous access to the  FileVista virtual directory
The user accounts have read access to the FileVista virtual directory and modify to their Root Folders in FileVista
I have ASP.net impersonation and Basic Auth enabled for the FileVista virtual directory (have also tried with Windows Auth enabled).

This is running on Server 2012/IIS 8

Login works fine with the domain administrator account, so it must be a permissions issue somewhere, I just can't find it.

The other accounts just repeatedly prompt for credentials (at the browser level, NOT the FileVista login screen), then errors out.

I've monitored with Process Explorer and don't see any "Access Denied" entries other than some related to the FileVista local user and the FileVista database.

Any ideas?

Hello? Cem, really need to get this install working ASAP. Any ideas?

Hi Loren,
Did you use IE10 (or newer) when testing because it seems IE10 performs Intranet zone detection differently than IE6/7/8/9.

Please refer to this article:
IE 10 Prompting for credentials - Windows Authentication

Let me know if this does not solve your problem.

By the way regarding the different behavior between domain administrator account and other accounts:
With Windows Integrated authentication, the user's password is not actually sent from the client to IIS.  Because IIS does not have the user's password, IIS resources will not be able to turn around and authenticate the user to another network resource.  When you are logged on locally to the server to test, now the machine does have the user's password (you're physically logged on to this machine) and you'll then see different behavior with regard to network resources, 

I'm testing from outside the network. Both Firefox and IE prompt for credentials (not the FileVista login).

The Domain Admin account works in IE and Firefox. With any other account, I just repeated browser password prompts.

If I enable ONLY basic auth on the File Vista subfolder in IIS, I can get the application to load, but it then says access is denied to the root (that is defined for the user). This affects the Domain Admin and other accounts. The accounts do have NTFS/AD permissions to access the path defined for their root folders.

At this point, it would be helpful to know which auth types should be enabled for AD/Windows integrations mode. There are five:

1. Anonymous.
2. ASP.Net Impersonation
3. Basic
4. Forms
5. Windows

As you are able to login with "Basic Authentication", now enable "ASP.NET Impersonation" so that you don't get access denied" error to the root folder. Enabling "ASP.NET Impersonation" will actually add this line to web.config:

<identity impersonate="true" />

By the way I see in your first post that you added a line like this before:

<identity impersonate="true" password="" userName="" />

You should better not include password="" userName="" maybe this caused the problem.

Re-enabling ASP.Net impersonation allows the domain admin to login, but other users still just get repeated password prompts. I tried it from inside the network so it would show the extended error info, rather than the generic IIS error page. It's this:

HTTP Error 401.1 - Unauthorized
You do not have permission to view this directory or page using the credentials that you supplied.Most likely causes:
The username supplied to IIS is invalid. 
The password supplied to IIS was not typed correctly. 
Incorrect credentials were cached by the browser. 
IIS could not verify the identity of the username and password provided. 
The resource is configured for Anonymous authentication, but the configured anonymous account either has an invalid password or was disabled. 
The server is configured to deny login privileges to the authenticating user or the group in which the user is a member. 
Invalid Kerberos configuration may be the cause if all of the following are true: 
Integrated authentication was used. 
the application pool identity is a custom account. 
the server is a member of a domain. 

I've verified that the account has read access to the FileVista virtual directory, it's parent (the root of the site) and the path to the user's FileVista root. Do these accounts need more than read access somewhere in the FileVista directory?

Thanks for the help today!

I think I found it. Since we're using impersonation, the end user accounts seem to need write permission to the <filevistaroot>\App_Data\Database folder. Once I changed it from read to modify the non-admin users can login, upload, delete, etc.

I'll make a final report once they've been using it a few days.

Glad to know you found the cause.
Strange, I would have thought that you would get an instant ASP.NET error message instead of repeated prompts when the impersonated user does not have Modify permission on the App_Data folder

IE would prompt for the credentials three times, then show the IIS error page. The generic page if logged in externally and the detailed page if logged in internally. Firefox would just keep prompting for credentials over and over and over...