Out of the box, FileVista has its own database for users that can login and use the application. These users are created/managed in the administration panel of FileVista.
However, you can allow existing Windows or Active Directory users/accounts on your machine or AD domain, to login and use the application with their existing credentials. You need to import those users into FileVista so that you can manage their root folder access and permissions. FileVista needs to create the same users in its database so that they can login.
This is usually done once when you setup FileVista and maybe when you have new users in Windows or AD. This needs to be done manually (in administration page on “Import Users” dialog) as there is no auto synchronization. However, when you change a password in the external account, it will still work in FileVista.
Only user name and some other properties for display purposes are saved in FileVista database. So you would need to reimport a user if the user name is changed.
As of current version, Windows or AD groups are not imported but you can create groups in FileVista and add imported users to them.
First log in to FileVista as the administrator (usually admin) and then follow the below steps:
- Go to the administation panel:
- On the Users section, click “Import Users” action which is accessible when you right click “Users” or which is accesible as a link below users count:
- On the opened "Import Users" dialog, fill in the necessary connection info:
For Active Directory users, select "Active Directory Domain Services (AD DS)" and enter your AD domain.
For Windows users, select "Machine (SAM store of a computer)" and enter your machine name.
Then press "Find All" button.
- The found users will be populated below. Select all or specific users from the list that you want to import:
Then press "Import Selected Users" button.
- The users now will be imported and saved to the FileVista database. You can see the imported users in "Users" section just like regular users and manage them like adding them to groups or root folders.
Note that at the end of day FileVista will always depend on underlying NTFS permissions. If the users do not have permissions they will get an error message like “Access Denied”.
The permissions of FileVista are a layer at top of NTFS permissions so it’s additional.
The UI knows about FileVista permissions and for example shows/hides menu items and toolbar buttons according to these permissions.
So permissions in FileVista, are an extra layer over Windows Permissions.
So, when you import a Windows/AD user to FileVista, you should add it to a Root Folder with some FileVista permissions.
However, if the Windows/AD user does not have Windows Permissions, FileVista will still show you “Access to path is denied” errors (in a dialog box when accessing the root folder).
When you import a Windows/AD user and login to FileVista with that, FileVista will impersonate that user when accessing the root folders.
When creating a root folder, it’s also possible to put a hardcoded credential if you don’t want to impersonate the current logged on Windows/AD user but use a common credential to access network paths.
Once you import the users, there are 2 ways to allow imported users to login:
- First way: Out of the box, imported users will be able to login on login.aspx page by entering their credentials. They will be impersonated automatically when required (e.g. when accessing a root folder pointing to a UNC share - network path). You don’t need to turn on Windows Authentication in IIS or Web.config. You should just keep it at Anonymous Authentication so that visitors can see login.aspx page directly and enter their Windows/AD credentials there.
When creating or editing a root folder, leave Connect As setting at Application user (which means current IIS Application Pool User):
Note that you should give Modify permission for Authenticated Users group on your root folder paths so that imported Windows/AD users can access the root folders.
The Authenticated Users group includes all users whose identities were authenticated when they logged on. It includes local user accounts as well as all domain user accounts from trusted domains but it excludes the Guest account even if that account has a password.
In Command Prompt (Run As Administrator):
icacls "My_RootFolder_Path" /grant "Authenticated Users":(OI)(CI)(M)
Note that you may not be able to test connection result on "Edit Root Folder" window if your administrator user is an application user such as the default created admin.
So in additition, you can give Modify permission for IIS APPPOOL\FileVista user (or IIS_IUSRS group) on your root folder paths so regular application users (not imported from Windows/AD) can access the root folders.
In Command Prompt (Run As Administrator):
icacls "My_RootFolder_Path" /grant "IIS APPPOOL\FileVista":(OI)(CI)(M)
- Second way: You can turn off Anonymous Authentication and enable Windows Authentication in IIS Manager for FileVista webapp:
Note that after this change, you probably will not be able to access FileVista administration panel if your only administrator user is an application user such as the default created admin.
So before this change, ensure you make one (or more) of your imported Windows/AD users have administrators right by simply adding them to the Administrators group in FileVista,
so that you can continue to access FileVista administration panel with that user.
From that point on, your users will not see FileVista’s login page login.aspx, instead they will logon automatically if your environment is configured for Integrated Authentication; i.e. it will be SSO (single sign-on) or they will see browser’s challenge response (enter credentials) dialog.
FileVista automatically detects the logged on user from IIS and matches it with the same user (exact name) in its database.
Note that after you turn on Windows Authentication (and turn off Anonymous Authentication), if you repeatedly see browser’s credentials/logon dialog and then see HTTP 401.1 error, you are probably accessing the site via custom hostname or domain (not localhost or machinename).
This problem comes up on Windows Servers and lately also on Windows 10 by a policy called Loopback Protection that is enabled by default. Loopback Protection disables authenticating against local Windows accounts through HTTP and a Web browser. Reference.
So you can disable this check to fix the problem, in Powershell (Run As Administrator):
New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword
When creating or editing a root folder, you should use Authenticated User (Windows) for Connect As option, which means you are using currently authenticated user in IIS and not the default IIS Application Pool User,
then this root folder should be accessible by the externally logged on Windows users.:
Note that you should give Modify permission for Authenticated Users group on your root folder paths so that imported Windows/AD users can access the root folders.
The Authenticated Users group includes all users whose identities were authenticated when they logged on. It includes local user accounts as well as all domain user accounts from trusted domains but it excludes the Guest account even if that account has a password.
In Command Prompt (Run As Administrator):
icacls "My_RootFolder_Path" /grant "Authenticated Users":(OI)(CI)(M)
Normally Application Pool Identity named IIS APPPOOL\FileVista is given Modify permission to FileVista\App_Data (and inherited by its subfolders) by FileVista Installer.But when you are using currently authenticated user in IIS and not the default IIS Application Pool User, that authenticated user should have write access (for example for DocumentViewer to work correctly, which stores DocumentCache under that folder).
In Command Prompt (Run As Administrator):
icacls "C:\inetpub\wwwroot\FileVista\App_Data" /grant "Authenticated Users":(OI)(CI)(M)
If the permission changes are not recognized in FileVista (e.g. you still get an access denied error), you may need to restart your web server, e.g. in Command Prompt (Run As Administrator):
iisreset
Troubleshooting access problems when using IIS Windows Authentication (second way to login):
The below information will also be useful if you experience problems when accessing your created root folder with UNC paths.
There are 2 impersonation levels Impersonation and Delegation and Windows does not allow accessing files in IIS if the level is not Delegation.
So with IIS Windows Authentication, impersonation is not enough network resources so you also need delegation:
Impersonation only allows you to access resources local to the web server as the browser user. If you want that user's identity to travel across the then you need delegation.
The reason it works when you provide user name and password is that when Windows has the password, it can access network resources.
However when there is no password, IIS creates a user token which can only access local resources.
IIS only creates a delegation user token when you use Basic Authentication because then it knows your password (passed in clear text).
So possibly you will see that you can access the path when you enable Basic Authentication. However this is not desirable because IIS would ask your credentials
every time you access the site (no automatic logon I guess). So we should focus on enabling delegation for Windows Authentication (your current setting)
To enable delegation in IIS, you need to enable Negotiate:Kerberos provider:
Under "Windows Authentication" right click and select "Providers". Add "Negotiate:Kerberos" and move it to the top
Note that configuring delegation seems to be a pain. So there are some other steps that may be required.
However we should first start by doing the above.
The other steps include
- Configuring the user's account to allow delegation in AD
- Setting up SPNs for users
One user solved the problem like this:
Eventually we found out what the problem was with impersonation level.
When the client negotiated with the server the authentication, a Kerberos ticket was requested but, as we used an alias for accessing the intranet, the ticket was not delivered, so the authentication was NTLM, not Kerberos.
The impersonation level was “Impersonate” not “delegate” due to NTLM cannot impersonate at delegation level (required for accessing to network resources). The result was the error denying the access.
To solve it, we had to say that the address (intranet.contoso.com) is a principal one at the web server (web001).
So, in the end, solving it was as easy as typing, at the web server:
Setspn -A HTTP/intranet.contoso.com web001
References: