Log In Security: Unique Email Addresses Required
Barracuda RMM Service Center now requires new user accounts have a unique email address for log in, and that the email be validated.
If more than one existing user account uses the same email addresses, the holder of the accounts should log in to one of the accounts using an authentication app and change the email address as soon as possible, or delete one of the accounts if it is no longer needed.
For extra security, if a user changes the email used in their Barracuda RMM profile, that user is automatically logged out of their session. That user is required to log in again before they can use their account and will have to validate the new email address.
Log In Security: Email Validation for Existing Users
Barracuda RMM now gives admins the option to require users to validate their email address if they have not already validated. This is highly recommended because an upcoming release of Barracuda RMM requires a unique email address for each user account and for that email to be validated.
Users are also required to validate their email address if they change the email address in their user profile information. See
For information on validating emails for existing users, see To send a user a email to verify their email address in Verifying User Email Addresses.
Due to this requirement, On Premise environments must have an SMTP Server set up before new users can be created or existing users can change their email addresses.
Users who access multiple VARs
Users who access multiple VARs may be required to validate their email address for each VAR they access. A request is sent when a user who has not validated their email address modifies their user profile. When the modification is saved, that a user whose email address is not validated is logged out and must validate their email address in order to log in. The validation link is sent to their email address. Users are only required to validate their email once per VAR.
If you do not access multiple VARs, this does not apply to you.
Log In Security: Multi-Factor Authentication
For security reasons, multi-factor authentication is no longer optional for user accounts.
On the upgrade to Barracuda RMM 12 SP6, all user accounts have MFA enabled. It is no longer possible to disable MFA for any account.
By default, MFA will be set to require a code from an authentication app.
Support for Bitlocker
Barracuda RMM 12 SP6 introduces support for Microsoft’s BitLocker Drive Encryption, a data protection feature that integrates with the operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers.
Devices using BitLocker are detected automatically. If a device is using Bitlocker, a new section automatically appears on its Device Overview page. From this page, you can enable, disable, and manage the device’s BitLocker drives.
For more information, see To enable or disable BitLocker encryption on a drive and To access a BitLocker recovery key in Customizing Devices.
Automation Improvements — Support for Large Files and the File Storage Server
Barracuda RMM can now support files over 25 MB for automation applications due to the addition of the File Storage Server. The new file limit is 1 GB.
The File Storage Server is a repository for binary files used in automation:
scripts
script packages
resource files
Files are uploaded to the File Storage Server automatically, with no manual intervention by the user. Communication between the File Storage Server and Barracuda RMM is handled by the File Storage Service.
For self-hosted and hosted users, the File Storage Server requires a change to the install process. During install or upgrade, the File Storage Server installation wizard launches and guides you through the process of installing the FSS.
Users in self-hosted environments can use a local server path on install or a UNC path. If a user uses a local path, they should be aware that the File Storage Server can use a large amount of hard disk space.
Users in a hosted environment can use a UNC path.
The addition of the File Storage Server improves performance for automation tasks, particularly when large files are involved.
The addition of the File Storage Server also provides the option for users on Self-Hosted platforms to Restore Automation Binaries, which rebuilds the Automation Library if it is deleted.
For more information, see Where Automation Files are Stored in Automation Requirements.
Support for PowerShell Core in Scripting
You can now write scripts in PowerShell Core, making your scripts truly cross-platform and taking advantage of PowerShell Core’s latest features. PowerShell Core scripts require an additional line of code. See Scripting Using PowerShell Core Cross Platform in About Adding Scripts.
Previous versions of PowerShell are currently still supported.
Introduction of the REST API
This version of Barracuda RMM introduces a new API, based on the REST architecture.
The Barracuda RMM Services API is a web service that provides access to some of the data provided and collected by Barracuda RMM, including the following:
alerts
asset tags
CPU assets
devices
fixed disk assets
groups
monitor assets
network card assets
network interface assets
optical drive assets
printers
Quick Fix Engineering assets
sites
software
system assets
trouble tickets
users
VARs
video cards
The documentation of the RMM APIs is available in Swagger (https://editor.swagger.io/) format and can be found in the following location:
http://<HostName>/SCMessaging/ui/index, where<HostName>is the name of you location where your Barracuda RMM instance is hosted.
The Install SentinelOne Agent Script
The Install SentinelOne Agent script is available from the Automation Library by default. For information on the script, see the Release Notes.
User History
For this release, the following has been added to user history.
Bitlocker
A record is created when Bitlocker encryption for a drive is:
enabled
disabled
Email Validation
A record is created when:
an email with a validation link is sent to a user’s email address
a user validates their email successfully
Users
A record is created when:
a user changes their mobile phone number
a user changes their email address
Multi-Factor Authentication
Because multi-factor authentication can no longer be disabled, a user history record is no longer created when multi-factor authentication is disabled.
A record is created when:
a user completes multi-factor authentication successfully
a user changes the method of multi-factor authentication from MFA application to email or email to MFA application
For more information, see Managing User History.