1
Root Folder Access via WAP/ADFS for External Users
Question asked by Guy - 9/15/2015 at 10:59 PM
Answered
Hi, I've installed the FileVista demo on a virginal, internal IIS server on 2012 R2 and set up our WAP/ADFS reverse proxy for external user access. All that has been configured on the server so far is SSL and a redirect from the root to the FileVista subfolder. Authentication has been left as is for now with Anonymous at the root and Anonymous & WIA at FileVista.
 
External users browsing to filevista_ourdomain_nz get directed to an ADFS prompt which requires a SPN UPN username and password. They are then automatically logged in to FileVista as long as the FileVista accounts are set up in the form Domain\Username. Cool.
(Accounts are set up in FileVista using the Import Users from AD feature. If they are set up in SPN UPN form the external user will get the error: "Login failed for Windows User Domain\Username. There is no FileVista user defined with the same name.")
 
The problem is that these external users are unable to browse the root folders that have been set up, while internal users can. The root folders are set up with UNC paths to shares on other servers with the Connect As option set to Application User. I've tried the other Connect As options which produce the following for external users:
- Application user, Authenticated User Windows, Authenticated User Claims - 161 Specified Path Invalid error
- Specific user - works but then everyone has that particular user's permissions to the root folders - not really an option.
 
Is this the same impersonation/delegation problem that Slodex has run into?

2 Replies

Reply to Thread
0
Cem Alacayir Replied
Employee Post Marked As Answer
If you are using "Windows Authentication" mode, i.e. you don't see FileVista login page and logged in automatically according to the current logged on Windows user, then you should use Authenticated User (Windows) for Connect As option. 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.
 
Otherwise, it should be a SPN issue which means IIS uses "impersonation" and not "delegation" token for some reason.
0
Guy Replied
Hi Cem,
Sorry - in the original post I meant UPN logins not SPN logins at the ADFS prompt. I've edited it.
The setup and testing is all being done with AD accounts. The only FileVista account is the original admin which I'm not using.
 
The internal users are logging on with your login page using the Domain\Username format with their AD credentials. They have a corresponding FileVista account with FileVista group permissions to the root folders, and AD permissions on the associated server shares.
 
The external users are logging in with WAP/ADFS using the UPN format and their AD credentials. They are automatically logged in to FileVista and don't see your login page. I didn't do anything to set this up, it just happens and was a pleasant surprise when I first tested because I didn't realise FileVista was claims aware.
 
Setting ConnectAs=Authenticated User (Windows) on the root folders causes internal users to get the "161 Specified Path Invalid" error, as well as the external users. If I'm logged on internally as a Domain Admin and set ConnectAs=Authenticated User (Windows) I notice that CurrentUser=(not found). Shouldn't the domain users name appear here?
 

Reply to Thread