Overview
This article will describe the permission logic of the network folder connector (NFC) when using Personal authentication type. There are few different use cases relating to end-user permissions and Indexer User permissions that are not so clear. This article will shed light on different scenarios.
Solution
First, note that this article only considers a situation where the NFC is configured to use Personal authentication, which is the most common scenario.
Second, there is a difference, how the permissions are checked based on how we access the content: via browsing or via quick search. When we are using quick search, the system uses indexed permission data, whereas when browsing or when using views, the system uses actual permission data from M-Files database (NACL - Named Access Control List) and the object itself (Windows permissions). That said, since the index is not necessarily inclusive e.g. because of re-indexing, it might give different results than other access methods.
Third, when using Personal authentication mode, every end-user must log in separately to the external repository. This means that they must have credentials that match Windows permissions in the network repository. So, the end-user first login to the M-Files client / vault and then they login to the external repository. That said, the end-user might have logged in with two different identities to the vault and to the NFC. This is good to keep in mind when discussing NACL vs non-NACL permission schemes in the following chapters.
Last, the permission logic will work identically with the end-users and with the Indexer User when it is crawling the repository.
Permission scheme when Not using NACL
In this case, the system only uses network folder object's Windows permissions. Objects M-Files permissions cannot be changed. When accessing the object by browsing or selecting the object, it uses the permissions of the user that has been logged in to the external repository and not the user that has been logged in to the vault.
In quick search, where the index is used, this scenario is a bit different. By default, indexing maps M-Files user groups All Internal Users and All Internal and External Users to object's Windows permission groups Authenticated Users and Everyone. When using quick search, the user that has been logged into the vault is used.
These two lead to the situation where the items are shown in the search results, even the user would not have actual permission to the object. When clicking an object, it will show a Not Found error about accessing it.
To mitigate the situation above, you can use the setting Verify User Access to Objects from External Repository in Searches (External repository configuration > General Settings > Search Indexing).
Using NACL
The logic with NACL is that when accessing an object in NFC, we first check the NACL permission set in NFC configuration against the credential that has been used when logging in to the vault. Still, we must remember that it is mandatory to also login to the external repository with credentials that will grant access there. That said, by the time we access the repository, we have done both logins. So, after the successful NACL check, the system still checks the access between the object's Windows permissions and the user that has been used when logging to the external repository.
Indexer User
As described before, Indexer User follows the same permission logic as the normal user. That is why it is recommended to give Indexer User the widest permission possible on Windows side and naturally include it with NACL if it has been set to the connector. If the Indexer User cannot access some document in the repository, it cannot index it, and the document cannot be found in the quick search.
