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:
- 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 credentials there.
When creating a root folder, leave Connect As setting at Application User (which means current IIS Application Pool User).
Note that you probably will not be able to access the root folder if you are logged in as the default “admin” account as it’s not a Windows/AD user. You can make one (or more) of your imported Windows/AD users have administrators right by simply adding them to the Administrators group in FileVista.
- You can turn off Anonymous Authentication and enable Windows Authentication in IIS Manager for FileVista webapp or in FileVista\Web.config (IIS Manager actually also modifies Web.config):
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="false" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer> Usually the yellow highlighted line is sufficient as by default Windows Authentication may be already enabled in your IIS.
Note that you also need to ensure Windows Authentication role service is enabled on your server, for this to work. FileVista installer already enables this role service on your machine.
For details please see here:
From that point on, your users will not see FileVista’s login page login.aspx so it will be SSO. Instead they will see browser’s challenge response dialog or they will not see anything and logon automatically if your environment is configured for Integrated Authentication.
FileVista automatically detects the logged on user from IIS and match it with the same user (exact name) in its database.
When creating 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 can not test the result on "Edit Root Folder" window if your administrator user is an application user such as the default created admin.
That Connect As option would work on that window if the administrator user is also in format Domain\User.
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