New Features
API: Ability to Get a User's Details Using Email Address
We have added a new API GET command to get a user's profile via their email address. The command is:
https://<instance>/tm-api/agent/<email|agent_id>?fileds=field1,field2...fieldN
Example 1 (Using Email Address):
https://acme.teramind.co/tm-api/agent/[email protected]?fileds=agent_id,first_name,last_name,department_id
Example 2 (Using Agent ID):
https://acme.teramind.co/tm-api/agent/49?fileds=first_name,last_name,department_id,email_address
If the fields variable isn't specified, the entire profile will be returned:
Improvements/Changes
Option to Enable a 2FA Trusted Device
We have added an option, Trust this device for 15 days to the 2-Factor Authentication screen. If the option is enabled, you will not be asked for a 2FA code for 15 days:
You will be able to use this option on multiple devices (each with its own time period) and for both Authenticator App and Email authentications.
2FA Enrollment Timeout
We have added a timeout feature on the 2FA enrollment screen. The user will have to set up the 2FA before this timeout expires:
The timeout value is taken from the Settings > Security > IDLE TIMEOUT field:
If the timeout is expired and the user hasn't set up the 2FA, they will be logged out. The event will be recorded in the System > System Log and the BI Reports > Audit reports as a Logout/Time left event:
Changes to the File Types Options in File Transfers Monitoring Settings
Recently, we stopped the support for .doc and .xls files for Content-sharing rules. To reflect the change, the FILE TYPES TO TRACK option on the File Transfers monitoring settings was updated:
Changes to the 2FA Verification Code Email
We have updated the 2FA verification code email to make it more concise:
Bug Fixes
Privileged Users without the Right Permission Could Edit a Policy
Due to a bug, a privileged user who didn't have the right permission could still access a policy and edit it. This is how the bug worked:
1. The user is assigned a Role (RBAC)-permission, e.g., Configure alerts setting:
2. The user is excluded from a policy by the EXCLUDE FROM POLICY option:
3. The user is able to still access that policy by going directly to the policy link (for example, https://acme.teramind.co/#/behavior-policy/edit/55).
The bug is fixed now so that the user will no longer be able to access the policy either from the Dashboard or through the direct URL.
Privileged Users would Retain Some Permissions After Being Removed from RBAC
This could happen in the following scenario:
Create a role-based access control policy and apply the Select all permissions option.
Apply the policy to an employee from their profile's RBAC tab. The user should now be able to do virtually anything like an Administrator.
Remove the RBAC permission from the user's profile. They should now be returned to a regular Employee status (i.e. no special permissions).
However, due to a bug, the user would still retain some permissions such as adding new employees, changing the Agent default settings, changing alert settings, etc.
The bug is fixed now.
RBAC Permissions not Fully Granted to a Privileged User with Department Targets
If you applied the right RBAC permission (e.g., the ability to delete agents, change agent status, etc.) to a privileged user and included a department as the target, the privileged user wouldn't be able to perform all the authorized actions to users under the department. For example, some of the batch actions (e.g., Delete/Restore/Lock/Unlock options on the Action menu) on the Employees report wouldn't work:
The bug is fixed now.
User Asked to Change Their Password when Logging In via SSO
Due to a bug, a user who had the Settings > Security > BASIC USER/PASSWORD AUTHENTICATION option disabled and the SINGLE SIGN ON AUTHENTICATION option enabled, would be asked to change their password during login:
The bug is fixed now so that:
When the BASIC USER/PASSWORD AUTHENTICATION option is enabled, users will be forced to change their password after an administrator resets it, or after the time set in the PASSWORD EXPIRY TIME (DAYS) field.
When the BASIC USER/PASSWORD AUTHENTICATION option is disabled, users will not be forced to change their password when logging in with SSO or LDAP.
2FA Modifications not Captured in the System Log/Audit Reports
Due to a bug, if the user enabled/disabled the 2FA settings, the activity wouldn't be captured in the BI Reports > Audit or the System > System Log report.
The bug is fixed now:
