Debug document level security (DLS)
Managed by | Updated .
The fileshare and trim collections use early binding security. This means that the security information is indexed at the time of update. If security permissions on a document are updated between when the last successful update occurred and when a user runs a search you can get results returned in search results that a user does not have (current) permission to access.
Things to check:
- Is security enabled in the collection.cfg of the collection being queried, and for component collections of a meta collection?
- Is the user able to access the document directly (ie. without Funnelback)?
- Is user key caching configured? If so, have the user's group memberships changed recently?
- Have the file permissions changed since the repository was last updated?
- Have document lock strings been gathered and indexed?
- Are user keys being correctly fetched when the query is run?
- Is single sign on working? Does the user get challenged for a password when accessing Funnelback (using IE). If so this might be an indicator that SSO is not working correctly.
- Is impersonation working (does the query run as the expected user)?
In this case a user will be able to see the item in the search results but should be denied access when clicking on the search result (as the underlying system – eg TRIM or NTFS, is responsible for enforcing the actual security on the document).
Accessing the document directly
NTFS Fileshare
If you find a user is getting access to a document that they shouldn’t have access to:
- Get the source URL from Funnelback (rerun the query and append &xml to the end of the query string, or view the data model
- Find the smb:// url and convert it to the UNC path
- Access that file from Windows Explorer and check the permissions on it. Get the user to open the file directly in Windows Explorer – if they are able to open the file from Windows Explorer then there is a problem with file permissions.
TRIM
If you find a user is getting access to a document that they shouldn’t have access to:
- Get the user to see if they can find and open the document from their TRIM Desktop client. If they can open the document then the permissions in TRIM are incorrect.
Checking that lock strings are stored and indexed
- View the contents of the S metadata field with padre-di
- (TRIM) increase log level of GetUserKeys binary and run from command line as the user.
Increasing security debug messages
Debugging can be increased in the following ways:
- Increasing the log level on the modern UI and viewing output in the modernui.log
- Enabling -deb_security=N query processor option (this will print out lock/key comparisons, though will make some queries run extremely slowly and potentially time out).
- Increasing the log level on other components (such as the GetUserKeys.exe for TRIM)
- Checking impersonation is working