Administration Guides
Understanding Search Security Results and User Login sessions
Home
Overview
This section explains how the various modes of search security are managed, and how user logon sessions are controlled. These is an important considerations before providing users access to search for indexed content.
5 security modes to secure search results:
- SMB Share Security mode:
- A user will login with AD User id and password that is verified by the PowerScale against Active Directory.
- Search & Recover cluster will retrieve the users AD groups and calculate which SMB shares the user has read or write access permissions.
- All searches for the logged in user will only return results for data at, or below the path defined by the SMB shares that they have PowerScale access.
- File Owner Security Mode:
- In this mode results are returned only if the user is listed as owner of the files, and share level permissions will Not be used to filter results returned to the user.
- Use Case: Home directories typically have 1 SMB share and many directories for each user under the SMB share path. A user owns the folder and all data within their home directory. Using File Owner Mode will ensure only data created or owned by the user will be returned in search results.
- Hybrid Security Mode:
- Enabling SMB and File Owner mode at the same time will filter data using both modes. This means group share searches for User X will only return data to User X for files they own in the group share, and will NOT return data for files owned by other users in the group share.
- SHARE ACL Mode:
- Requirements
- Requires 1.1.2 or later
- Release 1.1.5 removes the need for root user proxy to read ACL's and uses backup and restore permission on the service account. Covered in the minimum permissions guide.
- Limitations
- This feature does not behave like a file server that dynamically evaluate all folder ACL's in a file system tree. This feature only statically scans folders at one level in the file system to cache the results.
- Does not support nested folder ACL evaluation. A single level in the file system below a share will be scanned , that depth is controlled with a global varible.
- Use Case
- Group or project share space - This assumes a share for groups or projects is used and all the folders under this share have ACL's applied to determine which folder users see based on AD group ACL's applied.
- Example: For each of the shares under an indexed folder path, a list of folders that are nested under each SMB share path that is scanned to a folder depth as controlled by the ECA_AUTH_ACL_DEPTH levels deep cluster wide setting, will be scanned and AD groups and users will be evaluated to build a security view.
- Example with 1 Share:
- If the share is on /ifs/groupshares and ECA_AUTH_ACL_DEPTH has a value of 1 (the default), will enumerate the directory children of /ifs/groupshares, for example [/ifs/groupshares/groupA, /ifs/groupshares/groupB]. This is repeated for each folder under the SMB share path.
- Example with multiple shares:
- Indexed folder is /ifs/data/projects , and 3 shares exist below SMB share projectA /ifs/data/projects/projectA, SMB share projectB /ifs/data/projects/projectB and projectC /ifs/data/projects/projectC and default index depth is 1.
- Each of these shares will be scanned 1 folder depth below the share path and ACL's collected to evaluate which folders users can see.
- Key Information About ACL Mode
- This mode will evaluate share permissions first and then look at ACL user and group security applied to the file system under each SMB share path that falls under a path configured for indexing.
- The depth in the file system below share path is controlled globally and defaults to level 1 below the indexed path will be scanned for ACLs. The ACL's are used to evaluate which paths a user is allowed to see in search results. The ACL's are evaluated and cached every 1 hour by default to detect changes to the file system ACL's.
- The user must have at least read permissions to a share and to a folder ACL to get results returned.
- Deny permissions are also factored into the users search results.
- See the table below that shows expected search results depending on the ACL's applied to the SMB share, the ACL using user and group logic.
ID SMB Access Group ACL User ACL Expected Results Test Results 1 Deny <any> <any> User cannot login, or, if user has access through another share, user cannot see any search results on the ACL's share path User can login, no results are returned when searching. 2 Allow Deny Deny User can login but cannot see any search results on the share path Login is successful, no search results are returned. 3 Allow Deny Allow User can login but cannot see any search results on the share path Login is successful, no search results are returned. 4 Allow Allow Deny User can login but cannot see any search results on the share path Login is successful, no search results are returned. Login with different group user is successful, can perform search. 5 Allow Allow Allow User can login and see results All users from group can login and perform search. 6 Allow None None User can login and see results Login and search is successful with all group users. 7 Allow None Allow User can login and see results Login and search is successful. 8 Allow None Deny User can login but cannot see any search results on the share path Login is successful, no search results are returned. Login with any other user from group, no search results returned. 9 Allow Allow None User can login and see results Login and search is successful with all group users. 10 Allow Deny None User can login but cannot see any search results on the share path Login is successful with all users added on group, no search results are returned.
- Requirements
- Admin only Mode:
- This mode is global and only allows users listed on the admin list to login. See Configuration section on how to configure.
The first 4 security modes above can be configured per indexed folder.
User login Session Control
Users that login to the UI will have the AD userid and password validated, and a web token session sent to the browser. This session token will survive browser restarts. It is a signed authentication token with an expiry set by the Search cluster. The default is 12 hours. This can be changed on the cluster. NOTE: Any changes made to the cluster configuration will not be visible to end users until they logout and login again.
- ssh to the Search master node (node 1).
- Edit the config file to change the value
- vim /opt/superna/eca/eca-env-common.conf
- add the line below to set expiry time in minutes (x is minutes - replace with minutes)
- export SEARCHMW_SESSION_EXPIRATION_MINS=x
- shut down the Search cluster
- ecactl cluster down
- Then bring up the cluster
- ecactl cluster up